From: Mike M. <che...@ya...> - 2002-07-08 23:39:43
|
--- Michel Dänzer <mi...@da...> 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 |