Haven't looked in detail at the patch, but I'm pretty sure that this
goes into the right direction.
Christian.
Am 08.10.2013 23:53, schrieb Marek Olšák:
Sorry, I didn't realize this. You are right. My bad. Regardless of my
comment, I still wonder what people's opinion on this patch is.
Marek
On Tue, Oct 8, 2013 at 11:28 PM, Fredrik Höglund <fred...@kde.org> wrote:
On Tuesday 08 October 2013, Marek Olšák wrote:
From: Marek Olšák <marek.ol...@amd.com>
This was horribly, horribly broken. The limit was 1024 fences created
from the start of the application and as you probably know, pipe fences are
not reusable. If you wanted to use one fence per frame, you could only do
that for 1024 frames, whish was pretty bad. The error message "too many
concurrent fences" was misleading.
Not true. r600g has a pool of 1024 internal fences, and when a pipe_fence
is deleted, the internal fence is returned to the pool so it can be reused.
If you see that error message, it really means that the application or the
state tracker has created 1024 fences without waiting on them or
deleting them. Note that calling glClientWaitSync() or quering the state
of a signalled sync object also causes the state tracker to delete the fence.
This is not an objection to the patch, but I don't believe the ultimate cause
of the problem is the r600g implementation.
Fredrik
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
