#Phobos - Vulkan abstraction library in Rust
1 messages · Page 3 of 1
Also, when does recreating happen? After the desc dies (due to the lifetime limit) or when its resources are dropped/changed?
on change (I stole penguin's design for my thing
)
When a draw is recorded it looks for and creates any descriptor sets it needs
So lets say I bind buffer1 a single time per frame, does it re-create the desc set that contains buffer1 periodically or does it keep alive as long as the buffer1 resource is alive?
as long as you bind the exact same resource to the exact same binding it'll live
Aight sweet exactly like my wgpu renderer as well
Ohh I see how that would work yea
So the desc set doesn't immediatly get deleted, only after N frames (where N is the desc set lifetime limit I assume?)
Yeah
And if you use it somewhere in that timeframe it’s kept alive for another N frames
Awesome
back to the basics I guess lol (rewriting the renderer in my engine https://gitlab.com/pac85/GameKernel using phobos)
Les gooo
Ooh you have Rust reflection for ECS components*
Awesome
I always tell myself I'll implement it but I never do
Yeah but after doing some things by hand enough times I forced myself to do it
Thanks!
It's a bit messy
Because it started out very simple
Hopefully I can clean that up eventually
Holy shit even a scripting language
Didn't make that myself
It's wren
But yeah with reflection I was able to generate bindings on the fly
Thank you very much!
Hopefully I can get the renderer rewritten quickly enough. The previous one was a mess but I can at least resuse all of my shaders
Yep hopefully it goes well
Yea if you don't mind me imma just yoink most of your reflection code lol
No problem! Feel free to relicense it as well
Maybe I could turn that into a separate crate
Heheheha time to work on phobos at 4 am in the morning
Lmao
@night charm I submitted PR for exposing 3D texture stuff
Thamks
we did it
idk how to fix the upside down bit 
but its works
this is normalizing the world coordinates thank to getting the vertices
so ug
how do you generate normals
yeah but what if my model doesn't have normals
🤔
oh wait this is a bunch of cross products
i think?
Yep
cross product of two edges of a triangle
oui
'Tis how I do it
noooo
smh not multithreaded
smh doesn't use compute shaders that can scale across multiple gpus to create normals
Oh yea it's CPU based sowwy
kekw it's fine lmaoo
flip projection matrix
rayon!
Yes I really should use rayon for that
Makes rust multithreading super duper easy
can you multithread uploading to the gpu?
wait no you can't
well sorta?
you just gotta submit all the commands at once
Yea I guess that would be possible. Idk how that would help though. I think GPU-GPU copy is already paralellised by the GPU itself
i say sorta that it's gpu wizardry if it wants to do that
Yea I have not had to deal with complex command stuff like that yet
personally i feed my gpu 3 scoops of raw chicken meet + water bowl to get it
now im just waiting on penguin
to add the images
in the meantime
i'm gonna multithread everything i physically can
@languid fern added some comments
Yep just noticed
Sorry that the PR taking time is my first time doing this
Les fucking gooo
That's gonna make my life much easier when dealing with 3D texture voxel data and I'm all for it
yeah
ok lets run CI and merge
yeah i gotta actually work through a bunch of them soon
ill also try to make some progress on exposing more api features
@languid fern merged
Yay
dont tell him his pr had a bug

i didnt see it either when reviewing tbh
let image_type = if extent.height == 1 && extent.depth == 1 {
vk::ImageType::TYPE_1D
} else if extent.height > 1 {
vk::ImageType::TYPE_2D
} else if extent.depth > 1 {
vk::ImageType::TYPE_3D
} else {
return Err(anyhow::anyhow!("Image extents invalid"));
}
if height > 1 and depth > 1 this will return 2D
while it should be 3D
huh i realized the examples don't have a way to access the window
yeah the example framework is kinda shit and really simple
im using it 
hmmm how to rewrite it so window is visiblde
oh god
how to do window resizinfg
Tbh the sample is not a good start to use as a beginning point for a project, I should make it better

Does phobos have a VkImageMemoryBarrier ?
I need it for mip mapping
unless there is another way
oh uh
@night charm I don't you guys added any blit functionality
yes
should be in a command hol up
Trait representing a command buffer that supports graphics commands.
This struct represents an incomplete command buffer. This is a command buffer that has not been finished yet with IncompleteCommandBuffer::finish(). Calling this method will turn it into an immutable command buffer which can then be submitted to the queue it was allocated from. See also ExecutionManager.
no idea
oh im blind that is why 
Penguin, am I hallucinating or did you do something like Material ID = depth in depth buffer in your terrain thingy
epic, I am hallucinating then
i just do normal mapped phong shading everywhere lmao
Why is it every time I try to read something Unreal does it requires unimaginable amounts of brain juice to comprehend
true
Shit sorry
I knew there had to be one there due to me coding that tate
its fine lol
I figured it out
🫡 unreal engine
@night charm Shouldn't present, color, color_attachment... etc etc only be supported for the GraphicsDomain in PassBuilder?
that seems reasonable
Also could help remove the Fails if this pass was not created using PassBuilder::render() case since it would be type checked
Yos
Ah I realized
For this to actually benefit the user we'd have to assume that all PassBuilders using the Graphics domain are going to be render passes
If you're fine with that assumption then yea it would work
But in the case of present it seems like it's not considered a render pass (unless that's a bug?)
pub fn present(name: impl Into<String>, swapchain: &VirtualResource) -> Pass<'cb, D, U, A> {
Pass {
name: name.into(),
color: None,
inputs: vec![PassResource {
usage: ResourceUsage::Present,
resource: swapchain.clone(),
stage: PipelineStage::BOTTOM_OF_PIPE,
layout: vk::ImageLayout::PRESENT_SRC_KHR,
clear_value: None,
load_op: None,
}],
outputs: vec![],
execute: EmptyPassExecutor::new_boxed(),
is_renderpass: false,
}
}
thats not a bug no
i see what you mean though yeah
i think thats a reasonable assumption
actually nevermind its not
you can have a compute pass in a frame for example, which would still use the graphics domain
Yea hmm
Cause tbh I don't like that there's that panic that could occur
It feels like it could be typed out strongly and completely erased
it just returns an Err case so it doesnt necessarily panic, but I agree
ill do some pondering
yep
right yeah
the is_renderpass flag is mostly used to emit a vkCmdBegin/EndRendering when executing the pass @languid fern
which obviously you dont need to present
big complicated words 🗣️ (what is going on)
design ponderings
O I see
more gazing into the vuk orb needed
true
Time to implement pr heheheha
This is what happens when you give summer break to a hs student with nothing to do over the summer
Too much time
MSAA resolve is a graphics only thing or can it also be executed on compute?
graphics only
Alright I'll specialize that too then
I never had to deal with SMAA before because I hate any form or type of AA
fsr2 ftw
Yos
I'm just worried that my executable size will go up (it's already at 13 mb for an empty scene, which is a lot)
Eh whatever
@night charm are you looking to make the API like fully error prone with good error / validity or is it too low level for that?
The reason why I'm asking is cause I have my engine graphics API that already does a bunch of error validation (especially when reflecting shaders) so I was wondering if I should keep those or just scrap them and rely on Phobos validation instead
Some validation is done but stuff like validation layers are still needed
Also I don’t plan to make the same guarantees as vulkano does
Phobos makes it harder to make mistakes but it’s still possible
What sort of validation do you do specifically
Please don't do expensive validation
Definitely not
I think the right approach is to make UB inexpressible with the api
But oviosuly a few asserts here and there won't hurt anything
Yeah that’s the main goal, but I don’t want to end up too much like vulkano
You can still cause validation errors, but if you do it should usually not crash everything
BTW yesterday I forgot to store the instance object and in went out of scope, then it sigsevved when it tried to allocate a buffer lol

