View Full Version : Help using Mesa
10-30-2007, 02:12 PM
I have a GPU implementation of an algorithm, and I need to test how fast it would go if it were forced to operate entirely on the CPU. Re-writing isn't on the table, so the obvious choice was to try linking against Mesa's opengl32.lib rather than the NVIDIA driver's opengl32.lib.
But I can't seem to do it. I even renamed it to opengl32mesa.lib to ensure I wasn't accidentally pulling in the wrong library; but when I run the program (it compiles fine), glGetString still returns NVIDIA as the GL_VENDOR and my GPU as the renderer.
EDIT: I'm on Windows XP64.
I've managed to get Mesa to work somewhat on a machine without a GPU at all, and found that GL_EXTENSIONS doesn't include ARB_texture_float or ARB_color_buffer_float. I thought Mesa boasted about supporting such things even when hardware didn't?
10-30-2007, 03:51 PM
I think in both cases you called dynamically the MS GL dll, in turn calling the ICD if present.
For my tries with MESA as software emulation for GL2 I compiled the mesa opengl dll, carefully renamed it opengl32.dll, and simply put it in the exe folder.
10-31-2007, 08:15 AM
I have the mesa-built OPENGL32.dll (and GLU32.dll) in my VC8 project directory; not the same dir as the actual exe, but the working directory when running from within VC8.
Still no joy. Also, does Mesa only support FP30?
What's FP30 ?
Check, whether you have other OpenGL32.dll's on your system, possibly remove them (temporarily) to try to force your program to use your DLL.
Also "working directory" and "directory the binary is located in" are a bit strange in Visual Studio. Try putting your OpenGL32.dll also in the directory where the exe is in, it might be the problem.
10-31-2007, 09:27 AM
FP30 is the NV_fragment_program profile. FP40 is NV_fragment_program 2.0.
Moving the dlls to the Debug folder seems to have solved this problem....there's still the issue of Mesa's lack of ARB_texture_float, though....
10-31-2007, 10:27 AM
Yes but you get APPLE_packed_pixels, EXT_convolution, SUN_multi_draw_arrays and a few others I've never heard of...
10-31-2007, 11:22 AM
This is true.
All right, I need unclamped float values to be able to pass all the way from glColorPointer to glReadPixels. Is there another extension that will let me do this? I know sometimes equivalent extensions exist.....
I definitely need glClampColorARB or an equivalent function.
11-01-2007, 07:16 AM
Turns out that the OSMesa interface includes color clamping controls, so that's good. Now I just need to figure out how to compile Mesa to use 32-bit color depth by default.
I did find a #define CHAN_BITS in config.h, and changed it from 8 to 32. Is there anything else I need to do?
Powered by vBulletin® Version 4.2.3 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.