[Mesa-dev] [PATCH 1/2] i965: Don't bother trying to extend the current vertex buffers.

Kenneth Graunke kenneth at whitecape.org
Mon Oct 29 11:07:39 PDT 2012


On 10/29/2012 09:21 AM, Eric Anholt wrote:
> Kenneth Graunke <kenneth at whitecape.org> writes:
>
>> This essentially reverts the following:
>>
>>    commit c625aa19cb53ed27f91bfd16fea6ea727e9a5bbd
>>    Author: Chris Wilson <chris at chris-wilson.co.uk>
>>    Date:   Fri Feb 18 10:37:43 2011 +0000
>>
>>        intel: extend current vertex buffers
>>
>> While working on optimizing an upcoming Steam title, I broke this code.
>> Eric expressed his doubts about this optimization, and noted that the
>> original commit offered no performance data.
>>
>> I ran before and after benchmarks on Xonotic and Citybench, and found
>> that this code made no difference.  So, remove it to reduce complexity
>> and make future work simpler.
>
> I think both of those are VBO-only, so I don't think they would show
> anything.  The way I think this path could work is if you're doing
> interleaved upload.  Openarena would be an example of that.

I just ran OpenArena..."No difference proven at 95.0% confidence."

> That said, while I'd like numbers, I dislike this code even more.  When
> the code was written, iirc the kernel was doing a spinlocked lookup per
> relocation to find the target buffer, and that's what the optimization
> was trying to avoid.  Now, the lookups are done once into a temporary
> chaining hash table and that's used in the relocations.  So I would
> expect that, even if this code mattered back then, it matters less now,
> to the point of hopefully being unnecessary.
>
> If the kernel is still too expensive, I think there are things we could
> do in the kernel to improve lookup in general.
>
> Reviewed-by: Eric Anholt <eric at anholt.net>


More information about the mesa-dev mailing list