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
