On Sat, Feb 3, 2018 at 2:55 AM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 03.02.2018 um 00:31 schrieb Marek Olšák: >> On Sat, Feb 3, 2018 at 12:01 AM, Roland Scheidegger <srol...@vmware.com> >> wrote: >>> Am 02.02.2018 um 23:39 schrieb Marek Olšák: >>>> 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. >>> >>> That seems to be quite limited, why can't you have a shader ABI which >>> can do either 32 or 64 bit pointers? >> >> Good questions. GCN shaders have only 16 dwords of constant memory >> (GFX9 has 32). There are no shader resource slots and the pixel shader >> is the only one to have real inputs. All other stages don't have any >> shader inputs except for system values. >> >> The 16 dwords contain pointers and states to load inputs and load >> descriptions of resource slots from memory. One of the pointers >> sometimes points to constant buffer 0. If it's a VS, there are only 13 >> dwords, because 3 are reserved for baseinstance, basevertex, and >> drawID. We can also put some other data into that constant memory to >> skip load instructions. There is a huge incentive to free those >> precious dwords and use them for something else, like skipping some >> load instructions. I've been also considering 16-bit pointers (e.g. >> 32-bit pointers aligned to 64KB). >> > > Ok, so for other buffers you can't really do anything special? You just > go through a pointer to array-of-pointer lookup?
By default, the shader gets a pointer that points to a merged list of constant buffer and shader buffer descriptions in memory. If a shader only uses constant buffer 0 and no shader buffers, that pointer points to constant buffer 0 directly. > I thought "proper" apps would just use UBOs for everything these days > (hence nothing really much need for tuning slot 0). But maybe that's not > actually true... I can see that you'd want to optimize usage of this > precious space. I suppose GL doesn't give you much help there with its > iffy buffer handling. Yes, games use UBOs. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
