[Mesa-dev] Question about implementing viewport transfer and const load in nir
kenneth at whitecape.org
Mon Aug 28 04:51:16 UTC 2017
On Saturday, August 26, 2017 6:40:14 AM PDT Qiang Yu wrote:
> Hi guys,
> When working on lima gp compiler, I come across two problems about
> inserting extra uniform
> and instructions in nir for the driver and don't know where's the
> right place to do it. So I'd like
> to hear your opinion and if there's other driver already did so.
> 1. viewport transfer
> lima gp needs embed viewport transfer into vertex shader, so need to
> insert a uniform which
> holds the scale and transfer and some instruction to apply the
> calculation to the gl_Position
> varying output. If do this in driver callback create_vs_state(), seems
> won't affect the state
> tracker to allocate uniform space for it, maybe add something in
The best way to handle this is probably to use the statevars mechanism.
Extend src/mesa/program/prog_statevars.[ch] with new STATE_VIEWPORT_*
enum values, and populate it with the viewport values you need from the
Then, you can just refer to special built-in uniforms in NIR. See how
nir_lower_wpos_ytransform.c does this, for example.
> 2. const load
> lima gp needs const be loaded just as uniform, so I have to allocate
> uniform space for them.
> Besides the same problem as 1 (where to do it), the const node may be
> eliminated after driver
> nir optimization and won't have a base filed as uniform.
Not sure what to recommend here. It might be best to handle it as part
of your compiler backend. Or, perhaps late in the process, you could
convert load_const into load_uniform intrinsics. You can decide on the
constant buffer layout yourself, and just set the driver locations / load
> Seems some of these (space allocation) need be done in non-driver
> layer and some (instruction
> insertion and uniform base assign to const) can be done in driver.
> BTW. lima gp can only have one uniform buffer, so I can't just use a
> dedicated uniform buffer
> for viewport transfer and const uniform.
Makes sense. That shouldn't be a problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the mesa-dev