Michel DÃnzer wrote:
I also made it set the source pitch based on the image width. If the
image width is less than 64, we have a problem if the image height is
more than 1 (if the height is 1 the pitch doesn't matter). I made it
return an EINVAL error in that case. I didn't see that case ever
oc
On Fri, 2005-03-11 at 23:02 +1100, Paul Mackerras wrote:
> Michel DÃnzer writes:
>
> > The difference is that for a hostdata blit, the CP writes the data to
> > the hostdata registers synchronously, whereas with your change, the 2D
> > engine will fetch the data asynchronously.
>
> What do you th
Michel Dänzer writes:
> The difference is that for a hostdata blit, the CP writes the data to
> the hostdata registers synchronously, whereas with your change, the 2D
> engine will fetch the data asynchronously.
What do you think of this patch? I have added a wait command after
the blit, which I
On Thu, 2005-03-10 at 09:10 +1100, Paul Mackerras wrote:
> Michel DÃnzer writes:
>
> > Nice. It might also be interesting to experiment with copying the
> > texture data into the ring itself instead of into indirect buffers (and
> > use type 3 NOP packets to have the CP skip it), if someone feels
Paul Mackerras wrote:
+ OUT_RING((texpitch << 22) | (offset >> 10)); +
OUT_RING((texpitch << 22) | (tex->offset >> 10));
Are source and destination pitch always the same?
I found it quite hard to understand what was going on with
tex->width, tex->height and tex->pitch vs. image->widt
Michel Dänzer writes:
> Yeah, the real question is whether it breaks pre-R300 chips on big
> endian machines, but it looks fine to me.
Yes, we previously had two byte-swaps on those machines, and now we
have no byte-swap, so the outcome should be identical.
> Nice. It might also be interesting t
[ Please don't top-post ]
On Wed, 2005-03-09 at 10:38 +0100, Jerome Glisse wrote:
>
> I don't think this will change anything for x86 setup.
Yeah, the real question is whether it breaks pre-R300 chips on big
endian machines, but it looks fine to me.
> Moreover could this change also affect way
This was solution i wanted to implement (but not time to do :(), i really
think that os x driver use this to upload texture. I don't think this
will change
anything for x86 setup. Thus if no one is against, may we apply this change ?
Moreover could this change also affect way X do bitblit with xr
I started looking into the issue of how we handle various texture
formats on R300 on big-endian machines. It became evident that
textures were getting byte-swapped on their way to the framebuffer.
Setting RADEON_HOST_DATA_SWAP_32BIT in RADEON_RBBM_GUICNTL doesn't
seem to have any effect on R300.
