From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 20 Aug 1998 23:05:01 -0700 (PDT)

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

On Thu, 20 Aug 1998, teunis wrote:

> 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)

	Yes.  Segmentation of video RAM into buffers of various types,
caches, font tables, stencils, etc.  The ultimate solution would be to add
a DirectBuffer extension to Linux's VM subsystem so kernel subsections
like KGI could register their own specialized memory subtypes and handling
hooks.  Any drivers whose hardware contained storage of some sort (video,
sound, SCSI, IDE, even system RAM and caches) could hook into the VM
subsystem and act as "VM drivers".  IRC, Windows has MTDs (Memory
Technology Drivers) which do something like this.

	But for now, video RAM management with basic multiple-buffer 
handling should be enough.

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

	The implementations are what will take time.

> > > 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.

	Right, which brings us to the next level in DirectBuffer
technology, per-buffertype layout and handling hooks.  From depth buffers
to alpha buffers to colorspaces (CLUT vs. direct vs. whatever) to layout
(packed-pixel vs. planar vs. packed-pixel-planar) to colorspaces (RGB vs,
RGBA vs. BGR vs. CYM vs. whatever) vs. double- or triple-buffering, an
awful lot of things can be different between one chunk of bytes and the
next. 

	Right now we handle these differences with custom rendering
targets, which works.  But if we could hook those targets to customized
DirectBuffer types, we could encapsulate the DirectBuffer specializations
and the handling functions that go with them into classes of buffers. 
DirectBuffers would just be one particular type of attribute a buffer
could have - one which specifies the physical location and/or layout of
the buffer memory.

	This would probably best be done as an OOP class library, built on
top of the existing system of rendering functions and DirectBuffers, and 
inherited from general to specific like this:

buffer
 DirectBuffer
  DirectPseudoLinearBuffer
   ModeXDirectPseudoLinearBuffer
   ISADirectPseudoLinearBuffer
  DirectLinearBuffer
   DirectChunkyLinearBufer
   DirectPlanarLinearBufer
  DirectSoundFontBuffer
  DirectDMABuffer
 AbstractBuffer

	...and so on.  Well, it is a thought anyways.  Maybe it would work,
maybe not.  In any case, it is another one for the to-do pile.

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

	Apply it to anything! 

> > > 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 have done that too, and that is why I do not ever want to do it
again |->.  The more complexity in the implementation and the less in the
interface, the easier and more modular an API system will tend to be.

> 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...]

	I've been where you are many times in the past.  At times like
this, I find that the best thing to do is to do a top-down rewrite of the
whole system from first principles and just cannibalize your old system
for code.  I'm not trying to tell you to use *my* top-down rewrite
(LibGGI3D).  But I won't complain if you do, in whole or in part |->.

	Maybe you could stick your rendering/shading code in LibGGI3D
targets and reimplement your object system on top of LibGGI3D?  Might be a
good way to shake the dust off your codebase, update your rendering/
shading code to be able to use floating-point *or* integers, cleanly
separate your object interface from the rendering implementation backend
(I'm just making wild guesses here, I don't know how your existing system
is laid out), etc etc.  Just an idea....

Jon


---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed