Hi folks,
Apologises if I shouldn’t ask here, I thought I would try here before trying the mailing lists.
Is the current version of Mesa 3D, if anyone knows, able to run in software on the CPU without any hardware acceleration from the graphics card? I just needed to know this little nugget of information before setting the environment of whatever. If not, does anyone know a suitable alternative that would? Preferably the fastest one lol
Thanks in advance,
JB.
ok, after further research and reading, it seems that if I build the mesa project, opengl32.dll, glu32.dll and osmesa32.dll are created.
If I run the compiled ‘gears’ program that is available from the website, I get 60fps. I presume that this is using the opengl32.dll from my /Windows/System32 directory, thus supplied by the ATI (its a Radeon card) and thus in hardware.
If I drop the compiled opengl32.dll and glu32.dll into the directory of the .exe the fps drops to 25. I’m assuming this is now using the software renderer? I assume this due to the following on the Mesa site…
3.1 Rendering is slow / why isn’t my graphics hardware being used?
Stand-alone Mesa (downloaded as MesaLib-x.y.z.tar.gz) doesn’t have any support for hardware acceleration (with the exception of the 3DFX Voodoo driver).
What you really want is a DRI or NVIDIA (or another vendor’s OpenGL) driver for your particular hardware.
If anyone can confirm I am speaking sense, that would be really helpful.
Thanks in advance,
JB.
yes.
but 60 fps for hardware accelerated gears is very weak 
you probably have vsync on, which prevents to do any sort of precise benchmark.
True. Mesa3D is mainly a software implementation of the API.
It supports partial HW acceleration on some basic cards.
One benefit is you can switch to Mesa dll whenever you applicaiton suspects a built-in video chips, or the required version of GL is not supported.
Sounds like it to me.
If your “gears” app is the same as “glxgears” under Linux (part of freeglut), run it with the “-info” arg to get it to dump:
GL_RENDERER
GL_VERSION
GL_VENDOR
GL_EXTENSIONS
That’ll tell you pretty clearly which GL is being used.
Thats folks, much appreciated.
So it seems to be software, is Mesa Software Rendering going to perform much worse than any other software renderer? Coco3D seems to be an alternative, though I’m used to opengl so Mesa3D would suit me better from a development POV.
Dark Photon:
The following is the results from the ‘info’ arg.
GL_RENDERER = Mesa Windows GDI Driver
GL_VERSION = 2.1 Mesa 7.5
GL_VENDOR = Brian Paul
GL_EXTENSIONS = GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_shading_language_120 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_shared_texture_palette GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_swizzle GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_3DFX_texture_compression_FXT1 GL_APPLE_packed_pixels GL_APPLE_vertex_array_object GL_ATI_blend_equation_separate GL_ATI_envmap_bumpmap GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_ATI_fragment_shader GL_ATI_separate_stencil GL_IBM_multimode_draw_arrays GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_resize_buffers GL_MESA_texture_array GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_fragment_program GL_NV_light_max_exponent GL_NV_point_sprite GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_NV_vertex_program1_1 GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGI_texture_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays
i would’t say its slow. it’s slow compared to HW of course but the project is maintained for years and has stable versions according to changelist also optimized here and there. you should note that you can get artifacts like i did, check the picture for more info (left side Mesa 7.2): http://i31.tinypic.com/w6rtw5.jpg
_NK47 : isn’t this caused by low precision zbuffer (ie. could be using depth buffer default precision, can be 16bits with mesa, but 24 on your hardware implementation) ?
do you use shaders or just line rendering for the outlines ?
I’d like to know more about these artifacts.
ZbufferR: that was first thing entering my mind that depth buffer precision isn’t sufficient. thing is that i just put compiled mesa opengl32.dll and let it run, where my application enforces 24bit precision paired with 8bit stencil. the shader is GLSL 1.1 gooch shader containing two passes first pass for color computation and second for line drawing using linewidth of 5.0 and no fallback to FFP is done on the line pass (simple vertex/fragment shader). i didn’t dig much into that issue but saved the screen as a reference. if you need more details on the setup i could look more into it since its been half year since then.
