2011/12/21 Mathias Fröhlich <[email protected]>: > > Hi, > > On Wednesday, December 21, 2011 01:58:08 Brian Paul wrote: >> This fixes a regression seen with the isosurf demo when switching between >> glBegin/End and glDrawArrays (do it several times). The problem was the >> driver wasn't getting _NEW_ARRAY when the arrays were subtly changed: >> (vertex3f, normal3f) vs. (normal3f, vertex3f). >> >> This patch fixes that by signaling _NEW_ARRAY whenever we transition >> between glBegin/End and glDrawArrays mode. > > The basic idea should probably work, still preserving the optimization. > But I have two issues/thoughts on that: > > I also think that draw elements and draw arrays should not make a difference. > The array state should be already set dirty by the gl api functions on exactly > these occations where they change the array state. > So, there should be no need to set the array state dirty when switching > between draw arrays and draw elements. > > Additionaly, I think that the dlist draw path in vbo_save_draw.c needs the > same treatment like the the immediate mode draw path in vbo_exec_draw.c.
I'm not sure if "playback_vertex_list" is more like DRAW_BEGIN_END or DRAW_ARRAYS. Maybe add a DRAW_DISPLAY_LIST enum value? >> The patch also fixes up the initialization of the map_vp_none[] array >> to stop putting strange values in the last five elements of the array. > That change should render correct. > > Even if this could still insert the higher numbered generic arrays into the > fixed function enabled arrays where they should not be there. This is just > about the same as any previous sloution did, just with different arrays that > bleed into the generic arrays beyond the last material. I think the code is a bit more understandable now. -Brian _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
