On Fri, Feb 2, 2018 at 10:26 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 02.02.2018 um 21:48 schrieb Marek Olšák: >> Hi, >> >> This is the second and hopefully final version of 32-bit pointer >> support for radeonsi. >> >> Constant buffer 0 now has restrictions on which buffers can be set >> in that slot. >> >> I plan to push this when my LLVM patch lands in 6.0 (hopefully it >> will be accepted there). >> >> There will also be a dependency on new libdrm (not included in this >> series). >> >> Please review. >> > > From a api cleanliness point of view, I don't like this much. > First, you're making the hack case the default and even require it. IMHO > a driver should be able to bind ordinary UBOs to all buffer slots. This > is really not a nice burden to put on state trackers to do something > special for just slot 0. The gallium API should stay reasonable imho, > that's a bit too much custom tailoring for GL for my liking. > > Maybe I'm missing something but I can't quite see why you can't handle > this transparently inside the driver. Can't you just create a different > shader depending on what kind of buffer is bound or what's the problem? > (You wouldn't expect it to change therefore you should not have to > recompile.)
We don't recompile shaders in the vast majority of cases. When shader compilation stalls rendering, the gaming experience is destroyed. There is no alternative. Our shader ABI will be set up such that it only has 32-bit pointers in shader registers. There are performance-related reasons for that. We'll handle maintenance and testing of this feature. You won't have to do anything. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
