1 KGI developer testimony (Was: [Linux-fbdev-devel] Redesign of kernel graphics interface])

[Rodolphe O. <or...@la...>]

Hello Jon,

> ----- Forwarded message from Jon Smirl <jon...@ya...> -----
> 
> Delivered-To: nsouch@localhost
> Delivered-To: onl...@fr...
> From: Jon Smirl <jon...@ya...>
> To: dri-devel <dri...@li...>,
>   mesa3d-dev <mes...@li...>,
>   fb-devel <lin...@li...>
> Subject: [Linux-fbdev-devel] Redesign of kernel graphics interface
> Date: Thu, 6 May 2004 11:16:39 -0700 (PDT)
> 
> At the X Developers Conference there was a discussion of the issues around
> framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
> discussion. I'm going to try and list all of the issues I've heard from all
> sides so some of the proposed solutions are in conflict. The goal of this list
> is to provide direction for a topic discussion at the Ottawa Kernel Summit.
> 
> The top item is that accessing the video hardware is a free for all. There are
> two device drivers, FB and DRI, plus numerous user space apps, like X and
> SVGlib, all trying to control the hardware. The result of this is that it is
> easy to lock up your machine when switching between the different usages. X does
> particularly nasty things to the hardware from user space without informing the
> kernel.
[... (interesting) mail archives references deleted...]
> 
> Another topic that I missed was, why did kgi fail and what can we do to avoid
> repeating the same path this time around.

(I hope you spoke about the KGI project, twin of the GGI project at
http://www.ggi-project.org - if not, I'm sorry for bothering you.)

My view for possible failures of past kgi projects:
 1- this is a *very* "flamable" topic among software writers;
 2- hardware documentation is rarely available and apparently, only
XFree86 succeeds grabbing it;
 3- it seems this is a new kind of technical interface (wrt Unix
established kernel interfaces), and of course, when doing something new,
it's much more difficult to be sure that you do the right design.


Just as a little introduction for myself on this issue, I started on the
GGI/KGI project by writing a driver for the Cirrus Logic CL-GD5464 (Laguna
3D) on a Pentium in 1996 (in Linux 1.3.x era IIRC). Since then, I tried to
follow the issue; and most notably wrote most parts of the Matrox-related
driver code in the current KGI framework (ran on Linux 2.{2,3,4} then
FreeBSD 5.{1,2}).
 See:
http://www.kgi-project.org/ for current project info
http://sourceforge.net/projects/kgi-wip/ for aging Linux code
http://people.freebsd.org/~nsouch/kgi4BSD/ for recent FreeBSD code

Details: (of the above points)
=======

1) The initial problem (back to 1998) was a little virtual IMHO: Linus did
not want to have "X in the kernel" and never realized that he agreed with
all KGI developpers on this.
 I *suppose* there were other (technical or semi-technical) reasons for
his reluctance (the above is so simplist...) - but I cannot speak for
someone else.
 Afterwards, the KGI project lost momentum; and in the long run was never
capable to compete with linux "politically compatible" solutions (XFree86,
fbdev) because its workforce could not increase much. Nowadays, I
personnally think an immediate switch to FreeBSD (or possibly OpenBSD) in
1998 would have been extremely beneficial to KGI (maybe not to GGI: the
library part). At least, I suppose, we would have benefitted from the work
on VGL and have a good VESA driver. That's certainly the way now.
 The only lesson to learn from that is: kernel graphics interface is a
"flamable" topic. There is no need to research why; one really needs to be
careful on that topic.

2) The availability of hardware documentation is *really* a problem!
That's not a recent one: back in 1996 it was Matrox which was hiding its
specifications. In 1998 you had 3Dfx. Afterwards (while losing market
shares) Matrox released big parts of those specifications (e.g. Millenium,
G200, G400), but closed the door again in 2000 (>G450). Anyway, Matrox
never realeased some parts of its documentation- concerning the 3D WARP
setup engine. (I know these chipsets pretty well - I wrote big pieces of
the Matrox related code.) I don't speak of S3 hiding the defects of its
hardware, etc.  Nowadays, you have NVidia hiding its work. ATI probably is
not so cooperative when it comes to the heart of its own engine.
 To the difficulty to grab up-to-date hardware technical specification is
added the constant evolution of the hardware since 1994. It seems that,
every 3 months, you have a wonderful new piece of hardware.
 These pieces of hardware are extremely complex, now with literally
hundreds of registers - so, without documentation, it's very difficult to
cover the full capabilities of some device - unless by switching to...
DirectX. (Maybe this is the purpose in fact.)

3) There are several technical challenges IMHO with a such an interface:
 - management of graphics-related memory. It's not as simple a mmap()ing a
framebuffer; at least unless you get rid of AGP hardware translation
tables, of texture cache sharing between processes, of display list DMA
fetches, etc. But, from reading your posts, it seems to me you already
known pretty well such issues.
 - speed is a boring an recurring issue: 3D users want to send directly
megabytes/s of command lists to a chipset (mixing micro-code like commands
and data) that can fail mysteriously due to some of them. And it seems we
cannot force them to use Mesa only.
 - is there a need/do you want to provide a full "graphic context" for
processes? (like the actual process context; could include: graphics mode
setup, possibly fb content swapping, state registers saves/restores,
AGP table management, command list isolation, etc.)
 - I certainly forget something, and new things will certainly arise next
year...

> After the flames from this settle down I'll try to write a document summarizing
> the conclusions reached, if any. The best possible outcome would be a design
> document for review at Kernel Summit.

If you want to re-design again; I suggest that you build up from DRM,
fbdev and also KGI. I don't think it's possible to do a synthesis of the 3
approaches; but at least you would get 3 different views (of which I think
the last is clearly the most general - in fact, from my point of view,
I've seen most of it being re-invented several times - and I'd kindly
syggest everyone interested in kernel graphic interface to actually get
involved in KGI; whether undercover or in the open ;-).

See you, and have a good time on that subject!!! :-)

Rodolphe