what's wrong with Vulkano?
Vulkano does heavy validation all the time
I think I overcomplicated my validation layers a bit....
I should just assume whatever spv layout it is to always be valid ngl
Could've saved me lots of trouble
I could fix that by storing a copy of the instance inside the device
Not sure how desirable that is
Is it ref counted?
Tbh I don't care
It was my fault
I deserved that sigsev
It should at least panic or err ngl
Maybe the instance isn’t actually, but most core objects are
Its hard to check that
Mostly up to ash
If anything
Though technically safe APIs shouldn't cause this kind of crashes? But I wouldn't suggest doing anything other than marking things as unsafe
Ok so it's still pretty low level got it
But it's one of those things where preventing it is actually really hard and can't really be done without compromises
Absolutely yea
When I tried making a vulkan abstraction I was stuck trying to split up what should validation and what should be "high level" and "low level"
When I used wgpu I kinda disliked it because I did validation on top of what they already do so that's perf wasted
Wgpu has to do validation because it is meant to run in browsers I think
So security and what not
Yeah sorry
No I mean wgpu implements webgpu
And I'm like. Vulkan is THE cross platform api. If my program doesn't run on something it's not me not supporting that, is the platform not supporting my program 😎
faces reality
Yeah vulkan is meant to be cross platform but mobile vk is quite different from desktop in terms of best practices and hw support
Yeah
So making a higher level api unifying those requires compromise
Though I get the appeal of running things in browsers
And a lot of vulkan programmers don’t care about these platforms, so it would be a shame to make them use a less powerful version of the api
And clearly vulkan is not acceptable there
Yeah
Exactlyyy
If your app should run in a browser wgpu is good but that’s not always the case
Even if I wanted to care tbh I'm not restriciding myself to old vulkan + tons of workarounds because things are so broken
Fair
Like tiling GPUs are interesting
And optimizing things for it is an interesting problem
Its just not my problem 
But the other stuff that I said is not
Dealing with broken drivers is not an interesting problemn
That too
Lol
So it begins...
Big pog
At least now when I find a bug I can just literally fix it and continue devving unlike waiting for months for WGPU to fix it for all platforms
Lol
Yeah we go fast here
Yeah Phobos is small
12k lines for what it does is actually pretty darn impressive
Like if I jump to the definition of a function it's often ash code
Bro is on the grind
Vulkano is like 96k
My engine itself is at 20k kek
I might have to do a round of cleaning up internals at some point
No fucking way
wtf
Mine was 30k
Before deleting the renderer
Now idk
But I will go back up and past 30k eventually
It will be less lines with Phobos
But I'll do more stuff
I gotta keep an eye on your usage’s of the lib so I can see what needs to change
One of the things is that I want to go bindless right from the start
That should be possible now

