Ville Syrjälä wrote:
On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote:

--- Ville Syrjälä <[EMAIL PROTECTED]> 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 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to