[Mesa-dev] [RFCv0 0/8] gallium: add support for NIR as alternate IR
maraeo at gmail.com
Tue Oct 20 03:49:35 PDT 2015
On Tue, Oct 20, 2015 at 3:51 AM, Rob Clark <robdclark at gmail.com> wrote:
> On Mon, Oct 19, 2015 at 8:53 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> Yes, drivers need to "dup" tokens if they want to keep them. Their
>> lifetime is the create function and that's it. st/mesa only keeps the
>> tokens for vertex shaders, because it needs for emulating some
>> features with the Draw module.
> It is something that I think would be worth revisiting, since the
> common case is that drivers have to dup the tokens to do their own
> variant mgmt.. so that seems like the better case to optimize for. I
> think the only one that isn't doing it's own variant mgmt is nouveau,
> but Ilia mentioned at some point that there where some edge cases
> where they really do need a variant.
This would add more cruft into state trackers and modules. Doing "dup"
in the driver is the easiest way to handle this.
Also, drivers should be able to release any incoming IR if they don't
need it. Including NIR. Having a requirement that some IR must be in
memory for the lifetime of shaders is just overall a bad idea.
> it would be a lot of churn to change this for the tgsi case, but I
> still think worthwhile. Either way, I think we should at least
> consider this while introducing the possibility for other IR's (since
> cloning llvm or nir, for example, would be more expensive than cloning
For more complex IRs and *if* drivers want to keep them (some really
don't), you need reference counting on the whole IR, so that state
trackers can unreference it and drivers can keep it.
More information about the mesa-dev