State of Linux graphics

[Brian Paul]

Joe Krahn wrote:
> Brian Paul wrote:
> 
>> Just a few comments...
>>
>> Keith Packard wrote:
>>
>>  > Again, the question is whether a mostly-software OpenGL implementation
>>  > can effectively compete against the simple X+Render graphics model for
>>  > basic 2D application operations, and whether there are people 
>> interested
>>  > in even trying to make this happen.
>>
>> I don't know of anyone who's writen a "2D-centric" Mesa driver, but
>> it's feasible.  The basic idea would be to simply fast-path a handful
>> of basic OpenGL paths that correspond to the basic X operations:
>>
>> 1. Solid rect fill: glScissor + glClear
>> 2. Blit/copy: glCopyPixels
>> 3. Monochrome glyphs: glBitmap
>> 4. PutImage: glDrawPixels
> 
> ...
> OpenGL was designed from the beginning to be efficient at 2D rendering, 
> although providing only low-level functions. It can be fast at 2D 
> operations due to special-case features, like pixel copy with a 1:1 
> scale. Most of these 2D cases are already handled efficiently, right?

It varies from one driver to the next.  The r200 driver has some 
optimized glRead/DrawPixels code, but other drivers use software 
fallbacks.


> The hard part about 2D rendering in OpenGL, in my experience, is having 
> to make sure that a vast number of state changes for 3D have not been 
> changed. In the purely 2D case, those states should never change.
> 
> So, the main problem of 2D OpenGL is having to carry around a lot of 
> unused 3D states. How big is an entire OpenGL state structure?

Mesa's GLcontext+TNLcontext is about 120KB, plus there may be an 
arbitrary amount of texture, vertex, display list, etc. data hanging 
off of it.  Most OpenGL apps use just a handful of rendering contexts, 
often just one, so the size isn't generally an issue.  But clearly one 
wouldn't want to create a GL rendering context for each X GC.

Examining GL state isn't always as bad as you might think.  For 
example, in Mesa you can examine a single bitmask to determine if any 
texturing is enabled.  If it's not you can ignore all the texture 
state.  There are other bitmasks to indicate which blocks of GL state 
are enabled/disabled.


> There are a few other OpenGL deficiencies, but isn't it best to get 
> those into OpenGL rather than a whole separate rendering path?

I'm not certain I understand the question.  If you're saying we should 
add additional features/extensions to OpenGL rather than persue EXA, 
I'm of mixed opinion.  I'd like to see OpenGL become the universal 
base layer, but I can't blame people for persuing EXA since it 
provides good returns for relatively little effort.

-Brian