Exactly same mentality
@night charm I have a few questions if you don't mind me asking
go ahead
ComputePipelineBuilder::persistent just makes the pipeline alive forever and it states that the same method isn't available on PipelineBuilder because they need to rebuilt constantly. What exactly a pipeline to be rebuilt?
when the render target size changes
Oh there's no way to use dynamic state for that?
its somewhat annoying because theyre closely linked to renderpasses, even with dynamic rendering theres still some state info
honestly its kind of a hack
compute pipelines typically dont rebuild unless you do shader hot reloading stuffs
so its fine to just keep them alive
Surface, Instance and PhysicalDevice are not synced but access to them should be read-only anyway so its fine
oh swapchain too
you dont need to store the swapchain though
the framemanager holds it for you
Oh sweet cool
in my project I distinguish between SharedContext and "the rest"
I see I see
Yea I'll do the same
And a final question:
Is there a reason why FrameManager's new_frame takes in a callback instead of separating it into two distinct functions: aqcuire and present?
because it relies on sync between the two
and this frame sync is the same for every application so it makes sense to handle it there imo
I see alright thank you

Uhhhhhh this looks cursed to me
fn get_buffer_usage_flags(device: &Device) -> vk::BufferUsageFlags {
let mut usage = vk::BufferUsageFlags::SHADER_DEVICE_ADDRESS
| vk::BufferUsageFlags::INDEX_BUFFER
| vk::BufferUsageFlags::INDIRECT_BUFFER
| vk::BufferUsageFlags::STORAGE_BUFFER
| vk::BufferUsageFlags::STORAGE_TEXEL_BUFFER
| vk::BufferUsageFlags::TRANSFER_DST
| vk::BufferUsageFlags::TRANSFER_SRC
| vk::BufferUsageFlags::UNIFORM_BUFFER
| vk::BufferUsageFlags::UNIFORM_TEXEL_BUFFER
| vk::BufferUsageFlags::VERTEX_BUFFER;
if device.is_extension_enabled(ExtensionID::AccelerationStructure) {
usage |= vk::BufferUsageFlags::ACCELERATION_STRUCTURE_STORAGE_KHR
| vk::BufferUsageFlags::ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_KHR;
}
if device.is_extension_enabled(ExtensionID::RayTracingPipeline) {
usage |= vk::BufferUsageFlags::SHADER_BINDING_TABLE_KHR;
}
usage
}
Is this okay for performance?
I mean if it works it works but I don't see the reason why setting all flags would be needed
Unless this is another trick of BDA where you just don't give a shit and it just somehow works out
for buffers it doesnt matter
so might as well simplify the api and remove the parameter entirely
Damn
So all that extra validation that I had in my API was pretty much useless
WGPU kept complaining about it so I wrapped it up
Still surprised how there's no perf impact
Eh good enough
yeah
I think uniform buffers could be different on nvidia
Though not sure if the flags matter for it
yeah the flags shouldnt matter
but when using them in a shader they have a fast path yes
They have tiny super fast buffers
yeah but its more of a cache not a permanent memory location afaik
so the usage flags shouldnt affect it much
With and is just memory accessed with a different instructions with goes through a dedicated read only cache afaik
yep
AFAIK they both have a dedicated cache and cbuf which is memory
I guess the driver loads the cbufs
And if it runs out of them uses the cache
I'm going to re-expose the usages (for my downstream fork for custom engine) just because I can't trust my 1050 drivers kek
I would rather do that then change my whole API and then realize that I fucked up and gotta re-expose them again
@night charm Quick question, is there a way for me to modify the subresource range of a given image?
I can't seem to change base level + base layer
which I kinda need
I actually submitted a PR for that lel
For image views you mean?
Oh then yea I submitted a PR for dat
hmm what to do until then
Yes yes it's merged
I got confused for a sec lol
Call me tripping
but
pub fn view(
&self,
create_info: ImageViewCreateInfo,
) -> Result<ImageView> {
let ImageViewCreateInfo {
aspect,
view_type,
base_mip_level,
level_count,
base_layer,
layers
} = create_info;
// TODO: Validate args
let info = vk::ImageViewCreateInfo {
s_type: vk::StructureType::IMAGE_VIEW_CREATE_INFO,
p_next: std::ptr::null(),
flags: Default::default(),
image: self.handle,
view_type,
format: self.format,
components: vk::ComponentMapping::default(),
subresource_range: vk::ImageSubresourceRange {
aspect_mask: aspect,
base_mip_level,
level_count: match level_count {
Some(count) => count,
None => self.mip_levels - base_mip_level,
},
base_array_layer: base_layer,
layer_count: match layers {
Some(count) => count,
None => self.layers - base_layer,
},
},
};
let view_handle = unsafe { self.device.create_image_view(&info, None)? };
#[cfg(feature = "log-objects")]
trace!("Created new VkImageView {view_handle:p}");
Ok(ImageView(Arc::new(ImgView {
device: self.device.clone(),
handle: view_handle,
image: self.handle,
format: self.format,
samples: self.samples,
aspect,
size: self.size,
base_level: 0,
level_count: self.mip_levels,
base_layer: 0,
layer_count: self.layers,
id: ImgView::get_new_id(),
})))
}
base_level: 0 is defaulted to zero
Oh yea bug
Most probably
When I implemented it I only changed the subresource_range values I completely forgot about ImgView kek

