Dnia poniedziałek, 1 czerwca 2009 o 08:38:20 Nicolai Hähnle napisał(a):
> 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.

You are right about that one. I'll fix it.

> 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.
>

rcommon_emit_vector can't handle arrays with stride less than 4 bytes, because 
it uses int type (4 bytes) while copying data.
I've been told that app developers were informed not to provide GPU with < 4 
bytes attributes, so we shouldn't hit that fallback often. If we will find at 
least one app that heavily depends on this fallback, we might then implement 
proper handling in rcommon_emit_vector. I propose to leave it as it is for 
now.

> cu,
> Nicolai

Maciej Cencora

------------------------------------------------------------------------------
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