[Mesa-dev] [PATCH 1/4] r600g, radeonsi: force VRAM placement for DRI2 buffers

Marek Olšák maraeo at gmail.com
Fri Feb 7 04:30:59 PST 2014


On Fri, Feb 7, 2014 at 3:55 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On Mon, 2014-02-03 at 18:07 +0100, Marek Olšák wrote:
>> Do you mean something like:
>>
>> write_domains = VRAM
>> read_domains = VRAM | GTT
>>
>> I don't think it's perfect.
>
> That's what I meant, and of course it's not perfect. :)
>
>
>> We should treat rendering by an app and blitting by u_blitter (=
>> texture transfers) differently. We don't want u_blitter to mess up our
>> idea about which textures are used as a framebuffer, because once
>> u_blitter comes into play, everything can be a framebuffer.
>>
>> I've got the following idea:
>>
>> 1) Set the domain to VRAM | GTT by default for all buffers and textures.
>> 2) In set_framebuffer_state, if u_blitter isn't blitting, do this to
>> the domains of all renderbuffers: if (domains & VRAM) domains &= ~GTT;
>
> Interesting idea.
>
>
>> That said, I'm not too excited about this. Allowing more stuff to be
>> moved to GTT will have an adverse effect on performance. Being more
>> aggressive and trying to put more stuff in VRAM should almost always
>> be better if you can avoid buffer ping-ponging.
>
> The above should avoid BO ping pong in some cases, but it may indeed
> also cause some BOs to stay in GTT when it would be better for them to
> be in VRAM.
>
>
>> I have been messing with the domains since ever and what we have now
>> seems to work best. It's not perfect, but I have already tried all the
>> other options and they weren't better.
>
> What metrics did you use to determine that?

Just some tests. For example, Reaction Quake frame rate increased 4
times by changing relocations from VRAM|GTT to VRAM. It also caused
buffer ping-ponging for other apps.

I guess I'll try my idea described above.

Marek


More information about the mesa-dev mailing list