lets see if i can do a hack
god images are annoying asf
im getting so many flags errors 💀
why :(
but yeah
VUID-vkCmdBlitImage-dstImageLayout-00227 ] Object 0: handle = 0x26c8cceefd0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0xad2bdfa6 | vkCmdBlitImage: Layout for VkImage 0x9fde6b0000000014[Unnamed Image] is VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL but can only be VK_IMAGE_LAYOUT_GENERAL or VK_IMAGE_LAYOUT_GENERAL. The Vulkan spec states: dstImageLayout must be VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or VK_IMAGE_LAYOUT_GENERAL (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-vkCmdBlitImage-dstImageLayout-00227)
"maybe changing the flags will work" (it breaks it more)
it seems like the issue down to the fact that
base_layer isn't being set

Damn
I thought it'd at least tell you or something kek
Yea alright I'll submit a bug fix PR
as it is defaulting to zero
which would explain why i'm also getting that texture
i think there is anothe property we need too
@languid fern base_level + base_layer. Those two aren't being set whatsoever kek
Yep
I implemented that for the subresource range
But again I forgor to put it for the ImgView wrapper
forgor
"this wouldn't have gone through with test cases" 🤓
actually tests can't even help here 
well idfk what to do then. hmmmmmm disable mips then try to get normal textures working
this wouldn't have gone wrong if I didn't decide to code at 5 am
There might be a bug on lines 343-346 in image.rs due to the fact that we don't set the arguments of the created ImgView based on the given create info. https://github.com/NotAPenguin0/phobos-r...
It's such a dumb bug as well kek
@iron shadow Can you do me a favor and check if there's this when you go to the phobos-rs repo?
I hope it's a thing only locally vislbe otherwise that'd be annoying as fuck
Cool
I think we should uh
wait nvm we already are
I was gonna say avoid using hardcoded stuff and instead put it all into our structs
then expose some method that will let you straight up send the struct them without phobos doing any magic to it
Like raw VK structs?
yeah
Fyi I would rather not do this and instead expose all parameters in Phobos
Tbfh I feel like making more examples would be sufficient. Many parts of the examples don’t sufficiently cover all of phobos’ feature sets. So it’s why many small things just fall through cracks and holes
Yeah that might also be a thing
But running examples is more effort than running automated tests
Right
fixed the image view issue @iron shadow @languid fern
Awesome
im not getting any validation layer errors on my end when resizing in the samples
first time im ever using this feature lmao
You aren’t? 
no
I’ll try updating my drivers
your pc has a skill issue clearly

