c2k15: jsg@ on graphics work: Mesa, xenocara, drm, libGL
Contributed by pitrh on Tue Jul 28 18:09:22 2015 (GMT)
from the are these spikes real? dept.
The next c2k15 hackathon report comes from Jonathan Gray (jsg@), who got a lot done this time:
During c2k15 I mostly focussed on some of the userland parts of graphics
support, Mesa which implements the OpenGL library and libdrm the library
which abstracts/wraps drm ioctls sent to the kernel.
I initially set about trying to test how usable the development
version of Mesa was, which meant updating the libdrm code to the
latest version (2.4.62). Libdrm and Mesa are part of OpenBSD's xenocara
repository for X.Org and related components, which must be able to build
self contained without using any ports. As a result of this requirement
we maintain our own build systems for libdrm and Mesa as after they
switched to autotools they both required GNU make, python and assumed
Linux style library versioning. One of the people currently involved
upstream with both projects is Emil Velikov, who has been very helpful
in getting the GNU specific parts removed and including generated files
in the release tarballs. While this time libdrm was updated keeping
our build system, I looked into moving to the autotools build system,
moving back to separate drm headers for userland and kernel and
cleaned up/submitted some of the local patches.
It turns out somewhere after Mesa 10.4 running even simple libGL
programs like glxgears results in solid black application windows
with the i965 driver on at least Ironlake hardware. The software
renderer doesn't seem to be affected. Currently OpenBSD uses
Mesa 10.2.9, Mesa 10.4 was briefly in the xenocara tree before being
backed out due to problems with GPU compositing with chromium and
particular Radeon hardware. Ideally the version of Mesa in xenocara
would switch to using the autotools build system as well. With Emil's
proposed patch series to remove use of a lot of the GNU extensions and
some local changes it should be possible if the regression in the master
branch could be found and fixed. So I spent some time trying to track
down the regression(s?) without much luck. The 10.5 and 10.6 branches
briefly show a black screen but then segfault
(https://bugs.freedesktop.org/show_bug.cgi?id=91399). It is hard
to binary search through changes in the repository as there has
always been a need for additional patches to get things to build.
I also dusted off and committed a diff to handle the interrupt
controller on Exynos chips not being at the offsets from PERIPHBASE
the code expected and enabled building the exynos code by default
to help bmercer@ with his chromebook wrangling.
In the background to all this I ran clang svn, cppcheck and afl but
didn't find all that much this time around. I ran afl for the better
part of a day against mandoc without any crashes at all, though
Ingo suggested some different things to try for next time.
Many thanks to everyone who organised, hosted and made the hackathon
Thanks for the report and all the work, Jonathan!
<< c2k15: rzalamena@ on mpw(4), network MP safety | Reply | Flattened | Expanded | c2k15: sashan@ on SMP pf progress >>
Add Story |
Copyright © 2004-2008
All rights reserved.
Articles and comments are copyright their respective authors,
submission implies license to publish on this web site.
Contents of the archive prior to April 2nd 2004 as well as images
and HTML templates were copied from the fabulous original
Jim's kind permission.
Some icons from slashdot.org
used with permission from Kathleen.
This journal runs as CGI with
on OpenBSD, the
source code is
Search engine is ht://Dig.
undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]