mesa3d-users

[Mesa3d-users] Examples of OSMesa use

[Adam R. <ada...@ca...>]

Hi,

At this URL:

http://www.mesa3d.org/osmesa.html

it says there are examples of OSMesa "in the progs/osdemo/ directory". 
I have version 7.6.1 of Mesa, and there is no osdemo directory in the 
progs directory.  Where can I find examples of how to use the OSMesa API?

[Mesa3d-users] mesa make using dri undefined reference to `drmOpenOnce'

[Ekhlas S. <ekh...@re...>]

Hi, 

   I am trying to install Mesa 7.7 on a RHEL 5.4 64-bit machine. I was able to successfully compile and install the package using



make linux-x86-64.



But the graphics quality was not satisfactory for the flight simulator I want to run (FlightGear 1.9.1).



So, I thought of compiling Mesa with direct rendering. Hence I tried compiling it (after make realclean) using



make linux-dri-x86-64



and I got the following error after the compilation runs for quite some time:



../../lib64/libGL.so: undefined reference to `drmOpenOnce'

../../lib64/libGL.so: undefined reference to `XDamageAdd'

../../lib64/libGL.so: undefined reference to `drmCloseOnce'



My web search tells me I need to upgrade libdrm packages. But I have installed the latest packages of libdrm(libdrm 2.4.17).

Same with XDamage (version 1.1.2).



Can someone please help me? Why am I getting this error?



Thanks.

Ekhlas.

Re: [Mesa3d-users] Compiling Mesa with Nouveau Support

[Brian P. <br...@vm...>]

Just cc'ing Ben Skeggs on this in case he's not on the mesa3d-users list.

Ben, can you give any tips to Steve?

-Brian