Isn’t Sponza on the gltf examples site?
probably somewhere in my downloads folder
@limber rapids uploading rn
i have the entire gltf sample repo cloned in my downloads apparently
it doesnt load models yet
Penguin do you have anything to compile glsl shaders?
Or do you just use glslc manually?
I see
Guess I'll make a build.rs that builds them
Then I can include_bytes the spv
i do something like that yeah
that is weird
ERROR phobos::core::debug > [VALIDATION]: VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 (2094043421): Validation Error:
[ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object 0: handle = 0x1dc6800e4d0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x7cd
0911d | vkCreateSwapchainKHR() called with imageExtent = (1748,768), which is outside the bounds returned by vkGetPhysicalDeviceSurface
CapabilitiesKHR(): currentExtent = (768,768), minImageExtent = (768,768), maxImageExtent = (768,768). The Vulkan spec states: imageExte
nt must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCa
pabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://vulkan.lunarg.com/doc/view/1.3.2
50.1/windows/1.3-extensions/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274)
I'm on a newer Vulkan version
that could be why?
this error makes no sense to me though
if you resize then minExtent/maxExtent should allow that new size
I dont think so
if it works its probably fine
Hmmm so for descriptor indexing, is it really just an array of images that you can submit to your shader?
yes
oh
well i need a way to "compress" the indices of my images for my shader glsl then
That probably doesn't make sense but like if my asset gives me something like:
0 -> Image
4 -> Image
It should go into
0 -> Image
1 -> Image
Because arrays can't have empty space between them
not the entire array needs to be bound but currently i dont support leaving gaps
descriptor indexing allows for those gaps technically but i dont recommend it
yeah sounds like a bad idea for undefined behavior
https://gitlab.com/pac85/GameKernel/-/commit/9eae73a981743c681dd77fc6f1938f68e22cb16b
let vtx_code = build_shader!{
path: "data/shaders/test/vert.glsl",
stage: "vertex",
};
Doing it with build_rs didn't work out for me because my engine is a library and I found no simple way of storing a file from build.rs and accessing it later.
This works regardless
It can be even used by the user of the engine
I don't mind anyone borrowing this, it was rather boring to write
(Some things could be improved ofc, like not using format for paths lol)
I guess I could make a separate crate
Its pretty copy pasteable I think 
Yeah lol it's not much code
Ooh yea that's definitely interesting
Btw penguin is it possible to get access to descriptor sets directly? Since you currently don't support updating them for image arrays I though I could temporarily just take my old code to do it
i actually made it fully private a few releases ago
do you need to frequently update a large array?
Well yeah you know for bindless
Question: Is support for mobile GPUs not intended at all?
yeah but do the actual images inside that array change often
not soon in any case
a lot of stuff depends on modern features and assumes dynamic rendering is available
The thing is that recreating descriptor sets that large is expensive so no matter how often it happens it just can't be done during drawing
They dont get recreated if the contents are the same
So it should only happen when you load in a new texture
Yeah but say I add a new model, so I need a new texture in the array
Sure it happens every few frames, but basically it means stuttering
Unless I did it asynchronously I guess?
You can hack around doing it asynchronously but theres probably a good argument for implementing updates for arrays at least
I think this should be simple enough to do without changing any of the public api
I suppose sync is not handled for that kind of resource right?
Great
Why?
Well the naive method of doing an update would mean youre overwriting the set while its possibly in use on the gpu
So you'd probably need to double buffer it
Yeah there are ectentions to do that "safely"
Like "nothing will explode so long as the shader is not accessing that stuff"
Right
Wait that's not safe lol
Good enough
Yeah
penguin are you still on vacation
I got back last night

Would you mind implementing this: https://github.com/EpicGames/UnrealEngine/tree/463443057fb97f1af0d2951705324ce8818d2a55/Engine/Shaders/Private/VirtualShadowMaps
plus SMRT and PCSS kthxbye

I promise it'll look good
Yeah sure give me 5 minutes
You don't need ocss
UE does raynarching through the shadow nap
ye but light leaking
Yeah looks kinda nice

