Keith Whitwell wrote:
Ian Romanick wrote:
Michel Dänzer wrote:
On Tue, 2003-07-29 at 22:41, Ian Romanick wrote:

1. I don't like the hard-coding of 2*1024*1024 as the size of the indirect buffers. This was copied directly from the R200 driver, but I don't like it. We may want to change the size of this buffer at some point, and hard-coding the value into the client-side driver will make that difficult.

2. I don't like the hackish handing of the pre-1.3 DRM case. Are there other PCI IDs that need the 128MB offset? Do we even support the pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and don't intend to fix the support), I'd like to chop all the pre-1.3 stuff out. That will make the Radeon driver "look" a lot more like the R200 driver. That's a good thing IMHO.

Why not always use ( ( INREG( RADEON_MC_AGP_LOCATION ) & 0xffff ) << 16 ) + dri_priv->agpTexOffset

as discussed on IRC? This should work with any chip, memory layout, ...

Here's my inner conflict about that. If there's a perfectly good way to get this value with a simple INREG, why is there an ioctl to get it as well?

Oversight on my part. There are so many spaces that these things can be expressed in, I found one that I knew worked for sure (ie that value in the kernel) and ran with it.


Anyway, is an ioctl really heavier-weight than an INREG?

It probably depends on the platform, I guess. I mis-spoke a bit. The ioctl and the INREG do result in different values. The ioctl gets the base address of the indirect buffers and the INREG gives the base of AGP memory. Either can be used to calculate the base of textures in AGP memory. I think the INREG method is *better*, even for the R200 drivers, because it avoids the hard-coded '+ 2*1024*1024'.


Michel, does that INREG work for PCIGART as well?




------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to