Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New material setup for raytracing #208

Merged
merged 53 commits into from
Feb 26, 2024
Merged

New material setup for raytracing #208

merged 53 commits into from
Feb 26, 2024

Conversation

Duttenheim
Copy link
Contributor

No description provided.

@Duttenheim Duttenheim self-assigned this Feb 26, 2024
This changes move the ray tracing shaders out of syswork to their constituent code folders. There has been some changes in the CMake scripts for this to work, mainly with how shaders are located and output.
We want all the materials on the GPU, so we need a new material system to do so.
Material 'signatures' are handled CPU side instead of being purely content driven. Requires a bit of extra work if one wants a new material, but gives full control over materials passed to the GPU.
Resource loading is seeing a small but significant change in transfer operations not waiting or being waited for. This is to be coupled with better sparse handling, enabling us to have growing GPU buffers work in tandem with transfer operations.
Sparse buffers have been implemented.
The shader compiler doesn't make any folder assumptions at all. The CMake script takes care of providing proper paths to the shader compiler, but explicitly groups shaders in work under render/res/shaders.
All engine shaders ends up in a folder named system_shaders. This is to avoid other projects compiling shaders with equal names overwriting engine shaders.
Shader folder hierarchy is traversed and each level of folders are output to both the .fbx and the headers in order to avoid file collisions.
Allow for multiple json files to be merged into one single source file at the end. This allows extensions of materials in an easy manner.
Add legacy material for the MaterialParams struct we have already in Nebula. Easier to transition using it.
Replace material load code with new compile time version.
Make generators create untabbed files.
…shader instead of having it defined entirely dynamic.

Makes it easier to find uniform binding slots. 64 spaces should be enough.
Also fix shader server looking for shared.fxb, which has been moved to system_shaders/shared.fxb
Instead of providing arrays and dictionaries, it should suffice to use a 64 bit mask to describe each binding per set. Obviously this limits the size of our sets, but 64 bindings should definitely suffice.
TODO: When resizing arrays, we don't initialize all new values to 0, this causes some of the binding masks to get borked. Have to fix this.
…ted bits and skip the streaming step altogether.

This method is a bit brute force and can technically fail, so there should be some mechanism to delay mips that were not loaded if this happens, even for immediate resources.

Alternatively, immediate resources can allocate an intermediate buffer. That might actually be more stable.
Also added a resize with default value constructors for Array
This will spam quite a lot, so we should find some other way of finding batches which has no material associated with it instead.
Allow for resources to be immediately loaded if immediate is used.
Add another submission type for handovers, so graphics don't have to wait for transfers in the same frame.
Batches not corresponding to any material template will be flagged as useless.
Make material compiler build all the varibles and per-pass bindings as statics, such that we can access them directly in the code. One example of using this is the LightContext when setting up an area light.

It also keeps all the data in static memory, which might be better cache-wise than saving them directly in dictionaries.
Instead, just setup the entire raytracing pipeline from the shader modules found in each shader program provided.
This changes move the ray tracing shaders out of syswork to their constituent code folders. There has been some changes in the CMake scripts for this to work, mainly with how shaders are located and output.
@Duttenheim Duttenheim merged commit 3efd952 into master Feb 26, 2024
4 checks passed
@Duttenheim Duttenheim deleted the new_materials_rt branch February 26, 2024 14:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant