Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Holger Waechtler <holger@qanu.de>]

Ville Syrjälä wrote:
> On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote:
> 
>>--- Ville Syrjälä <syrjala@sci.fi> wrote:
>>
>>>>I said OpenGL is the only accelerated API available on Linux. Can you name
>>>>another?
>>>
>>>DirectFB.
>>
>>Does DirectFB work on anything beside Matrox now?
> 
> 
> It works on any card with a working fbdev driver (vga16fb excluded). 
> Hardware acceleration is available on quite a few chips these days.
> 
> ati128  cyber5k  mach64  neomagic  nvidia  savage  tdfx
> cle266  i810     matrox  nsc       radeon  sis315

Keep in mind that beside the matrox driver almost none of them 
implements the full accelerated 2D API and that most are misusing the 3D 
engine to implement 2D functionality. Alpha blended stretch blits are 
almost always implemented using the 3D texture engines on PC graphics cards.

About one third of these drivers have been written using specs and 
documentation files that have never been officially released by the 
hardware vendors, so I'm not really sure whether they are much better 
from a security point of view than a closed source driver -- what's the 
point of a open source hardware driver without hardware specs? - you're 
not really able to review it seriously.

The specs for the remaining ones usually showed up as soon the hardware 
was getting outdated. Basically the same situation like the one you see 
with DRI drivers.


> That's the list of drivers in DirectFB cvs. Plus there is at least one 
> driver outside the DirectFB tree.
> 
> I use matrox and mach64 drivers daily. It's been a few years since I 
> seriously used XFree86.

Have you ever thought about the inherent security risks of memory mapped 
i/o registers when executing non-trusted applications? Imagine what 
happens if every single application is allowed to program the blitter 
and texture engines to copy host memory from anywhere in the system to 
graphics memory and back - a single misbehaving application can damage 
your entire system.

And do you really have the time to review every line of code you execute 
on your system?


>>>>There is a little acceleration in framebuffer, but I don't know of any
>>>>others. Also, software mesa works just fine to provide OpenGL on dumb 2D
>>>
>>>cards.
>>>
>>>Using unaccelerated OpenGL for 2D rendering doesn't sound exatly useful. 
>>
>>There is much more to 2D rendering in things like the Mac UI and Longhorn than
>>can be accomplished with BitBlt. You need transforms, filters and alpha
>>blending. Hardware texturing is much faster than doing it in software. Some of
>>the effects are achieved with pixel shaders. xserver features a fully composited
>>window manager, it needs these features to have a fast response time.
>>
>>OpenGL to me seems like the best pick for these reasons:
>>1) with have a good open source version, mesa
>>2) mesa supports a broad number of cards, basically everything there is doc for
> 
> 
> Just about as broad as DirectFB.

be honest.


>>3) OpenGL is a well published API, it is taught in universities and many books
>>are available
>>4) It is likely that Nvidia and ATI will support standalone OpenGL stacks for
>>their high end hardware on Linux
>>5) OpenGL is cross-platform. For example Cairo is being written with an OpenGL
>>back end. OpenGL Cairo will run on Window and the Mac too. This will make Linux
>>apps more portable.
>>6) The embedded market has OpenGL-ES which can run in less than 100K.
>>
>>What would be reasons for picking another API?

:) well - I could see one, but that's not the point here, as soon you 
have a secure low-level GPU interface you can place any API wrapper you 
want above this, OpenGL is just one of multiple choices. But probably 
the one that's most familiar to most of us.

Even a secure DirectFB port would be possible on top of this interface 
if you don't need any 3D graphics (you remember the DirectFB-on-SDL 
system target?).


> DirectFB is good for a few reasons:
> - Input handling
> - Easy access to hardware overlays
> - YUV formats
> - Ease of porting DirectX applications
> - Good acceleration
> - Easy API / personal preference
> 
> I'm not suggesting that everyone start using DirectFB. Everyong should be 
> able to use any API they want. The kernel should provide just enough to 
> allow these APIs to be implemented.

that would be always possible, don't worry.

Please keep in mind that we developed DirectFB at Convergence as API to 
access SettopBox and Game Console functionality in a convenient way, it 
was never intended and has not been designed for use in 
security-critical desktop or workstation environments.

Holger


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click