https://bugs.freedesktop.org/show_bug.cgi?id=79223
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #18 from Pierre Ossman ---
(In reply to comment #17)
>
> glReadPixels is currently always synchronous with all Gallium based drivers,
> as there's no hardware acceleration for PBOs yet.
>
Hmm... But I'm not consistently seeing a de
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #17 from Michel D?nzer ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > Down to dri2_drawable_get_buffers() now. I assume I'll be hitting a point
> > > where I'll have to switch over to loo
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #16 from Pierre Ossman ---
Right now it feels like a lot of the blame falls on xbmc. But at the same time,
this works on nouveau and presumably the proprietary drivers.
I guess the behaviour that xbmc is expecting is that the only ti
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #15 from Pierre Ossman ---
Ok, I took a step back and decided to look at this at a higher level again. A
single wait for vsync can't be causing problems, and there has to be at least
two. So I set out to find the other one. And I thin
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #14 from Pierre Ossman ---
(In reply to comment #13)
> (In reply to comment #9)
> > No effect I'm afraid. Since this is a full screen application I assume it
> > was already using flipping and not blitting anyway?
>
> Probably. For t
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #13 from Michel D?nzer ---
(In reply to comment #9)
> No effect I'm afraid. Since this is a full screen application I assume it
> was already using flipping and not blitting anyway?
Probably. For the sake of testing, have you tried d
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #12 from Pierre Ossman ---
More digging. Down to dri2_drawable_get_buffers() now. I assume I'll be hitting
a point where I'll have to switch over to looking in the X server soon...
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #11 from Pierre Ossman ---
Pinpointed it further to:
FLUSH_VERTICES(ctx, _NEW_PROGRAM | _NEW_PROGRAM_CONSTANTS);
But that's enough for tonight. Will have to resume this another day.
--
You are receiving this mail because:
Y
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #10 from Pierre Ossman ---
Ok, some kind of progress. The call that is causing the delay now is
glUseProgram(0);. It grows gradually from no latency up to 17 ms (i.e. one
frame @ 60 Hz). Then it goes back down again and the cycle repe
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #9 from Pierre Ossman ---
(In reply to comment #8)
> The vsynced blit path for presentation is implemented by *stalling* GPU
> command processing. That's a big hammer, and might be related to your
> problems. You can skip this (at the
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #8 from Grigori Goronzy ---
The vsynced blit path for presentation is implemented by *stalling* GPU command
processing. That's a big hammer, and might be related to your problems. You can
skip this (at the cost of tearing in some case
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #7 from Pierre Ossman ---
Anyhoo, getting back to the matter at hand.
I set up a new machine so I can more easily do debugging of this. The hardware
is instead:
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/AT
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #6 from Pierre Ossman ---
(In reply to comment #5)
> (In reply to comment #4)
> > I'm also seeing something else waiting for vsync. With glReadPixels() out of
> > the picture, and glXSwapIntervalMESA(0), I'm still getting 60 fps and n
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #5 from Michel D?nzer ---
(In reply to comment #4)
> I'm also seeing something else waiting for vsync. With glReadPixels() out of
> the picture, and glXSwapIntervalMESA(0), I'm still getting 60 fps and no
> tearing. Possibly related?
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #4 from Pierre Ossman ---
Any appropriate tracing tools for this?
I'm also seeing something else waiting for vsync. With glReadPixels() out of
the picture, and glXSwapIntervalMESA(0), I'm still getting 60 fps and no
tearing. Possibl
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #3 from Michel D?nzer ---
I'd try to narrow down where exactly in glReadPixels the delay is incurred.
Either using some profiling / tracing tool, or just by adding printfs with
timestamps in strategic places.
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #2 from Pierre Ossman ---
Ok, so it is glReadPixels() that is waiting for vsync. I added some
measurements around that call and it is definitely where the delay happens.
For good measure I removed the mapping (step 2) and the extra r
https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #1 from Pierre Ossman ---
Hardware and software info:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks
PRO [Radeon HD 6570/7570/8550]
mesa-libGL-10.1.3-1.20140509.fc20.x86_64
kernel-3.14.4-200.fc20.x86
19 matches
Mail list logo
