> > Right. Here's my updated suggestion. Leave the '&3' in the patch, but > expand the 'vertex' array in radeon_vb from 15 elements to 17. That will > prevent code like > > glMultiTexCoord2fv( GL_TEXTURE3, foo );
Yes, that works for this path. The other you have to look at is where the generated code actually dereferences the texcoordptr array -- it means we need 4 elements in there, one of them a dummy. > 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. > >>>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. This scheme appeals to me, but so does static allocation... 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. Keith ------------------------------------------------------- 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
