lol I understand how to share memory. I was just saying we don't have an automatic system based on graph dependencies.
There is one particular case I’m thinking of where because of deep seated legacy code, it was generating 1000s of commands (past caring about nodes at this point in the frame) and generating transitions was reaching 2-digit ms.
-
-
Of course, we had other issues for this example and having a chance to compile/reuse the frame might not be the best answer, but it would certainly have been one of the easier ones.
-
In the end, 1000s of these commands “squashed” into basically 1 node of “work” and it generated few transitions. The process of optimizing was expensive tho. Had we had a better API years ago, we probably wouldn’t have had the issue. Collateral damage of a changing codebase.
Keskustelun loppu
Uusi keskustelu -
-
-
You shouldn’t have barriers inside your render passes. Output order is guaranteed by ROPs. Are you mixing compute + dependent draws at single call granularity? Better to do compute setup tasks first. Then one barrier and draw the whole render pass (1000+ draws) with no barriers.
-
Also if you do upload (from CPU). Do not track uploads at one draw call granularity (fences between draws). This would be very bad for GPU utilization.
Keskustelun loppu
Uusi keskustelu -
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.