Posts Tagged OpenGL
RFC: is OpenGL not the Right Thing (TM)?
Posted by Alessandro Pignotti in Insane Projects, Lightspark on October 2, 2010
It’s late at night and I’m back in Pisa for my last year of master. And, as often happens, a weird idea struck my mind. What if OpenGL is not the right thing for Lightspark? No, I’m not talking about dropping hardware accelerated rendering as that’s surely the right way to go, but using OpenGL really looks unnatural. In the design of the advanced graphics engine OpenGL is being basically used only to upload images rendered with cairo to the VRAM, and to blit and composite all the rendered chunks together... do we really need all the OpenGL complexity to do this??
Well... OpenGL is basically the only thing we have, the only way to talk with the graphics hardware. But, here it comes the gallium project! As gallium splits the API from the driver it could be possible, in theory, to write a specialized gallium state tracker to do only the work we need... and maybe do it better.
I’m writing here first because I’m not (yet) experienced enough with the gallium platform to know if the idea is sane, and second because I somehow feel the same approach could be useful for other apps... for example Lightspark and compositing window managers have similar needs. So I’d like to have some feedback about writing a small API and a gallium state tracker to do:
- DMA accelerated transfers of rendered image data
- Blitting and compositing of such data on screen
- Notify the application when asynchronous work (such as DMA transfers) has ended (BTW: what’s the right way of doing this in OpenGL?)
- Enqueue to-be-uploaded-to-vram images and have them sequentially transfered
- Apply simple but programmable (shader-like) transformation to pixel data
Big disclaimer: I’ve not yet started working on this idea. I’ve not even seriously though about it’s feasibility. I’d just like to have some feedback on this.
Lightspark 0.4.3 RC1
Posted by Alessandro Pignotti in Lightspark on August 8, 2010
Today has been published the first release candidate of Lightspark 0.4.3. Source tarballs are available as usual from launchpad. Prebuild packages for Ubuntu Lucid and Maverick are available from the PPA as usual.
The new features in this release are
- Faster rendering
- Reduced memory consumption
- Support for H263/MP3 video (using FFmpeg)
- Smoother audio and video playback
Be sure to try this out and report bugs in launchpad and our irc channel (irc://irc.freenode.org/lightspark). Users of radeon cards (and the open source radeon driver) are especially invited to try lightspark. Many radeon users complained about crashes and weird renderings which are often caused by missing features in the drivers. It would be nice to gather as much information as possible on working/non working cards to open a unique bug report upstream.
The quest for graphics performance: part I
Posted by Alessandro Pignotti in Coding tricks on June 27, 2009
Developing and optimizing Lightspark, the modern Flash player, I’m greatly expanding my knowledge and understanding of GPU internals. In the last few days I’ve managed to find out a couple of nice tricks that boosted up performance and, as nice side effects, saved CPU time and added features
First of all, I’d like to introduce a bit of the Lightspark graphics architecture
The project is designed from the ground up to make use of the features offered by modern graphics hardware. Namely 3D acceleration and programmable shaders. The Flash file format encodes the geometries to be drawn as set of edges. This representation is quite different from the one understood by GPUs. So the geometries are first triangulated (reduced to a set of triangles). This operation is done on the CPU and is quite computationally intensive, but the results are cached, so overall this does not hit performance.
Moreover Flash offer several different fill styles that should be applied on geometry, for example solid color and various kind of gradients. Lightspark handles all those possibilities using a single fragment shader, a little piece of code that is invoked on every pixel to compute the desired color. Of course the shader has to know about the current fill style. This information along with several other parameters could be passed with different methods. More on this on the next issue.
There is one peculiar thing about the shader though, let’s look at a simple pseudo code:
gl_FragColor=solid_color()*selector[0]+linear_gradient()*selector[1]+circular_gradient()*selector[2]...;
Selector is a binary array, the only allowed values are zero or one. Moreover only one value is one. This means that the current fragment (pixel) color is computed for every possible fill style and only afterward the correct result is selected. This may look like a waste of computing power, but it is actually more efficient than something like this:
if(selector[0]) gl_FragColor=solid_color(); else if(selector[1]) gl_FragColot=linear_gradient(); ...
This counter intuitive fact comes from the nature of the graphics hardware. GPUs are very different from CPUs and are capable of cruching tons of vectorial operations blindingly fast. But they totally fall down on their knees when encountering branches in the code. This is actually quite common on deeply pipelined architecture which misses complex branch prediction circuitry, not only GPUs but also number crunching devices and multimedia monsters such as IBM Cell. Keep this in mind when working on such platforms.
Lightspark second technical demo announcement
Posted by Alessandro Pignotti in Insane Projects on June 13, 2009
I’m currently finishing some last cleanups and enhancements before releasing a second technical demo of the Lightspark Project. Much time is passed from the first demo, and the project is growing healty. This release aims at rendering the following movie, selected from adobe demo. The results may not be very impressive. But many things are going on under the hood.
The most interesting feature in this release are:
- GLSL based rendering of fill styles (eg. gradients)
- LLVM based ActionScript execution. Code is compiled just in time
- A few tricks are also played to decrease the stack traffic tipical of stack machines.
- First, although simple, framerate timing
- Framework to handle ActionScript asynchronous events. Currently only the enterFrame event works, as the input subsystem is not yet in place. But stay tuned, as I’ve some nice plan about that.
The code will be released in a couple of more days, or at least I hope so
The Lightspark Project, a modern flash player implementation
Posted by Alessandro Pignotti in Insane Projects on March 28, 2009
When some months ago Adobe released the complete SWF file format specification I though that it would be nice to develop a well designed open source flash player. Now I’ve been working for some time on this idea and I’ve recently relased the code on SourceForge.
The project objectives are quite ambitious, as the flash specification are really complex. The project is designed to take advance of the feautures present on modern hadrware, so it not supposed to run on older machines. All the graphic rendering is done using OpenGL and in the future programmable shaders will be used to offload even more calculations on the GPU. Extensive multithreading is employed to make use of multicore and hyper-threading processors. I’ll write a more detailed post about some tricky and interesting part of the project soon.