Eric Anholt wrote:
Yeah, it was clear that we used to emit in whatever order, and that
would have been nicer. At this point I'm seeing about 5% CPU time in
EmitState for ipers, which seems pretty hefty for such a small bit
of code, but I didn't see much obvious for improvement.
That's indeed quite a bit. It's not enough though to really be concerned
about it at the moment imho.
Fixed order (at least within limits) being required certainly makes
sense to me. I've found that docs sometimes say things like, "Writes
to this register take no effect if bits X of register Y are not set
to Z." It may be that those dependencies were just not recorded.
It's just suspicious because there seems to be nothing at all about it
in the documentation (well don't ask me, I don't have any...).
I certainly think it's a good idea. However, I still think it
should be possible to lock across multiple buffers, to make it
possible to emit larger numbers of vertices at once (for instance
for things like glDrawElements), which, as far as I understand,
just cannot work if you're restricted to one buffer.
Multiples of which buffers are you talking about here?
Well, I'm not really sure about it. But it looked to me like there might
be problems wrt context switching if your vertex data doesn't fit into
one vertex buffer (basically you fill up one buffer, another app another
one, and I'm not too sure offsets and such will be correct). Well maybe
I'm wrong.
Roland
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
