State of Linux graphics
brian.paul at tungstengraphics.com
Thu Sep 1 09:26:56 PDT 2005
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
>> > 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
> 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
> 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.
More information about the xorg