On Tue, 26 Oct 1999, Jos Hulzink wrote:
> On Mon, 25 Oct 1999, Martin Lexa wrote:
>
> > O.K I'l look at textures. Could you explain me how should I load
> > textures into memory and then get it to triangle func. And how are these
> > persepective correction parameters computed?
>
> Allright,
>
> The next text is based on my own ideas and not based on any experience.
> Therefore I forward it to the GGI mailinglist, I hope to get some comments
> from there.
>
> Before you can load textures first this:
>
> The driver should have some memory management. In my eyes, this has to be
> in the KGI(con) driver, and not in the libraries, for otherwise many
> libraries would have to implement the same memorymanagement.
Remember that hardware memory management can only work with page
size granularity. I remember Brian Julin bringing this up back when we
were discussing a Sprite/texture cache extension. In many cases, your
textures or sprites or glyphs or whatever will be smaller than PAGE_SIZE,
in which case you will need some software memory management anyway.
> Just
> thinking: it could be done by libggi too, but would maybe require chipset
> specific code in libggi.
Yes.
> A few weeks ago we had a thread on the GGI
> mailinglist about this, and some kgi_commands were proposed to do the job.
> I'm working on code for this at the moment.
>
> Well, loading textures is not very hard. You just copy a bunch of pixels
> to the video memory, and keep in mind where the texture starts en what
> size it is. Talking about ViRGE: You can use mipmaps by storing two
> textures right after each other (in different sizes) but for it's only
> ViRGE, you don't want to use mipmaps (unless you want to play Quake 1 in
> 320x240 at 1 fpm(inute)). So forget mipmapping for now. (Unless Jon is
> gonna shoot me for saying this, he knows the S3 chips better as I do) (Yes
> Jon, that was a hint :) (And no, not to shoot me)
You do not need to treat "normal" textures and mipmapped textures
differently in modern hardware, IIRC.
> The memory management scheme I had in mind is (for our ViRGE 3D
> accelleration)
>
> The 2d framebuffer starts at offset 0 and is virt.x * virt.y * bpp / 8
> bytes.
> Directly after that the Z buffer starts, size : virt.x * virt.y * 2 bytes.
> After this the texture buffer is located
> The last 1K is (can be) used for hardware cursors. Thinking : Is that
> 2-colour cursor not only nice in 2D mode ? Maybe this 1 K can be used for
> textures too, our ViRGE cards are low on memory already.
I used such a fixed layout scheme for Savage4. Easy, but not so
nice when you begin to consider cards with the same chipset but one is AGP
and one PCI, or with different amounts of video memory on the card.
> Nice issue here is when you can overwrite texture data in the videomemory.
> You try to keep as many textures as possible stored in videomemory, but
> with 1,2 or 4 MB the ViRGE can't store many :( At the moment I'm thinking
> of a mixture between LRU and LFU (Least Recently and Frequently used)
Yes. It is not so easy to create a comprehensive memory
management subsystem to handle all these cases. I think we may want to
wait on the fancy MM stuff, and just fix a memory map for each board type
or something for now.
> The calculation of the perspective correction parameters is a hard math
> job. Don't know how to do it (I can start the math calculations, but I
> think there must be a good source of info for this.) First get a texture
> on-screen, we'll see about this later. Anyone on the GGI list having info
> about this ?
Usually Mesa will handle this if necessary, and you just pass the
appropriate values through the driver to the hardware in the GGIMesa
target code. I don't remember the details of the linear algebra myself
right now either. I was using the 'meschach' library for this in
LibGGI3D, but I never got around to converting my old Ada transformation
code to C. The principle is the same, though - you set up a matrix with
your coordinates, multiply by one or more transformation matrices, and the
resultant matrix contains your transformed coordinates. You really can
look at the whole process as somewhat of a black box.
> Pfft... man, what a huge job is it to write a videodriver if you don;t
> have time to do it.
Remember, the way to eat an elephant is one bite at a time |->.
That is why I do not think that we should jump into designing a
somphisticated memory management subsystem in KGIcon right now. We should
take it nice and easy until we have a few drivers which can do basic
textured triangle drawing to play with. Just MHO of course.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
