J
Jean-Sébastien Pédron
Guest
The DRM update patch is now ready for review and testing.
As you can see, the patch is huge and I don’t expect a deep review of it. When I started to work on this, I tried to import some bits here and there. But I ended up porting every DRM files from Linux 3.8 from scratch. Many symbols were renamed (structure names, members, variables, etc.), functions were reordered or moved between files, new helpers and macros were added. The end-result is that the diff with Linux is greatly reduced.
Changes are mostly under-the-hood; the most important ones are described below. Beside a couple Radeon PCI IDs, drivers are largely untouched. Don’t expect Haswell support or Radeon power management in this patch for instance.
I think the two changes which could cause stability issues are:
Now, the new things! First, support for the setmaster/dropmaster ioctls was introduced. A master is the application controlling the video device. The most common master is the X.Org server. Those ioctls allows masters to tell when they no longer use the video device so another master can use it. This can be used to run two X.Org servers for instance: when a user vt-switch, the currently displayed X.Org server drops its master privilege, allowing the second server to become the master.
The other new feature is the support for minor devices. Historically, a video device is accessed through /dev/dri/card0 for instance. As shown in the previous paragraph, if two masters compete for the same device, only one is allowed to execute commands on the video device. It could make sense for two X.Org servers. It is less than ideal if you want to run multiple OpenCL programs. Minor devices where introduced to present several /dev entries for a given video device. With this patch, you will see /dev/dri/card0 and /dev/dri/controlD64. The second dev entry is not used currently. When we update the drivers to a more recent Linux version and gain support for render nodes, another minor device will appear: /dev/dri/renderD128. Render nodes are used to grant applications such as computation programs a limited access to the video device. The X.Org server remains the master application, and an OpenCL program can use the video card without having to ask anything to the server. It doesn’t even need a running server. But this feature is not for now: we need to update the drivers first.
Continue reading...
As you can see, the patch is huge and I don’t expect a deep review of it. When I started to work on this, I tried to import some bits here and there. But I ended up porting every DRM files from Linux 3.8 from scratch. Many symbols were renamed (structure names, members, variables, etc.), functions were reordered or moved between files, new helpers and macros were added. The end-result is that the diff with Linux is greatly reduced.
Changes are mostly under-the-hood; the most important ones are described below. Beside a couple Radeon PCI IDs, drivers are largely untouched. Don’t expect Haswell support or Radeon power management in this patch for instance.
I think the two changes which could cause stability issues are:
- A new lock, global to the DRM subsystem, was introduced. This one exists in Linux for a long time, but was not used in the original port of DRM: it was replaced by the lock protecting accesses to the structure representing a device. This incompatible change required us to sometimes unlock/relock the device lock to avoid recursion. Now that the global DRM lock is restored, we may have issues in some places where the device is now missing.
- Return values were hopefully sanitized. On Linux, they return negative integers to indicate an error code. In FreeBSD, we do the opposite. The original DRM port modified many places to use positive integers. I restored negative integers to reduce the diff. Now, integers are converted from/to positive integers only when they come from a FreeBSD API or when they are returned to other FreeBSD subsystems. I reviewed every return values to make sure we use the proper sign, but I’m sure there are bugs in this area.
Now, the new things! First, support for the setmaster/dropmaster ioctls was introduced. A master is the application controlling the video device. The most common master is the X.Org server. Those ioctls allows masters to tell when they no longer use the video device so another master can use it. This can be used to run two X.Org servers for instance: when a user vt-switch, the currently displayed X.Org server drops its master privilege, allowing the second server to become the master.
The other new feature is the support for minor devices. Historically, a video device is accessed through /dev/dri/card0 for instance. As shown in the previous paragraph, if two masters compete for the same device, only one is allowed to execute commands on the video device. It could make sense for two X.Org servers. It is less than ideal if you want to run multiple OpenCL programs. Minor devices where introduced to present several /dev entries for a given video device. With this patch, you will see /dev/dri/card0 and /dev/dri/controlD64. The second dev entry is not used currently. When we update the drivers to a more recent Linux version and gain support for render nodes, another minor device will appear: /dev/dri/renderD128. Render nodes are used to grant applications such as computation programs a limited access to the video device. The X.Org server remains the master application, and an OpenCL program can use the video card without having to ask anything to the server. It doesn’t even need a running server. But this feature is not for now: we need to update the drivers first.
Continue reading...