--- Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Mon, 2002-07-08 at 20:17, Tim Smith wrote: > > On Monday 08 Jul 2002 12:49 am, Michel Dänzer scribed numinously:" > > > > > The scratch register values need to be read with DRM_READ32(), which > > > accounts both for endianness and memory barriers. So it would be > > > > > > u32 done_age = DRM_READ32(&dev_priv->scratch[1]); > > > > That's good to know; I'll file that a little closer to my forebrain. I'd > > noticed the macros before but not taken enough notice. I thought the card > > took care of that when it wrote the value back (I believe it can) but maybe > > not. > > It can, but that would mean extra code to set the control registers > according to endianness and wouldn't really buy us anything as reading > little endian data is free with a decent big endian CPU and the memory > barriers would still have to be dealt with. > That surprises me, WHY would you go throught all the trouble of making avalibul a control register that changes byte ordering? Is the GPU big endian, and thay are just letting you turn off there endianness schem? I don't know mutch about modern technology but I allways thought that in the olden days endianness was an optimisation, like the way singed intergers are handeled. Could tweaking this have any effect, even /w little endian CPUs or do any thing?
> > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