My idea was using blocker info to deduce optimal cone size, ray step and clipmap distance
if blocker is big then ray step can be big
Ohh kinda like sphere tracing in ray marching?
Kinda but not kinda
I have a beautiful drawing
hold on
#1090390868449558618 message
There it is
admire my flawless drawing skills
Wait but question
How would the ray stop at the plane if the shadow depth buffer value was overwritten
Unless it's not just normal shadow mapping
You don't overwrite the shadow map
And somehow retains info about stuff that has been obstructed
Uhm I think you just need the VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT flag to do what I said
You shrimply sample the shadow and then raymarch towards the blocker
The farther away you are the less chance there is for the ray to hit the blocker
thus contact hardening
easy enough, we can already add flags to descriptor bindings
Thoug When entries are overwritten it's kinda unsafe and you need to track what could be potentially used by in flight work
Do you think that should be up to the user?
I wonder how other graphs handle this
@limber rapids #general I don't want to floos Phobos thread again 
ye true 
We can support just appending elements I guess
Mmm that's too limited
it handles the case of new textures being added
Yeah but eventually you run out of slots
Mmm
I guess we should just ask one of the many authors of render graphs what they do?
onto #1025797519550185533 we go
You can go ahead, you seem to know more about the specific requirements
👍
OK dunno if you read
But basically everything is bindless for them
And any live resource exists within the descriptor set. So long as the resource lifetime is handled correctly so is the descriptor set then I guess
That makes a lot of sense
I might have already been explained this. It doesn't sound new to me. In any case this is not how ohobos does things which is unfortunate
But not all hope is lost
I guess bindless resourced can be their own thing and work that way
So the rest of the api remains the same?
Hmm that is an interesting approach yeah
I guess I'll dive deeper into your codebase when I have time and see if I can come up with a sane way if implementing this
yeah ill do some thinking and tinkering too
Its also possible to solve the sync issue by storing a frame id in the lookup info that loops around N frames
So you implicitly n-buffer them by abusing the cache system
Mmm
BTW penguin if it makes sense for you to use descriptor buffers let me know, dunno if you read the discussion over there
yeah descriptor buffers are not out of the question
i just havent had the time to look at them properly
Really simple. You get a pointer to the raw memory with the descriptor sets and functions that tell you where and what do writ to them
Seems easy enough yeah
So your resourced store that bit of data onf offset in them
And then you just memcpy
(This is what ravd does interbslyk AFAIK, and AFAIK the extension was just valve wanting to expose this)
yeah i imagine its already done like this internally anyway
if that's the case the world will end tomorrow
whenever tomorrow is in your timezone 
it's joever
what's the issue
an unwrap error too 
that I can't help with
some phobos error that mostly is because of incorrect usage but i can't pin point why
info.layout = *self.current_set_layouts.get(index as usize).unwrap();

says it fails if it couldn't find the desciprtor set/bind
but the issue is, this isn't one of the expected errors
are you actually using the descriptor in the shader
yes i think so
the compiler will optimize out any descriptors you don't use
layout (set = 1, binding = 2) uniform texture2D texArray[];
Yes?
this is a declaration
No but are you actually accessing that array
I mean usage wise
are you using the descriptor in a way that meaningfully contributes to the output
i.e it writes something 
This could be a bug don’t get me wrong but make sure it’s not optimized out yeah
you don't
What does phobos do with descriptors from shaders?
output += 0.001 * texture(…);
okok
Generates the pipeline layout
I see
output = texture(...)
output = something else
And does it check it?
Because like it is really annoying when you comment out stuff for debugging but stuff panics
Things easily covered by vulkan validation are usually not checked again, but I know what you mean
With vulkano it was basically impossible to comment out anything
It might be reasonable to add methods for optionally binding something
e.g. bind_xxx_if_exists(…)
oh shooot i need to input samplers too i forgor
Though I guess it is illegal for vulkan to have gaps so you'd also need to bind dummy descriptor sets?
Wouldn’t work with gaps no, but if the shader only goes up to say binding 4
You can optionally bind to binding 5 and add it back later
Dunno
I don't think that's illegal
You can leave gaps in binding numbers I think yeah
ye but you need to enable robustness which is annoying
Ah set numbers, fair enough
Then you need dummy desc layouts
Welly out can have gaps in the shader, the problem is when you bind afaik
So not really a problem after all
Right you’d need to bind them one by one
Easy to work around
It is yeah
My lazy way was to bind a random ds lol, but I guess it would be wiser to keep a dummy empty ds aroundb
you can shrimply create a desc layout with no bindings for each gap in the numbers
And not bind any sets to that layout
That too
To be honest I'm reading the spec right now and I'm not entirely sure
Even easier: if the shader compiler optimizes it out then this already happens in Phobos, because then spirv-cross doesn’t report the binding at all
But at least you can definitely bind the same dummy set everywhere
I night just not be remembering and it night have been a dummy descriptor set layout
I'm trying to find the part of the spec
@iron shadow does it work now?
focus son
im trying but im too deep into rewriting the material system
@hybrid pilot you are indeed correct
But you can bind the same dummy set over and over
I'm still waiting for the moment danny realizes what I'd told him days ago about textures in RT

Weird, I'm usually wrong
I'm always wrong 
Now we need a mathematician to create a logic system where your sentence is well defined
We'll leave the proof of that system to the reader as an exercise
ye
you can't prove that math can't prove itself
which is sad
smh godel's theorem
if he didn't make that theorem we'd be proving a lot more things
Lol
what have you done.......
Also related to phobos:
Do you know exaclty which features / extensions cause renderdoc to crash
Cause if they're optional (like bda) I could just remove them in my internal fork
BDA works great in renderdoc
ray tracing is on

