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 :)
best
Vladimir Dergachev
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
------------------------------------------------------- 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
