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

Reply via email to