On Wed, 26 Jan 2005 00:51:46 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Mon, 2005-01-24 at 14:24 +0100, Jerome Glisse wrote: > > On Sun, 23 Jan 2005 15:54:26 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote: > > > On Sun, 2005-01-23 at 12:31 +0100, Jerome Glisse wrote: > > > > > > > > I was wondering what was the differences between using hostdata_blt > > > > & bitblt_multi. One faster than other ? Do not use same path for reading > > > > data ? > > > > > > Indeed, the BITBLT_MULTI type 3 packet only allows blits within the > > > GPU's address space, whereas hostdata blits transfer data from the CPU > > > (the host) to the GPU. The fact that the former works correctly just > > > 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. 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
