On Fri, Feb 2, 2018 at 11:39 PM, Marek Olšák <mar...@gmail.com> wrote: > 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.
The CAP is only a formality. In reality, we only have to fix vl_compositor.c to use pipe_context::const_uploader::flags (or the CAP) and that's it. All other code we care about is unaffected (GL, VDPAU, VAAPI, OpenMax, Nine). There are no users binding a real buffer as constant buffer 0 other than VL and XA. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
