3D support for Displaylink devices

3D support for Displaylink devices

[PRASANNA KUMAR]

[-- Attachment #1.1: Type: text/plain, Size: 646 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 902 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3D support for Displaylink devices

[Alex Deucher]

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

Re: 3D support for Displaylink devices

[Prasanna Kumar T S M]

[-- Attachment #1.1: Type: text/plain, Size: 3628 bytes --]

Garry,

My first name is "PrasannaKumar". I will use my full name to prevent 
confusion :).

I want 3D acceleration for running Compiz or GNOME3 or KWin with 
composition. Currently windows Displaylink driver compresses and 
transfers pixel data where there is a change (only damaged area is 
transferred) to reduce the amount of data transfer. It is able to play 
HD video without dropping frames. So I think that 3D acceleration and 
video playback acceleration is possible. High end games cannot be played 
but the normal 3D and video operations should work without any issues. 
When displaylink introduces USB 3.0 devices the bandwidth issue will go 
away (I remember reading in Wikipedia that displaylink is working on a 
USB 3.0 product).

The displaylink framebuffer driver that comes with linux (udlfb) also 
compresses and transfers only the damaged region to conserve the USB 
bandwidth. Also CPU usage for doing the compression is very less making 
it ideal for mobile devices (may be an android mobile). 
http://www.youtube.com/watch?v=3-bLOc1qnMM&feature=player_embedded shows 
android mobile with displaylink device. When a mobile phone is able to 
power a high resolution graphics normal desktops and notebooks can do 
provide good quality output.

PrasannaKumar Muralidharan

On 31-05-2011 15:36, Garry Hurley Jr. wrote:
> Kumar
>
> I am going to make the assumption that your culture puts the family 
> name first, so please excuse me for calling you Kumar if that is not 
> your given name.
>
> As to your question, I think I understand what you are asking for and 
> I was thinking similar things about displaying over ethernet about 
> five years ago. The problem is complex due to video refresh rates and 
> the latency of the connection. You would not get the same performance 
> on a video game, for example, unless you dropped a few dozen frames 
> per second, since the USB bus is slower than the PCI bus or even the 
> ISA bus. If you are talking about 3D acceleration, I presume you want 
> to game with it. The solution may lie in buffering, but again, your 
> performance would suffer unless you took the quality down a notch. 
> From the gamers I know, dropping quality for performance is a very 
> tricky balance. Each one is different about the quality he or she will 
> allow to be dropped in a game but when that balance is tipped, they 
> will complain or switch to a different technology.
>
> I am not saying it is not possible, but I am asking if, knowing this, 
> you truly feel it is worth the effort to try to implement it.
>
> Sent from my iPhone
>
> On May 30, 2011, at 1:30 PM, PRASANNA KUMAR 
> <prasanna_tsm_kumar@yahoo.co.in 
> <mailto: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.
>>
>> Thanks,
>> Prasanna Kumar
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org <mailto:dri-devel@lists.freedesktop.org>
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[-- Attachment #1.2: Type: text/html, Size: 5531 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3D support for Displaylink devices

[Alan Cox]

> 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

Re: 3D support for Displaylink devices

[Rob Clark]

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

Re: 3D support for Displaylink devices

[Prasanna Kumar T S M]

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.

Re: 3D support for Displaylink devices

[Alex Deucher]

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