Re: DRM development process wiki page..
Dave, This process looks ok to me, but I think some clarifications are needed: Dave Airlie wrote: Okay I've put some thoughts up at: http://dri.freedesktop.org/wiki/DRMProcess and I've pasted it in below this for discussion. some other points: a) People are pushing for a process change, we will have something change, however this isn't a who shouts loudest competition, so more than likely you'll end up compromising, deal with the fact that nirvana for you may be hell for others. b) BSD developers do exist now, giving out that they didn't exist in the past or aren't adding features is pointless. Would you seriously start developing features before getting the code caught up?. So live with the fact that we should help the BSD guys *if* its practical. So we shouldn't do anything major that alienates their further development. (personally I care little for BSD, the license or the OSes, however I'm attempting to be some way fair). c) We get testers from drm master, we get better testers using drm master for features than a separate kernel tree. We get better regression tests from getting stuff upstream. However upstreaming stuff to Linus is not how to find regressions, it helps but its suboptimal in that he will eventually ignore us if the regression rate gets too high. So upstreaming is great for features like GEM, however it would suck for something like vblank-rework. This appears to point at, upstream is great if you touch one driver and exist in your own world, however if you want interfaces that all drivers can use like vbl-rework you need to work somewhere else or carry two interfaces until everyone is ported. So lets see if we can improve this for everyone... Dave. DRM Development Process (Proposed) ... 1. All patches to be sent to the mailing list with S-O-B, no patches to be committed to master branch. Nothing goes upstream or into master without Signed-off-by and maintainers Signed-off-by. 2. Do not mix cleanup and developement ever. If you move a bunch of registers or code into a separate file, do just that in one patch. 3. Backwards compat patches in separate patches. So first patch should be upstreamable, backwards compat patches should be in sequence. Let's say we rework a driver completely, including DDX, to support GEM / TTM or whatever. The driver is, in effect, a new driver and there are no intermediate versions of drm that could be of interest really, since they wouldn't work with any of the user-space clients. So no bisecting is possible. Would it be OK to treat such work as a new driver and post it as a (URL to) single patch? Upstream first policy This policy places a restriction on users of the drm, i.e. Mesa, DDX, X server. No upstream release should include code that hasn't been included in a Linux kernel release cycle. Upstream can use a --enable-experimental-kernel-api type flag but default build should never require any unreleased kernel/drm API to build or run. Distros should not enable experimental APIs in releases, unless they are willing to version their kernel and other components against each other and deal with the fallout of API changes. All userspace APIs need to be submitted to dri-devel and to the Linux kernel list, also all patches which need exports or use new non-drm kernel functionality should be reviewed by both lists. Are driver-specific IOCTL interfaces included in this? Regards, Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM development process wiki page..
On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström [EMAIL PROTECTED] wrote: Dave, This process looks ok to me, but I think some clarifications are needed: Dave Airlie wrote: Okay I've put some thoughts up at: http://dri.freedesktop.org/wiki/DRMProcess and I've pasted it in below this for discussion. some other points: a) People are pushing for a process change, we will have something change, however this isn't a who shouts loudest competition, so more than likely you'll end up compromising, deal with the fact that nirvana for you may be hell for others. b) BSD developers do exist now, giving out that they didn't exist in the past or aren't adding features is pointless. Would you seriously start developing features before getting the code caught up?. So live with the fact that we should help the BSD guys *if* its practical. So we shouldn't do anything major that alienates their further development. (personally I care little for BSD, the license or the OSes, however I'm attempting to be some way fair). c) We get testers from drm master, we get better testers using drm master for features than a separate kernel tree. We get better regression tests from getting stuff upstream. However upstreaming stuff to Linus is not how to find regressions, it helps but its suboptimal in that he will eventually ignore us if the regression rate gets too high. So upstreaming is great for features like GEM, however it would suck for something like vblank-rework. This appears to point at, upstream is great if you touch one driver and exist in your own world, however if you want interfaces that all drivers can use like vbl-rework you need to work somewhere else or carry two interfaces until everyone is ported. So lets see if we can improve this for everyone... Dave. DRM Development Process (Proposed) ... 1. All patches to be sent to the mailing list with S-O-B, no patches to be committed to master branch. Nothing goes upstream or into master without Signed-off-by and maintainers Signed-off-by. 2. Do not mix cleanup and developement ever. If you move a bunch of registers or code into a separate file, do just that in one patch. 3. Backwards compat patches in separate patches. So first patch should be upstreamable, backwards compat patches should be in sequence. Let's say we rework a driver completely, including DDX, to support GEM / TTM or whatever. The driver is, in effect, a new driver and there are no intermediate versions of drm that could be of interest really, since they wouldn't work with any of the user-space clients. So no bisecting is possible. Would it be OK to treat such work as a new driver and post it as a (URL to) single patch? Yes I'd be happy with that, of course I'd also like the development to occur in the open. If someone else were to start working on something in the open that others were working on under contract or in secret, then I'd expect the contracted group to merge to the open stuff Upstream first policy This policy places a restriction on users of the drm, i.e. Mesa, DDX, X server. No upstream release should include code that hasn't been included in a Linux kernel release cycle. Upstream can use a --enable-experimental-kernel-api type flag but default build should never require any unreleased kernel/drm API to build or run. Distros should not enable experimental APIs in releases, unless they are willing to version their kernel and other components against each other and deal with the fallout of API changes. All userspace APIs need to be submitted to dri-devel and to the Linux kernel list, also all patches which need exports or use new non-drm kernel functionality should be reviewed by both lists. Are driver-specific IOCTL interfaces included in this? Yes, any userspace API, anything we need to support for ever and ever. Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM development process wiki page..
Dave Airlie wrote: On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström [EMAIL PROTECTED] wrote: Dave, This process looks ok to me, but I think some clarifications are needed: Dave Airlie wrote: Okay I've put some thoughts up at: http://dri.freedesktop.org/wiki/DRMProcess and I've pasted it in below this for discussion. some other points: a) People are pushing for a process change, we will have something change, however this isn't a who shouts loudest competition, so more than likely you'll end up compromising, deal with the fact that nirvana for you may be hell for others. b) BSD developers do exist now, giving out that they didn't exist in the past or aren't adding features is pointless. Would you seriously start developing features before getting the code caught up?. So live with the fact that we should help the BSD guys *if* its practical. So we shouldn't do anything major that alienates their further development. (personally I care little for BSD, the license or the OSes, however I'm attempting to be some way fair). c) We get testers from drm master, we get better testers using drm master for features than a separate kernel tree. We get better regression tests from getting stuff upstream. However upstreaming stuff to Linus is not how to find regressions, it helps but its suboptimal in that he will eventually ignore us if the regression rate gets too high. So upstreaming is great for features like GEM, however it would suck for something like vblank-rework. This appears to point at, upstream is great if you touch one driver and exist in your own world, however if you want interfaces that all drivers can use like vbl-rework you need to work somewhere else or carry two interfaces until everyone is ported. So lets see if we can improve this for everyone... Dave. DRM Development Process (Proposed) ... 1. All patches to be sent to the mailing list with S-O-B, no patches to be committed to master branch. Nothing goes upstream or into master without Signed-off-by and maintainers Signed-off-by. 2. Do not mix cleanup and developement ever. If you move a bunch of registers or code into a separate file, do just that in one patch. 3. Backwards compat patches in separate patches. So first patch should be upstreamable, backwards compat patches should be in sequence. Let's say we rework a driver completely, including DDX, to support GEM / TTM or whatever. The driver is, in effect, a new driver and there are no intermediate versions of drm that could be of interest really, since they wouldn't work with any of the user-space clients. So no bisecting is possible. Would it be OK to treat such work as a new driver and post it as a (URL to) single patch? Yes I'd be happy with that, of course I'd also like the development to occur in the open. If someone else were to start working on something in the open that others were working on under contract or in secret, then I'd expect the contracted group to merge to the open stuff Yes, that sounds fair. I guess at least the very least should be a common understanding with the people actively working on the open stuff on what to keep and what not to keep. Upstream first policy This policy places a restriction on users of the drm, i.e. Mesa, DDX, X server. No upstream release should include code that hasn't been included in a Linux kernel release cycle. Upstream can use a --enable-experimental-kernel-api type flag but default build should never require any unreleased kernel/drm API to build or run. Distros should not enable experimental APIs in releases, unless they are willing to version their kernel and other components against each other and deal with the fallout of API changes. All userspace APIs need to be submitted to dri-devel and to the Linux kernel list, also all patches which need exports or use new non-drm kernel functionality should be reviewed by both lists. Are driver-specific IOCTL interfaces included in this? Yes, any userspace API, anything we need to support for ever and ever. That's really the point that this may or may not be the same thing. The old drm model placed a driver's user space interface under versioning, and any app using that interface would need to monitor the major version number to check for compatibility, although major bumps were strongly discouraged. /Thomas Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net
Re: DRM development process wiki page..
On Thu, Aug 28, 2008 at 9:32 PM, Thomas Hellström [EMAIL PROTECTED] wrote: Dave Airlie wrote: On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström [EMAIL PROTECTED] wrote: Dave, This process looks ok to me, but I think some clarifications are needed: Dave Airlie wrote: Okay I've put some thoughts up at: http://dri.freedesktop.org/wiki/DRMProcess and I've pasted it in below this for discussion. some other points: a) People are pushing for a process change, we will have something change, however this isn't a who shouts loudest competition, so more than likely you'll end up compromising, deal with the fact that nirvana for you may be hell for others. b) BSD developers do exist now, giving out that they didn't exist in the past or aren't adding features is pointless. Would you seriously start developing features before getting the code caught up?. So live with the fact that we should help the BSD guys *if* its practical. So we shouldn't do anything major that alienates their further development. (personally I care little for BSD, the license or the OSes, however I'm attempting to be some way fair). c) We get testers from drm master, we get better testers using drm master for features than a separate kernel tree. We get better regression tests from getting stuff upstream. However upstreaming stuff to Linus is not how to find regressions, it helps but its suboptimal in that he will eventually ignore us if the regression rate gets too high. So upstreaming is great for features like GEM, however it would suck for something like vblank-rework. This appears to point at, upstream is great if you touch one driver and exist in your own world, however if you want interfaces that all drivers can use like vbl-rework you need to work somewhere else or carry two interfaces until everyone is ported. So lets see if we can improve this for everyone... Dave. DRM Development Process (Proposed) ... 1. All patches to be sent to the mailing list with S-O-B, no patches to be committed to master branch. Nothing goes upstream or into master without Signed-off-by and maintainers Signed-off-by. 2. Do not mix cleanup and developement ever. If you move a bunch of registers or code into a separate file, do just that in one patch. 3. Backwards compat patches in separate patches. So first patch should be upstreamable, backwards compat patches should be in sequence. Let's say we rework a driver completely, including DDX, to support GEM / TTM or whatever. The driver is, in effect, a new driver and there are no intermediate versions of drm that could be of interest really, since they wouldn't work with any of the user-space clients. So no bisecting is possible. Would it be OK to treat such work as a new driver and post it as a (URL to) single patch? Yes I'd be happy with that, of course I'd also like the development to occur in the open. If someone else were to start working on something in the open that others were working on under contract or in secret, then I'd expect the contracted group to merge to the open stuff Yes, that sounds fair. I guess at least the very least should be a common understanding with the people actively working on the open stuff on what to keep and what not to keep. Upstream first policy This policy places a restriction on users of the drm, i.e. Mesa, DDX, X server. No upstream release should include code that hasn't been included in a Linux kernel release cycle. Upstream can use a --enable-experimental-kernel-api type flag but default build should never require any unreleased kernel/drm API to build or run. Distros should not enable experimental APIs in releases, unless they are willing to version their kernel and other components against each other and deal with the fallout of API changes. All userspace APIs need to be submitted to dri-devel and to the Linux kernel list, also all patches which need exports or use new non-drm kernel functionality should be reviewed by both lists. Are driver-specific IOCTL interfaces included in this? Yes, any userspace API, anything we need to support for ever and ever. That's really the point that this may or may not be the same thing. The old drm model placed a driver's user space interface under versioning, and any app using that interface would need to monitor the major version number to check for compatibility, although major bumps were strongly discouraged. Major bumps once stuff went into the kernel weren't allowed at all. You'd need to fork the driver in any case. So we did this once or twice on drivers in devel trees like mach64. However upstream first policy should avoid this need. I'd also prefer to see getparam for new features instead of version checks. The linear version check sucks. Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Re: DRM development process wiki page..
Major bumps once stuff went into the kernel weren't allowed at all. You'd need to fork the driver in any case. So we did this once or twice on drivers in devel trees like mach64. However upstream first policy should avoid this need. I'd also prefer to see getparam for new features instead of version checks. The linear version check sucks. This is an interesting concept that opens up some ideas for dealing with feature deprecation, etc. Think about opengl's extension mechanism -- features can be exposed through that mechanism without ever providing a guarantee of future availability -- in fact there is no guarantee of any availability outside the current session. Future versions of a GL driver might add or remove extensions as desired, within the constraints of the GL version number advertised. What we could see is something similar for the DRM interface -- a base level of functionality specified by the Major/Minor numbers, but additional extensions that may be advertised according to the whim of the kernel module that the driver can take advantage of if present, but which it must otherwise function correctly without... Extensions that don't work out can be dropped, those that do can be incorporated into the next increment of the minor number, a la GL1.5 Keith - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[GEM i945] X server eats lots of cpu after resuming from s2ram
Hi guys, since I do not quite know who is the culprit for that problem, I want to ask here first before filing a bug report. Maybe one of you has got an idea how to deal with that. The problem is as follows: Using kernel 2.6.27-rc* with the GEM extensions from Eric's drm-gem-merge branch as of today and after resuming from suspend to RAM the xserver eats up about 80% of the cpu load on my DualCore system. X.org modular is from git master as well as mesa, libdrm (branch modesetting-gem) and xf86-video-intel (master after merge of modesetting). None of the logs shows anything irregular. I am using an intel 945GM. Any recommendations how to track that behaviour? OProfile? Cheers, Johannes - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM development process wiki page..
On Thu, Aug 28, 2008 at 8:23 AM, Keith Whitwell [EMAIL PROTECTED] wrote: Major bumps once stuff went into the kernel weren't allowed at all. You'd need to fork the driver in any case. So we did this once or twice on drivers in devel trees like mach64. However upstream first policy should avoid this need. I'd also prefer to see getparam for new features instead of version checks. The linear version check sucks. This is an interesting concept that opens up some ideas for dealing with feature deprecation, etc. Think about opengl's extension mechanism -- features can be exposed through that mechanism without ever providing a guarantee of future availability -- in fact there is no guarantee of any availability outside the current session. Future versions of a GL driver might add or remove extensions as desired, within the constraints of the GL version number advertised. What we could see is something similar for the DRM interface -- a base level of functionality specified by the Major/Minor numbers, but additional extensions that may be advertised according to the whim of the kernel module that the driver can take advantage of if present, but which it must otherwise function correctly without... Yep, it works a lot better to advertise the features available directly rather than just exposing an incrementing version number. This is how I redid the DRI driver interface - everything is an extension that may or may not be exposed by the driver. I would suggest to use a hybrid where we advertise individual features as suggested, but also version them. For example, if we find out that GEM needs another domain bit or something, it's nicer to be able to advertise GEM version 1.1 rather than GEM and GEM_WITH_THAT_NEW_DOMAIN_BIT. cheers, Kristian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM development process wiki page..
Keith Whitwell wrote: Major bumps once stuff went into the kernel weren't allowed at all. You'd need to fork the driver in any case. So we did this once or twice on drivers in devel trees like mach64. However upstream first policy should avoid this need. I'd also prefer to see getparam for new features instead of version checks. The linear version check sucks. This is an interesting concept that opens up some ideas for dealing with feature deprecation, etc. Think about opengl's extension mechanism -- features can be exposed through that mechanism without ever providing a guarantee of future availability -- in fact there is no guarantee of any availability outside the current session. Future versions of a GL driver might add or remove extensions as desired, within the constraints of the GL version number advertised. Would you want to have the ioctl numbers dynamically allocated, like the event and error bases in the xserver? Otherwise you could run out of them if you statically allocate numbers for extensions which are then later removed. Or would you rather create a single entry point for the extension commands and the multiplex everything through that? Also, you'll have to distinguish between extensions supported by the kernel and userspace (like GLX server and client side extensions), and provide drm_get_proc_address() to get the userspace library entry points. I think the extension mechanism that OpenGL/GLX uses is much better then simple linear versioning. If the userspace code is properly written, you can deprecate and remove extensions without breaking anything (at worst the driver will simply refuse to work, but no crashes etc). No more 5 years waiting to remove old features - take that Linus! :) tom - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
