-
Notifications
You must be signed in to change notification settings - Fork 50
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Duttenheim
force-pushed
the
new_materials_rt
branch
from
February 26, 2024 12:58
b3a763d
to
d3a4e0a
Compare
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.
…comes first) before submission
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
force-pushed
the
new_materials_rt
branch
from
February 26, 2024 14:33
5f238c1
to
966d15f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.