On Tue, 2009-06-02 at 20:58 +0200, Maciej Cencora wrote:
> Dnia wtorek, 2 czerwca 2009 o 20:18:17 Michel Dänzer napisał(a):
> > On Mon, 2009-06-01 at 16:39 +0200, Maciej Cencora wrote:
> > > Dnia poniedziałek, 1 czerwca 2009 o 14:25:57 Maciej Cencora napisał(a):
> > > > Dnia poniedziałek, 1 czerwca 2009 o 12:44:20 Michel Dänzer napisał(a):
> > > > > On Sat, 2009-05-30 at 21:00 +0200, Maciej Cencora wrote:
> > > > > > Hi,
> > > > > >
> > > > > > this round of patches for r300 brings:
> > > > > > 1) hardware accelerated support for 8bit and 16bit vertex attribute
> > > > > > data formats,
> > > > > > 2) support for 16bit vertex indices,
> > > > > > 3) support for EXT_vertex_array_bgra extension,
> > > > > > 4) T&L path cleanup. it's used when hardware TCL is enabled, but we
> > > > > > have to fallback for software TCL - clipping is still done in
> > > > > > hardware unlike in software TCL path.
> > > > > >
> > > > > > Those patches are unfinished, to be done:
> > > > > > 1) unmap bo's after rendering is finished
> > > > > > Currently the map/unmap functions are noop so it's working ok, but
> > > > > > when we will add support for VBO's it won't work.
> > > > > >
> > > > > > 2) handle big endian machines correctly
> > > > > > Is this really an issue?
> > > > >
> > > > > The driver certainly used to have special code for non-32-bit elts on
> > > > > big endian. How can I test this on my PowerBook?
> > > >
> > > > Hmm, since vbo branch merge all elts are always 32bit. I've looked a
> > > > little at the code before the merge and I couldn't find any big endian
> > > > specific code for elt handling, but maybe I just haven't looked hard
> > > > enough.
> > > >
> > > > mesa/progs/trivial/draw2arrays is using unsigned bytes as indexes,
> > > > change it to unsigned shorts and check if the rendering is correct.
> > >
> > > I meant mesa/progs/trivial/drawrange
> >
> > Patch 4 indeed breaks that on my PowerBook. The patch below is a minimal
> > fix. Not sure why the #if 0'd code to just swap short indices doesn't
> > work...
> >
> >
> > commit b7315145e0fe40a5de3846bff8f1874199c52e58
> > Author: Michel Dänzer <daen...@vmware.com>
> > Date: Tue Jun 2 20:14:09 2009 +0200
> >
> > r300: Endianness fixes for recent vertex path changes.
> >
> > diff --git a/src/mesa/drivers/dri/r300/r300_draw.c
> > b/src/mesa/drivers/dri/r300/r300_draw.c index bb85d63..341c952 100644
> > --- a/src/mesa/drivers/dri/r300/r300_draw.c
> > +++ b/src/mesa/drivers/dri/r300/r300_draw.c
> > @@ -80,9 +80,36 @@ static void r300FixupIndexBuffer(GLcontext *ctx, const
> > struct _mesa_index_buffer ind_buf->free_needed = GL_TRUE;
> > ind_buf->is_32bit = GL_TRUE;
> > } else if (mesa_ind_buf->type == GL_UNSIGNED_SHORT) {
> > +#if MESA_BIG_ENDIAN
> > + GLushort *in = (GLushort *)src_ptr;
> > + GLuint *out = _mesa_malloc(sizeof(GLushort) *
> > + ((mesa_ind_buf->count + 1) &
> > ~1)); + int i;
> > +#if 0
> > + for (i = 0; i + 1 < mesa_ind_buf->count; i += 2) {
> > + out[i / 2] = in[i] | in[i + 1] << 16;
> > + }
> > +
> > + if (i < mesa_ind_buf->count) {
> > + out[i / 2] = in[i];
> > + }
> > +
> > + ind_buf->is_32bit = GL_FALSE;
> > +#else
> > + for (i = 0; i < mesa_ind_buf->count; ++i) {
> > + out[i] = (GLuint) in[i];
> > + }
> > +
> > + ind_buf->is_32bit = GL_TRUE;
> > +#endif
> > +
> > + ind_buf->ptr = out;
> > + ind_buf->free_needed = GL_TRUE;
> > +#else
> > ind_buf->ptr = src_ptr;
> > ind_buf->free_needed = GL_FALSE;
> > ind_buf->is_32bit = GL_FALSE;
> > +#endif
> > } else {
> > ind_buf->ptr = src_ptr;
> > ind_buf->free_needed = GL_FALSE;
> > @@ -157,7 +184,11 @@ static void r300TranslateAttrib(GLcontext *ctx, GLuint
> > attr, int count, const st } else
> > src_ptr = input->Ptr;
> >
> > - if (input->Type == GL_DOUBLE || ((getTypeSize(input->Type) *
> > input->Size)
> > % 4 > 0)) { + if (input->Type == GL_DOUBLE ||
> > +#if MESA_BIG_ENDIAN
> > + getTypeSize(input->Type) != 4 ||
> > +#endif
> > + ((getTypeSize(input->Type) * input->Size) % 4 > 0)) {
> > if (RADEON_DEBUG & DEBUG_FALLBACKS) {
> > fprintf(stderr, "%s: Converting vertex attributes,
> > attribute data
> > format %x,", __FUNCTION__, input->Type); fprintf(stderr, "stride %d,
> > components %d\n", input->StrideB, input->Size);
>
> Could you check the latest patches, that I've used sent as a reply to
> Nicolai's message?
The patch above is against the latest patches you posted to the list.
> After some more thought and quick look at the available swap registers,
Which ones are you looking at?
> I think there shouldn't be any issues with big endian machines since we're
> not
> going to copy data with stride lesser than the native type - i.e. if the data
> will be in bytes/shorts, we copy it in ints, so the byte ordering is
> preserved. Am I right?
No. The immediate problem here is probably that we're setting up the CP
to byte-swap each 32 bit word it reads (via BUF_SWAP_32BIT in
CP_RB_CNTL), so we don't need to byte-swap each and every one of them
with the CPU. This means that the order of values smaller than 32 bit
gets mangled.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
