Re: [Dri-devel] fix for i810 issues of late..
Keith Whitwell wrote: Dave Airlie wrote: I think I'll give up for today and go at it again later, perhaps the i810 just can't do this in hardware and I need to fallback or perhaps the number of vertices being output is out by one .. who knows :-) Okay I found it and checked in the fixes for it, the macro expansion was catching the code on ALLOC_VERTS(nr+1) for i810,i830 and mga, these all did nr * x type things, instead of (nr) * x in their ALLOC_VERTS macro expansions.. Funny enough I now know how the mesa vertex code works very well!!! I'll be hiding for a while I think.. my brain is fried... Nice one Dave. It's worth checking the rest of the drivers for this as well. Ah, OK, I see you already have... Keith --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] fix for i810 issues of late..
Dave Airlie wrote: I think I'll give up for today and go at it again later, perhaps the i810 just can't do this in hardware and I need to fallback or perhaps the number of vertices being output is out by one .. who knows :-) Okay I found it and checked in the fixes for it, the macro expansion was catching the code on ALLOC_VERTS(nr+1) for i810,i830 and mga, these all did nr * x type things, instead of (nr) * x in their ALLOC_VERTS macro expansions.. Funny enough I now know how the mesa vertex code works very well!!! I'll be hiding for a while I think.. my brain is fried... Nice one Dave. It's worth checking the rest of the drivers for this as well. Keith --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] fix for i810 issues of late..
> > I think I'll give up for today and go at it again later, perhaps the i810 > just can't do this in hardware and I need to fallback or perhaps the > number of vertices being output is out by one .. who knows :-) Okay I found it and checked in the fixes for it, the macro expansion was catching the code on ALLOC_VERTS(nr+1) for i810,i830 and mga, these all did nr * x type things, instead of (nr) * x in their ALLOC_VERTS macro expansions.. Funny enough I now know how the mesa vertex code works very well!!! I'll be hiding for a while I think.. my brain is fried... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] fix for i810 issues of late..
> > Hi Keith, > > To my untrained eye it looks like the test at the start of the > render_line_loop_verts is incorrect, but maybe I am just covering up the > problem, with this change blender and tri work without my previous > patch... but maybe I'm just moving the issue :-) > > patch below.. apologies to the list and Keith for the noise, but that patch was bogus, still digging it out, it must be an out by one somewhere but I can't see where it is happening ... I'm learning way more about Mesa internals that I ever cared to !!! I think I'll give up for today and go at it again later, perhaps the i810 just can't do this in hardware and I need to fallback or perhaps the number of vertices being output is out by one .. who knows :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] fix for i810 issues of late..
> > I see the code uses LINE_STRIPS to LINE_LOOP but it seems to be > in-correct, well it locks the card, I've no idea if it is correct or not!! Hi Keith, To my untrained eye it looks like the test at the start of the render_line_loop_verts is incorrect, but maybe I am just covering up the problem, with this change blender and tri work without my previous patch... but maybe I'm just moving the issue :-) patch below.. Dave. Index: t_dd_dmatmp.h === RCS file: /cvs/mesa/Mesa/src/mesa/tnl_dd/t_dd_dmatmp.h,v retrieving revision 1.5 diff -u -r1.5 t_dd_dmatmp.h --- t_dd_dmatmp.h 4 Feb 2004 16:59:30 - 1.5 +++ t_dd_dmatmp.h 5 Feb 2004 04:53:25 - @@ -216,9 +216,9 @@ INIT( GL_LINE_STRIP ); if (flags & PRIM_BEGIN) -j = start; - else j = start + 1; + else +j = start; /* Ensure last vertex won't wrap buffers: */ -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] fix for i810 issues of late..
> This is GL_LINE_LOOP? That makes sense. > > > Interesting - this should only be a heuristic to choose the fastest path, not > have any correctness value. Correctness should be ensured by > i810_validate_render, from t_dd_dmatmp.h. Can you try & find out what's going > wrong with that? okay I've figured this out a bit further, the bug is in i810_render_line_loop_verts from t_dd_dmatmp.h choose_render returns GL_FALSE for these because there is no value in hw_prim[2], however validate_render returns GL_TRUE as it just checks whether the hardware has LINE_STRIPS not LINE_LOOP, and then when it uses the i810_render_line_loop_verts function it locks the card up ... I see the code uses LINE_STRIPS to LINE_LOOP but it seems to be in-correct, well it locks the card, I've no idea if it is correct or not!! Dave. p.s. I've checked out the latest version of t_dd_dmatmp.h in case you were going to ask :-) -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] fix for i810 issues of late..
Dave Airlie wrote: Since Keith's tnl_dd_dmatmp.h patches on the 11 Dec last year, the poor i810 has been seriously fubar, I've just gotten time to look at it now (well I've been staring at it on and off for weeks with a blank) The fix is up at http://freedesktop.org/~airlied/i810_render_fix.diff I've taken it from the i830 code, and I've modified scale_prim so that the 3rd element is also a fallback case, This is GL_LINE_LOOP? That makes sense. Keith can you tell me if my numbers are correct for the i810? or at least where you got the numbers for the i830... The number is the number of HW vertices emitted per incoming vertex in the fallback path. So for things like GL_POINTS --> 1 if rendering with a HW point prim --> 4 if rendering with a HW quad or trifan prim (unlikely) --> 6 if rendering with 2 triangles GL_LINES --> 1 if rendered with a HW line prim --> 3 if rendered with 2 tris/line GL_LINE_LOOP GL_LINE_STRIP --> 2 if rendering with HW line prim 6 if rendered with 2 tris/line and so on... if no major objections I'll apply it soon, I'd like to just figure out the values for scale_prim are correct... fixes, blender and tri sample program among others... Interesting - this should only be a heuristic to choose the fastest path, not have any correctness value. Correctness should be ensured by i810_validate_render, from t_dd_dmatmp.h. Can you try & find out what's going wrong with that? Keith --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