make sure you explicitly disable that
unless phobos has already done that
I know renderdoc doesn't do RT so it crashes when it is on
I mean when I run the app outside renderdocs it's fine
And it's not RT because I have a 1050 
hmmm
let me pull up the phobos ext
Uhh
make sure acceleration structs are off?
Don't even have support for them either lol
renderdoc moment 
Eh I'll look into it later
worst case get nsight
i basically forgotten what renderdoc looks like this point 
Yea I just really like renderdoc for debugging since I've gotten used to it
(I could put that on my resume)
RenderDoc is a million times nicer than nsight
it probably is but it doesn't support ray tracing :(
BDA is broken beyond any usefulness on Nsight
ya but im stuck with it
printf in shaders
i never knew bout it
Least cursed graphics extension
fellas
should i submit my material information i.e. albedo texture index in the descriptor
wait wrong channel

So, tomorrow I guess we can discuss with penguin how much he likes daxa's approach. It could be challenging to do it without breaking APIs which is why I'm thinking of making something that sits alongside the existing stuff
Oh yea can you like fill me in on what you guys are even talking about
I don't really understand what it is you're spying on in the first place 
Bindless. Imagine creating a resource, then just sending it's ID or address to the shader and being able to access it
Oh so like descriptor indexing basically?
Ah I see alright
I prefer when i can just implement it myself
why would Daxa's approach be better? im confused
ah it generalizes it across every resource buffer, image, etc.
yeah i like that idea
You can't because descriptor sets are managed by Phobos
Yeah
i just finished getting my bdas working and now working on bindless textures
I mean I suppose the current stuff would still work
Also this is just me saying stuff we'll see what penguin says
it would but the urge to recode it 
yeah it would sounds really nice
tbh I just want barrier management & placement by the rendergraph but i could be tripping and that is not possible 
dynamicstate3 is not available but it shouldnt enable that if it isnt
same with the rt extensions
Penguin yesterday I asked many questions about daxa. So there every resource is just an handle you pass around. Now the way resource mapping works on their render graph is that it creates and updates a uniform buffer with BDAs and indices for you. Do you think that would make sense doe Phobos?
afaik in daxa the render graph manages and allocates all resources
If we do this it’s essentially a rewrite of a lot of stuff
Idk if this would help but i camacross this
This talk was presented at Vulkanised 2023 (Feb 7-9, Munich Germany). Vulkanised is organised by the Khronos Group and is the largest event dedicated to 3D developers using the Vulkan API. The event provides a unique opportunity to bring the Vulkan developer community together to exchange ideas, solve problems and help steer the future develo...
By traverse research who made the kajiya rust rendererer.
Mmm no I'm not really proposing that. The thing is that currently Phobos has a concept of virtual resources and physical resources and a way of binding one to the other. Now with bindless there is really no such thing as binding, so the semantics of that operation in the case of daxa is sending the handles to the shader
Though I suppose that's not necessarily something we need. After all resources handled by the graph wouldn't be bindless, so I guess it would be enough for Phobos to have a way of saying "bind the bindless descriptor for images here" and then the user does whatever they want to get the handles up in the shader. Then all Phobos would have to do is expose some pool of bindless resources and keep a descriptor set up to date
Dunno let me know your thoughts
The problem there is that then the host has absolutely no knowledge of that is being used on the device so this will always allow use after free and therefore would be unsafe.
Though if use after free is already possible in Phobos I guess nobody fares anyway
those virtual resources are mostly intended for attachments and things that need sync, imo its not a problem for bindless
Yeah I get it
i think the best way to go for now is to keep it simple and figure out how to update large descriptor sets instead of recreating them
Yeah so, I guess having a BindlessPool that would contain a descriptor set. Then you can allocate Bindless<Actualimage> from it. It would automatically update the descriptor set. When they go out of scope it would free itself from the pool wgich internally keeps tack of empty slots so it can reuse them. Then the user can get indices from it and send them to a shader however they want
Sounds good?
hmm
the thing i dont like about this is how it enforces some kind of layout in the shader (you need a matching bindless descriptor set in the shader)
hmm
But the actual layout of the pool would be enforced
Like of the descriptor set itseld
Which makes sense to me though
I was thinking something like
We keep the public api the same, with bind_sampled_image_array
And then behind the scenes something like
if bindings.descriptor_count > update_treshold {
let new_set = find_unused_set_to_update(bindings);
update_set(new_set, bindings);
return new_set;
}
Mmm what would that do?
The thing is
With bind image array you always pass all of the images right?
Right
And if you have thousands or millions it won't ever work
So the descriptor set update has to happen when you create the resource
Not when you bind it
When would you have millions of textures 
(Also I'd keep the current api regardless)
Lol
But I mean if it is 4096
Just iterating them has a cost
And the whole point of bindless is not worrying about binding
Which is why you get that layout requirement
You are not managing bindings per shader
But globally
Also the only requirement is that you have an image array
Does it?
also allows for better and more seamless bindless support
Yeah
Then theres mostly just the question of how to handle resource lifetimes
e.g. what if you register a texture as a bindless texture but you then want to deallocate it
Does the bindless manager own the resources?
Or do we somehow signal this destruction
Well I think it would be easier to make it own it
That was the idea behind by Bindless<T> wrapper
why are CPUs so slow
Would definitely be easier yeah
Signaling means something else owns it but cannot use it because it could be destroyed at any point
So it's just owned with extra steps
Alright lets work out a more concrete api and see what we end up with
So is it OK if I start working on this? Usually when you actuallybdo stuff a lot more problems arise
Though I don't have a ton of times so I can't promess I'll do it quickly
Yeah, can you make a PR with a draft of the design and work on it there?
My idea was, to make sure it is actually works, to have something using it in my engine before merging anything
Sure!
Yeah, exactly
Otherwise it's all shiny and pretty but then it turns out it's not suitable for anything remotely real
The reason I'm asking for a rough outline is so its easier to figure out whats going on and help out
Just to get myself up to speed: this is about updating only textures that change inside the large bindless array, right?
Yeah sure
Yeah, and more first-class bindless support
Yeah, and also keeping a pool of resources bound at all times to when you need then "you just use them"
why "bound at all times"?
It doesnt need to be permanently bound no
ok
I misphrased it
I’m so confused what you guys talked about 
Redesigning how Phobos handles bindless
And consequently how I handle bindless 

My plan was to leave rhre what is already there
Just use Phobos ™️
Or you mean in your own thing
If you port phobos to C++ I might consider it
Yeah no need to remove it, we can deprecate it later
I love api stability
Its an improved rust port of a c++ lib I made 
Also the stuff to bind an image array could be useful for smaller image arrays
True
Like when you bind the mip chain as images
Yeah exactly
It would get worse
phobos++ 
Wait so bindless = arrays of images
I thought it was more like an array of descriptors
yeah but you cant mix descriptor types in glsl
so you need an array of images to index into
Wdym by mix?
Like reinterpret one descriptor type as another?
I see
yeah sure it is a descriptor
"descriptor" is fancy for pointer (with some metadata)
but yeah you do need an array of images for bindless usually
ye, you could also say it's an array of descriptors that contain images
Ok so if I understand correctly for bindless you need arrays of images + bda
Ok and another thing
Can you do something like this in GLSL
layout(set = 0, binding = 0, r32ui) uniform image2D textures[];
layout(set = 0, binding = 0, rg32ui) uniform image2D textures[];
layout(set = 0, binding = 0, rgba32ui) uniform image2D textures[];
So you don't have to make multiple descriptor sets for different types of images
Oh how
Can you just do something like
layout(set = 0, binding = 0) uniform image2D textures[];
``` directly?
this should work already but bindless is usually for textures nto storage images
you can alias formats like that
the way you wrote it initially
Oh okay
Yea cause I was wondering
If you're gonna do bindless from the start
Why not stick with it throughout
Unless there's a performance cost to doing such things, and doing non-bindless for some things proves to be more efficient
i find it not very useful for storage resources
mostly for readonly stuff
like textures
I'm trying to think what would require so many storage images
pretty much that yeah
GI probably
Pengiun do you think I need to create the pool type myself? I saw there is a Pool type but I don't see how ti make it do what I want
specifically Lumen-like SDFDDGI
Nono I was just wondering if it was possible that's all
DescriptorPool or the Pooled<T> stuff
In my engine I use like 3 storage textures per comp shader max
Yeah I was looking into the pooled stuff but there is no way of telling it what to do when something is returned right?
not yet but its probably not hard to add
Mmm I see
So no new types
Which makes sense because some of the logic is in place
If all the logic is there then it'd be nice to fit it in there yeah
But if not its totally fine to add new stuff
Something like a BindlessPool
I see
Thx
I'll met you know if I encounter any roadblocks in rescuing pool
Rn I can't work on it but later I should
So what's the main™️ plan for bindless at the moment?
implement some sort of caching for sampled images
Why caching
Register resources with a global bindless pool -> bind the pool when you want to use it -> this binds one descriptor set with all resource
iterating through all textures and updating the whole set at once is expensive
Makes sense
Probably more performant than iterating through all resources and caching internally
Most definitely more performant kek
I though tthat was the game plan? I got it wrong then
should be yeah
Makes sense yes
so:
create desc bindless pool
update resources when needed
bind pool
```?
Hol up
doesn't this still require updating the whole set at once? 
Or do you store "changes" as well in this bindless pool
You allocate and release stuff from and to the pool, the pool internally maintains a ds up to date
The set it's just updated every time you allocate or release
