Index: [thread] [date] [subject] [author]
  From: teunis <teunis@computersupportcentre.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 20 Aug 1998 20:54:47 -0700 (MST)

Re: DirectBuffer extension requests?!(!) (was Re: LibGGI3D RFC)

On Thu, 20 Aug 1998, Jon M. Taylor wrote:

> On Thu, 20 Aug 1998, teunis wrote:
> 
> > On Thu, 20 Aug 1998, Marcus Sundberg wrote:
> > 
> > > > Supposedly DirectBuffer handles this.  Will someone -please- tell me the
> > > > status on non-primary-display DirectBuffers?!?!?!?!??!
> > > > WHAT NEEDS DOING?
> > > 
> > > Well, someone needs to write an extension that provides functions
> > > to request such buffers, and then someone needs to add functions
> > > for this into the KGI API, that's all. ;-)
> > 
> > Okay - please!
> > Any ideas?
> 
> 	First, let's define our terminology.  A DirectBuffer is a memory
> buffer which is specified to be located on a particular type of storage
> (video RAM right now) and/or has a hardware-specific internal
> layout/structure, and/or needs specialized handling methods.  Am I in the
> ballpark?

This sounds right.   (there's a really good doc on this written somewhere)

TODO:  (guessing)
	KGI memory management?
	(this should be duable userspace inside KGI target, just need to
	 keep track of what's been used where)

AFAIK the rest of directbuffer is already operational.  actually the KGI
(and kgicon) driver needs a buncha work here.

> > This'll be handy for lotsa stuff (movie players, anything with BITBLT (X
> > comes to mind), 3D textures, videocards with subwindow support, font
> > loading/unloading [on S3/textmode this is present in text memory, on
> > videomodes it'd be handy for fast blitting :])
> 
> 	Any place where "memory" is not just a bunch of bits.  This goes
> beyond video hardware - the SoundFont storage in a Soundblaster AWE64
> could be set up as a DirectBuffer.  So could any type of cache memory.  So
> could disk storage, for that matter!  DB is a way to bypass virtual memory
> systems and say "I specifically want *this* memory".

Hmmm.  Except DirectBuffer requires access to that memory directly.
Indirect memory (ie. VGA 16-colour modes or the GUS audio-memory) won't
have directbuffer capabilities.

Interesting idea btw - never thought of applying it to sound-memory :)
[and I've GOT a Gravis Ultrasound :]

> > I really don't know.  I've been fighting with one -weird- system for the
> > last six months and have kind of forgotten how to write GGI extensions/etc
> > (though I'm still mucking with drivers :)
> 
> 	If you ever want to donate any code, working or not, to the
> LibGGI3D cause I would be grateful.  You seem to know this stuff better 
> than I do....

I'm just reassessing what I've got.  And rewriting.
Yes I wrote a system kin to that 10000+ function api that everyone's been
grousing about.  I made a bunch of poor assumptions though (such as no
floatingpoint whatsoever!) so looking at it again is a good idea.  The
whole monster is linked together with a whole object-management system
which unfortunately is badly broken.  *sigh*  [and the rewritten system
has problems...]

G'day, eh? :)
	- Teunis

Index: [thread] [date] [subject] [author]