on 13/05/2012 00:39 Konstantin Belousov said the following: > With r235375, all required VM support for new Intel GPU driver was > committed into HEAD. There are still some things to improve and > change, but now the all.14.9.patch does not touch anything outside agp > or drm. This allows to start the process of importing the new Intel > GPU driver into HEAD. > > I am writing this as initial head-up and to discuss some questions, > for which I do have answers but would prefer to have additional > feedback from people doing Xorg work. > > The patch as-is just replaces the Intel DRI1 bits with DRI2 > driver. Patch added most of the KMS infrastructure into DRM > core. Also, patch completely changed the locking model used by Intel > driver. I made absolutely minimal efforts needed to keep other DRI1 > drivers compilable. Despite that, I got several surpising reports that > Radeon DRI1 still works. > > That said, for import I can (first choice) just apply the patch, > replacing the Intel driver with new one. Or (second choice) I may > create another directory, say sys/dev/drm2, and import _only_ Intel > driver together with updated DRM core, there. > > The positive points to the second approach is that we still have older > kernel drivers around. Also, I have more freedom in changing the DRM > core, without fearing breakage in the DRI1 land. Since I do not really > want to deal with Gen2-3 hardware, and VGA console does not work with > new driver (yet), there are definite advantages. > > On the other hand, driver automatic loading will not work with > dev/drm2 approach. New driver have to use different module name to > co-exist with dri1 driver, so ddx driver cannot load new driver by old > name. As result, users need to manually kldload new driver before > starting Xorg. > > My own preference is to implement second choice and put the driver > into dev/drm2. I think that I would prefer this path too for the reasons you already mentioned above: - potential problems for other drivers - need to easily fallback for those who use the intel driver and may run into problems with the new code - some missing bits related to kms like syscons support, which makes troubleshooting harder BTW, I think that we should patch xf86-video-intel port to try loading "i915kms"/"i915gem"/... if i915 is not available. I think that that should be fine for a FreeBSD-specific patch. Alternatively, we could keep the same names for drivers/modules and then have a global knob (WITH_DRM2/WITH_KMS/etc) to select which source is code is used to build the drivers. Finally, thank you very much for this work! Looking forward to having it in the tree. -- Andriy GaponReceived on Mon May 14 2012 - 09:31:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:26 UTC