USB graphics devices from displaylink does not have 3D hardware. To get 3D effects (compiz, GNOME 3, KWin, OpenGL apps etc) with these device in Linux the native (primary) GPU can be used to provide hardware acceleration. All the graphics operation is done using the native (primary) GPU and the end result is taken and send to the displaylink device. Can this be achieved? If so is it possible to implement a generic framework so that any device (USB, thunderbolt or any new technology) can use this just by implementing device specific (compression and) data transport? I am not sure this is the correct mailing list.
Thanks, Prasanna Kumar
On Mon, May 30, 2011 at 1:30 PM, PRASANNA KUMAR prasanna_tsm_kumar@yahoo.co.in wrote:
USB graphics devices from displaylink does not have 3D hardware. To get 3D effects (compiz, GNOME 3, KWin, OpenGL apps etc) with these device in Linux the native (primary) GPU can be used to provide hardware acceleration. All the graphics operation is done using the native (primary) GPU and the end result is taken and send to the displaylink device. Can this be achieved? If so is it possible to implement a generic framework so that any device (USB, thunderbolt or any new technology) can use this just by implementing device specific (compression and) data transport? I am not sure this is the correct mailing list.
The window system needs support for splitting rendering and display. In X these are currently tied together. The only real obstacle is fixing this in X. However, this is a lot of work. Dave Airlie has started working on this, but it's not really usable yet. See: http://airlied.livejournal.com/71734.html http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvlayer
Alex
The window system needs support for splitting rendering and display. In X these are currently tied together. The only real obstacle is fixing this in X. However, this is a lot of work. Dave Airlie has started working on this, but it's not really usable yet. See: http://airlied.livejournal.com/71734.html http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvlayer
In the windows world it basically works by 'borrowing' the real graphics card for rendering and then doing the damage list/compression/uplink.
So its basically a *very* strange CRTC/scanout. To most intents and purposes plugging one into an i915 say is an extra i915 head, and indeed you can sensibly display the same scanout buffer on both real and link heads.
Alan
On 03-06-2011 00:16, Alan Cox wrote:
The window system needs support for splitting rendering and display. In X these are currently tied together. The only real obstacle is fixing this in X. However, this is a lot of work. Dave Airlie has started working on this, but it's not really usable yet. See: http://airlied.livejournal.com/71734.html http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvlayer
In the windows world it basically works by 'borrowing' the real graphics card for rendering and then doing the damage list/compression/uplink.
So its basically a *very* strange CRTC/scanout. To most intents and purposes plugging one into an i915 say is an extra i915 head, and indeed you can sensibly display the same scanout buffer on both real and link heads.
Alan
Why not tell X that DisplayLink device connected is a monitor (like connecting a projector) so that Intel driver will take care of all the 3D support (at least for Compiz) and video acceleration, only mode setting and data transfer from memory can be taken care by a DisplayLink driver. This may be a **very** bad way of implementing and may be hypothetical but if there is a possibility it will dramatically improve multi monitor support in X. I guess "Rotate and Resize" extensions can be supported easily if such a thing is implemented.
On Fri, Jun 3, 2011 at 5:00 AM, Prasanna Kumar T S M prasanna_tsm_kumar@yahoo.co.in wrote:
On 03-06-2011 00:16, Alan Cox wrote:
The window system needs support for splitting rendering and display. In X these are currently tied together. The only real obstacle is fixing this in X. However, this is a lot of work. Dave Airlie has started working on this, but it's not really usable yet. See: http://airlied.livejournal.com/71734.html http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvlayer
In the windows world it basically works by 'borrowing' the real graphics card for rendering and then doing the damage list/compression/uplink.
So its basically a *very* strange CRTC/scanout. To most intents and purposes plugging one into an i915 say is an extra i915 head, and indeed you can sensibly display the same scanout buffer on both real and link heads.
Alan
Why not tell X that DisplayLink device connected is a monitor (like connecting a projector) so that Intel driver will take care of all the 3D support (at least for Compiz) and video acceleration, only mode setting and data transfer from memory can be taken care by a DisplayLink driver. This may be a **very** bad way of implementing and may be hypothetical but if there is a possibility it will dramatically improve multi monitor support in X. I guess "Rotate and Resize" extensions can be supported easily if such a thing is implemented.
Patches welcome. It's still a lot of work.
Alex
On Mon, May 30, 2011 at 12:30 PM, PRASANNA KUMAR prasanna_tsm_kumar@yahoo.co.in wrote:
USB graphics devices from displaylink does not have 3D hardware. To get 3D effects (compiz, GNOME 3, KWin, OpenGL apps etc) with these device in Linux the native (primary) GPU can be used to provide hardware acceleration. All the graphics operation is done using the native (primary) GPU and the end result is taken and send to the displaylink device. Can this be achieved? If so is it possible to implement a generic framework so that any device (USB, thunderbolt or any new technology) can use this just by implementing device specific (compression and) data transport? I am not sure this is the correct mailing list.
fwiw, this situation is not too far different from the SoC world. For example, there are multiple ARM SoC's that share the same IMG/PowerVR core or ARM/mali 3d core, but each have their own unique display controller..
I don't know quite the best way to deal with this (either at the DRM/kernel layer or xorg driver layer), but there would certainly be some benefit to be able to make DRM driver a bit more modular to combine a SoC specific display driver (mostly the KMS part) with a different 2d and/or 3d accelerator IP. Of course the (or some of the) challenge here is that different display controllers might have different memory mgmt requirements (for ex, depending on whether the display controller has an IOMMU or not) and formats, and that the flip command should somehow come via the 2d/3d command stream.
I have an (experimental) DRM/KMS driver for OMAP which tries to solve the issue by way of a simple plugin API, ie the idea being to separate the PVR part from the OMAP display controller part more cleanly. I don't think it is perfect, but it is an attempt. (I'll send patches as an RFC, but wanted to do some cleanup first.. just haven't had time yet.) But I'm definitely open to suggestions here.
BR, -R
Thanks, Prasanna Kumar _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
-
Alan Cox -
Alex Deucher -
PRASANNA KUMAR -
Prasanna Kumar T S M
-
Rob Clark