On Tue, 14 Dec 1999, Jon M. Taylor wrote:
> On Mon, 13 Dec 1999, teunis wrote:
>
>
> > And many of the interfaces
> > developed (ping/pong buffers as an example) are either currently unusable
> > or not really tested all that much. I'd -love- to see some sort of formal
> > FAQ/RFC on this issue... anyone?
>
> Lots of mailing list posts, plus I wrote up a detailed explanation
> of PP bufs for John Carmack once. I'll try to pull all of this togther
> into a comprehensive FAQ when I have some time.
Looks like I'll give it a try :)
Anyways, here goes:
---------------------------------------------------------------------------
This is an attempt at a FAQ/RFC for GGI work towards a hardware-accelerated
system.
I've never written a FAQ before so please let me know. I'm available at
[EMAIL PROTECTED] AFAIK which'll point to my real address...
Q: Is this going to be directX?
A: No. Never. But -someone- will eventually write a library that makes it
look like it. After all we don't want to fall into many of the holes that
Microsoft fell into or be trapped into Someone Else's Problem. It's best
if we make a whole new set of holes of our own *grin*.
Q: How does 2D acceleration look?
A: Very little acceleration yet. See below for more information on how it's
currently being done.
Q: What's being looked at for 3D acceleration?
A: Currently work is going into making sure Mesa has 3D accelerator support.
Long-term goal is to get libGGI3D up and running to handle 3D-accels.
Q: does glide work for display?
A: yes. glide-2 and below. glide-3 is pretty much X-only and has some hoopy
stuff about it. It's also only in beta yet.
Q: I see a Mesa-GGI target in my beta cvs-download of Mesa. Does it support
acceleration?
A: no. (please someone let me know when it is :)
Anyways I phrased it this way as the publically available Mesa/GGI target
has never worked for me. The CVS usually does with only limited patching
*grin*
Q: How do I send textures to my videocard?
A: Oh a complicated question. As far as I know one can request access to the
memory on the videocard and just read/write to there. I don't think
there's really anything written for this yet. directbuffer documentation
does handle this but it's unimplemented:
- Someone says one should open a large block of memory.
Why not a 'texturepool' directbuffer request?
- Any other issues? :)
Q: How do I open a Z-buffer, alpha-buffer, ... to the card?
(ie a buffer that'll be used to render the display but not directly for
display)
A: This is a driver issue. Ideally it should be setup by, say, Mesa through
the standard OpenGL methods - then Mesa talks to the kernel driver or
perhaps libGGI3d and then sets it up for you. Same on the texture memory
above. But the technicalities on -how- this should work are... undecided.
Q: Can KGI, FBdev, ... handle DMA transfers?
A: Can't see why not. Anyone know of a driver setup for this? And anyone
know how one can talk to DMA from userspace? :)
Q: Can KGI, FBdev, ... handle AGP acceleration?
A: 2.3.30 added generic AGP support. If anyone know how AGP is applicable
to video-acceleration, let me know, eh? :)
-> TODO : libAGP? Prolly...
Q: What's the difference between DMA and MMIO access?
A: DMA uses a memory buffer that's shared between hardware and the computer
that's <=64K in size. MMIO just makes itself look like part of the
computer's memory.
Q: Why shouldn't video setup be handled in userspace such as X currently does?
A: Because a partial or corrupted write to the videocard could nuke the card,
monitor, ... See VGAdoc or the GGI mailing list for past examples.
Also, it's really nice to be able to open multiple accesses to the
videocard. Opening X multiple times is just too resource-intense and
not particularily stable due to the previous note.
/Aside:
Please noone say -how- this can be done here. Let those who want to know
learn the hard way (or ask on ggi-devel or something). That it -can- be
done is bad enough. It's not like it's hidden knowledge or anything, just
not appopriate here.
/Aside end.
This is one of the reasons why DRI is a Bad Thing. Security and stability
should be the preferences of an OS. Even if it sacrifices some speed.
Arguments? :)
Q: How does one talk to an accelerator?
A: Depends on the card. Possible routes:
(/Aside: Anyone know how the SGI direct rendering system works? /Aside end)
Directly talk to the videocard:
Crash city. If your app crashes kiss your display goodbye. If it's
got good keyboard support and you have a recovery app maybe it'll work.
Examples: svgalib. Crashing's not always recoverable...
Also you can't use interrupts or DMA.
X works this way too currently but is farely well tested so doesn't
tend to make your display unusable when it dies... (I do mean -when-
for me anyways. Most other people have never seen X crash :)
! you can't share the accelerator with another program
Also if you misprogram a videocard you could crash your computer,
-destroy- your videocard or monitor (and I -mean- this!), and so forth.
This is a good argument for not -ever- allowing such commands into
userspace as a malicious program could...
Open a direct pipe to the videocard through the kernel:
DMA can be handled this way.
! This has a huge security risk in that videocards can be capable
of reading anywhere in the system's memory and you don't really want
to open this security hole..
! Also refer to previous example.
! you can't share the accelerator with another program
Most interrupt-based communications to the videocard can be done so.
DRI works this way more-or-less. Does anything else?
Have some sort of interpreter in kernel that turns a list of commands
into a list of accelerations from a shared memory block in userspace.
ping/pong buffers: swapping is handled if you overflow the block
by an automatic segfault
others? I like this concept but I'd like a 'flush' command as well.
- A nice bonus to both this and the next possibility is one can control
what commands are sent to the videocard. Generally you can send them
straight on through as per the network I/O in linux but sometimes
it'd be handy to stop dangerous combos (such as sending only one
triangle-accel to orignal S3 ViRGE - this crashes the card. Have to send
two)
- Another nice bonus is it's possible to tell who sent it and therefore
whether they currently have access to the videocard's accelerator.
Send a command to kernel via individual ioctl's:
There's a cost to switching between user/kernelspace. In an ideal
world this is good but it's hardly an ideal world. Anyways, mostly
this is how what little acceleration is currently handled is used.
(whoah what a sentance. Grr)
Q: Why don't we run acceleration like directX does, by calling one ioctl at
launch that fills up a bunch of function pointers, and the caller falls
back on ioctls if the function pointer is NULL?
A: (thanks Andreas Beck from a post a while back)
It's a huge waste of time to test every possible accel function at init.
Q: What videocards support -any- acceleration?
A: FBdev: Matrox
3Dfx/Banshee; 3Dfx/3
(but it uses the tdfx driver for this and as the 3dfx and
tdfx switch the card into different modes they tend to
crash eachother... *sigh*)
As far as I know none of the non-intel platforms are
accelerated. Anyone know better?
KGI/FBcon: Matrox (anyone know which driver's better?)
Permedia/2 (untested)
KGI: Permedia/2 (untested)
DRI: 3Dfx/Banshee and 3Dfx/3
3dlabs GMX 2000
(ggi doesn't support DRI. Why not?)
svgalib: I -know- some cards are accelerated. Which ones?
==============================================================================
Here's a proposal for a 'feature' requester circa Brian S. Julin
<[EMAIL PROTECTED]> included here for anyone who cares:
I posted a while back about the state of discussion on
the "feature" issue. Basically before AGP we need a feature
negotiation API that allows an app to determine inside what
parameters do the textures/etc. operate on the display target
that is being used, and adjust the video mode accordingly.
The proposal I sent Andy and Marcus gave each "feature" a couple
of parameters, which I've enhanced since (and renamed in Spanish
since it had the words with the right shades of meaning. Maybe
Marcus and Andy know/would prefer German equivalents. :)
struct feature_s {
unsigned long long tipo; /* Type field, e.g.
is it a BLT or 3dtexture or a Sprite */
int n_este; /* Number of "real-time" simultaneous occurances
allowed for this feature, e.g. # of sprites that
can be displayed on the screen at the same time.
Probably not used for AGP/textures. */
void *este; /* Pointers to feature-private structures. */
int n_ese; /* Number of "short term memory" objects of this
type, e.g. textures stored in on-board graphics RAM. */
void *ese; /* Pointers to feature-private structures. */
int n_aquel; /* Number of "long term memory" objects of this
type, e.g. textures stored in main RAM. */
void *aquel; /* Pointers to feature-private structures. */
/* There's other stuff in the structure. */
}
There would be functions to copy/swap data between the three modalities
(este, ese and aquel). Say the function to move one of the "features"
from aquel to ese was activated on an extension target library for
an AGP chipset, then the library would use AGP to move the data onto
the card to the specified slot in the onboard texture cache. Or the
whole feature_s could be turned over to hw caching control.
This would complete a base structure which is generic (can be used
for various types of "features" -- sprites, textures, hw fonts,
overlay windows) and primitive. Upon this could be built any number of
texture cache management libraries. I doubt you'll ever find one
single algorithm that satisfies everyone in this area, so best to implement
generic primatives and let the application developer worry about caching.
----
incidentally, I like this proposal for features...
Could use some rearranging but I can't think straight anymore.
Could use a real explanation other than the occasional blurb on why some
situations are Bad Things. Such as DRI, FBdev, ... (afaik the only
problem that fbdev has is no 'testmode' feature to see if a mode's
possible - just a way of setting the mode and then testing if it
succeeded)
G'day, eh? :)
- Teunis
