[Mesa-dev] Status update of XvMC on R600

Alex Deucher alexdeucher at gmail.com
Thu Nov 11 08:17:22 PST 2010


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.
>

The drm bo blit code can be used as a reference. it supports arbitrary
sizes and offsets using loops and scissors.
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/radeon/r600_blit_kms.c;h=8362974ef41ac9eac713f1e66377661aa7106c0b;hb=refs/heads/drm-next

Alex

> Keith
> ________________________________________
> From: mesa-dev-bounces+keithw=vmware.com at lists.freedesktop.org [mesa-dev-bounces+keithw=vmware.com at lists.freedesktop.org] On Behalf Of Alex Deucher [alexdeucher at gmail.com]
> Sent: Thursday, November 11, 2010 3:25 PM
> To: Christian König
> Cc: mesa-dev at lists.freedesktop.org
> Subject: Re: [Mesa-dev] Status update of XvMC on R600
>
> 2010/11/11 Christian König <deathsimple at vodafone.de>:
>> Am Mittwoch, den 10.11.2010, 15:30 -0500 schrieb Younes Manton:
>>> In the meantime, I suggest you check if your vertex buffers are in
>>> sytem memory (preferably at least WC-ed if not cached); I don't recall
>>> spending that much time in gen_block_verts in Nouveau.
>>
>> Looks like your suspicions about the vertex buffer not being in system
>> memory were right. Even if I move every single calculation from
>> gen_block_verts into the vertex shader the cpu time spend in this
>> function doesn't goes below ~35%.
>>
>> I also doesn't understand why it's only gen_block_verts and not
>> gen_macroblock_verts. Probably because most blocks are only intra
>> blocks, but we will see if this changes when I manage to implement
>> proper buffer usage modes into r600g.
>>
>
> FWIW, Keithw committed a bunch of r600g usage fixes last week.
>
> Alex
>
>> Christian.
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


More information about the mesa-dev mailing list