On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
> > from overwriting normalptr and floatcolorptr. :) In actuality, should this
> > be expanded anyway? How was the value 15 arrived at?
>
> Yes, you need a bigger maximum for the extra texture coord.
Okay. It should be changed to 19, then?
+ 3 for normal
+ 3 for color (or are 3f colors not supported?)
+ 3 for secondary / fog color (or are 3f colors not supported?)
+ 2 for texture 0
+ 2 for texture 1
+ 2 for texture 2
+ 2 for texture 3 padding
---
17
Since the previous version wouldn't have had the last 2 fields, why was the
size 15 (should have been 13)? Are 3f texcoords supported? Was there just
extra space for "someday" when support for the 3rd TMU was added? Whatever
change gets made, I'll explain exactly why that value is used in the
structure. :)
> >>>On other question, that I just noticed. Why is the scale by 8 (shl
> >>>$3,%edx), and why is the second store to texcoordptr[0]+4? Are the two sets
> >>>of texture coordinates interleaved in a single buffer?
> >>>
> >
> > Okay, I figured this one out for myself. If both texture units are enabled,
> > then texcoordptr[1] points to texcoordptr[0][2]. texcoordpointer[n+1]
> > should point to texcoordptr[n][2] whenever texture units [0,n] are enabled,
> > correct? If that's the case, then I'll make some other changes to this code
> > path.
>
> Yes, the code here only handles size 2 texcoords.
> > Right. I wanted to move the code that actually does the allocation,
> > deallocation, and stealing into the kernel. The only problem that I saw was
> > in notifying applications that their memory had been stolen. Sending a
> > signal seemed like it would work, but that also felt like a very ugly
> > solution.
> >
> > Linus, do you have any suggestions on this one?
>
> It also ties in to the way the driver builds buffers. If an app has a
> half-built buffer hanging around with texture addresses in it, somebody's got
> to go through and find the dead references.
>
> One option is to have the kernel actually do the fixup of the buffers when
> they are submitted by the client, so the driver never knows really where it's
> textures are, but talks about them via. some indirection.
Interesting. Basically we'd have a kernel API that would mirror a subset of
the OpenGL texture API? Something like:
int drmCreateTexture( int fd, int * texture_handle, int target,
unsigned width, unsigned height, unsigned depth,
unsigned bytes_per_texel,
int mipmaps );
int drmDestroyTexture( int fd, int texture_handle );
int drmUploadTextureData( int fd, int texture_handle, int level,
int xoffset, int yoffset, int zoffset,
int width, int height, int depth,
void * pixels );
The 'mipmaps' value of Create would have to tell it 'none', 'user supplied',
or 'acclerated SGIS_create_mipmaps'. The assumption is that the user-mode
driver would supply data to the kernel in the format that it needs to be in.
Then the texture pointer programmed by the user-mode driver would be the
'texture_handle' returned by CreateTexture. The kernel would then have to
make sure that the texture was addressable and fix-up the pointer.
Would some sort of fencing be needed? By that I mean, we're programming in
texture addresses and stealing textures. Do we need to know when the card
is done rendering the polygons that reference a texture to know when it can
safely be kicked-out?
What sort of semantics would we want for what the kernel could do with the
'pixels' pointer? Would it be the same as for TexImage or could it keep the
pointer until replaced or the texture is destroyed? The latter seems better
to me. That might even allow directly mapping the user-mode pointer into
AGP space. That being the case, we might change the API all together.
Replace UploadTextureData with SetTexturePointer / LockTexture /
UnlockTexture. Then user-mode could do all of the TexSubImage-like copying.
> One viatal property any of these schemes must support is accelerated
> CopyTexSubImage: this can't be done unless you know that the data on the card
> is somehow protected, and won't get thrown in the bit bucket by some other app.
Right. This is something that's been missing from DRI for way too long. :)
This would also enable support for accelereated SGIS_generate_mipmaps.
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
