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
