https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #36 from Roland Scheidegger <srol...@vmware.com> 2012-07-26 21:42:26 PDT --- (In reply to comment #33) > Also, IIRC, blender uses GL_SELECT for which is currently always software. > There is a patch to hw accelerate it, but it never made it into master: > http://cgit.freedesktop.org/mesa/mesa/log/?h=hw_gl_select Oh yes that will also cause swrast (I don't know how frequent its use of GL_SELECT vs. some random operation like DrawPixels causing fallbacks is). That patch wouldn't help though for the classic drivers. (In reply to comment #35) > I'm not sure to understand all the facts ( I'm a newbie in opengl/multimedia > programming ), maybe, as you said the best solution would be to modify > Blender, > > but there is one thing I don't understand: why blender is very fast if I use > the software mode for opengl with 8.0.4 mesa lib ( by using the command > "export > LIBGL_ALWAYS_SOFTWARE=1" before running blender ) ? > > is it because only the CPU power works here for opengl instructions and not > the > graphic card ? ( in this case swrast works differently ? ) > > it's weird to see the graphic performances decreasing when I use the normal > mode ( graphic card acceleration ) with Blender and see the exact opposite > when > I use the software mode for opengl operations in mesa 8.0.4 Yes typically you'd expect hardware to be (much) faster. The problem here though is however that (likely) all the drawing operations are fairly cheap, but the graphic chip is doing nothing but constantly copying the buffers from graphic card memory to system memory and back due to these fallbacks. Something you don't have to do if the buffers just stay in system memory because you only use the cpu to access them. And the cost of that is going to kill you - now I don't know what exactly blender is doing but when it crashed the function was called icon_draw_rect(), so it's probably fair to assume this was some simple, small rectangle to draw. Most likely really just a couple of pixels, but the gpu will most likely blit an area corresponding the the whole window from card memory to system memory (and back) for being able to draw these couple of pixels. And if it was drawing say 20 small icons it will copy that whole large buffer 20 times back and forth... Now as said the code in earlier mesa versions didn't have to copy the whole buffers but could copy them partially, so the cost of the fallbacks was generally smaller for cases like this, but on the flipside it didn't quite work right some of the time neither. And the new code makes things easier for swrast itself - the effort has gone to avoid fallbacks whenever possible instead. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
