no_gfx Tracking Issue

[leotmp]

NOTE: If you want to attempt to implement any major feature, discuss the API with me first.

Minor:

• cmd_copy_from_texture
• Expose present modes (fifo, immediate, mailbox, ...)
• Add missing validations, add debug naming info to vulkan objects
• Named debug markers
• Shadow samplers?

Major:

• Proper cubemap, 3D textures and texture array support
• C bindings (+ other languages)
• Specialization constants
• Mesh shaders
• Opacity micromaps (as an optional feature) - I don't expect this to be that much work
• Hand-written introduction and docs
• Virtual memory and virtual textures?

Maybe (Discuss here whether we should have these features or not):

• raytracing using SBT (not ray queries) - seems kind of annoying to implement, but maybe not. Not a fan the number of new shader types this would add, but those could be separated in the same way we separate graphics vs compute shaders, so people only using the standard raster stuff can just look at Shader_Type_Graphics.
• DLSS and others - Personally not a huge fan of these, but they seem to be better than TAA at least, for antialiasing. I have no experience with any of these.

If you want any other features feel free to let me know in this thread or privately.

[Dudejoe870]

One thing I'm curious about is, why are there so few texture formats supported? Like no one-channel or two-channel textures except for EAC compressed textures. BC1, BC3, and BC7, but no BC4, BC5, BC6H? Looking at the code it also seems fairly trivial to add, so I'd like to know if there's a reason they aren't added (other than just not needed for an initial implementation), and if there isn't then I was probably going to add at least a few and make a PR

[leotmp]

No reason. As you said they should be easy to add. The compressed formats are a little more involved to test that they're working, though we already have some compressed formats working so i'd probably expect the others to also work.

[Dudejoe870]

I actually just bound an RDO BC1-7 encoder to Odin for my games asset preprocessor, so I should be able to test it. I've already added some texture formats to my local vendored version and once I test it works I can make a PR

[leotmp]

If you can test it with your setup that's great!

[Dudejoe870]

So, on my local fork I went ahead and also implemented texture arrays and cubemaps, and cubemap texture arrays, and a lot of texture formats. A lot of it is largely untested but from my small amount of research about Vulkan (setting the right flags in ImageCreateInfo, etc.) I think it should work. I changed the way the Slang API works as well because it gets very cumbersome to reimplement a wrapper of every single method a particular resource type has access to. A better approach is to just have a function that gets a resource from the heap and returns it, then you can do .Whatever() to do stuff with it. The different resource types are handled by just binding a different heap type to the same bindslot, so you can just "reinterpret" the resource as whatever you need it as. Still all of this is in my vendored fork but I could copy it out to a fork of the main repository and maybe make a draft PR. I don't know what changes would be necessary for NOSL though since I'm using Slang.