Re: OpenGL-based framebuffer concepts
- From: "D. Hazelton" <dhazelton@xxxxxxxxx>
- Date: Fri, 26 May 2006 02:09:42 +0000
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: replacing X Window System !
- From: linux cbon
- Re: OpenGL-based framebuffer concepts
- From: Jon Smirl
- Re: OpenGL-based framebuffer concepts
- From: Alexander E. Patrakov
- Re: replacing X Window System !
- Prev by Date: Re: why svc_export_lookup() has no implementation?
- Next by Date: Re: [PATCH] scsi: properly count the number of pages in scsi_req_map_sg()
- Previous by thread: Re: OpenGL-based framebuffer concepts
- Next by thread: Re: OpenGL-based framebuffer concepts
- Index(es):
Relevant Pages
|