Hi,
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 ? Without specs hard to understand that :)
Btw on ppc if data like bitmap are send using bitblt_multi they end
in correct order while with hostdata
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 spa
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 ?
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. O
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
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 o
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 i
On Wed, 2005-01-26 at 13:36 -0500, Vladimir Dergachev wrote:
>
> Correction - I looked at the source and we compile the texture data as a
> string, so no conversion is being done.
Define 'compiling as a string', but it sounds to me like it does
implicitly produce the same byte order regardless o
On Wed, 2005-01-26 at 23:10 -0500, Vladimir Dergachev wrote:
>
> I meant that RGBA picture is represented as an unsigned char
> array. So byte 0 is always R, byte 1 G, and so on - irrespectively of the
> architecture.
>
> There is however an issue of whether conversion is being done when doing
On Wed, 26 Jan 2005, Michel [ISO-8859-1] Dänzer wrote:
On Wed, 2005-01-26 at 13:36 -0500, Vladimir Dergachev wrote:
Correction - I looked at the source and we compile the texture data as a
string, so no conversion is being done.
Define 'compiling as a string', but it sounds to me like it does
impl
On Wed, 26 Jan 2005 23:28:29 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-01-26 at 23:10 -0500, Vladimir Dergachev wrote:
> >
> > I meant that RGBA picture is represented as an unsigned char
> > array. So byte 0 is always R, byte 1 G, and so on - irrespectively of the
> > architec
On Wed, 26 Jan 2005, Jerome Glisse wrote:
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 i
On Thu, 2005-01-27 at 19:06 +0100, Jerome Glisse wrote:
>
> So no hope for using MULTIBLT ? I haven't looked to the source but
> i suppose dri do not use agp space to upload texture but a dma buffer.
Yes, but that's not set in stone, so as I said, it might be a
possibility for OpenGL texture uplo
13 matches
Mail list logo
