[Mesa-dev] Question about implementing viewport transfer and const load in nir
Rob Clark
robdclark at gmail.com
Wed Aug 30 14:44:29 UTC 2017
On Wed, Aug 30, 2017 at 10:18 AM, Qiang Yu <yuq825 at gmail.com> wrote:
> On Wed, Aug 30, 2017 at 9:03 PM, Rob Clark <robdclark at gmail.com> wrote:
>> On Wed, Aug 30, 2017 at 3:26 AM, Qiang Yu <yuq825 at gmail.com> wrote:
>>>> btw, does lima have some way to write to memory from cmdstream (ie.
>>>> without setting up a full blown draw)? If so perhaps you could get
>>>> away with leaving some extra space at the end of your uniform buffer
>>>> that you copy driver internal uniforms into before kicking the draw?
>>> Unfortunately lima can't do this. Seems you guys all know how to
>>> "reserve space in uniform buffer", how?
>>>
>>>>
>>>> fwiw, freedreno does have driver specific uniforms, see
>>>> ir3_driver_param. Although normal uniforms (ie. non-UBO) get copied
>>>> into internal memory, so I just upload driver specific uniforms (as
>>>> needed) and immediates to the tail of the uniform memory before the
>>>> draw.
>>> So you mean freedreno will do an extra copy from the constant buffer
>>> set by set_constant_buffer to a driver allocated memory then append
>>> the driver spec uniform? If so, that can explain the trick above.
>>
>> Kind of.. it is really a copy into internal uniform memory that the
>> shaders access. Although if the uniforms were a buffer in system
>> memory and you had a way to memcpy from cmdstream synchronized with
>> draws, then that could work too. (I do similar w/ some immediates
>> too, since in some cases it avoids an extra move from immed
>> instruction in the shader.)
> lima store uniform in system memory and can't write memory in
> cmd stream, so I have to do a memcpy before draw if not use the
> constant buffer of set_constant_buffer.
>
that is a bit unfortunate.. and also means you have to create multiple
versions of uniform buffer if internal driver params change between
draws but user uniforms did not :-(
BR,
-R
More information about the mesa-dev
mailing list