STEVE555 wrote:
>  Hi to all,
>            I have been compling Mesa from git using autoconf for sometime,I
> have been pulling the lastest updates from the repository regulary.I have
> been running into problems recently from a recent change in the
> repository.Here is the link to the cahnge I'm talking about:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=e00ae524e236afba1305150cacd634eaa1f5460b
> 
> Here are the ./configure options I'm using with ./configure:
>  ./configure --prefix=/usr --sbindir=/usr/sbin
> ----oldincludedir=/usr/include --x-includes=/usr/include
> --x-libraries=/usr/lib --enable-32-bit --enable-xcb --enable-glx-tls
> --enable-gallium-nouveau --with-x --with-dri-driverdir=/usr/lib/dri
> --with-xorg-driver-dir=/usr/lib/xorg/modules/drivers
> 
> I keep running into this error at the end with make after ./configure
> finishes:
> gmake[5]: Entering directory `/tmp/mesa/src/gallium/winsys/drm/nouveau/dri'
> gcc -c -I. -I../../../../../../src/mesa/drivers/dri/common -Iserver
> -I../../../../../../include -I../../../../../../include/GL/internal
> -I../../../../../../src/gallium/include
> -I../../../../../../src/gallium/auxiliary
> -I../../../../../../src/gallium/drivers
> -I../../../../../../src/gallium/winsys/common -I../../../../../../src/mesa
> -I../../../../../../src/mesa/main -I../../../../../../src/mesa/glapi
> -I../../../../../../src/mesa/math -I../../../../../../src/mesa/transform
> -I../../../../../../src/mesa/shader -I../../../../../../src/mesa/swrast
> -I../../../../../../src/mesa/swrast_setup -I../../../../../../src/egl/main
> -I../../../../../../src/egl/drivers/dri -I/usr/include/drm    -g -O2 -Wall
> -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32  -fPIC
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
> -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -I/usr/include/drm
> -I/usr/include/nouveau   nouveau_context.c -o nouveau_context.o
> gcc -c -I. -I../../../../../../src/mesa/drivers/dri/common -Iserver
> -I../../../../../../include -I../../../../../../include/GL/internal
> -I../../../../../../src/gallium/include
> -I../../../../../../src/gallium/auxiliary
> -I../../../../../../src/gallium/drivers
> -I../../../../../../src/gallium/winsys/common -I../../../../../../src/mesa
> -I../../../../../../src/mesa/main -I../../../../../../src/mesa/glapi
> -I../../../../../../src/mesa/math -I../../../../../../src/mesa/transform
> -I../../../../../../src/mesa/shader -I../../../../../../src/mesa/swrast
> -I../../../../../../src/mesa/swrast_setup -I../../../../../../src/egl/main
> -I../../../../../../src/egl/drivers/dri -I/usr/include/drm    -g -O2 -Wall
> -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32  -fPIC
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
> -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -I/usr/include/drm
> -I/usr/include/nouveau   nouveau_screen.c -o nouveau_screen.o
> gcc -c -I. -I../../../../../../src/mesa/drivers/dri/common -Iserver
> -I../../../../../../include -I../../../../../../include/GL/internal
> -I../../../../../../src/gallium/include
> -I../../../../../../src/gallium/auxiliary
> -I../../../../../../src/gallium/drivers
> -I../../../../../../src/gallium/winsys/common -I../../../../../../src/mesa
> -I../../../../../../src/mesa/main -I../../../../../../src/mesa/glapi
> -I../../../../../../src/mesa/math -I../../../../../../src/mesa/transform
> -I../../../../../../src/mesa/shader -I../../../../../../src/mesa/swrast
> -I../../../../../../src/mesa/swrast_setup -I../../../../../../src/egl/main
> -I../../../../../../src/egl/drivers/dri -I/usr/include/drm    -g -O2 -Wall
> -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32  -fPIC
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
> -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -I/usr/include/drm
> -I/usr/include/nouveau   nouveau_swapbuffers.c -o nouveau_swapbuffers.o
> gcc -c -I. -I../../../../../../src/mesa/drivers/dri/common -Iserver
> -I../../../../../../include -I../../../../../../include/GL/internal
> -I../../../../../../src/gallium/include
> -I../../../../../../src/gallium/auxiliary
> -I../../../../../../src/gallium/drivers
> -I../../../../../../src/gallium/winsys/common -I../../../../../../src/mesa
> -I../../../../../../src/mesa/main -I../../../../../../src/mesa/glapi
> -I../../../../../../src/mesa/math -I../../../../../../src/mesa/transform
> -I../../../../../../src/mesa/shader -I../../../../../../src/mesa/swrast
> -I../../../../../../src/mesa/swrast_setup -I../../../../../../src/egl/main
> -I../../../../../../src/egl/drivers/dri -I/usr/include/drm    -g -O2 -Wall
> -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32  -fPIC
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
> -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -I/usr/include/drm
> -I/usr/include/nouveau   nouveau_lock.c -o nouveau_lock.o
> /bin/sh ../../../../../../bin/mklib -noprefix -o nouveau_dri.so \
>                 ../../../../../../src/mesa/drivers/dri/common/utils.o
> ../../../../../../src/mesa/drivers/dri/common/vblank.o
> ../../../../../../src/mesa/drivers/dri/common/dri_util.o
> ../../../../../../src/mesa/drivers/dri/common/xmlconfig.o nouveau_context.o
> nouveau_screen.o nouveau_swapbuffers.o nouveau_lock.o
> ../../../../../../src/gallium/winsys/drm/nouveau/drm/libnouveaudrm.a
> ../../../../../../src/gallium/drivers/nv04/libnv04.a
> ../../../../../../src/gallium/drivers/nv10/libnv10.a
> ../../../../../../src/gallium/drivers/nv20/libnv20.a
> ../../../../../../src/gallium/drivers/nv30/libnv30.a
> ../../../../../../src/gallium/drivers/nv40/libnv40.a
> ../../../../../../src/gallium/drivers/nv50/libnv50.a
> ../../../../../../src/mesa/libmesagallium.a
> ../../../../../../src/gallium/auxiliary/draw/libdraw.a
> ../../../../../../src/gallium/auxiliary/translate/libtranslate.a
> ../../../../../../src/gallium/auxiliary/cso_cache/libcso_cache.a
> ../../../../../../src/gallium/auxiliary/pipebuffer/libpipebuffer.a
> ../../../../../../src/gallium/auxiliary/tgsi/libtgsi.a
> ../../../../../../src/gallium/auxiliary/sct/libsct.a
> ../../../../../../src/gallium/auxiliary/rtasm/librtasm.a
> ../../../../../../src/gallium/auxiliary/util/libutil.a     -ldrm   -lexpat
> -lm -lpthread -ldl -ldrm_nouveau
> mklib: Making Linux shared library:  nouveau_dri.so
> /bin/sh ../../../../../../bin/minstall nouveau_dri.so
> ../../../../../../lib/gallium
> gmake[5]: Leaving directory `/tmp/mesa/src/gallium/winsys/drm/nouveau/dri'
> gmake[5]: Entering directory `/tmp/mesa/src/gallium/winsys/drm/nouveau/dri2'
> ../../Makefile.template:124: depend: No such file or directory
> rm -f depend
> touch depend
> /usr/bin/makedepend -fdepend -I/usr/lib/gcc/i586-redhat-linux/4.4.0/include
> -I. -I../../../../../../src/mesa/drivers/dri/common -Iserver
> -I../../../../../../include -I../../../../../../include/GL/internal
> -I../../../../../../src/gallium/include
> -I../../../../../../src/gallium/auxiliary
> -I../../../../../../src/gallium/drivers
> -I../../../../../../src/gallium/winsys/common -I../../../../../../src/mesa
> -I../../../../../../src/mesa/main -I../../../../../../src/mesa/glapi
> -I../../../../../../src/mesa/math -I../../../../../../src/mesa/transform
> -I../../../../../../src/mesa/shader -I../../../../../../src/mesa/swrast
> -I../../../../../../src/mesa/swrast_setup -I../../../../../../src/egl/main
> -I../../../../../../src/egl/drivers/dri -I/usr/include/drm
> ../../../../../../src/mesa/drivers/dri/common/utils.c
> ../../../../../../src/mesa/drivers/dri/common/vblank.c
> ../../../../../../src/mesa/drivers/dri/common/dri_util.c
> ../../../../../../src/mesa/drivers/dri/common/xmlconfig.c  \
>                  2> /dev/null
> gmake[5]: Leaving directory `/tmp/mesa/src/gallium/winsys/drm/nouveau/dri2'
> gmake[5]: Entering directory `/tmp/mesa/src/gallium/winsys/drm/nouveau/dri2'
> gmake[5]: *** No rule to make target
> `../../../../../../src/gallium/state_trackers/dri2/libdri2drm.a', needed by
> `nouveau_dri2.so'.  Stop.
> gmake[5]: Leaving directory `/tmp/mesa/src/gallium/winsys/drm/nouveau/dri2'
> gmake[4]: *** [default] Error 1
> gmake[4]: Leaving directory `/tmp/mesa/src/gallium/winsys/drm/nouveau'
> gmake[3]: *** [default] Error 1
> gmake[3]: Leaving directory `/tmp/mesa/src/gallium/winsys/drm'
> gmake[2]: *** [default] Error 1
> gmake[2]: Leaving directory `/tmp/mesa/src/gallium/winsys'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/tmp/mesa/src'
> make: *** [default] Error
> 
>>From the message header in the cahnge I'm talking about,I quote:
> drm_api is a set of hooks used by the dri2 state tracker, this wraps our
> dri1 code around the same set of hooks.
> 
> "Currently the dri2 build will produce nouveau_dri2.so which you'll need
> to install as nouveau_dri.so if you wish to try it.  The dri2 state
> tracker doesn't make it easy for a driver to support both paths in the
> same binary."
> 
> Can somebody tell me how to change the revelant file form which directory so
> I can compile Mesa with Nouveau support agian? or should I wait patiently
> wait for the next round of updates to the repository so it can build
> successfully again?
> 
> Regards,
>             STEVE555
> 
> --
> View this message in context: http://www.nabble.com/Compiling-Mesa-with-Nouveau-Support-tp22629649p22629649.html
> Sent from the mesa3d-users mailing list archive at Nabble.com.
> 
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
> .
> 

Re: [Mesa3d-users] mgl mesa impl

[Chia-I Wu <ol...@gm...>]

On Fri, Jan 29, 2010 at 01:38:05AM -0800, Daniel Hoggan wrote:
> no I'm referring to the Scitech MGL library.  It has a cut down version of the Mesa3d api that it supply's as part of the DDK.
> If the misunderstanding is becuase of how I worded the question then I should clear that up.
> The MGL is a graphics engine. It's smaller than X and has built in hardware acceleration. It's a portable and manageable library.
> My question basically came down to this:  On a mobile device is the requirement that you use OpenGLES, or can you just stick to GL?
> If not then would the cut down version of Mesa that ships with the MGL be compatible with the version of OpenGLES that you provide?
> If neither of those are appropriate then how should I go about providing for the OpenGL layer that I require for my programs.
I have no idea what's in MGL.  The choice between OpenGL and OpenGL ES
should depend on what your platform provides.  And if your platform has
no dedicated hardware for 3D acceleration, you may choose OpenGL or
OpenGL ES as you want, because they will both fall back to software
rendering.

-- 
Regards,
olv

Re: [Mesa3d-users] mgl mesa impl

[Daniel H. <dan...@ze...>]

no I'm referring to the Scitech MGL library.  It has a cut down version of the Mesa3d api that it supply's as part of the DDK.

If the misunderstanding is becuase of how I worded the question then I should clear that up.
The MGL is a graphics engine. It's smaller than X and has built in hardware acceleration. It's a portable and manageable library.

My question basically came down to this:  On a mobile device is the requirement that you use OpenGLES, or can you just stick to GL?

If not then would the cut down version of Mesa that ships with the MGL be compatible with the version of OpenGLES that you provide?

If neither of those are appropriate then how should I go about providing for the OpenGL layer that I require for my programs.

--- ol...@gm... wrote:

From: Chia-I Wu <ol...@gm...>
To: Daniel Hoggan <dan...@ze...>
Cc: mes...@li...
Subject: Re: [Mesa3d-users] mgl mesa impl
Date: Thu, 28 Jan 2010 23:23:31 +0800

On Wed, Jan 27, 2010 at 01:29:53AM -0800, Daniel Hoggan wrote:
> The mgl have an implementation of mesa as part of their ddk, however
> I'm just curious about something, your code should work against your
> implementation of gles/egl right, so would that be the same here.  or
> could I get around the requirement for gles/egl and just use it?
Sorry, I don't think I understand your question.  Did you refer to
gl_mangle.h when you said "mgl"?

-- 
Regards,
olv








_____________________________________________________________
Free Email Account by ZenSearch.com 
http://email.ZenSearch.com

Re: [Mesa3d-users] rendering artifacts mesa vs hardware

[burlen <bur...@gm...>]

> 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
>>>>>>>               

Re: [Mesa3d-users] mgl mesa impl

[Chia-I Wu <ol...@gm...>]

On Wed, Jan 27, 2010 at 01:29:53AM -0800, Daniel Hoggan wrote:
> The mgl have an implementation of mesa as part of their ddk, however
> I'm just curious about something, your code should work against your
> implementation of gles/egl right, so would that be the same here.  or
> could I get around the requirement for gles/egl and just use it?
Sorry, I don't think I understand your question.  Did you refer to
gl_mangle.h when you said "mgl"?

-- 
Regards,
olv

[Mesa3d-users] mgl mesa impl

[Daniel H. <dan...@ze...>]

The mgl have an implementation of mesa as part of their ddk, however I'm just curious about something, your code should work against your implementation of gles/egl right, so would that be the same here.  or could I get around the requirement for gles/egl and just use it?

_____________________________________________________________
Free Email Account by ZenSearch.com 
http://email.ZenSearch.com

Re: [Mesa3d-users] question about anti-aliasing in OSMesa

[Brian P. <br...@vm...>]

Martijn Sanderse wrote:
> Hi,
> 
> I'm pretty new to OpenGL and Mesa (I am reading my redbook...). If  I
> picked the wrong place for my question, please let me know.
> 
> I'm trying to find out whether I can use mesa for rendering polygons
> to offscreen images. In particular I'm interested in the accuracy of
> the anti-aliasing routines.
> 
> To find out I followed the example in
> MesaDemos/progs/osdemos/osdemo32.c. I changed the function
> render_image() to the one described below. I basically draw a simple
> polygon with three vertices.
> 
> Because the top vertex of my polygon is almost flat, but not entirely,
> I expect (theoretically) to find a  row with increasing pixel values
> in the buffer. However, the total number of unique pixel values is 23
> at maximum. I inspect only the "R" color component, as I'm interested
> only in greyscale images, and assume that anti-aliasing is equal for
> all color components.
> 
> I suspect that the anti-aliasing routine is written for speed,
> producing a result that is visually acceptable. Is there a way that I
> can increase the accuracy of the anti-aliasing routine? Or, do I have
> to turn to more GPGPU/shader kind of solutions, when I'm more
> interested in accuracy then in speed?
> 
> I use Mesa in a VirtualBox, so I guess it's all software rendering.

The mesa swrast AA triangle code is in src/mesa/swrast/s_aatriangle.c 
and s_aatritemp.h

The compute_coverage() functions (different versions for RGB vs. CI 
mode) basically count how many sub-pixel samples lie inside the 
triangle for each pixel.  A jittered 4x4 sample pattern is used.  You 
could probably increase the number of samples to improve AA quality a 
little.

-Brian

Re: [Mesa3d-users] Anti-aliasing lines Intel GMA 4500 question

[Brian P. <br...@vm...>]

Stefan Parvu wrote:
> Hi Brian,
> 
> Probable this would make things clear:
> 
> Nvidia:
>   OpenGL vendor string: NVIDIA Corporation
>   OpenGL renderer string: Quadro FX 1500/PCI/SSE2
>   OpenGL version string: 2.1.2 NVIDIA 190.53
> 
>   GL_LINE_WIDTH_GRANULARITY = 0.1
>   GL_LINE_WIDTH_RANGE = 0.5 10.0
> 
> 
> Intel:
>   OpenGL vendor string: Tungsten Graphics, Inc
>   OpenGL renderer string: Mesa DRI Mobile Intel GM45 Express Chipset
>                           GEM 20090712 2009Q2 RC3
>   OpenGL version string: 2.1 Mesa 7.6
>   GL_LINE_WIDTH_GRANULARITY = 0.5
>   GL_LINE_WIDTH_RANGE = 1.0 5.0
> 
> As you said with NVIDIA I have much higher degree and better quality.
> So this looks specific to each OpenGL implementation. Question is why in 
> Mesa we have GL_LINE_WIDTH_GRANULARITY = 0.5 instead of 0.1 like in NVIDIA 
> case ? Is it direct dependant of the GPU, or the driver ... !?

The Intel i965 line width register only has one fractional bit.

-Brian

Re: [Mesa3d-users] Anti-aliasing lines Intel GMA 4500 question

[Stefan P. <sp...@sy...>]

> The Intel i965 line width register only has one fractional bit.

aha. Clear enough. Makes sense.
stefan

Re: [Mesa3d-users] Anti-aliasing lines Intel GMA 4500 question

[Stefan P. <sp...@sy...>]

Hi Brian,

Probable this would make things clear:

Nvidia:
  OpenGL vendor string: NVIDIA Corporation
  OpenGL renderer string: Quadro FX 1500/PCI/SSE2
  OpenGL version string: 2.1.2 NVIDIA 190.53

  GL_LINE_WIDTH_GRANULARITY = 0.1
  GL_LINE_WIDTH_RANGE = 0.5 10.0


Intel:
  OpenGL vendor string: Tungsten Graphics, Inc
  OpenGL renderer string: Mesa DRI Mobile Intel GM45 Express Chipset
                          GEM 20090712 2009Q2 RC3
  OpenGL version string: 2.1 Mesa 7.6
  GL_LINE_WIDTH_GRANULARITY = 0.5
  GL_LINE_WIDTH_RANGE = 1.0 5.0

As you said with NVIDIA I have much higher degree and better quality.
So this looks specific to each OpenGL implementation. Question is why in 
Mesa we have GL_LINE_WIDTH_GRANULARITY = 0.5 instead of 0.1 like in NVIDIA 
case ? Is it direct dependant of the GPU, or the driver ... !?

Many thanks,
Stefan

Re: [Mesa3d-users] Anti-aliasing lines Intel GMA 4500 question

[Stefan P. <sp...@sy...>]

>
> Just be aware that the quality of AA lines from one GPU/driver to another can 
> vary a lot.  I think NVIDIA may have higher quality AA lines than other GPUs.

setting INTEL_STRICT_CONFORMANCE did not bring any difference.

Probable this is a driver issue. The difference is big: on Intel
Im not even capable of seeing all coordinates properly set:
http://systemdatarecorder.org:9009/bugzilla/attachment.cgi?id=1
(missing the red axis) If I resize the window then I get properly
the coordinates set and all lines displayed :)

On Nvidia the quality of AA lines is higher and the lines are
properly set from start.

Probable not much I can do. I will try to test on a different machine,
using ATI and Solairs or Linux to see the difference.

Thanks,
Stefan

Re: [Mesa3d-users] Anti-aliasing lines Intel GMA 4500 question

[Brian P. <br...@vm...>]

Stefan Parvu wrote:
> Hi,
> 
>> I don't see any attachments.
> 
> Probable hidden a bit inside bugzilla.
> 
> Here you go:
> 
>   Ubuntu intel gma4500:
>   http://systemdatarecorder.org:9009/bugzilla/attachment.cgi?id=1
> 
>   Solaris nvidia:
>   http://systemdatarecorder.org:9009/bugzilla/attachment.cgi?id=2
> 
>> Are you talking about line antialiasing?
> 
> yep. Im just plotting the Barry coordinates using a simple sequence
> like:
> 
>          /* Enable Anti-aliasing and width of axis */
>          glEnable(GL_LINE_SMOOTH);
>          glEnable(GL_BLEND);
>          glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
>          /* glHint(GL_LINE_SMOOTH_HINT, GL_DONT_CARE); */
>          glHint(GL_LINE_SMOOTH_HINT, GL_NICEST);
>          glLineWidth(0.5);
> 
> 
>          glBegin(GL_LINES);
> 
>              /* draw axis */
>              /* Usr Red */
>  	    glColor3f (1.0f, 0.0f, 0.0f);
>  	    glVertex2f(b3Vertex[1][0], b3Vertex[1][1]);
>  	    glVertex2f(op_usr.x, op_usr.y);
> 
>              ...
> 
>          glEnd();
> 
>> I think the 4500 has some limitations w.r.t. antialiased lines.  You might 
>> try settting the INTEL_STRICT_CONFORMANCE env var to 1 and see what happens. 
>> This will turn on software-drawn AA lines.  Performance will be poor, 
>> however.
> 
> thanks. I will try this. I will report back the results.

Just be aware that the quality of AA lines from one GPU/driver to 
another can vary a lot.  I think NVIDIA may have higher quality AA 
lines than other GPUs.

-Brian

Re: [Mesa3d-users] Anti-aliasing lines Intel GMA 4500 question

[Stefan P. <sp...@sy...>]

Hi,

> I don't see any attachments.

Probable hidden a bit inside bugzilla.

Here you go:

  Ubuntu intel gma4500:
  http://systemdatarecorder.org:9009/bugzilla/attachment.cgi?id=1

  Solaris nvidia:
  http://systemdatarecorder.org:9009/bugzilla/attachment.cgi?id=2

> Are you talking about line antialiasing?

yep. Im just plotting the Barry coordinates using a simple sequence
like:

         /* Enable Anti-aliasing and width of axis */
         glEnable(GL_LINE_SMOOTH);
         glEnable(GL_BLEND);
         glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
         /* glHint(GL_LINE_SMOOTH_HINT, GL_DONT_CARE); */
         glHint(GL_LINE_SMOOTH_HINT, GL_NICEST);
         glLineWidth(0.5);


         glBegin(GL_LINES);

             /* draw axis */
             /* Usr Red */
 	    glColor3f (1.0f, 0.0f, 0.0f);
 	    glVertex2f(b3Vertex[1][0], b3Vertex[1][1]);
 	    glVertex2f(op_usr.x, op_usr.y);

             ...

         glEnd();

> I think the 4500 has some limitations w.r.t. antialiased lines.  You might 
> try settting the INTEL_STRICT_CONFORMANCE env var to 1 and see what happens. 
> This will turn on software-drawn AA lines.  Performance will be poor, 
> however.

thanks. I will try this. I will report back the results.

stefan

[1] http://www.systemdatarecorder.org/cpuplayer/src/cpuplayer.c

Re: [Mesa3d-users] Anti-aliasing lines Intel GMA 4500 question

[Brian P. <br...@vm...>]

Stefan Parvu wrote:
> Hi all,
> 
> Im currently developing a prototype as described here:
> http://www.systemdatarecorder.org/cpuplayer/ using OpenGL.
> Im basically working on Solaris x64 + Nvidia and Ubuntu
> x64 + Mesa as main platforms.
> 
> Im trying to understand why my code does not execute similar
> regarding Anti-aliasing, as described under:
> http://systemdatarecorder.org:9009/bugzilla/show_bug.cgi?id=42
> 
> Check the Solaris 11 and Ubuntu screenshots attached.

I don't see any attachments.


> On my Ubuntu laptop Im using:
> direct rendering: Yes
> OpenGL renderer string: Mesa DRI Mobile Intel GM45 Express Chipset GEM 
> 20090712 2009Q2 RC3
> 
> This is a Ubuntu 9.10 x64 using Intel GMA 4500 MHD, running Mesa 7.6.0-1.
> 
> Any ideas, is this a problem with Mesa OpenGL implementation, is this
> a Intel driver bug or ... !?

Are you talking about line antialiasing?

I think the 4500 has some limitations w.r.t. antialiased lines.  You 
might try settting the INTEL_STRICT_CONFORMANCE env var to 1 and see 
what happens.  This will turn on software-drawn AA lines.  Performance 
will be poor, however.

-Brian

[Mesa3d-users] question about anti-aliasing in OSMesa

[Martijn S. <mar...@gm...>]

Hi,

I'm pretty new to OpenGL and Mesa (I am reading my redbook...). If  I
picked the wrong place for my question, please let me know.

I'm trying to find out whether I can use mesa for rendering polygons
to offscreen images. In particular I'm interested in the accuracy of
the anti-aliasing routines.

To find out I followed the example in
MesaDemos/progs/osdemos/osdemo32.c. I changed the function
render_image() to the one described below. I basically draw a simple
polygon with three vertices.

Because the top vertex of my polygon is almost flat, but not entirely,
I expect (theoretically) to find a  row with increasing pixel values
in the buffer. However, the total number of unique pixel values is 23
at maximum. I inspect only the "R" color component, as I'm interested
only in greyscale images, and assume that anti-aliasing is equal for
all color components.

I suspect that the anti-aliasing routine is written for speed,
producing a result that is visually acceptable. Is there a way that I
can increase the accuracy of the anti-aliasing routine? Or, do I have
to turn to more GPGPU/shader kind of solutions, when I'm more
interested in accuracy then in speed?

I use Mesa in a VirtualBox, so I guess it's all software rendering.

Thanks a lot,
Martijn Sanderse

#define WIDTH 2500
#define HEIGHT 20

static void render_image( void )
{
   glViewport(0, 0, WIDTH, HEIGHT);
   glMatrixMode(GL_PROJECTION);
   glLoadIdentity();
   gluOrtho2D(0, WIDTH, 0, HEIGHT);

   glEnable (GL_POLYGON_SMOOTH);
   glEnable (GL_BLEND);
   glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
   glHint (GL_POLYGON_SMOOTH_HINT, GL_NICEST);

   glClearColor(0.0, 0.0, 0.0, 0.0); //black
   glClear(GL_COLOR_BUFFER_BIT);

   glColor3f (1.0, 1.0, 1.0); // white
   glPushMatrix();
   glBegin (GL_POLYGON);
      glVertex2d (0.0, 10.0);
      glVertex2d (2500.0, 11.0); // slope = 1/2500
      glVertex2d (2500.0, 10.0);
   glEnd ();
   glPopMatrix();

   glFinish();
}

[Mesa3d-users] Anti-aliasing lines Intel GMA 4500 question

[Stefan P. <sp...@sy...>]

Hi all,

Im currently developing a prototype as described here:
http://www.systemdatarecorder.org/cpuplayer/ using OpenGL.
Im basically working on Solaris x64 + Nvidia and Ubuntu
x64 + Mesa as main platforms.

Im trying to understand why my code does not execute similar
regarding Anti-aliasing, as described under:
http://systemdatarecorder.org:9009/bugzilla/show_bug.cgi?id=42

Check the Solaris 11 and Ubuntu screenshots attached.

On my Ubuntu laptop Im using:
direct rendering: Yes
OpenGL renderer string: Mesa DRI Mobile Intel GM45 Express Chipset GEM 
20090712 2009Q2 RC3

This is a Ubuntu 9.10 x64 using Intel GMA 4500 MHD, running Mesa 7.6.0-1.

Any ideas, is this a problem with Mesa OpenGL implementation, is this
a Intel driver bug or ... !?

Many thanks,
Stefan

Re: [Mesa3d-users] VMWGFX / VMware for Windows

[Sorin P. <ma...@hy...>]

>> dmesg | grep vmwgfx
[vmwgfx] Initialized drm 1.1.0 20060810
vmwgfx 0000:00:0f.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[vmwgfx] Capabilities:
[vmwgfx]   Rect copy.
[vmwgfx]   Cursor.
[vmwgfx]   Cursor bypass.
[vmwgfx]   Cursor bypass 2.
[vmwgfx]   8bit emulation.
[vmwgfx]   Alpha cursor.
[vmwgfx]   3D.
[vmwgfx]   Extended Fifo.
[vmwgfx]   Multimon.
[vmwgfx]   Pitchlock.
[vmwgfx]   Irq mask.
[vmwgfx]   Display Topology.
[vmwgfx]   GMR.
[vmwgfx] Max GMR ids is 128
[vmwgfx] Max GMR descriptors is 4096
[vmwgfx] VRAM at 0xd0000000 size is 131072 kiB
[vmwgfx] MMIO at 0xd8000000 size is 2048 kiB
[vmwgfx] global init.
[vmwgfx] width 640
[vmwgfx] height 480
[vmwgfx] bpp 32
[vmwgfx] Fifo max 0x00200000 min 0x00001000 cap 0x0000007f
[vmwgfx] Have 3D
[vmwgfx] Initialized vmwgfx 0.1.2 20090724 for 0000:00:0f.0 on minor 0
[vmwgfx] Master create.
[vmwgfx] Master set.
[vmwgfx] Master drop.
[vmwgfx] Master destroy.
[vmwgfx] Master create.
[vmwgfx] Master set.
[vmwgfx] Dropmaster
[vmwgfx] Master drop.
[vmwgfx] Master destroy.

>> cat Xorg.0.log
X.Org X Server 1.7.4
Release Date: 2010-01-08
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32-gentoo-r1 i686
Current Operating System: Linux gentoo 2.6.32-gentoo-r2 #4 SMP PREEMPT
Fri Jan 22 11:32:14 EET 2010 i686
Kernel command line: BOOT_IMAGE=/boot/kernel-2.6.32-gentoo-r2
root=UUID=a7c28276-cc0e-4100-9b4f-845eb5f21106
Build Date: 11 January 2010  03:18:48PM

Current version of pixman: 0.17.2
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sat Jan 23 00:18:33 2010
(==) Using config file: "/etc/X11/xorg.conf"
(++) ServerLayout "VMware"
(**) |-->Screen "Screen1" (0)
(**) |   |-->Monitor "Monitor"
(**) |   |-->Device "Device1"
(**) |-->Input Device "Mouse1"
(**) |-->Input Device "Keyboard"
(==) Not automatically adding devices
(==) Not automatically enabling devices
(==) FontPath set to:
	/usr/share/fonts/misc/,
	/usr/share/fonts/TTF/
(**) ModulePath set to "/usr/lib/xorg/modules"
(II) Loader magic: 0x81d7800
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.4
	X.Org Video Driver: 6.0
	X.Org XInput driver : 7.0
	X.Org Server Extension : 2.0
(--) using VT number 7

(--) PCI:*(0:0:15:0) 15ad:0405:15ad:0405 VMware SVGA II Adapter rev 0,
Mem @ 0xd0000000/134217728, 0xd8000000/8388608, I/O @ 0x000010d0/16,
BIOS @ 0x????????/32768
(II) Open ACPI successful (/var/run/acpid.socket)
(II) "extmod" will be loaded by default.
(II) "dbe" will be loaded by default.
(II) "glx" will be loaded by default.
(II) "record" will be loaded by default.
(II) "dri" will be loaded by default.
(II) "dri2" will be loaded by default.
(II) LoadModule: "extmod"
(II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
	compiled for 1.7.4, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"
(II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
	compiled for 1.7.4, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor="X.Org Foundation"
	compiled for 1.7.3.902, module version = 1.0.0
	ABI class: X.Org Server Extension, version 2.0
(==) AIGLX enabled
(II) Loading extension GLX
(II) LoadModule: "record"
(II) Loading /usr/lib/xorg/modules/extensions/librecord.so
(II) Module record: vendor="X.Org Foundation"
	compiled for 1.7.4, module version = 1.13.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension RECORD
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions/libdri.so
(II) Module dri: vendor="X.Org Foundation"
	compiled for 1.7.4, module version = 1.0.0
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension XFree86-DRI
(II) LoadModule: "dri2"
(II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
(II) Module dri2: vendor="X.Org Foundation"
	compiled for 1.7.4, module version = 1.1.0
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DRI2
(II) LoadModule: "vmwgfx"
(II) Loading /usr/lib/xorg/modules/drivers/vmwgfx_drv.so
(II) Module vmwgfx: vendor="X.Org Foundation"
	compiled for 1.7.4, module version = 0.1.0
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 6.0
(II) LoadModule: "vmmouse"
(II) Loading /usr/lib/xorg/modules/input/vmmouse_drv.so
(II) Module vmmouse: vendor="X.Org Foundation"
	compiled for 1.7.4, module version = 12.6.5
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 7.0
(II) VMWARE(0): VMMOUSE module was loaded
(II) LoadModule: "kbd"
(II) Loading /usr/lib/xorg/modules/input/kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
	compiled for 1.7.4, module version = 1.4.0
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 7.0
(II) vmwgfx: Driver for VMware SVGA device: VMware SVGA Device
(II) Primary Device is: PCI 00@00:0f:0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmOpenByBusid: Searching for BusID PCI:0:15:0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmOpenByBusid: drmOpenMinor returns 9
drmOpenByBusid: drmGetBusid reports pci:0000:00:0f.0
(**) vmwgfx(0): Depth 24, (--) framebuffer bpp 32
(==) vmwgfx(0): RGB weight 888
(==) vmwgfx(0): Default visual is TrueColor
(II) vmwgfx(0): Output LVDS1 using monitor section Monitor
(II) vmwgfx(0): Output LVDS2 has no monitor section
...
(II) vmwgfx(0): Output LVDS8 has no monitor section
(II) vmwgfx(0): Modeline "1920x1440"x60.0  234.00  1920 2048 2256 2600
 1440 1441 1444 1500 -hsync +vsync (90.0 kHz)
...
(II) vmwgfx(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480
489 492 525 -hsync -vsync (31.5 kHz)
(II) vmwgfx(0): Output LVDS1 connected
(II) vmwgfx(0): Output LVDS2 disconnected
...
(II) vmwgfx(0): Output LVDS8 disconnected
(II) vmwgfx(0): Using user preference for initial modes
(II) vmwgfx(0): Output LVDS1 using initial mode 1440x900
(II) vmwgfx(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
(==) vmwgfx(0): DPI set to (96, 96)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/lib/xorg/modules/libfb.so
(II) Module fb: vendor="X.Org Foundation"
	compiled for 1.7.4, module version = 1.0.0
	ABI class: X.Org ANSI C Emulation, version 0.4
(II) Loading sub module "exa"
(II) LoadModule: "exa"
(II) Loading /usr/lib/xorg/modules/libexa.so
(II) Module exa: vendor="X.Org Foundation"
	compiled for 1.7.4, module version = 2.5.0
	ABI class: X.Org Video Driver, version 6.0
(II) Loading sub module "dri2"
(II) LoadModule: "dri2"
(II) Reloading /usr/lib/xorg/modules/extensions/libdri2.so
(==) Depth 24 pixmap format is 32 bpp
(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II)         Composite (RENDER acceleration)
(II)         UploadToScreen
(II)         DownloadFromScreen
(II) vmwgfx(0): [DRI2] Setup complete
(==) vmwgfx(0): Backing store disabled
(==) vmwgfx(0): Silken mouse enabled
(II) vmwgfx(0): RandR 1.2 enabled, ignore the following RandR disabled message.
(==) vmwgfx(0): DPMS enabled
(--) RandR disabled
(II) Initializing built-in extension Generic Event Extension
(II) Initializing built-in extension SHAPE
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension BIG-REQUESTS
(II) Initializing built-in extension SYNC
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-MISC
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) AIGLX: enabled GLX_MESA_copy_sub_buffer
(II) AIGLX: enabled GLX_SGI_make_current_read
(II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
(II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
(II) AIGLX: Loaded and initialized /usr/lib/dri/vmwgfx_dri.so
(II) GLX: Initialized DRI2 GL provider for screen 0
(II) vmwgfx(0): Damage tracking initialized
(II) vmwgfx(0): Setting screen physical size to 380 x 238
(II) VMWARE(0): vmmouse is available
(**) Option "CorePointer"
(**) Mouse1: always reports core events
(**) Option "Device" "/dev/input/mice"
(**) Option "ZAxisMapping" "4 5 6 7"
(**) Mouse1: ZAxisMapping: buttons 4 and 5
(II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE)
(**) Mouse1: (accel) keeping acceleration scheme 1
(**) Mouse1: (accel) acceleration profile 0
(II) VMWARE(0): VMMOUSE DEVICE_INIT
(II) VMWARE(0): VMMOUSE DEVICE_ON
(II) VMWARE(0): vmmouse enabled
(**) Option "CoreKeyboard"
(**) Keyboard: always reports core events
(**) Option "Protocol" "standard"
(**) Keyboard: Protocol: standard
(**) Option "XkbRules" "base"
(**) Keyboard: XkbRules: "base"
(**) Option "XkbModel" "pc105"
(**) Keyboard: XkbModel: "pc105"
(**) Option "XkbLayout" "us"
(**) Keyboard: XkbLayout: "us"
(**) Option "CustomKeycodes" "off"
(**) Keyboard: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "Keyboard" (type: KEYBOARD)
(II) vmwgfx(0): xorg_composite_accelerated fallback Component alpha
not supported with source alpha and source value blending. (op=3)
(II) vmwgfx(0): xorg_composite_accelerated fallback Component alpha
not supported with source alpha and source value blending. (op=3)
... repeated many times ...
(II) vmwgfx(0): xorg_composite_accelerated fallback Component alpha
not supported with source alpha and source value blending. (op=3)
(II) vmwgfx(0): xorg_composite_accelerated fallback Component alpha
not supported with source alpha and source value blending. (op=3)
(II) VMWARE(0): VMMOUSE DEVICE_OFF/CLOSE
(II) VMWARE(0): VMMOUSE DEVICE_OFF/CLOSE
(II) VMWARE(0): VMMouseUnInit
(II) UnloadModule: "kbd"

> BTW, which version(s) of VMware Workstation are you using in each case?
Version 7.0.0 build 203739 for both Windows and Linux. Had no luck
with 6.5.3 either.

Re: [Mesa3d-users] rendering artifacts mesa vs hardware

[tom f. <tf...@al...>]

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
> >>>>>       
> >>>>>           
> 

Re: [Mesa3d-users] rendering artifacts mesa vs hardware

[burlen <bur...@gm...>]

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
>>>>>       
>>>>>           

Re: [Mesa3d-users] rendering artifacts mesa vs hardware

[tom f. <tf...@al...>]

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
> >>>       
> 

Re: [Mesa3d-users] rendering artifacts mesa vs hardware

[burlen <bur...@gm...>]

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
>>>       

Re: [Mesa3d-users] VMWGFX / VMware for Windows

[Sorin P. <ma...@hy...>]

2010/1/19 Michel Dänzer <da...@vm...>:
> Does it work better with
>
>        Option  "2DAccel" "off"
>
> ? The 2D acceleration is still work in progress.

Unfortunately, no. I get a black screen with only the mouse cursor visible.

Re: [Mesa3d-users] 32bit vs 64bit question regarding glLightfv (one works, the other crashes)

[Brian P. <br...@vm...>]

Tobias Burnus wrote:
> Hello,
> 
> I have the problem that calling glLightfv works with the 32bit version
> of mesa but fails with the 64bit version on a x86-64 Linux system:
> 
> $ cat test.c
> #include <GL/gl.h>
> 
> int main ()
> {
>   GLfloat ambient[4]      = {0.2, 0.2, 0.2, 1.0};
>   glLightfv(GL_LIGHT0, GL_AMBIENT,  ambient);
>   return 0;
> }
> 
> $ gcc test.c -lGL && ./a.out
> Segmentation fault
> $ gcc -m32 test.c -lGL && ./a.out
> $
> 
> (Reduced example from http://www.xcrysden.org/.) I failed to see what
> goes wrong here as the syntax looks fine, but I also find it unlikely
> that it fails both with an old Fedora 6 with
> mesa-libGL-devel-6.5.1-9.fc6 and on an openSUSE Factory with
> Mesa-7.7-5.3.x86_64, which somehow implies a user error instead of a
> library problem.
> 
>  * * *
> 
> For completeness, if I use glutInit(); ....; glutCreateWindow(...)
> before calling glLightfv(), it does not crash with mesa-64bit. Xcrysden
> is to convoluted for me to really see what is called where. Is there
> anything which I should tell the Xcryden developers to handle differently?

The "problem" with your example above is there's no rendering context 
bound when glLightfv() is called.  We're probably trying to jump 
through a null pointer in the dispatcher.

I guess Xcryden is making some GL calls w/out a bound rendering 
context.  That's usually an application bug.

As far as Mesa goes, my guess is we've got something wrong in the 
x86-64 API dispatch code.  I'm not too knowledgable of x86-64 assembly 
code.  Have you filed a bug report about this?

-Brian