On 2/13/08, Jesse Barnes <[EMAIL PROTECTED]> wrote: > On Wednesday, February 13, 2008 2:22 pm Stephane Marchesin wrote: > > On 2/13/08, Dave Airlie <[EMAIL PROTECTED]> wrote: > > > So I've been thinking about this stuff a lot lately wrt to getting the > > > DRM into a state that enables fast-user-switching, GPGPU apps, > > > different users on a per head one a single card.. > > > > > > http://dri.freedesktop.org/wiki/DRMRedesign > > > > > > has a nice picture and some notes.. either comment direct on the webpage, > > > or reply here.. > > > > > > A lot of the code heading in this direction just got merged into > > > modesetting-101, it should in theory all be backwards compat in the > > > single render/master case... > > > > Hi, > > > > So basically, you'd expose multiple /dev entries for a single piece of > > hardware. As I said on irc, this would be like exposing /dev/sda1_ext2 > > and /dev/sda1_xfs and ... which obviously doesn't scale long-term. > > > > Lets forget about the concept of "master" for a moment. In a case > > where the concept of "master" does not exist, an application that can > > draw to screen (formerly "master") would simply be one that has a > > scanout BO and is using it. > > > > So here is the point: with the current work on enforcing proper > > permissions on BOs (including scanout BOs), is a separate device > > really needed ? The reason for doing this device separation in the > > first place basically comes down to enforcing those permissions > > properly in a per-app fashion. The same effect could be achieved by > > enforcing the policy on BO creation instead of device opening. > > IIRC, the reason we came up with this was to deal with CRTC<->output mapping, > not for BO permissions so much (doing proper perms there still requires a lot > of work). > > You don't want any application to be able to change CRTC<->output mappings, or > bind BOs to CRTCs. Ideally you'd just have one app that could do that on a > given system, and it would contain the distribution's policy regarding output > cloning, hotplug actions, etc.
I don't see how that interferes with the solution I propose ? I'm not discussing policy but where to store the policy. The existence of one client being able to scanout at a time is ovbious in any case. > > So the master/slave concept is really more analogous to pty master & slave > nodes than it is to your /dev/sda_ext3 example. You open the master node, > ask for a specific mapping, and if you have permission, a slave node will be > created that you can do what you like with... > Yeah, probably my analogy is far from perfect. Since people seem to concentrate on the analogy instead of the point, let me state the point. My point is that exposing different uses for a device should not be exposed through separate /dev entries. GPGPU is obviously a very recent trend. Will we have to add new /dev entries for future trends as well, and how future proof is that ? Obviously other (binary) drivers do fine without thanks to more flexible interfaces. I still wonder what suddenly mandates the addition of a GPGPU-specific device node to DRM, can't we be flexible instead ? Stephane ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
