Any idea if we can wrap legacy DRI users in a separate 'rendering
context' so that you can run old and new X servers/DRI clients in
different sessions? I'm thinking the exclusive nature will make some
application compatibility
harder (app 'Q' runs only on old DRI, app 'R'
runs only on new
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
On Wed, Feb 13, 2008 at 5:22 PM, Stephane Marchesin
[EMAIL PROTECTED] 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
Hi guys,
Keith Packard escreveu:
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
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
On Wednesday, February 13, 2008 1:28 am Dave Airlie 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
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
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
On Wed, Feb 13, 2008 at 11:22:10PM +0100, Stephane Marchesin wrote:
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.
Er, you mean
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,
On Feb 13, 2008 4:28 AM, 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
On Wednesday, February 13, 2008 3:55 pm Stephane Marchesin wrote:
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
On 2/14/08, Jesse Barnes [EMAIL PROTECTED] wrote:
On Wednesday, February 13, 2008 3:55 pm Stephane Marchesin wrote:
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
On 2/14/08, Stephane Marchesin [EMAIL PROTECTED] wrote:
I don't know if it interferes, but I also can't see how your proposal deals
with this case. Can you provide more details? Just saying a BO has scanout
permission isn't sufficient either, since CRTC-output mappings are
important too
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
Okay please Shift-reload :0
http://dri.freedesktop.org/wiki/DRMRedesign
nice new picture and new text to go with it..
This is mostly from talking to marcheu and jbarnes and krh at
various points today, no code yet :)
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied /
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
On Thu, 2008-02-14 at 01:50 -0500, Alex Deucher wrote:
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
On Thu, 2008-02-14 at 06:46 +, Dave Airlie wrote:
Okay please Shift-reload :0
http://dri.freedesktop.org/wiki/DRMRedesign
nice new picture and new text to go with it..
Any idea if we can wrap legacy DRI users in a separate 'rendering
context' so that you can run old and new X
19 matches
Mail list logo
