OpenBSD Journal

g2k14: Jonathan Gray on driver improvements for X

Contributed by tbert on from the closing-holes-by-closing-apertures dept.

Jonathan Gray (jsg@) writes in to let us know why he spent 30 hours in coach to be with us:

One of the first things I did at g2k14 was import the Mesa update I've been working on for some time now. I've been tracking the Mesa git for a few months and submitting patches to reduce the amount of pain involved and given the local diff isn't too large anymore it seemed like a decent time to update. Shortly before the hackathon I ran into a problem getting Mesa to build on i386 however. It turns out there is an i386 only codepath that does a sysctl to check if SSE is enabled. This turned out to be a problem because sysctl.h pulls in uvm_extern.h which then pulls in a bunch of kernel headers including mutex.h which meant that Mesa's mtx_init() collided with the kernel's mtx_init(). Theo spent some time cleaning up the sysctl and uvm headers so they wouldn't include anywhere near as many definitions, and that work had already been committed when I arrived at the hackathon.

The following day I did some xenocara builds to try and catch any additional problems. The problem I found was due to a symlink in the Mesa dist file that cvs import ignores, which was fixed by pointing the Makefiles to a different directory. I also double checked that LLVM enabled Mesa builds worked still worked via the LLVMpipe software renderer. Another problem the Mesa builds showed is that sys.mk the Makefile that gets automatically included by make adds CFLAGS to CXXFLAGS. As Mesa is a mixture of C that assumes C99 and C++ code, g++ ends up complaining that it gets the C specific -std=c99 flag passed to it. A diff to correct this in the system Makefiles and a few other places will be mailed out in future.

I also looked into getting the src tree to build with OPENSSL_NO_DEPRECATED defined which in most cases involved adding includes that are not automatically pulled in by other includes anymore. For some things like nginx that are externally maintained there are patches already available in future versions that we'll eventually pick up so it doesn't seem worthwhile patching our version just yet when there are still other places in the tree (libkeynote/bind/sendmail etc) that need changes made. I also had a quick look at compiling with OPENSSL_NO_SSL_INTERN but after seeing how dc and gzsig broke when building I decided to look elsewhere.

I looked into updating some clang patches I've had lurking around for a few years and committed some things relating to that.

Xorg can now run without having to grant userland direct access to a window of kernel/device memory if kernel modesetting (KMS) is supported. The problem being other devices still need access to this window to run Xorg. The installer asks a question if it finds a vga device that enables the window via the machdep.allowaperture sysctl. After a discussion with a few people at g2k14 I created some small scripts to extract PCI vendor/product numbers from the radeondrm and inteldrm drivers which are used by the pci attachment of the vga driver to print a line to dmesg if the window will be needed to run Xorg. The installer has been modified by halex@ and rpe@ to check for this line and will only ask if the person installing intends to run X11 (which enables the window) if it is found. The X11 question will not be asked on many servers now as there is a blacklist of graphics devices commonly found in servers in the code that decides whether the aperture is needed.

A problem I've run into a few times now is the lack of a cpuid.h header which is provided by gcc >= 4.3 and clang to provide an interface to calling cpuid on i386 and amd64. Mesa git now requires cpuid.h to build. The Intel Xorg driver disables codepaths involved in deciding if SSE is present and making decisions based on cache sizes if it missing. And at least some ports (ie OpenXCOM) seem to expect it now. So I've taken the cpuid.h from clang to include in our version of GCC 4.2.1. Initially I changed the SSE_4_1 and SSE_4_2 definitions to SSE_41 and SSE42 to match the names used by GCC but likely both definitions will be included when this gets committed.

Many thanks to the OpenBSD Foundation and Mitja for making g2k14 possible.

(Comments are closed)


Comments
  1. By Marc Espie (espie) espie@nerim.net on

    There was also some fallout from the update in ports. Since you don't talk about it, it seems you don't even notice.

    Think about it: there was an upstream from you aware from your work. Theo fixed issues with uvm so that the MESA update did work.

    But the MESA update broke a few things, which added to the number of ports we (naddy, sthen, I, matthieu, landry) had to fix, along with the libressl stuff, which *fortunately for us*, Bob et al gave us forewarning about.

    Just a hint for the next time...

    Comments
    1. By Jonathan Gray (210.15.216.215) on

      > There was also some fallout from the update in ports. Since you don't talk about it, it seems you don't even notice.
      >
      > Think about it: there was an upstream from you aware from your work. Theo fixed issues with uvm so that the MESA update did work.
      >
      > But the MESA update broke a few things, which added to the number of ports we (naddy, sthen, I, matthieu, landry) had to fix, along with the libressl stuff, which *fortunately for us*, Bob et al gave us forewarning about.
      >
      > Just a hint for the next time...

      The patches and xenocara builds were available since the end of June along with a request for people to test them. I was waiting to receive testing reports from the GNOME crowd but gave up and did fresh installs to test that GNOME3 worked, along with all the other hardware specific checks.

      I also saw no issue with chrome or various other ports. The only fallout I saw was the adding of gbm to the egl pkg-config file which no one actually talked to me about.

      I don't see any reason why a ports bulk build couldn't have been done before import if there were concerns from the ports side. If an invitation to do so is required that can happen for the next update.

    2. By Cabal (Cabal) Maybe Cabal on https://lobste.rs/

      Seems like this could have been better addressed over email.

Credits

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 deadly.org 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.]