On Wed, 22 Jan 2003, Rodolphe Ortalo wrote: > I just start now in this heated discussion. > > Apparently, there are several subjects: > 1) Whether generic backbuffering is desirable or not in general; > 2) Whether it is possible to implement such a backbuffering mechanisms in > a safe way on current hardware. > > As to 1), I guess this is primarily an application point of view. It seems > to me that applications that are worth a backbuffer are those that do not > have an easy mean to redraw their screen entirely. These are probably: > fastly written small apps, and apps that do a lot of computations to > produce the pixels (raytracer for example).
A good raytracer doesn't raytrace directly to video memory, and I'd like to translate "fast written small apps" by "buggy garbage". I can imagine that the raytracer requests a non-VRAM area to draw into, but definitely not that we give any app that is switched away a backbuffer. The raytracer itself draws in the requested area (and maybe when in foreground to the graphical console), can handle the copy-to-screen itself rather easily, and no ugly tricks have to be done to get the stuff mapped away at a console switch. If it gets focus again, the code does a "copy to screen" and continues like nothing happened. (Maybe that a PutPixel should also be done to the screen, instead of the buffer only). This is not the fastest way, but programs too slow to redraw don't care about that. > Other applications (GUI, games) apparently have enough internal > information to recompute a display. Furthermore, these applications will > probably want to stop doing CPU expensive drawing while they are not > visible. Apart from whether the application wants that, it is the current foreground task that definitely wants that. There is no reason why a game or GUI has to draw while it is not visible. And if it does so, it destroys the performance (and thus framerate) of your current foreground game. > Concerning 2), I'd say that from the KGI perspective, it seems to me that > such a backbuffer system should, if possible, be managed by a userspace > library. It seems to me that it is much safer if userspace takes care of > moving/saving fb-related memory. This is simply because there is usually > no MMU-like features (page tables, memory protection) wrt the graphic > board memory; so nearly none of the VM mechanisms used for main memory are > applicable. Of course, KGI could provide a systematic save of fb memory > into main memory on context switch, but, as many of you outlined already, > given the trend in memory size on graphic boards, this is probably not > realistic. > Plus, it seems to me that, if LibGGI imposes a few restrictions on the > application that wants a backbuffer (like, the interdiction to use > DirectBuffer), it can be done pretty easily, and probably transparently to > the application. (I noted that it may not be so easy to replace the > functions of one display with those of the memory display, but can't > these problems be solve?) Don't forget that when you let GGI do it, GGI must be fully aware of multithreaded applications. I step back as volunteer to get that fixed. > A possible impact of this discussion is the fact that, from the KGI point > of view, we should really take care to identify the resources that are > preserved transparently accross a VT-switch and those that are not. > (Pointer position comes to my mind for example, in the future, AGP-capable > memory, or in-main-memory graphic buffers.) We should do that in the near future anyway, the resource stuff is also suboptimal for dual-head cards. > Well, in fact, from the KGI perspective, I'd like to say that I am > extremely reluctant to make provision to send all of VRAM to swap on > VT-switch. In fact, I would be more favorable to use some of the VRAM > as a swap area... :-) Which has been done before, I already used 3 MB of my ViRGE memory as swapspace back in the kgicon days. I really hope this day is not to be remembered as the day GGI became BIG & BLOATWARE [tm] Jos
