Alex Deucher wrote: > On Feb 13, 2008 9:09 PM, Keith Packard <[EMAIL PROTECTED]> wrote: >> On Wed, 2008-02-13 at 19:22 -0500, Alex Deucher wrote: >> >>> How about a "compat" node for old clients and a "new" render node that >>> handles both new clients and GPGPU? Then the backwards compat stuff >>> could just be a shim layer and everything else could use the same code >>> instead of dealing with separate render and gpgpu nodes. >> Recall that one of the goals is to support multiple user sessions >> running at the same time, so we really do want to have per-session >> 'devices' which relate the collection of applications running within >> that session and reflect the access permissions of the various objects >> and methods within that session. >> >> Any 'compat' node would eventually have to deal with this new >> environment, and I'm not sure it's entirely practical, nor do I think it >> entirely necessary. >> >> As for GPGPU usage, that would presumably look an awful lot like a >> separate session, although I can imagine there being further limits on >> precisely which operations a GPGPU application could perform. > > I guess I just don't see a difference between X/DRI rendering and > GPGPU; it's just command submission. It seems like the only reason > for the render/gpgpu split is for backwards compatibility. I think we > need to differentiate between display and rendering rather than > "visual" rendering and compute applications.
Yes, though maybe GPGPU is just a convenient phrase for 'rendering facility divorced from display'. I'm not sure. There are real cases where you want to render images yet never have an interest in display - for example scientific visualization and gpu-accelerated offline rendering. From the point of view of the DRM, these should fall into the same bucket as GPGPU. Keith ------------------------------------------------------------------------- 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
