Am Sunday 31 May 2009 23:09:46 schrieb Maciej Cencora:
> Dnia niedziela, 31 maja 2009 o 17:58:26 Nicolai Hähnle napisał(a):
> > Am Saturday 30 May 2009 21:00:51 schrieb Maciej Cencora:
> > > 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.
> >
> > Thanks for this work!
> >
> > > 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?
> >
> > Good question. Anybody who works on big-endian able to fill in the gaps
> > of whether (and if so, where) the card needs to be setup for byteswap?
> >
> > > 3) testing
> > > Currently I've tested these patches only with some simple apps from
> > > mesa/progs, sauerbraten game and with 3dmark 2000 on wine (patches give
> > > nice performance boost here, the "high polygon count" test result
> > > increased from 6M tris/sec to 8M tris/sec on my rv380).
> > >
> > > 4) rename 4th commit ;)
> > >
> > > Please review and comment.
> >
> > The general structure of the patches is looking good. For the rest, see
> > IRC #radeon...
> >
> > cu,
> > Nicolai
>
> Attached patch should fix the issues you've reported.

Just looking at the patch, without having tested it:

In the hunk: @@ -222,32 +225,49 @@
+                       switch (input->Size) {
+                               case 1:
+                                       r300_attr.dwords = 2;
+                                       /* fall through */
+                               case 2:
+                                       r300_attr.data_type = 
R300_DATA_TYPE_SHORT_2;
+                                       break;
+                               case 3:
+                                       r300_attr.dwords = 4;
+                                       /* fall through */
+                               case 4:
+                                       r300_attr.data_type = 
R300_DATA_TYPE_SHORT_4;
+                                       break;
+                       }

That switch() statement (and the similar one below for GL_UNSIGNED_SHORT) is 
confusing, because it seems that dwords isn't set correctly in case 2 and 4, 
and it is wrong because dwords should be 1 or 2, not 2 or 4. I suggest 
changing the line that sets dwords for everybody to:

        r300_attr.dwords = (getTypeSize(type) * input->Size + 3) / 4;

This gives the desired round-up property without any hassle.

Finally, I don't understand the fallback for strideB < 4. If, as you mentioned 
on IRC, all vertex upload goes through rcommon_emit_vector, and this function 
fixes the stride for us, then won't rcommon_emit_vector *also* fix the stride 
if it is less than 4? In that case, it appears to me that you do not need any 
stride-related fallbacks at all.

cu,
Nicolai

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to