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. Alex ------------------------------------------------------------------------- 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
