[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