[Intel-gfx] Page flipping not working as expected for compositing - engineering resource available to help fix it
Simon Farnsworth
simon.farnsworth at onelan.com
Fri May 7 15:07:47 CEST 2010
Hello,
We're using Intel GPUs and Linux in our digital signage players, and hitting
problems with getting OpenGL compositing to be tear-free. My understanding is
that we need to be fairly close to the bleeding edge to get this working, and
that the Fedora 12 packages aren't good enough.
I've therefore built a kernel and X stack from git, using the following
components on top of a Fedora 12 installation, but I'm not getting the
behaviour I'd expect:
* drm-intel-next kernel from
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git branch drm-
intel-next
as of e15831656778d032f3c7655949f8cc3997f2b04a
* util-macros-1.7.0 from the tarball at
http://ftp.x.org/pub/individual/util/util-macros-1.7.0.tar.bz2
* dri2proto from
git://anongit.freedesktop.org/xorg/proto/dri2proto branch master
as of c34ce137fdb21fc9a52bb8d5a0c25e3c5d79e687
* libdrm from
git://anongit.freedesktop.org/mesa/drm branch master
as of 6293152eb065016a2e5e4fcd047c2db5c2fb0f36
* mesa from
git://anongit.freedesktop.org/mesa/mesa branch master
as of f58d780b08a7059b82707291ad163cf6590134df
* xserver from
git://anongit.freedesktop.org/xorg/xserver branch master
as of 72758287f79a4f1aa8fa388f20947042e3e14693
* xf86-video-intel from
git://anongit.freedesktop.org/xorg/driver/xf86-video-intel branch master
as of 8562b7bc6740eef2602af76b8685388efd2d4d37
The kernel appears to induce out of range signals on my display, which is one
bug - am I using the correct kernel tree here? I can, however, test the
userspace stack against the F12 kernel, which appears to have enough
pageflipping support to tell me that I'm on the right lines.
When I run my test program in direct rendering mode, I see a steady 60 fps;
unfortunately, it appears that I can't use that for my compositing, as
GLX_EXT_texture_from_pixmap doesn't function when I'm direct rendering (the
resulting textures have no contents, so my compositing code draws white
rectangles).
I've attached my test program (it's based on our C++ OpenGL compositor, but
cut down to just test OpenGL pageflipping) as performance.c, and my test X
stack's Xorg.0.log after one run of "performance -indirect" (which ran for 573
frames). I'm using a 32-bit PAE kernel - I can add information as required,
and I'm happy to run tests or experiments for people.
I therefore have two questions:
1) Am I using the right kernel tree for page flipping? If not, what should I
use? I'm quite git-happy, so if the answer is "this tree with these bits
merged in and these patches on top", that's fine.
2) How should I go about fixing compositing? Should I fix indirect rendering to
use pageflipping (and if so, where do I start looking for the code that's
getting it wrong), or should I make TFP work when direct rendering (and again,
where should I start looking)?
I have a mild personal preference for making TFP work when direct rendering -
but this is because perf on my test program suggests that I gain from using
vertex buffers objects (it appears that i965_dri.so implements glDrawArrays
with a temporary VBO if I'm not using VBOs), and AIGLX doesn't support VBOs.
Our management sees this as a high priority, so both myself and my colleagues
are able to drop what we're doing to work on this during office hours (10am to
6pm BST); we have C coding experience, and have contributed patches before, so
we're happy to dive into the code and debug if that's what's needed - some
idea of where to start looking would be really helpful.
Any advice will be gratefully received.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: performance.c
Type: text/x-csrc
Size: 4975 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100507/8cc1b805/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 27670 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100507/8cc1b805/attachment.bin>
More information about the Intel-gfx
mailing list