From: burlen <bur...@gm...> - 2010-01-15 17:22:01
|
I would like to report an issues I see when I replace hardware rendering in my app with mesa. I am new to mesa so I am not sure where the bug lies, in the app or mesa. So I suspect it may be in mesa because hardware rendering works fine , I have doubts because I don't know if the app does anything special when it uses mesa. I hope some one here can say for sure weather or not it's a mesa issue. The issue is strong artifacts appear on the surface of rendering tubes. zooming in makes the artifacts recede to the edges of the tubes but never completely go away. Here is an illustration of the artifacts and a hardware rendering that doesn't have the artifacts. http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-artifacts.png http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-no-artifacts.png By the way, I reproduced on two machines with intel and gcc compiler and two mesa version 7.5.1 and 7.7. |
From: Jeff L. <jef...@us...> - 2010-01-15 18:36:20
|
looks like a depth buffering issue - what happens when you setenv MESA_GLX_DEPTH_BITS 24? On Fri, Jan 15, 2010 at 12:22 PM, burlen <bur...@gm...> wrote: > I would like to report an issues I see when I replace hardware rendering > in my app with mesa. I am new to mesa so I am not sure where the bug > lies, in the app or mesa. So I suspect it may be in mesa because > hardware rendering works fine , I have doubts because I don't know if > the app does anything special when it uses mesa. I hope some one here > can say for sure weather or not it's a mesa issue. > > The issue is strong artifacts appear on the surface of rendering tubes. > zooming in makes the artifacts recede to the edges of the tubes but > never completely go away. Here is an illustration of the artifacts and a > hardware rendering that doesn't have the artifacts. > > > http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-artifacts.png > > http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-no-artifacts.png > > By the way, I reproduced on two machines with intel and gcc compiler and > two mesa version 7.5.1 and 7.7. > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Mesa3d-users mailing list > Mes...@li...<https://mail.google.com/a/cdnorthamerica.com/?view=cm&tf=0&to=Mes...@li...> > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > > |
From: burlen <bur...@gm...> - 2010-01-15 20:01:27
|
Thanks for your help, It didn't make a difference, but I agree it looks like depth buffer issue. Another issue I am seeing in the mesa rendering has to do with inconsistent choice of which tubes are on top. This occurs in parallel rendering only so I didn't mention it before. You can see the inconsistency by comparing the hardware/nvidia and mesa in these images: http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-artifacts-decomp.png http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-no-artifacts-decomp.png Jeff Lee wrote: > looks like a depth buffering issue - what happens when you setenv > MESA_GLX_DEPTH_BITS 24? > > On Fri, Jan 15, 2010 at 12:22 PM, burlen <bur...@gm... > <mailto:bur...@gm...>> wrote: > > I would like to report an issues I see when I replace hardware > rendering > in my app with mesa. I am new to mesa so I am not sure where the bug > lies, in the app or mesa. So I suspect it may be in mesa because > hardware rendering works fine , I have doubts because I don't know if > the app does anything special when it uses mesa. I hope some one here > can say for sure weather or not it's a mesa issue. > > The issue is strong artifacts appear on the surface of rendering > tubes. > zooming in makes the artifacts recede to the edges of the tubes but > never completely go away. Here is an illustration of the artifacts > and a > hardware rendering that doesn't have the artifacts. > > http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-artifacts.png > http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-no-artifacts.png > > By the way, I reproduced on two machines with intel and gcc > compiler and > two mesa version 7.5.1 and 7.7. > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently > attracts the > world's best and brightest in the field, creating opportunities > for Conference > attendees to learn about information security's most important > issues through > interactions with peers, luminaries and emerging and established > companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > <https://mail.google.com/a/cdnorthamerica.com/?view=cm&tf=0&to=Mes...@li...> > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > > |
From: tom f. <tf...@al...> - 2010-01-17 02:48:50
|
Hi Burlen! Hope you're doing well. burlen <bur...@gm...> writes: > Thanks for your help, > It didn't make a difference, but I agree it looks like depth buffer > issue. I think you should file a bug, not all the Mesa devs follow this list. https://bugs.freedesktop.org/ A (very unlikely to be enlightening) thing to try is to export: LIBGL_ALWAYS_SOFTWARE=1 LIBGL_ALWAYS_INDIRECT=1 MESA_DEBUG=1 and re-run. Other than the libtxc warning, any errors you see on your terminal may be relevant. > Another issue I am seeing in the mesa rendering has to do with > inconsistent choice of which tubes are on top. This occurs in > parallel rendering only so I didn't mention it before. You can see > the inconsistency by comparing the hardware/nvidia and mesa in these > images: > > http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-artifacts > -decomp.png > http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-no-arti > facts-decomp.png It looks like these are changing per-tile -- you can see the obvious banding along the rightmost streamlines. Does enabing/disabling IceT in ParaView solve the problem? I'm guessing that will change how PV does load decomposition as well, but if not you might want to play with those settings. Best, -tom > Jeff Lee wrote: > > looks like a depth buffering issue - what happens when you setenv > > MESA_GLX_DEPTH_BITS 24? > > > > On Fri, Jan 15, 2010 at 12:22 PM, burlen <bur...@gm... > > <mailto:bur...@gm...>> wrote: > > > > I would like to report an issues I see when I replace hardware > > rendering > > in my app with mesa. I am new to mesa so I am not sure where the bug > > lies, in the app or mesa. So I suspect it may be in mesa because > > hardware rendering works fine , I have doubts because I don't know if > > the app does anything special when it uses mesa. I hope some one here > > can say for sure weather or not it's a mesa issue. > > > > The issue is strong artifacts appear on the surface of rendering > > tubes. > > zooming in makes the artifacts recede to the edges of the tubes but > > never completely go away. Here is an illustration of the artifacts > > and a > > hardware rendering that doesn't have the artifacts. > > > > http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-art > ifacts.png > > http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-n > o-artifacts.png > > > > By the way, I reproduced on two machines with intel and gcc > > compiler and > > two mesa version 7.5.1 and 7.7. > > > > ----------------------------------------------------------------------- > ------- > > Throughout its 18-year history, RSA Conference consistently > > attracts the > > world's best and brightest in the field, creating opportunities > > for Conference > > attendees to learn about information security's most important > > issues through > > interactions with peers, luminaries and emerging and established > > companies. > > http://p.sf.net/sfu/rsaconf-dev2dev > > _______________________________________________ > > Mesa3d-users mailing list > > Mes...@li... > > <https://mail.google.com/a/cdnorthamerica.com/?view=cm&tf=0&to=Mesa3d-u > se...@li...> > > https://lists.sourceforge.net/lists/listinfo/mesa3d-users |
From: burlen <bur...@gm...> - 2010-01-19 23:18:13
|
Hi Tom, many thanks for responding, I played with the environment vars you mentioned and I'm seeing a whole bunch of the following coming from where VTK puts the camera matrix in to the matrix stack. I don't know weather or not to be worried. Burlen Mesa: User error: GL_INVALID_OPERATION in glReadBuffer(buffer=0x405) Breakpoint 2, _mesa_ReadBuffer (buffer=1028) at main/buffers.c:519 519 _mesa_readbuffer(ctx, buffer, srcBuffer); Current language: auto The current source language is "auto; currently c". (gdb) where #0 _mesa_ReadBuffer (buffer=1028) at main/buffers.c:519 #1 0x00007fffeb32cbb3 in vtkOpenGLCamera::Render (this=0xb4b330, ren=0xae8aa0) at /home/burlen/ext/ParaView/ParaView3/VTK/Rendering/vtkOpenGLCamera.cxx:108 102 { 103 glDrawBuffer(static_cast<GLenum>(win->GetFrontBuffer())); 104 105 // Reading front buffer means front left. see OpenGL spec. 106 // because one can write to two buffers at a time but can only read from 107 // one buffer at a time. 108 glReadBuffer(static_cast<GLenum>(win->GetFrontBuffer())); 109 } #2 0x00007fffeb26b9c6 in vtkRenderer::UpdateCamera (this=0xae8aa0) at /home/burlen/ext/ParaView/ParaView3/VTK/Rendering/vtkRenderer.cxx:441 #3 0x00007fffeb360546 in vtkOpenGLRenderer::DeviceRender (this=0xae8aa0) at /home/burlen/ext/ParaView/ParaView3/VTK/Rendering/vtkOpenGLRenderer.cxx:236 #4 0x00007fffeb26b48c in vtkRenderer::Render (this=0xae8aa0) at /home/burlen/ext/ParaView/ParaView3/VTK/Rendering/vtkRenderer.cxx:336 #5 0x00007fffeb268d3c in vtkRendererCollection::Render (this=0xae8460) at /home/burlen/ext/ParaView/ParaView3/VTK/Rendering/vtkRendererCollection.cxx:52 #6 0x00007fffeb27f892 in vtkRenderWindow::DoStereoRender (this=0xae8530) at /home/burlen/ext/ParaView/ParaView3/VTK/Rendering/vtkRenderWindow.cxx:708 #7 0x00007fffeb27f79a in vtkRenderWindow::DoFDRender (this=0xae8530) at /home/burlen/ext/ParaView/ParaView3/VTK/Rendering/vtkRenderWindow.cxx:677 #8 0x00007fffeb27f251 in vtkRenderWindow::DoAARender (this=0xae8530) at /home/burlen/ext/ParaView/ParaView3/VTK/Rendering/vtkRenderWindow.cxx:564 #9 0x00007fffeb27e827 in vtkRenderWindow::Render (this=0xae8530) at /home/burlen/ext/ParaView/ParaView3/VTK/Rendering/vtkRenderWindow.cxx:377 #10 0x00007fffeb3b7f99 in vtkXOpenGLRenderWindow::Render (this=0xae8530) at /home/burlen/ext/ParaView/ParaView3/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1846 #11 0x00007fffecd9a0eb in vtkParallelRenderManager::RenderRMI (this=0xad6a80) at /home/burlen/ext/ParaView/ParaView3/VTK/Parallel/vtkParallelRenderManager.cxx:757 #12 0x00007ffff75f66de in vtkPVClientServerRenderManager::RenderRMI (this=0xad6a80) at /home/burlen/ext/ParaView/ParaView3/Servers/Filters/vtkPVClientServerRenderManager.h:55 #13 0x00007ffff75f53eb in RenderRMI (arg=0xad6a80) at /home/burlen/ext/ParaView/ParaView3/Servers/Filters/vtkPVClientServerRenderManager.cxx:57 #14 0x00007fffeccdc47a in vtkMultiProcessController::ProcessRMI (this=0xad3200, remoteProcessId=1, arg=0x0, argLength=0, rmiTag=34532) at /home/burlen/ext/ParaView/ParaView3/VTK/Parallel/vtkMultiProcessController.cxx:699 #15 0x00007fffeccdc1d8 in vtkMultiProcessController::ProcessRMIs (this=0xad3200, reportErrors=0, dont_loop=1) at /home/burlen/ext/ParaView/ParaView3/VTK/Parallel/vtkMultiProcessController.cxx:647 #16 0x00007ffff7b6279a in vtkRemoteConnection::ProcessCommunication (this=0xac4d40) at /home/burlen/ext/ParaView/ParaView3/Servers/Common/vtkRemoteConnection.cxx:75 #17 0x00007ffff7af424c in vtkProcessModuleConnectionManager::MonitorConnections (this=0x93e170, msec=0) at /home/burlen/ext/ParaView/ParaView3/Servers/Common/vtkProcessModuleConnectionManager.cxx:429 #18 0x00007ffff7afd1a6 in vtkProcessModule::StartServer (this=0x64d700, msec=0) at /home/burlen/ext/ParaView/ParaView3/Servers/Common/vtkProcessModule.cxx:444 #19 0x00007ffff7afcc2f in vtkProcessModule::Start (this=0x64d700, argc=1, argv=0x64be80) at /home/burlen/ext/ParaView/ParaView3/Servers/Common/vtkProcessModule.cxx:355 #20 0x00007ffff763d845 in vtkPVMain::Run (this=0x64a990, options=0x64b960) at /home/burlen/ext/ParaView/ParaView3/Servers/Filters/vtkPVMain.cxx:273 #21 0x000000000040131f in main (argc=2, argv=0x7fffffffde98) at /home/burlen/ext/ParaView/ParaView3/Servers/Executables/pvserver.cxx:45 tom fogal wrote: > Hi Burlen! Hope you're doing well. > > burlen <bur...@gm...> writes: > >> Thanks for your help, >> It didn't make a difference, but I agree it looks like depth buffer >> issue. >> > > I think you should file a bug, not all the Mesa devs follow this list. > > https://bugs.freedesktop.org/ > > A (very unlikely to be enlightening) thing to try is to export: > > LIBGL_ALWAYS_SOFTWARE=1 > LIBGL_ALWAYS_INDIRECT=1 > MESA_DEBUG=1 > > and re-run. Other than the libtxc warning, any errors you see on your > terminal may be relevant. > > >> Another issue I am seeing in the mesa rendering has to do with >> inconsistent choice of which tubes are on top. This occurs in >> parallel rendering only so I didn't mention it before. You can see >> the inconsistency by comparing the hardware/nvidia and mesa in these >> images: >> >> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-artifacts >> -decomp.png >> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-no-arti >> facts-decomp.png >> > > It looks like these are changing per-tile -- you can see the obvious > banding along the rightmost streamlines. Does enabing/disabling IceT > in ParaView solve the problem? I'm guessing that will change how PV > does load decomposition as well, but if not you might want to play with > those settings. > > Best, > > -tom > > >> Jeff Lee wrote: >> >>> looks like a depth buffering issue - what happens when you setenv >>> MESA_GLX_DEPTH_BITS 24? >>> >>> On Fri, Jan 15, 2010 at 12:22 PM, burlen <bur...@gm... >>> <mailto:bur...@gm...>> wrote: >>> >>> I would like to report an issues I see when I replace hardware >>> rendering >>> in my app with mesa. I am new to mesa so I am not sure where the bug >>> lies, in the app or mesa. So I suspect it may be in mesa because >>> hardware rendering works fine , I have doubts because I don't know if >>> the app does anything special when it uses mesa. I hope some one here >>> can say for sure weather or not it's a mesa issue. >>> >>> The issue is strong artifacts appear on the surface of rendering >>> tubes. >>> zooming in makes the artifacts recede to the edges of the tubes but >>> never completely go away. Here is an illustration of the artifacts >>> and a >>> hardware rendering that doesn't have the artifacts. >>> >>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-art >>> >> ifacts.png >> >>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-n >>> >> o-artifacts.png >> >>> By the way, I reproduced on two machines with intel and gcc >>> compiler and >>> two mesa version 7.5.1 and 7.7. >>> >>> ----------------------------------------------------------------------- >>> >> ------- >> >>> Throughout its 18-year history, RSA Conference consistently >>> attracts the >>> world's best and brightest in the field, creating opportunities >>> for Conference >>> attendees to learn about information security's most important >>> issues through >>> interactions with peers, luminaries and emerging and established >>> companies. >>> http://p.sf.net/sfu/rsaconf-dev2dev >>> _______________________________________________ >>> Mesa3d-users mailing list >>> Mes...@li... >>> <https://mail.google.com/a/cdnorthamerica.com/?view=cm&tf=0&to=Mesa3d-u >>> >> se...@li...> >> >>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >>> |
From: tom f. <tf...@al...> - 2010-01-19 23:39:15
|
burlen <bur...@gm...> writes: > Hi Tom, many thanks for responding, > > I played with the environment vars you mentioned and I'm seeing a > whole bunch of the following coming from where VTK puts the camera > matrix in to the matrix stack. I don't know weather or not to be > worried. > > Mesa: User error: GL_INVALID_OPERATION in glReadBuffer(buffer=0x405) > > Breakpoint 2, _mesa_ReadBuffer (buffer=1028) at main/buffers.c:519 > 519 _mesa_readbuffer(ctx, buffer, srcBuffer); Yeah, I get this error all the time in my current GPU VR pipeline. That seems to work, so the error is non-critical at least. Though I do go behind VTK's back a bit and pull out the rug.. Anyway, if the read buffer was wrong you're most likely to see *nothing* instead of the artifacts you're encountering, so I don't think this is the root issue. I'm still curious if fiddling IceT on/off has an effect, though... Another option would be to make something in the scene have just a smidgen of transparency. That should force ParaView to sort everything, instead of relying on a painter's alg, and thus it might workaround the issue. -tom > tom fogal wrote: > > Hi Burlen! Hope you're doing well. > > > > burlen <bur...@gm...> writes: > > > >> Thanks for your help, > >> It didn't make a difference, but I agree it looks like depth buffer > >> issue. > >> > > > > I think you should file a bug, not all the Mesa devs follow this list. > > > > https://bugs.freedesktop.org/ > > > > A (very unlikely to be enlightening) thing to try is to export: > > > > LIBGL_ALWAYS_SOFTWARE=1 > > LIBGL_ALWAYS_INDIRECT=1 > > MESA_DEBUG=1 > > > > and re-run. Other than the libtxc warning, any errors you see on your > > terminal may be relevant. > > > > > >> Another issue I am seeing in the mesa rendering has to do with > >> inconsistent choice of which tubes are on top. This occurs in > >> parallel rendering only so I didn't mention it before. You can see > >> the inconsistency by comparing the hardware/nvidia and mesa in these > >> images: > >> > >> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-artifa > cts > >> -decomp.png > >> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-no-a > rti > >> facts-decomp.png > >> > > > > It looks like these are changing per-tile -- you can see the obvious > > banding along the rightmost streamlines. Does enabing/disabling IceT > > in ParaView solve the problem? I'm guessing that will change how PV > > does load decomposition as well, but if not you might want to play with > > those settings. > > > > Best, > > > > -tom > > > > > >> Jeff Lee wrote: > >> > >>> looks like a depth buffering issue - what happens when you setenv > >>> MESA_GLX_DEPTH_BITS 24? > >>> > >>> On Fri, Jan 15, 2010 at 12:22 PM, burlen <bur...@gm... > >>> <mailto:bur...@gm...>> wrote: > >>> > >>> I would like to report an issues I see when I replace hardware > >>> rendering > >>> in my app with mesa. I am new to mesa so I am not sure where the bug > >>> lies, in the app or mesa. So I suspect it may be in mesa because > >>> hardware rendering works fine , I have doubts because I don't know if > >>> the app does anything special when it uses mesa. I hope some one here > >>> can say for sure weather or not it's a mesa issue. > >>> > >>> The issue is strong artifacts appear on the surface of rendering > >>> tubes. > >>> zooming in makes the artifacts recede to the edges of the tubes but > >>> never completely go away. Here is an illustration of the artifacts > >>> and a > >>> hardware rendering that doesn't have the artifacts. > >>> > >>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-a > rt > >>> > >> ifacts.png > >> > >>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia > -n > >>> > >> o-artifacts.png > >> > >>> By the way, I reproduced on two machines with intel and gcc > >>> compiler and > >>> two mesa version 7.5.1 and 7.7. > >>> > >>> --------------------------------------------------------------------- > -- > >>> > >> ------- > >> > >>> Throughout its 18-year history, RSA Conference consistently > >>> attracts the > >>> world's best and brightest in the field, creating opportunities > >>> for Conference > >>> attendees to learn about information security's most important > >>> issues through > >>> interactions with peers, luminaries and emerging and established > >>> companies. > >>> http://p.sf.net/sfu/rsaconf-dev2dev > >>> _______________________________________________ > >>> Mesa3d-users mailing list > >>> Mes...@li... > >>> <https://mail.google.com/a/cdnorthamerica.com/?view=cm&tf=0&to=Mesa3d > -u > >>> > >> se...@li...> > >> > >>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users > >>> > |
From: burlen <bur...@gm...> - 2010-01-20 02:03:02
|
Doesn't PV use IceT all the time? I mean even for serial rendering , I'm sure its used in parallel rendering. Transparency is currently crashing it :) that's a PV bug. tom fogal wrote: > burlen <bur...@gm...> writes: > >> Hi Tom, many thanks for responding, >> >> I played with the environment vars you mentioned and I'm seeing a >> whole bunch of the following coming from where VTK puts the camera >> matrix in to the matrix stack. I don't know weather or not to be >> worried. >> >> Mesa: User error: GL_INVALID_OPERATION in glReadBuffer(buffer=0x405) >> >> Breakpoint 2, _mesa_ReadBuffer (buffer=1028) at main/buffers.c:519 >> 519 _mesa_readbuffer(ctx, buffer, srcBuffer); >> > > Yeah, I get this error all the time in my current GPU VR pipeline. > That seems to work, so the error is non-critical at least. Though I do > go behind VTK's back a bit and pull out the rug.. Anyway, if the read > buffer was wrong you're most likely to see *nothing* instead of the > artifacts you're encountering, so I don't think this is the root issue. > > I'm still curious if fiddling IceT on/off has an effect, though... > > Another option would be to make something in the scene have just > a smidgen of transparency. That should force ParaView to sort > everything, instead of relying on a painter's alg, and thus it might > workaround the issue. > > -tom > > >> tom fogal wrote: >> >>> Hi Burlen! Hope you're doing well. >>> >>> burlen <bur...@gm...> writes: >>> >>> >>>> Thanks for your help, >>>> It didn't make a difference, but I agree it looks like depth buffer >>>> issue. >>>> >>>> >>> I think you should file a bug, not all the Mesa devs follow this list. >>> >>> https://bugs.freedesktop.org/ >>> >>> A (very unlikely to be enlightening) thing to try is to export: >>> >>> LIBGL_ALWAYS_SOFTWARE=1 >>> LIBGL_ALWAYS_INDIRECT=1 >>> MESA_DEBUG=1 >>> >>> and re-run. Other than the libtxc warning, any errors you see on your >>> terminal may be relevant. >>> >>> >>> >>>> Another issue I am seeing in the mesa rendering has to do with >>>> inconsistent choice of which tubes are on top. This occurs in >>>> parallel rendering only so I didn't mention it before. You can see >>>> the inconsistency by comparing the hardware/nvidia and mesa in these >>>> images: >>>> >>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-artifa >>>> >> cts >> >>>> -decomp.png >>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-no-a >>>> >> rti >> >>>> facts-decomp.png >>>> >>>> >>> It looks like these are changing per-tile -- you can see the obvious >>> banding along the rightmost streamlines. Does enabing/disabling IceT >>> in ParaView solve the problem? I'm guessing that will change how PV >>> does load decomposition as well, but if not you might want to play with >>> those settings. >>> >>> Best, >>> >>> -tom >>> >>> >>> >>>> Jeff Lee wrote: >>>> >>>> >>>>> looks like a depth buffering issue - what happens when you setenv >>>>> MESA_GLX_DEPTH_BITS 24? >>>>> >>>>> On Fri, Jan 15, 2010 at 12:22 PM, burlen <bur...@gm... >>>>> <mailto:bur...@gm...>> wrote: >>>>> >>>>> I would like to report an issues I see when I replace hardware >>>>> rendering >>>>> in my app with mesa. I am new to mesa so I am not sure where the bug >>>>> lies, in the app or mesa. So I suspect it may be in mesa because >>>>> hardware rendering works fine , I have doubts because I don't know if >>>>> the app does anything special when it uses mesa. I hope some one here >>>>> can say for sure weather or not it's a mesa issue. >>>>> >>>>> The issue is strong artifacts appear on the surface of rendering >>>>> tubes. >>>>> zooming in makes the artifacts recede to the edges of the tubes but >>>>> never completely go away. Here is an illustration of the artifacts >>>>> and a >>>>> hardware rendering that doesn't have the artifacts. >>>>> >>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-a >>>>> >> rt >> >>>>> >>>>> >>>> ifacts.png >>>> >>>> >>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia >>>>> >> -n >> >>>>> >>>>> >>>> o-artifacts.png >>>> >>>> >>>>> By the way, I reproduced on two machines with intel and gcc >>>>> compiler and >>>>> two mesa version 7.5.1 and 7.7. >>>>> >>>>> --------------------------------------------------------------------- >>>>> >> -- >> >>>>> >>>>> >>>> ------- >>>> >>>> >>>>> Throughout its 18-year history, RSA Conference consistently >>>>> attracts the >>>>> world's best and brightest in the field, creating opportunities >>>>> for Conference >>>>> attendees to learn about information security's most important >>>>> issues through >>>>> interactions with peers, luminaries and emerging and established >>>>> companies. >>>>> http://p.sf.net/sfu/rsaconf-dev2dev >>>>> _______________________________________________ >>>>> Mesa3d-users mailing list >>>>> Mes...@li... >>>>> <https://mail.google.com/a/cdnorthamerica.com/?view=cm&tf=0&to=Mesa3d >>>>> >> -u >> >>>>> >>>>> >>>> se...@li...> >>>> >>>> >>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >>>>> >>>>> |
From: tom f. <tf...@al...> - 2010-01-20 02:53:02
|
burlen <bur...@gm...> writes: > Doesn't PV use IceT all the time? I mean even for serial rendering, > I'm sure its used in parallel rendering. No idea, haven't loaded up PV in many a year. However, PV has been around longer than IceT, AFAIK, so I was just assuming that there was previously some home-brewed compositing code in there that you could enable to test with. W.r.t. serial, I've got no idea, but it would seem a little silly to require IceT because of the MPI requirement. > Transparency is currently crashing it :) that's a PV bug. Hrm. Sad face. It's ambiguous to me where the problem lies. One simple thing you could try is to fiddle with your version of Mesa and see if you can show that this is a regression. Maybe the PV team has some ideas on how you can fiddle with the compositing code, and you could thereby prove/disprove the problem lies there. -tom > tom fogal wrote: > > burlen <bur...@gm...> writes: > > > >> Hi Tom, many thanks for responding, > >> > >> I played with the environment vars you mentioned and I'm seeing a > >> whole bunch of the following coming from where VTK puts the camera > >> matrix in to the matrix stack. I don't know weather or not to be > >> worried. > >> > >> Mesa: User error: GL_INVALID_OPERATION in glReadBuffer(buffer=0x405) > >> > >> Breakpoint 2, _mesa_ReadBuffer (buffer=1028) at main/buffers.c:519 > >> 519 _mesa_readbuffer(ctx, buffer, srcBuffer); > >> > > > > Yeah, I get this error all the time in my current GPU VR pipeline. > > That seems to work, so the error is non-critical at least. Though I do > > go behind VTK's back a bit and pull out the rug.. Anyway, if the read > > buffer was wrong you're most likely to see *nothing* instead of the > > artifacts you're encountering, so I don't think this is the root issue. > > > > I'm still curious if fiddling IceT on/off has an effect, though... > > > > Another option would be to make something in the scene have just > > a smidgen of transparency. That should force ParaView to sort > > everything, instead of relying on a painter's alg, and thus it might > > workaround the issue. > > > > -tom > > > > > >> tom fogal wrote: > >> > >>> Hi Burlen! Hope you're doing well. > >>> > >>> burlen <bur...@gm...> writes: > >>> > >>> > >>>> Thanks for your help, > >>>> It didn't make a difference, but I agree it looks like depth buffer > >>>> issue. > >>>> > >>>> > >>> I think you should file a bug, not all the Mesa devs follow this list. > >>> > >>> https://bugs.freedesktop.org/ > >>> > >>> A (very unlikely to be enlightening) thing to try is to export: > >>> > >>> LIBGL_ALWAYS_SOFTWARE=1 > >>> LIBGL_ALWAYS_INDIRECT=1 > >>> MESA_DEBUG=1 > >>> > >>> and re-run. Other than the libtxc warning, any errors you see on your > >>> terminal may be relevant. > >>> > >>> > >>> > >>>> Another issue I am seeing in the mesa rendering has to do with > >>>> inconsistent choice of which tubes are on top. This occurs in > >>>> parallel rendering only so I didn't mention it before. You can see > >>>> the inconsistency by comparing the hardware/nvidia and mesa in these > >>>> images: > >>>> > >>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-arti > fa > >>>> > >> cts > >> > >>>> -decomp.png > >>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-no > -a > >>>> > >> rti > >> > >>>> facts-decomp.png > >>>> > >>>> > >>> It looks like these are changing per-tile -- you can see the obvious > >>> banding along the rightmost streamlines. Does enabing/disabling IceT > >>> in ParaView solve the problem? I'm guessing that will change how PV > >>> does load decomposition as well, but if not you might want to play with > >>> those settings. > >>> > >>> Best, > >>> > >>> -tom > >>> > >>> > >>> > >>>> Jeff Lee wrote: > >>>> > >>>> > >>>>> looks like a depth buffering issue - what happens when you setenv > >>>>> MESA_GLX_DEPTH_BITS 24? > >>>>> > >>>>> On Fri, Jan 15, 2010 at 12:22 PM, burlen <bur...@gm... > >>>>> <mailto:bur...@gm...>> wrote: > >>>>> > >>>>> I would like to report an issues I see when I replace hardware > >>>>> rendering > >>>>> in my app with mesa. I am new to mesa so I am not sure where the bu > g > >>>>> lies, in the app or mesa. So I suspect it may be in mesa because > >>>>> hardware rendering works fine , I have doubts because I don't know > if > >>>>> the app does anything special when it uses mesa. I hope some one he > re > >>>>> can say for sure weather or not it's a mesa issue. > >>>>> > >>>>> The issue is strong artifacts appear on the surface of rendering > >>>>> tubes. > >>>>> zooming in makes the artifacts recede to the edges of the tubes but > >>>>> never completely go away. Here is an illustration of the artifacts > >>>>> and a > >>>>> hardware rendering that doesn't have the artifacts. > >>>>> > >>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa > -a > >>>>> > >> rt > >> > >>>>> > >>>>> > >>>> ifacts.png > >>>> > >>>> > >>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvid > ia > >>>>> > >> -n > >> > >>>>> > >>>>> > >>>> o-artifacts.png > >>>> > >>>> > >>>>> By the way, I reproduced on two machines with intel and gcc > >>>>> compiler and > >>>>> two mesa version 7.5.1 and 7.7. > >>>>> > >>>>> ------------------------------------------------------------------- > -- > >>>>> > >> -- > >> > >>>>> > >>>>> > >>>> ------- > >>>> > >>>> > >>>>> Throughout its 18-year history, RSA Conference consistently > >>>>> attracts the > >>>>> world's best and brightest in the field, creating opportunities > >>>>> for Conference > >>>>> attendees to learn about information security's most important > >>>>> issues through > >>>>> interactions with peers, luminaries and emerging and established > >>>>> companies. > >>>>> http://p.sf.net/sfu/rsaconf-dev2dev > >>>>> _______________________________________________ > >>>>> Mesa3d-users mailing list > >>>>> Mes...@li... > >>>>> <https://mail.google.com/a/cdnorthamerica.com/?view=cm&tf=0&to=Mesa > 3d > >>>>> > >> -u > >> > >>>>> > >>>>> > >>>> se...@li...> > >>>> > >>>> > >>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users > >>>>> > >>>>> > |
From: burlen <bur...@gm...> - 2010-01-28 16:51:26
|
> My (old) VTK is using OSMesaCreateContext() to establish the OSMesa > context. Try changing this to OSMesaCreateContextExt(). This will > allow you to explicitly say how big you want your depth buffer to > be. Make it 32, of course. I was just looking through the code in > Mesa master, and it appears the above environment variables *aren't* > respected by *OS*Mesa, so this is probably the only way to increase > your depth. I just got a chance to get back to this. Good call man!! OSMesa defaults to 16 bit depth buffer. Explicitly requesting 32 fixed both the tiling and artifacts issues. This VTK's fault for not explicitly requesting 32 bits depth buffer (the code may be older than OSMesaCreateContextExt). Thanks again Burlen tom fogal wrote: > burlen <bur...@gm...> writes: > >>> However, there's a second artifact that only exists in the parallel >>> case, and is suspiciously aligned, as if it is related to the >>> screen-space decomposition. Ref. my amazing gimp skills in the >>> attached image. >>> >> Agreed. Totally. There are two distinct bugs here 1) artifacts 2) >> tiling. >> >> I kind of wonder if can reproduce 1) outside of PV using only VTK. I >> also wonder if it has something to do with the data, how small the >> polys are or how small the stream line segments are or something like >> that. I'll look into this. >> > > That would be enlightening. Particularly if you could get a > single-file test case, it would be a good thing to attach to the Mesa > bug. > > >>> It's entirely possible that we *are* seeing the image space >>> decomposition, and its just different processors making subtly >>> different choices, and it would all go away with a higher res Z >>> buffer. >>> >> Yeah, it really does look like different processes making a different >> choice due to accumulated round off error. >> >> >>> Try exporting MESA_GLX_DEPTH_BITS=32. >>> >> No change. can we say for sure mesa is using 32 bits? glxinfo says >> its available. >> > > There's also MESA_RGB_VISUAL, to hint at a particular visual. I had a > big paragraph explaining things here, but then -- > > Ahh, but it appears I've been totally off -- you're using OSMesa, not > mangled xlib Mesa, right? All of this Xlib and Mesa visual stuff is > going to be irrelevant, then. Very sorry. > > My (old) VTK is using OSMesaCreateContext() to establish the OSMesa > context. Try changing this to OSMesaCreateContextExt(). This will > allow you to explicitly say how big you want your depth buffer to > be. Make it 32, of course. I was just looking through the code in > Mesa master, and it appears the above environment variables *aren't* > respected by *OS*Mesa, so this is probably the only way to increase > your depth. > > This is all in vtkXOpenGLRenderWindow. > > -tom > > >> tom fogal wrote: >> >>> burlen <bur...@gm...> writes: >>> >>> >>>> From: "Moreland, Kenneth" <km...@sa...> >>>> To: burlen <bur...@gm...> >>>> cc: paraview <par...@pa...> >>>> Date: Mon, 18 Jan 2010 11:52:08 -0700 >>>> Subject: Re: [Paraview] tube filter, surfaces aren't closed? >>>> >>>> I'm guessing that this is a z-buffer precision issue. The nVidia >>>> card must= be using a higher precision z-buffer or doing something >>>> else that is preventing the z-fighting that appears to be happening >>>> in the Mesa implementation. >>>> >>>> >>> I do think a depth buffer issue is very likely here. >>> >>> However, there's a second artifact that only exists in the parallel >>> case, and is suspiciously aligned, as if it is related to the >>> screen-space decomposition. Ref. my amazing gimp skills in the >>> attached image. >>> >>> Note that those lines continue across large swaths of the image. >>> >>> OTOH, if this was actually a composition issue, I would expect to see >>> *vertical* lines in addition to horizontal ones. Unless PV is using >>> full-width tiles, which wouldn't be a bad idea. >>> >>> It's entirely possible that we *are* seeing the image space >>> decomposition, and its just different processors making subtly >>> different choices, and it would all go away with a higher res Z buffer. >>> >>> Try exporting MESA_GLX_DEPTH_BITS=32. >>> >>> -tom >>> >>> >>> >>>> On 1/18/10 11:47 AM, "burlen" <bur...@gm...> wrote: >>>> >>>> Yes, that is the case. There are 200 lines , each a single cell , and >>>> the pvtp reader splits them up fairly evenly amongst processes to begin >>>> with. D3 is moving stuff around but it doesn't noticeably change the resul >>>> >> t= >> >>>> . >>>> >>>> Moreland, Kenneth wrote: >>>> >>>> >>>>> Looking at the mesa-artifacts-decomp.png image, it appears that >>>>> you have many tubes that are coincident (or at least close to >>>>> coincident). There might be z-buffer resolution problems. What >>>>> happens if you run the geometry through D3? >>>>> >>>>> -Ken >>>>> >>>>> >>>>> On 1/15/10 10:28 AM, "burlen" <bur...@gm...> wrote: >>>>> >>>>> FYI, I re-organized the images illustrating the bug, and made a >>>>> comparison of nvidia to mesa rendering on two cases 1) the >>>>> artifacts 2) >>>>> the parallel inconsistency, and removed the older images. >>>>> >>>>> 1) >>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-a >>>>> >> = >> >>>>> >>>>> >>>> rtifacts.png >>>> >>>> >>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia >>>>> >> = >> >>>>> >>>>> >>>> -no-artifacts-decomp.png >>>> >>>> >>>>> 2) >>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-a >>>>> >> = >> >>>>> >>>>> >>>> rtifacts-decomp.png >>>> >>>> >>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia >>>>> >> = >> >>>>> >>>>> >>>> -no-artifacts.png >>>> >>>> >>>>> burlen wrote: >>>>> > So you are right these are artifacts not holes. Nasty looking ones >>>>> >> = >> >>>>> >>>>> >>>> at >>>> >>>> >>>>> > that. zooming in enough makes the artifacts receded toward the egde >>>>> >> = >> >>>>> >>>>> >>>> s >>>> >>>> >>>>> > of the tube. After some experimentation I'm finding that this has >>>>> > something to do with mesa. It is reproducible only when using mesa. >>>>> > Hardware rendering works fine, no artifacts. >>>>> > >>>>> > There also looks to be two things going on, 1) the artifacts, 2) >>>>> > inconsistent selection of the visible faces on parallel runs. >>>>> This is >>>>> > shown here: >>>>> > http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/deco >>>>> >> = >> >>>>> >>>>> >>>> mp-8-procs.png >>>> >>>> >>>>> > >>>>> > >>>>> > I was using PV on this cluster fine back in dec to make very simila >>>>> >> = >> >>>>> >>>>> >>>> r >>>> >>>> >>>>> > figures with stream tubes and didn't see any of these issues... >>>>> > >>>>> > I added the dataset to reproduce to the bug report. >>>>> > >>>>> > Moreland, Kenneth wrote: >>>>> >> It could be a rendering artifact. What happens when you zoom into >>>>> >> the problem area? >>>>> >> >>>>> >> -Ken >>>>> >> >>>>> >> >>>>> >> On 1/14/10 12:24 AM, "burlen" <bur...@gm...> wrote: >>>>> >> >>>>> >> Any ideas as to why tubes from the tube filter aren't closed >>>>> >> surfaces >>>>> >> now? screenshot: >>>>> >> http://public.kitware.com/Bug/view.php?id=3D10139 >>>>> >>>>> >>> #image/png [artifacts.png] artifacts.png >>> >>> tom fogal wrote: > burlen <bur...@gm...> writes: > >> Doesn't PV use IceT all the time? I mean even for serial rendering , I'm >> sure its used in parallel rendering. >> Transparency is currently crashing it :) that's a PV bug. >> > > Hey, this was starting to look like a PV support thread, so I think > it's appropriate to take it off the Mesa ML until we can narrow down > where the problem lies. > > IceT has a variety of strategies that one can apply. PV almost > definitely defaults to ICET_STRATEGY_REDUCE, but attempting > ICET_STRATEGY_SERIAL might be a good test. That said, IceT's pretty > solid code and not changing much, so I'd be a surprised if the issue > was there. > > You might also try a single-domain dataset in PV; the parallelization > case for that is likely to be very different. Obviously that might not > be valid/a good method given your data, but it could help to weed out a > parallel processing PV issue. > > Take all of this with a grain of salt ;) I'm applying VisIt debugging > techniques / implementation guesses to ParaView, which is sketchy at > best <g>. > > Wherever you bring this thread, please keep me CC'd. > > Best, > > -tom > > >> tom fogal wrote: >> >>> burlen <bur...@gm...> writes: >>> >>> >>>> Hi Tom, many thanks for responding, >>>> >>>> I played with the environment vars you mentioned and I'm seeing a >>>> whole bunch of the following coming from where VTK puts the camera >>>> matrix in to the matrix stack. I don't know weather or not to be >>>> worried. >>>> >>>> Mesa: User error: GL_INVALID_OPERATION in glReadBuffer(buffer=0x405) >>>> >>>> Breakpoint 2, _mesa_ReadBuffer (buffer=1028) at main/buffers.c:519 >>>> 519 _mesa_readbuffer(ctx, buffer, srcBuffer); >>>> >>>> >>> Yeah, I get this error all the time in my current GPU VR pipeline. >>> That seems to work, so the error is non-critical at least. Though I do >>> go behind VTK's back a bit and pull out the rug.. Anyway, if the read >>> buffer was wrong you're most likely to see *nothing* instead of the >>> artifacts you're encountering, so I don't think this is the root issue. >>> >>> I'm still curious if fiddling IceT on/off has an effect, though... >>> >>> Another option would be to make something in the scene have just >>> a smidgen of transparency. That should force ParaView to sort >>> everything, instead of relying on a painter's alg, and thus it might >>> workaround the issue. >>> >>> -tom >>> >>> >>> >>>> tom fogal wrote: >>>> >>>> >>>>> Hi Burlen! Hope you're doing well. >>>>> >>>>> burlen <bur...@gm...> writes: >>>>> >>>>> >>>>> >>>>>> Thanks for your help, >>>>>> It didn't make a difference, but I agree it looks like depth buffer >>>>>> issue. >>>>>> >>>>>> >>>>>> >>>>> I think you should file a bug, not all the Mesa devs follow this list. >>>>> >>>>> https://bugs.freedesktop.org/ >>>>> >>>>> A (very unlikely to be enlightening) thing to try is to export: >>>>> >>>>> LIBGL_ALWAYS_SOFTWARE=1 >>>>> LIBGL_ALWAYS_INDIRECT=1 >>>>> MESA_DEBUG=1 >>>>> >>>>> and re-run. Other than the libtxc warning, any errors you see on your >>>>> terminal may be relevant. >>>>> >>>>> >>>>> >>>>> >>>>>> Another issue I am seeing in the mesa rendering has to do with >>>>>> inconsistent choice of which tubes are on top. This occurs in >>>>>> parallel rendering only so I didn't mention it before. You can see >>>>>> the inconsistency by comparing the hardware/nvidia and mesa in these >>>>>> images: >>>>>> >>>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa-arti >>>>>> >> fa >> >>>>>> >>>>>> >>>> cts >>>> >>>> >>>>>> -decomp.png >>>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvidia-no >>>>>> >> -a >> >>>>>> >>>>>> >>>> rti >>>> >>>> >>>>>> facts-decomp.png >>>>>> >>>>>> >>>>>> >>>>> It looks like these are changing per-tile -- you can see the obvious >>>>> banding along the rightmost streamlines. Does enabing/disabling IceT >>>>> in ParaView solve the problem? I'm guessing that will change how PV >>>>> does load decomposition as well, but if not you might want to play with >>>>> those settings. >>>>> >>>>> Best, >>>>> >>>>> -tom >>>>> >>>>> >>>>> >>>>> >>>>>> Jeff Lee wrote: >>>>>> >>>>>> >>>>>> >>>>>>> looks like a depth buffering issue - what happens when you setenv >>>>>>> MESA_GLX_DEPTH_BITS 24? >>>>>>> >>>>>>> On Fri, Jan 15, 2010 at 12:22 PM, burlen <bur...@gm... >>>>>>> <mailto:bur...@gm...>> wrote: >>>>>>> >>>>>>> I would like to report an issues I see when I replace hardware >>>>>>> rendering >>>>>>> in my app with mesa. I am new to mesa so I am not sure where the bu >>>>>>> >> g >> >>>>>>> lies, in the app or mesa. So I suspect it may be in mesa because >>>>>>> hardware rendering works fine , I have doubts because I don't know >>>>>>> >> if >> >>>>>>> the app does anything special when it uses mesa. I hope some one he >>>>>>> >> re >> >>>>>>> can say for sure weather or not it's a mesa issue. >>>>>>> >>>>>>> The issue is strong artifacts appear on the surface of rendering >>>>>>> tubes. >>>>>>> zooming in makes the artifacts recede to the edges of the tubes but >>>>>>> never completely go away. Here is an illustration of the artifacts >>>>>>> and a >>>>>>> hardware rendering that doesn't have the artifacts. >>>>>>> >>>>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/mesa >>>>>>> >> -a >> >>>>>>> >>>>>>> >>>> rt >>>> >>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ifacts.png >>>>>> >>>>>> >>>>>> >>>>>>> http://nashi-submaster.ucsd.edu/movies/PV/tube-filter-artifact/nvid >>>>>>> >> ia >> >>>>>>> >>>>>>> >>>> -n >>>> >>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> o-artifacts.png >>>>>> >>>>>> >>>>>> >>>>>>> By the way, I reproduced on two machines with intel and gcc >>>>>>> compiler and >>>>>>> two mesa version 7.5.1 and 7.7. >>>>>>> >>>>>>> ------------------------------------------------------------------- >>>>>>> >> -- >> >>>>>>> >>>>>>> >>>> -- >>>> >>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ------- >>>>>> >>>>>> >>>>>> >>>>>>> Throughout its 18-year history, RSA Conference consistently >>>>>>> attracts the >>>>>>> world's best and brightest in the field, creating opportunities >>>>>>> for Conference >>>>>>> attendees to learn about information security's most important >>>>>>> issues through >>>>>>> interactions with peers, luminaries and emerging and established >>>>>>> companies. >>>>>>> http://p.sf.net/sfu/rsaconf-dev2dev >>>>>>> _______________________________________________ >>>>>>> Mesa3d-users mailing list >>>>>>> Mes...@li... >>>>>>> <https://mail.google.com/a/cdnorthamerica.com/?view=cm&tf=0&to=Mesa >>>>>>> >> 3d >> >>>>>>> >>>>>>> >>>> -u >>>> >>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> se...@li...> >>>>>> >>>>>> >>>>>> >>>>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >>>>>>> |