Are these shaders located in an assetbundle? Can you compare the shader assetbundle size of a build where the geometry shows up and where it’s missing?
Hey everyone! Excited to dig deeper into this feature. However, when I enable it, my editor crashes. Sometimes when hitting play mode, sometimes when working in the editor. I just worked for hours without a crash with GPU drawer turned off, and as soon as I enabled it, I got two crashes. Bug #IN-75529
This is very annoying 23.3 once worked fine for me but now the editor crashes over and over again when it is turned on. Is there some quick fix that we don’t think about but it works?
I have not tried it yet, but maybe use a new set of project settings that does not include the changes for GPU Driven Rendering?
I have noticed that the crash happens when some shader is recompiling. Or immediately after it recompiles.
Sometimes it happens right after launching a scene. (I assume again because some shader compiles.)
Opening the project again in a non Unity 6 version, (i.e. 2023.2) fixes the issue, however you have to jump through a few hoops because some packages are not unloading properly.
i.e.in some cases HDRP 17 persists along with version 16 in some weird way. They are both installed simultaneously and can’t be removed but only manualy.
I reported a bug too along with some others. Was quite weird.
Like the objects disappeared. Only the terrain was showing and that under conditions. Eventually that disappeared too.
Hi all! Have you tried the Unity6 GPU Resident Drawer? I did! and I found WORSE performance than before! I wonder what im doing wrong or if my case is not supported.
[quote=“morfevs, post:250, topic: 930675, username:morfevs”]
Hi all! Have you tried the Unity6 GPU Resident Drawer? I did! and I found WORSE performance than before! I wonder what im doing wrong or if my case is not supported.
[/quote]This GPU Occlusion culling implementation uses an additional pass, which ends up adding more draw calls than anything else from what I’ve seen so far, so you should probably disable it (failing to see the point of it, to be honest). Also if you have any, make sure your custom shaders use DOTS Instancing. Even then, your mileage will vary depending on the renderers in your scene (only MeshRenderers are supported) and the amount of instancing they’re capable of, among other things. Batches using GPU Resident Drawer should have the “Hybrid Batch Group” label in the Frame Debugger.
Hopefully the Burst Occlusion Culling system on the roadmap is gonna be the actual answer to Umbra’s shortcomings, among other things. :copium:
Now I need a function similar to TransformAccessiArray, let’s call it “RenderAccessiArray” in order to use the JobsSystem high-performance switch display
This is a performance analysis of 100000 mobile cubes. For moving entities, it looks quite poor, and the performance bottleneck lies in three aspects: IJobParallelForTransform, UpdateRenderBoundingVolumes,
And GpuResidentDrawer
Can we opt into the new GPU Occlusion Culling? Say I have a compute shader for collecting instance data. Is there a shader function available to us that we can just call with the bounds or whatnot to see if those are occluded?
Hi. is GPU Rendering Driven better or GPU Instancer (Asset)? what could be the difference? or for a scene with open-world foliage which one could be better? Which one do you suggest?
It seems like GPU Resident Drawer actually makes performance much worse in our use case. This is on a Revit model of a Stadium.
Static Batching is ON and GPU Occlusion Culling is ON.
GPURD ON
GPURD OFF
I’m not sure why the batching becomes zero when it’s turned on, but it does not offer any benefits. It seems like it is kind of behind the scenes actually turning off features which are helping performance? I thought we would see at least a 20% improvement based on what I’ve read about GPURD.
What’s weirder is that GPU Occlusion Culling is ON and I’m just looking at the wall of the stadium, so there’s no reason to be rendering thousands of smaller structural members on the inside, and yet perf behaves like it is.
I’m assuming that this model is like CAD models. I don’t think the system is suitable for this scenario where there are tons of unique mesh because it’s instance rendering.
We run it through a pipeline that converts it into glTF. It detects mesh duplicates and reuses the mesh for those instances, so there’s definitely some room for it to work, and definitely room for occlusion culling to make huge improvements.
But, I do agree it’s not as simple as their test cases using mostly copies of a few objects. I just don’t quite understand why perf is actually worse.