[Mesa-dev] Status update of XvMC on R600

Corbin Simpson mostawesomedude at gmail.com
Thu Nov 11 15:34:22 PST 2010


This. I thought that, to trigger uploads, we just had to change the domain
on the buffer.

Sending from a mobile, pardon the brevity. ~ C.

On Nov 11, 2010 3:00 PM, "Jerome Glisse" <j.glisse at gmail.com> wrote:
> 2010/11/11 Keith Whitwell <keithw at vmware.com>:
>> There is still more to do there.  Currently r600g treats buffer and
texture uploads separately, and I've only attempted to improve texture
uploads.  Buffer is just as important however.
>>
>> The change needed is likely to be one of two:
>> a) Allow newly created vertex buffers to be in the GTT domain, where they
can be mapped cached.
>> b) Provide a staging resource upload path (with the staging buffer in GTT
domain).
>>
>> The latter will catch more cases and doesn't suffer from waits for the
engine to go idle when accessing an in-use buffer.  The former is probably
fastest for the cases where it works.
>>
>> Right now staged texture uploads use a 3d blit to copy from the staging
resource to the final destination.  That probably won't work (directly at
least) for buffer uploads as buffer dimensions (eg 64k by 1) mean they
usually can't be bound as render targets.  So we need to jump through some
hoops to get a hardware upload path in the absence of a DMA engine or
1d-blit.
>>
>> Keith
>
> I am not sure on how gallium texture upload was ever supposed to be or
> done, but from memory management point of view the idea i had was to
> create all bo in GTT and let migrate them to VRAM once they are use,
> eliminating any need for staging buffer. So it would be allocate bo,
> memcpy to bo the content of the texture, use bo and set it as vram bo
> so kernel migrate it to vram, that way you take advantage of kernel bo
> move which should be faster than any blit helped move.
>
> Anyway this was my initial thinking when doing the code.
>
> Cheers,
> Jerome Glisse
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20101111/199f7a82/attachment.htm>


More information about the mesa-dev mailing list