On 10/29/2012 09:21 AM, Eric Anholt wrote:
Kenneth Graunke <[email protected]> writes:
This essentially reverts the following:
commit c625aa19cb53ed27f91bfd16fea6ea727e9a5bbd
Author: Chris Wilson <[email protected]>
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 <[email protected]>
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
