On Wed, 26 Jan 2005 09:58:34 -0500 (EST), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > >>>> means that the source data in the framebuffer already has the correct > >>>> byte order. > >>> > >>> BITBLT_MULTI work if i put data in the agpgart space with cpu (memcpy) > >>> and then read it and put it in the framebuffer with bitblt_multi. > >> > >> This still requires that the data is copied to AGP space with the > >> correct byte order. This might indeed work for the 3D driver (Mesa can > >> provide little endian texture data), but not as is in the X server. > > > > With r300 demo i do not remember doing anybyteswapping before > > doing the memcpy. So i send them as i get (i guess little endian > > order as on x86) and they end up well in card memory. > > > > So i get same result for r300 demo on x86 & ppc for all texture > > test. Without anybyte swapping. So i was thinking that > > byteswapping now only work with BITBLT_MULTI but i think > > this is strange. > > I think I know what the issue is - r300_demo includes the texture as a C > array. So the byteswapping is done automatically :) >
This was what i fear :) Jerome Glisse ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
