Re: OpenGL-based framebuffer concepts

["D. Hazelton" <dhazelton@enter.net>]

On Friday 26 May 2006 04:57, Alexander E. Patrakov wrote:
> Jon Smirl wrote:
> > Most video hardware (99%) has enough memory to support double
> > buffering. You save it to the other buffer, display the error, and
> > copy it back on enter.
>
> This is possible only if the video memory management is in the kernel.
> Reason: userspace may also want to use double buffering, and we definitely
> want to allocate the "other (maybe third) buffer" somewhere in the free
> video memory. And allocating a lot of system RAM on oops seems to be a very
> bad idea (cascade of oopses may follow).
>
> Also, did anyone measure the video RAM usage during a typical Xgl session
> (i.e.: is there really enough free video RAM, not occupied by various
> caches)?
>
> Although, a Microsoft-ish "lost context, please redraw" solution has been
> already proposed.

In the case of an oops or a panic the system might not be stable enough to 
continue operation.  In fact, I have never had a system experience either and 
still be able to run - even at the console.

In such a case, I think it'd be preferable to overwrite any graphics mode 
currently in use to display the data.  However, there must be some control on 
this, to prevent people from arbitrarily killing the video mode to display 
data.  In any event, seeing the huge ideological split and the inability of 
the people involved with this discussion to agree on a single, clear path for 
the graphics system to take...

Let me put it this way: I may write code for free, but I don't write code 
unless theres a design to it. I joined this conversation to toss a few ideas 
off the top of my head out there and see if any were useful. This has become 
something of a very genial flame war... 

Over the next couple of days I'll work on a few design ideas for a replacement 
to the current, somewhat poorly done graphics core in Linux and post them for 
comments. These will hopefully cover all sides of the currently seen 
ideological split as well as one or two that hopefully span the split.

All of them will be open for comment and revision, and if one of them is 
ultimately agreed on, I'll start work on it. If not, then I'll go back to 
just watching the traffic and hoping someone will finally start fixing the 
problems in the graphics systems.

DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/