OpenBSD Journal

c2k15: jsg@ on graphics work: Mesa, xenocara, drm, libGL

Contributed by pitrh on 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 ( 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 possible.

Thanks for the report and all the work, Jonathan!

(Comments are closed)


Copyright © - Daniel Hartmeier. 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 as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]