Michael wrote:
>
> On Sat, Feb 09, 2002 at 05:03:31AM +0000, Keith Whitwell wrote:
>
> Thanks for your reply.
>
> > My solution to this would be to always produce Clip coordinates from Model
> > coordinates using the ModelProject matrix ....
>
> Ok. Done.
>
> > Secondly, we need to investigate the software path - is unwanted additional
> > precision somehow sneaking in? It's often appealing to allow GLdouble
>
> I've been looking through _mesa_transform_tab[] et al since I posted I
> can't see anything that doesn't use GLfloat in the MESA_NO_ASM=1 path
> (and the generated asm didn't show anything obvious at a glance)
> similary in the X86 path (dunno about 3DNOW as I've no idea what the
> instructions mean)
>
> > I think some investigation of the demo is required to see if it is expecting
> > something unreasonable or not.
>
> Ok, I think I've glanced at this 'open gl invariance' thing on a web
> site, I'll grab the docs and read it in more detail....probably look at
> why RTCW has problems and see if that's really somewhere else.
>
> Can I change this thread to get your wisdom on another problem?
>
> (chess.c exhibits this)
>
> Scenario : Application is generating a display list firing a lot of
> vertices in a loop something like :-
>
> glBegin(QUAD_STRIP or similar)
> for (...) {
> Normal
> Vertex3f(...)
> ..
> ..
> Vertex3f(....)
> }
> glEnd()
>
> Ok, if the last Vertex() of the loop forces a _tnl_flush_immediate
> because the IM is full the first slot of the next Immediate will get the
> _END.
>
> Problem : When you later execute the list the code considers the last n
> vertices of IM 1 should be copied forward and since slot 3 of IM
> 2 has the first VERT_END, it then tries to render just those n vertices.
>
> Thing is, the emit() loops have unsigned counters, so a check like j<
> count - 3) becomes j < 2^32-1 (also nr+= nr - count is
> zero) (when count = 2 for example)
I've just hit exactly the same problem on the mesa-4-0-branch with the
t_dd_dmatmp.h file (included in radeon_render.c). I fixed it after saying
'doh' by making the tests into things like 'j+3 < count', etc.
> I figure these vertices ideally wouldn't be copied, unless it
> happened in the middle of the for loop, since the next call is glEnd()
> The real problem is not knowing the glEnd() is coming next in advance.
It's hard in general to predict the future.
> This gives a few possible solutions :
>
> a) Fix the j, nr loops. Sounds like fixing the symptom - unless there
> are valid scenarios where the infinite loop may hit.
>
> b) Change the logic in fixup_compiled_primitives (or perhaps earlier in
> _tnl_copy_immediate_vertices) to throw away these vertices if IM slot 3
> is an end, they'll have already been rendered afaict.
>
> c) change the front end api so things like _tnl_Vertex/VERTEXn instead of being
> count = IM->Count++
> store vertex[count]
> check if IM is full
> flush_immediate
> it checks and flushes first
> check if full
> flush_immediate
>
> store vertex[IM->Count++]
This is actually an interesting idea. I don't like the 'stranded end'
immediates, but there are a bunch of other similar oddities that I've felt
just have to be coped with.
> I haven't completely thought this one through, but I'm assuming that as
> 216 is a nice multiple of 2,3, 4 and 6 that currently the chances of an
> IM being flushed exactly before a glEnd() call is high, whereas if there
> is another vertex when IM->Count==216, we really are in the middle of
> something - hmm, but it needs a mechanism to get that IM and
> things that stick in the current slot, like Normal()s could be messy
> (well they'd need to flush).
>
> d) something completely different? ...
My feeling has just been to build it robust enough to cope with flushes
*anywhere*. In the radeon tcl driver, there's a real benefit to being able to
flush before & after material calls, for instance.
Ultimately the whole struct immediate should be taken as 1) a storage
mechanism for display lists and 2) a fallback for immediate mode rendering.
The fact that it is also the normal mechanism for immediate mode rendering in
the existing drivers is more of an accident than anything else - there have
been 2 or 3 efforts to put in a proper, tight, fast immediate mode engine
which have floundered for various reasons. I'm working on a tcl-specific one
at the moment... It's very simple so hopefully it won't suffer the same fate.
Keith
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
