o3de/Pass at development - o3de - Gitea: DaWig's Git

You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

History

santorac 029bf03870 Changed PassBuilder's job dependencies to be OrderOnce. Using a normal job dependency was overkill. As a result, modifying a shader would trigger a pass to rebuild, and that would cause the entire render pipeline to reinitialize. This causes a lot of unnecessary churn that made debugging shader hot reloads difficult. When a builder depends on knowing the UUID of another asset, it does need to have a job dependency on that asset. But when the builder doesn’t actually consume any data from inside the asset, and it just needs the ID, it is best to use JobDependencyType::OrderOnce to simply make sure the AP knows about the asset. Also, the call to GetSourceInfoBySourcePath was an unnecessary check because the AP does not require the file to exist at the time a dependency is reported. GetSourceInfoBySourcePath will only succeed after the AP has scanned the requested source file. We can’t just assume that a false result indicates the file does not exist, it just isn’t known yet. There are a couple additional use cases to be aware of (from @antonmic)... 1. Passes are critical assets, and some passes depend on shaders, so those shaders need to be processed, that's one reason for the dependency (otherwise you can start the engine, load all critical passes, try to load the shader, shader isn't ready, and bad things happen) 2. If a shader is deleted/removed, the pass should try to rebuild and fail. This was a recent issue that I fixed, you could have some odd condition where you delete a shader, but the pass that references that shader doesn't update or throw any errors because it doesn't rebuild, so the user is unaware that they need to change the .pass file and bad things happen OrderOnce is sufficient for both these cases. #1 is related to first time processing which exactly the time when OrderOnce would be applied. I tested #2 as well; deleting a .shader file with OrderOnce dependency did trigger the .pass file to rebuild and fail. Testing: Ran an ASV pass test with both an exiting cache and after deleting the local cache. Started the Editor with a clean cache and didn't encounter any startup issues. Was able to successfully load a level the first time. Deleted SkyBox.shader and saw SkyBox.pass fail in the AP. Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>	4 years ago
..
PassBuilder.cpp	Changed PassBuilder's job dependencies to be OrderOnce.	4 years ago
PassBuilder.h	Making pass files declare dependency on shader files (part 01)	4 years ago

santorac 029bf03870 Changed PassBuilder's job dependencies to be OrderOnce.

Using a normal job dependency was overkill. As a result, modifying a shader would trigger a pass to rebuild, and that would cause the entire render pipeline to reinitialize. This causes a lot of unnecessary churn that made debugging shader hot reloads difficult.

When a builder depends on knowing the UUID of another asset, it does need to have a job dependency on that asset. But when the builder doesn’t actually consume any data from inside the asset, and it just needs the ID, it is best to use JobDependencyType::OrderOnce to simply make sure the AP knows about the asset.

Also, the call to GetSourceInfoBySourcePath was an unnecessary check because the AP does not require the file to exist at the time a dependency is reported. GetSourceInfoBySourcePath will only succeed after the AP has scanned the requested source file. We can’t just assume that a false result indicates the file does not exist, it just isn’t known yet.

There are a couple additional use cases to be aware of (from @antonmic)...
1. Passes are critical assets, and some passes depend on shaders, so those shaders need to be processed, that's one reason for the dependency (otherwise you can start the engine, load all critical passes, try to load the shader, shader isn't ready, and bad things happen)
2. If a shader is deleted/removed, the pass should try to rebuild and fail. This was a recent issue that I fixed, you could have some odd condition where you delete a shader, but the pass that references that shader doesn't update or throw any errors because it doesn't rebuild, so the user is unaware that they need to change the .pass file and bad things happen

OrderOnce is sufficient for both these cases. #1 is related to first time processing which exactly the time when OrderOnce would be applied. I tested #2 as well; deleting a .shader file with OrderOnce dependency did trigger the .pass file to rebuild and fail.

Testing:
Ran an ASV pass test with both an exiting cache and after deleting the local cache.
Started the Editor with a clean cache and didn't encounter any startup issues. Was able to successfully load a level the first time.
Deleted SkyBox.shader and saw SkyBox.pass fail in the AP.

Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>

PassBuilder.cpp

Changed PassBuilder's job dependencies to be OrderOnce.

PassBuilder.h

Making pass files declare dependency on shader files (part 01)