Menu
▾
▴
Re: [Mesa3d-users] rendering artifacts mesa vs hardware
|
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 >>>>>>> |
