On Thu, Sep 26, 2002 at 04:51:37PM +0100, Keith Whitwell wrote: > Ian Romanick wrote: > > On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote: > > I guess my problem is, should values other than [GL_TEXTURE0, GL_TEXTURE0 + > > MAX_TEXTURE_UNITS] ever get this far in the pipeline? > > This far???? This function gets hooked right into the dispatch table!
Yeah, I knew that. :) > >>which is slightly more work when looking at the codegen templates. > > > > On archs. with CMOV we could work around this with something like (this is > > off the top of my head): [snip] > > On any of the archs. that support CMOV, that only adds 2 instructions and > > should only add 2 clock cycles. In any case, it would be a trivial > > addition. > > Yes, but the generic x86 arch doesn't have cmov. For p4's we really want to > be using sse2, so yes, p3's and athlons could do this. 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 ); from overwriting normalptr and floatcolorptr. :) In actuality, should this be expanded anyway? How was the value 15 arrived at? > > 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. > >>>By the end of this week I hope to have two more Radeon patches (one to fix > >>>one of the crashes on non-TCL hw, and one to enable AGP textures). I've > >>>finally gotten back to cleaning up my old texture manager patch, so I hope > >>>to get that out RSN as well. > >>> > >>Please note that the r200 has taken a divergent path with respect to the use > >>of the agp texture memory. In summary, there's a kernel-space manager for > >>this memory heap which allows us to divide up that region of agp space without > >>the fear that it will be 'stolen' by another context, as the existing texture > >>management code allows. This allows me to implement the client agp allocator > >>from GL_NV_vertex_array_range, and will allow a full implementation of that > >>extension presently... [snip] > > What I'd really like to see is other drivers implement this as > > well. At some level, it could be moved to the device independent part of > > the DRM. One of the things that irritated me the most in my previous > > texture management work was how differently each driver allocated and > > managed textures. One of the first things I did in the MGA driver was > > eliminate the need for mgatexcnv.c and make mgaChooseTextureFormat work like > > the Radeon driver. > > This is historic (the mga part) -- the radeon driver uses new facilities that > weren't available at the time the mga driver was written. That's pretty much what I figured. > > A lot of this stuff is inherently device independent with some device > > dependent "direction" (i.e., *ChooseTextureFormat), but it hasn't been > > implemented that way. As a reference point, my previous work removed > > somewhere around 450 lines of code from the MGA driver (~5%). The gains in > > the Radeon weren't quite as significant (there was no radeon_texcnv.c to get > > rid of). This just feels like a win-win to me. :) > > > > Having all of it in the kernel will make it easier to implement other > > off-screen buffers that can't be stolen (i.e., pbuffers, dynamically > > allocated back/depth buffer, etc.). > > I take it you don't really mean "all" of it, ie. not the texture conversion > stuff you mention in the preceding paragraph. 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? > > 3. I honestly do not think that NV_var should be exposed by any driver that > > doesn't already expose it (on any platform). The biggest problem with that > > extension is that it requires applications to know a priori if a SW TCL > > fallback will be needed. This can be problematic enough just across the > > GeForce line! Not only that, NV_var is really hard to use correctly (for > > the most common uses) w/o NV_fence. A better choice for right now would be > > ATI_vertex_array_object, and hopefully something better will be available > > soon. > > We want NV_fence as well, hence the irq ioctls in the newest r200 work. > > > Given some of the interrupt work that is being done, I'm guessing that > > NV_fence is in the R200 driver's future? > > Correcto. > > The appeal of NV_var is the simplicity of the spec and my perception that > software out there actually uses it. I don't know if the ATI extension has > the same support. I haven't examined the ATI extension in any detail at this > point, either. The impression I'm getting is that most ISVs that use one also use the other. What other hardware vendors have told me is that ISVs like the simplicity of ATI_vao, but that NV_var is better for dynamic data (i.e., tweening animation). -- 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