On Mon, 13 Dec 1999, teunis wrote:
> Hmm. Interesting situation.
> I wonder if Microsoft will get mad that wine has working directX? :)
Hmmmm... (!) This I hadn't tried... what level of compatibility, is
it up to DirectX7 yet?
> Anyways as far as I know (and I don't know much):
> - 3D accel within GGI is currently targetted at writing hw
> drivers for Mesa.
Correct, until libGGI3d matures.
> - non-video buffers within the videocard (ie Z-buffers) are
> afaik accounted for within the directbuffer api specs
> but also afaik nobody's bothered writing an
> implementation....
Sort of, not quite. Currently the extra visual area can be
used for stuff like this as long as you have an extension and
a chipset target to make the "features" (BLTs, etc.) work.
But they are not currently given directbuffers, just extra area
on the main directbuffer. I think it was decided that giving such
areas their own directbuffers would be too heavyweight since
hundreds or even thousands of small textures might be required,
and you'd have to have a supporting struct for each.
> - AGP should be handled by some sort of libAGP extension. I
> haven't seen even a proposal for how this should be done.
> Incidentally, the 3Dfx driver seems to have AGP support...
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.
> A big problem I've found with the GGI project is that noone really knows
> how acceleration -should- be handled between kernel and userspace.
Shared memory is the way to go. I think the general idea, though,
since KGI will be multi-architecture, is to develop the metalanguage
for the chipset separate from the method used to transfer it, and
then KGI's core implements the methods that work best (or at all) for
the OS/arch you are running. There may be a couple of places where it's
advantageous to change the metalanguage to take advantage of a faster
pipe, but not many.
> or even which methods are most appropriate. 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?
It's there, just strewn across list and private e-mail. You volunteering to
pull it together?
> Some issues I can think of:
> - Some cards have -very- good DMA support (I think the permedia,
> 3Dfx, and some others fall into this category but I'm not sure)
> : these should be easy to code potentially and most work will be
> done in userspace
> - Some cards are -dangerous- for DMA work but doable, some sort of
> translation IP-stack-style would probably be good (S3 ViRGE comes to
> mind here)
> - Some cards are strictly PIO-based. Mostly old pre-3D cards really
> ioctls work well here
> : this is the current working accel format as far as I know.
> Don't expect impressive performance, switching between kernel
> and userspace has a fare bit of delay... but for a complex
> accel this should work well.
These issues really all pertain simply to the implementation of
the KGI metalanguage -- that is, what kind of commands are allowed
through the boundary between the driver and the app. (BTW Steffen,
how hard to add support for a Permedia1? Those are available to me
cheap.)
James is working on addressing hairier issues preventing or allowing
(as appropriate) simultaneous accel and framebuffer access using his new
strategy of a custom scheduler that schedules processes around each other
in regards to the graphics card.
> > Also on that last one, some cards are incredibly dangerous to allow
> any kind of direct access; all commands should be controlled to
> prevent abuse. Extreme examples are that it -is- possible to blow up
> many cards by misprogramming graphics modes. Particularily older
> cards.
Probably if you clock the DAC higher than it's designed for it might
not like that too much.
> I've heard of (Paradise VGA?) cards being lost this way.
Heh. I would think that if they were vulnerable this way, that I would have
fizzed one by now :). No, but some do have some really weird lab test
registers exposed. I _have_ smoked a monitor with one once, tho.
--
Brian
P.S.
este = this right here
ese = that
aquel = that over there
