Some considerations
Keith Whitwell
keith@tungstengraphics.com
Sun, 04 Jan 2004 21:36:44 +0000
Marcelo E. Magallon wrote:
> On Wed, Nov 26, 2003 at 01:19:14AM -0800, Keith Packard wrote:
>
> > Window buffers which aren't actively updating will be migrated back
> > to main memory if other applications have more pressing need for
> > video memory. But, if everything is updating all the time, you're
> > gonna need piles of memory to keep everything resident. Do realize
> > that even a full-screen image is "small" these days -- with 256meg
> > video cards, even several 4meg full-screen images are manageable.
>
> Well, yes, but you are ignoring windowed OpenGL applications that _use_
> those 256 MB of RAM (or something close to it), e.g. Maya, which the OP
> mentioned. The question is probably how is texture memory going to be
> used? Does every application get its own texture? A pretty smart
> texture manager is in order. Since window resizes would mean
> destroying and allocating new textures, that might wreak havoc with the
> driver's texture manager.
>
> I have been reading the last few weeks worth of posts to this mailing
> lists, particularly looking for something related to the OpenGL-based
> renderer, particularly:
>
> * How to leverage existing proprietary OpenGL drivers
>
> * How will OpenGL applications work
>
> * What's the impact on OpenGL applications
>
> For the first question, as far as I understand it, there's a regular
> Xserver using the proprietary driver, and a fullscreen application runs
> on this. This application receives all the requests from clients and
> translates them to an OpenGL command stream to do the actual rendering.
> The actual implementation might look a bit different, but somewhere
> there's got to be a client that uses the vendor's OpenGL driver. Since
> all the proprietary OpenGL drivers are GLX-based, you need an Xserver.
Initially this is correct, but I see this as a development/transitional
architecture to be replaced by one in which the proprietry and opensource
drivers are engineered to exist and operate without a second X server.
> That has an impact on the second question. A great deal of effort has
> been put into implementing direct rendering drivers (and I'm not
> refering only to those provided by the DRI project). In plain English,
> OpenGL applications running locally are direct rendering clients for
> all situations of interest. The application sets up a window and event
> loops with the Xserver but all of the rendering in that window goes
> straight to the card bypassing the Xserver.
>
> Which brings me to the third question: on SGIs, where sync-to-vblank is
> standard, I can have continously updating OpenGL applications running
> side-by-side with little trouble. On Linux using NVIDIA drivers and a
> 2.6 kernel, this gets very jerky (_even_ with sync-to-vblank).
> Framerates aren't bad, but inconsistent. In the context of transparent
> windows, double-buffering gets interesting :-)
This has much to do with scheduling algorithms - SGI I'm sure has done a lot
of work to integrate the behaviour of opengl apps and the system scheduler so
that this appearance of smooth behaviour results.
Additionally, there's a suprising amount of work, including probably hardware
support you need to get multiple applications running sync-to-vblank
efficiently. My (limited) understanding is that the nvidia hardware has much
of what's required, but who knows if it's been a priority for them at the
driver level.
If you think about it, a GL app with direct rendering probably looks a lot
like a batch application to the scheduler.
> Much larger areas of
> the screen get damaged. In can imagine the best solution is to render
> each window to a texture and then rendering a bunch of polygons one on
> top of the other.
Who is doing this rendering? Are you talking about doing the rendering on CPU
to a buffer which is then handed off to the card as a texture?
> The blending code I posted before is pretty good,
> but it only beats up blending on the card _if_ the data isn't already
> available on the card's memory:
>
> Operation | Texture | DrawPixels
> =======================================
> Clear | 1 | 1
> =======================================
> Texture upload | 36 |
> Texture upload | 36 |
> Render quad | 1 |
> Render quad | 1 |
> ---------------------------------------
> DrawPixels | | 16
> DrawPixels | | 18
> ---------------------------------------
> ReadPixels | 42 | 41
> ---------------------------------------
> Total | 117 | 76
>
> (times are ms; images are 1k x 1k RGBA; hardware is a
> GeForce3)
>
> Just ignore the ReadPixels call.
>
> Blending a handful of large quads is not _that_ expensive, but
> uploading large amounts of texture data is.
>
> And where does that leave my OpenGL application? As long as my OpenGL
> application is a top-level window everything is ok, but when I lower
> it, I start to get inconsistent results, or did I miss something?
I'm not really sure what you're getting at - an opengl app would be rendering
to an offscreen buffer and composited along with everything else.
Keith