mesa3d-users

[Mesa3d-users] Linux Install Issue

[Denat H. <De...@De...>]

Hi,

I have Debian Squeeze and tried ./configuring, making and make
installing the Mesa download folder, when I tried to gcc the demos in
the Mesa folder, I got some errors. Something isn't installed right with
the Mesa on this machine.

Here's terminal output of compiling a demo:

username/libs/Demos/MesaDemos-7.7/progs/demos# gcc -o arbfplight
arbfplight.c
/tmp/cc6JMPpU.o: In function `normalize':
arbfplight.c:(.text+0x7b): undefined reference to `sqrt'
/tmp/cc6JMPpU.o: In function `Redisplay':
arbfplight.c:(.text+0xeb): undefined reference to `glClear'
arbfplight.c:(.text+0x134): undefined reference to `glEnable'
arbfplight.c:(.text+0x13e): undefined reference to `glEnable'
arbfplight.c:(.text+0x148): undefined reference to `glDisable'
arbfplight.c:(.text+0x15e): undefined reference to `glLightfv'
arbfplight.c:(.text+0x168): undefined reference to `glDisable'
arbfplight.c:(.text+0x172): undefined reference to `glDisable'
arbfplight.c:(.text+0x17c): undefined reference to `glEnable'
arbfplight.c:(.text+0x181): undefined reference to `glPushMatrix'
arbfplight.c:(.text+0x19c): undefined reference to `glRotatef'
arbfplight.c:(.text+0x1b7): undefined reference to `glRotatef'
arbfplight.c:(.text+0x1ce): undefined reference to `glutSolidSphere'
arbfplight.c:(.text+0x1d3): undefined reference to `glPopMatrix'
arbfplight.c:(.text+0x1d8): undefined reference to `glutSwapBuffers'
arbfplight.c:(.text+0x200): undefined reference to `glutGet'
/tmp/cc6JMPpU.o: In function `Idle':
arbfplight.c:(.text+0x318): undefined reference to `glutPostRedisplay'
/tmp/cc6JMPpU.o: In function `Reshape':
arbfplight.c:(.text+0x341): undefined reference to `glViewport'
arbfplight.c:(.text+0x34b): undefined reference to `glMatrixMode'
arbfplight.c:(.text+0x350): undefined reference to `glLoadIdentity'
arbfplight.c:(.text+0x38d): undefined reference to `glFrustum'
arbfplight.c:(.text+0x397): undefined reference to `glMatrixMode'
arbfplight.c:(.text+0x39c): undefined reference to `glLoadIdentity'
arbfplight.c:(.text+0x3af): undefined reference to `glTranslatef'
/tmp/cc6JMPpU.o: In function `Key':
arbfplight.c:(.text+0x431): undefined reference to `glutIdleFunc'
arbfplight.c:(.text+0x440): undefined reference to `glutIdleFunc'
arbfplight.c:(.text+0x4b3): undefined reference to `glPolygonMode'
arbfplight.c:(.text+0x4c7): undefined reference to `glPolygonMode'
arbfplight.c:(.text+0x531): undefined reference to `glutDestroyWindow'
arbfplight.c:(.text+0x540): undefined reference to `glutPostRedisplay'
/tmp/cc6JMPpU.o: In function `SpecialKey':
arbfplight.c:(.text+0x5da): undefined reference to `glutPostRedisplay'
/tmp/cc6JMPpU.o: In function `Init':
arbfplight.c:(.text+0x631): undefined reference to
`glutExtensionSupported'
arbfplight.c:(.text+0x653): undefined reference to
`glutExtensionSupported'
arbfplight.c:(.text+0x675): undefined reference to `glutGetProcAddress'
arbfplight.c:(.text+0x6ab): undefined reference to `glutGetProcAddress'
arbfplight.c:(.text+0x6e1): undefined reference to `glutGetProcAddress'
arbfplight.c:(.text+0x717): undefined reference to `glutGetProcAddress'
arbfplight.c:(.text+0x74d): undefined reference to `glutGetProcAddress'
/tmp/cc6JMPpU.o:arbfplight.c:(.text+0x783): more undefined references to
`glutGetProcAddress' follow
/tmp/cc6JMPpU.o: In function `Init':
arbfplight.c:(.text+0x8a7): undefined reference to `glGetIntegerv'
arbfplight.c:(.text+0x8ac): undefined reference to `glGetError'
arbfplight.c:(.text+0x8d9): undefined reference to `glGetString'
arbfplight.c:(.text+0xab7): undefined reference to `glGetIntegerv'
arbfplight.c:(.text+0xabc): undefined reference to `glGetError'
arbfplight.c:(.text+0xae9): undefined reference to `glGetString'
arbfplight.c:(.text+0xb5e): undefined reference to `glClearColor'
arbfplight.c:(.text+0xb68): undefined reference to `glEnable'
arbfplight.c:(.text+0xb72): undefined reference to `glEnable'
arbfplight.c:(.text+0xb7c): undefined reference to `glEnable'
arbfplight.c:(.text+0xb90): undefined reference to `glMaterialfv'
arbfplight.c:(.text+0xba4): undefined reference to `glMaterialfv'
arbfplight.c:(.text+0xbbb): undefined reference to `glMaterialf'
arbfplight.c:(.text+0xbc5): undefined reference to `glGetString'
/tmp/cc6JMPpU.o: In function `main':
arbfplight.c:(.text+0xc12): undefined reference to `glutInit'
arbfplight.c:(.text+0xc21): undefined reference to
`glutInitWindowPosition'
arbfplight.c:(.text+0xc30): undefined reference to `glutInitWindowSize'
arbfplight.c:(.text+0xc3a): undefined reference to `glutInitDisplayMode'
arbfplight.c:(.text+0xc49): undefined reference to `glutCreateWindow'
arbfplight.c:(.text+0xc59): undefined reference to `glutReshapeFunc'
arbfplight.c:(.text+0xc63): undefined reference to `glutKeyboardFunc'
arbfplight.c:(.text+0xc6d): undefined reference to `glutSpecialFunc'
arbfplight.c:(.text+0xc77): undefined reference to `glutDisplayFunc'
arbfplight.c:(.text+0xc8c): undefined reference to `glutIdleFunc'
arbfplight.c:(.text+0xc96): undefined reference to `glutMainLoop'
collect2: ld returned 1 exit status


K, I can tell you any other info about my machine/situation,
Denat

Re: [Mesa3d-users] Mesa/Gallium Cell Driver 0.4 issues

[Dmitry N. M. <mae...@gm...>]

Thank you for your kind help, Brian!

2010/3/18 Brian Paul <br...@vm...>:
> Those may be run of the mill bugs in the driver.  The cell driver is
> incomplete and some things don't work properly.  The docs/cell.html has some
> status info.
>
> -Brian
>
> Dmitry N. Mikushin wrote:
>>
>> Brian,
>>
>> I'm afraid with 0.3 I also have issues. Not that hard that with 0.4,
>> but still. I tried to run Bullet physics visual demo and received
>> screen with black slices. I verified that this behavior is encountered
>> with mesa/gallium 7.7/0.3 turned on via LD_LIBRARY_PATH environment
>> variable, and everything is OK, when it is turned off. Including two
>> screenshots.
>>
>> D
>>
>> 2010/3/17 Brian Paul <br...@vm...>:
>>>
>>> Dmitry N. Mikushin wrote:
>>>>
>>>> The most recent version I've found, that does not have opcode error
>>>> for me is gallium 0.3 in mesa 7.7, the previous one.
>>>
>>> In between other things I'm doing a bisect on the 7.8 branch to find
>>> where
>>> things broke.  I'll try to fix it.
>>>
>>>
>>>> The following
>>>> question might by quiet stupid, but how can I see the performance
>>>> difference between cell-gallium and general mesa? Running glxgears
>>>> Enlightenment on PS3 shows around 105 FPS for both, so I really wonder
>>>> what can benefit from spu acceleration, and how to see that. I'm
>>>> mostly interested in boosting OpenGL.
>>>
>>> First, be sure you're using the driver you expect with glxinfo (see the
>>> "renderer" value).
>>>
>>> Be aware that SwapBuffers() is pretty slow with Cell so you'll never get
>>> super high frame rates.
>>>
>>> Where the Cell driver shines is in non-trivial shaders.  If you compare
>>> the
>>> speed of some of the demos in progs/glsl/ the Cell driver should be much
>>> faster that than the other software drivers.
>>>
>>> -Brian
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>
>

Re: [Mesa3d-users] Mesa/Gallium Cell Driver 0.4 issues

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

Those may be run of the mill bugs in the driver.  The cell driver is 
incomplete and some things don't work properly.  The docs/cell.html 
has some status info.

-Brian

Dmitry N. Mikushin wrote:
> Brian,
> 
> I'm afraid with 0.3 I also have issues. Not that hard that with 0.4,
> but still. I tried to run Bullet physics visual demo and received
> screen with black slices. I verified that this behavior is encountered
> with mesa/gallium 7.7/0.3 turned on via LD_LIBRARY_PATH environment
> variable, and everything is OK, when it is turned off. Including two
> screenshots.
> 
> D
> 
> 2010/3/17 Brian Paul <br...@vm...>:
>> Dmitry N. Mikushin wrote:
>>> The most recent version I've found, that does not have opcode error
>>> for me is gallium 0.3 in mesa 7.7, the previous one.
>> In between other things I'm doing a bisect on the 7.8 branch to find where
>> things broke.  I'll try to fix it.
>>
>>
>>> The following
>>> question might by quiet stupid, but how can I see the performance
>>> difference between cell-gallium and general mesa? Running glxgears
>>> Enlightenment on PS3 shows around 105 FPS for both, so I really wonder
>>> what can benefit from spu acceleration, and how to see that. I'm
>>> mostly interested in boosting OpenGL.
>> First, be sure you're using the driver you expect with glxinfo (see the
>> "renderer" value).
>>
>> Be aware that SwapBuffers() is pretty slow with Cell so you'll never get
>> super high frame rates.
>>
>> Where the Cell driver shines is in non-trivial shaders.  If you compare the
>> speed of some of the demos in progs/glsl/ the Cell driver should be much
>> faster that than the other software drivers.
>>
>> -Brian
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>

Re: [Mesa3d-users] undefined reference to 'glBlitFramebufferEXT' when building against Mesa7.7

[Alan Wu <al...@au...>]

tom fogal wrote:
> Alan Wu <al...@au...> writes:
>> I have built and compiled a linux-x86-32 shared object library
>> of Mesa7.7 under Ubuntu8.04, both glxinfo and glewinfo show me
>> that glBlitFramebufferEXT is available however I got the undefined
>> reference error message when I call the function in my program. I
>> also could not find "glBlitFramebufferEXT" when ran a "objdump -x"
>> command on the built library.
> 
> It's just "glBlitFramebuffer" if you're going to call it directly.  At
> least, that holds with my build of semi-recent master..
> 
> If you want to load it dynamically, I would bet that
> 'glXGetProcAddressARB("glBlitFramebufferEXT");' works; leaving off the
> EXT should work too, of course.
> 
> It shows up in glewinfo because GLEW *is* loading it dynamically.
> 
> I'd recommend you just use GLEW yourself; you don't want rely on an
> extension being available at compilation time, anyway.  Even if your
> program is worthless without the extension, at least you'll have enough
> control to pop up a semi-useful error message.
> 
> Cheers,
> 
> -tom

Thanks Tom, I am considering using GLEW too, at this moment we handle 
loading the headers ourselves, perhaps should let GLEW to do it instead.

Interestingly, I have built Mesa7.7 on both 32 and 64 bit machine and 
glBlitFramebuffer is only defined on the 64bit built.

Cheers,
Alan

Re: [Mesa3d-users] Mesa/Gallium Cell Driver 0.4 issues

[Dmitry N. M. <mae...@gm...>]

Hello, Brian,

Thanks for suggestion,

Last night I've tried out 7.8 RC1 source tar ball from
ftp://ftp.freedesktop.org/pub/mesa/7.8/RC/

Results are pretty same on PS3, I wonder what could be wrong with it:

[root@host192-168-0-104 Mesa-7.8-rc1]# cd progs/xdemos/

[root@host192-168-0-104 xdemos]# ./glxgears
SPU 2: bad opcode: 0x0
SPU 0: bad opcode: 0x0
spu_command.c:714: cmd_batch(): assertion 0 failed.
SPU 3: bad opcode: 0x0
SPU 1: bad opcode: 0x0
spu_command.c:714: cmd_batch(): assertion 0 failed.
spu_command.c:714: cmd_batch(): assertion 0 failed.
spu_command.c:714: cmd_batch(): assertion 0 failed.
SPU 4: bad opcode: 0x0
spu_command.c:714: cmd_batch(): assertion 0 failed.
SPU 5: bad opcode: 0x0
spu_command.c:714: cmd_batch(): assertion 0 failed.
^C

[root@host192-168-0-104 xdemos]# cd ../..

[root@host192-168-0-104 Mesa-7.8-rc1]# ./glxinfo.sh
/home/marcusmae/Programming/mesa-versions/Mesa-7.8-rc1/lib/gallium:/home/marcusmae/Programming/mesa-versions/Mesa-7.8-rc1/lib/
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: Brian Paul
server glx version string: 1.4 Mesa 7.8-rc1
server glx extensions:
    GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
    GLX_MESA_release_buffers, GLX_ARB_get_proc_address,
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer
client glx vendor string: Brian Paul
client glx version string: 1.4 Mesa 7.8-rc1
client glx extensions:
    GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
    GLX_MESA_release_buffers, GLX_ARB_get_proc_address,
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer
GLX version: 1.4
GLX extensions:
    GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
    GLX_MESA_release_buffers, GLX_ARB_get_proc_address,
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on Cell
OpenGL version string: 1.5 Mesa 7.8-rc1
OpenGL extensions:
    GL_ARB_copy_buffer, GL_ARB_depth_texture, GL_ARB_draw_buffers,
    GL_ARB_fragment_coord_conventions, GL_ARB_fragment_program,
    GL_ARB_fragment_shader, GL_ARB_framebuffer_object,
    GL_ARB_map_buffer_range, 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_provoking_vertex,
    GL_ARB_shader_objects, GL_ARB_shading_language_100,
    GL_ARB_shading_language_120, GL_ARB_shadow, 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_array_bgra, GL_ARB_vertex_array_object,
    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_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax,
    GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_copy_texture,
    GL_EXT_draw_range_elements, GL_EXT_framebuffer_blit,
    GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_object,
    GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil,
    GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters,
    GL_EXT_polygon_offset, GL_EXT_provoking_vertex, GL_EXT_rescale_normal,
    GL_EXT_secondary_color, GL_EXT_separate_specular_color,
    GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap,
    GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,
    GL_EXT_texture_cube_map, 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_object,
    GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_vertex_array,
    GL_EXT_vertex_array_bgra, GL_APPLE_packed_pixels,
    GL_APPLE_vertex_array_object, 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_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square,
    GL_NV_light_max_exponent, GL_NV_packed_depth_stencil,
    GL_NV_texture_env_combine4, GL_NV_texture_rectangle,
    GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix,
    GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
    GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays

64 GLX Visuals
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x21 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc2 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc3 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc4 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc5 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc6 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc7 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc8 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc9 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xca 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xcb 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xcc 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xcd 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xce 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xcf 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd0 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd1 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd2 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd3 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd4 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd5 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd6 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd7 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd8 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd9 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xda 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xdb 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xdc 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xdd 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xde 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xdf 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe0 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe1 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe2 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe3 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe4 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe5 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe6 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe7 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe8 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe9 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xea 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xeb 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xec 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xed 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xee 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xef 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf0 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf1 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf2 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf3 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf4 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf5 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf6 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf7 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf8 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf9 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xfa 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xfb 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xfc 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xfd 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xfe 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xff 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0x41 32 tc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16  0  0 0 None

64 GLXFBConfigs:
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x21  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc2  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc3  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc4  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc5  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc6  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc7  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc8  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xc9  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xca  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xcb  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xcc  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xcd  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xce  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xcf  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd0  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd1  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd2  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd3  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd4  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd5  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd6  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd7  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd8  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xd9  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xda  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xdb  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xdc  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xdd  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xde  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xdf  0 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe0  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe1  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe2  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe3  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe4  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe5  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe6  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe7  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe8  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xe9  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xea  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xeb  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xec  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xed  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xee  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xef  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf0  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf1  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf2  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf3  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf4  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf5  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf6  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf7  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf8  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xf9  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xfa  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xfb  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xfc  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xfd  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xfe  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0xff  0 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None
0x41  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 None

2010/3/17 Brian Paul <br...@vm...>:
> Marcus Mae wrote:
>>
>> Hello, Mesa3d users,
>>
>> Thanks for high-quality software, yesterday I've succeeded with
>> building the latest git snap of Mesa/Gallium Cell Driver. Everything
>> is OK with building, except two small issues: missing ";" after
>> cell_velems_state struct definition in cell_context.h
>
> I'll fix that.
>
>> and missing
>> libidentity.a target, that solved simply by performing make in
>> src/gallium/driver/identity folder.
>
> I'll add that to the linux-cell config file.
>
>
>> With glxinfo it describes itself as
>>
>> OpenGL renderer string: Gallium 0.4 on Cell
>> OpenGL version string: 1.5 Mesa 7.9-devel
>>
>> However, experimenting with driver on PS3 appears to be one big issue
>> for me. First, running OpenGL apps returns "PPU: Multiple rendering
>> contexts not yet supported on Cell.",
>
> Yeah, that's a known short-coming of the driver.
>
>
>> then I was not able to connnect
>> x11vnc server to E16 desktop session running on gallium drivers.
>
> I've never tried the Cell driver with VNC.
>
>
>> And
>> finally, none of progs/demos are working returning "unknown Opcode
>> 0x00" for all 6 spus. So, what could be wrong with it, is current git
>> main branch broken?? Does it work for you, what versions have you
>> tested?
>
> The Cell driver was broken a few weeks ago because of some new gallium
> architectural changes.  I haven't had time to update the driver.
>
> I'd suggest using the Mesa "7.8" branch in the mean time.  The Cell driver
> on that branch should be fine.
>
> -Brian
>
>

Re: [Mesa3d-users] undefined reference to 'glBlitFramebufferEXT' when building against Mesa7.7

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

Alan Wu <al...@au...> writes:
> I have built and compiled a linux-x86-32 shared object library
> of Mesa7.7 under Ubuntu8.04, both glxinfo and glewinfo show me
> that glBlitFramebufferEXT is available however I got the undefined
> reference error message when I call the function in my program. I
> also could not find "glBlitFramebufferEXT" when ran a "objdump -x"
> command on the built library.

It's just "glBlitFramebuffer" if you're going to call it directly.  At
least, that holds with my build of semi-recent master..

If you want to load it dynamically, I would bet that
'glXGetProcAddressARB("glBlitFramebufferEXT");' works; leaving off the
EXT should work too, of course.

It shows up in glewinfo because GLEW *is* loading it dynamically.

I'd recommend you just use GLEW yourself; you don't want rely on an
extension being available at compilation time, anyway.  Even if your
program is worthless without the extension, at least you'll have enough
control to pop up a semi-useful error message.

Cheers,

-tom

[Mesa3d-users] undefined reference to 'glBlitFramebufferEXT' when building against Mesa7.7

[Alan Wu <al...@au...>]

Hi all,

I have built and compiled a linux-x86-32 shared object library of 
Mesa7.7 under Ubuntu8.04, both glxinfo and glewinfo show me that 
glBlitFramebufferEXT is available however I got the undefined reference 
error message when I call the function in my program. I also could not 
find "glBlitFramebufferEXT" when ran a "objdump -x" command on the built 
library.

I am planning to do a MSAA with framebuffer object and I was very 
excited to find that glRenderBufferStorageMultisampleEXT is now 
supported. Great work!

Anyway, I greatly appreciate any suggestion that you guys may have. I 
thought GL_EXT_framebuffer_blit is supported since Mesa6.5.
Thanks so much for your time.

Kind Regards,
Alan

Re: [Mesa3d-users] Mesa/Gallium Cell Driver 0.4 issues

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

Marcus Mae wrote:
> Hello, Mesa3d users,
> 
> Thanks for high-quality software, yesterday I've succeeded with
> building the latest git snap of Mesa/Gallium Cell Driver. Everything
> is OK with building, except two small issues: missing ";" after
> cell_velems_state struct definition in cell_context.h

I'll fix that.

> and missing
> libidentity.a target, that solved simply by performing make in
> src/gallium/driver/identity folder.

I'll add that to the linux-cell config file.


> With glxinfo it describes itself as
> 
> OpenGL renderer string: Gallium 0.4 on Cell
> OpenGL version string: 1.5 Mesa 7.9-devel
> 
> However, experimenting with driver on PS3 appears to be one big issue
> for me. First, running OpenGL apps returns "PPU: Multiple rendering
> contexts not yet supported on Cell.",

Yeah, that's a known short-coming of the driver.


> then I was not able to connnect
> x11vnc server to E16 desktop session running on gallium drivers.

I've never tried the Cell driver with VNC.


> And
> finally, none of progs/demos are working returning "unknown Opcode
> 0x00" for all 6 spus. So, what could be wrong with it, is current git
> main branch broken?? Does it work for you, what versions have you
> tested?

The Cell driver was broken a few weeks ago because of some new gallium 
architectural changes.  I haven't had time to update the driver.

I'd suggest using the Mesa "7.8" branch in the mean time.  The Cell 
driver on that branch should be fine.

-Brian

[Mesa3d-users] Mesa/Gallium Cell Driver 0.4 issues

[Marcus M. <mae...@gm...>]

Hello, Mesa3d users,

Thanks for high-quality software, yesterday I've succeeded with
building the latest git snap of Mesa/Gallium Cell Driver. Everything
is OK with building, except two small issues: missing ";" after
cell_velems_state struct definition in cell_context.h and missing
libidentity.a target, that solved simply by performing make in
src/gallium/driver/identity folder.

With glxinfo it describes itself as

OpenGL renderer string: Gallium 0.4 on Cell
OpenGL version string: 1.5 Mesa 7.9-devel

However, experimenting with driver on PS3 appears to be one big issue
for me. First, running OpenGL apps returns "PPU: Multiple rendering
contexts not yet supported on Cell.", then I was not able to connnect
x11vnc server to E16 desktop session running on gallium drivers. And
finally, none of progs/demos are working returning "unknown Opcode
0x00" for all 6 spus. So, what could be wrong with it, is current git
main branch broken?? Does it work for you, what versions have you
tested?

Thanks,
M.

Re: [Mesa3d-users] undefined symbol in egl/egl_x11_swrast.so and init problems

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

On Fri, Mar 12, 2010 at 6:02 AM, Andreas Pokorny
<and...@gm...> wrote:
> 2010/3/11 Chia-I Wu <ol...@gm...>:
>> On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny
>> <and...@gm...> wrote:
>>> I work on: b8656c4825b9e054f05258773ba012e41d4fcdee
>>> I have two rather strange problems using egl. I have implemented a
>>> egl/es2/libX11 based renderer shared object file. The shared object
>>> file gets loaded and initialized using dlopen/dlsym. Then when the
>>> renderer is supposed to initialize EGL, and to create a window I run
>>> into runtime symbol lookup errors.
>>> ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so:
>>> undefined symbol: _eglInitDriverFallbacks
>> It seems _eglInitDriverFallbacks in libEGL.so is not resolved when
>> egl_x11_swrast.so is loaded.  I am not quite sure about your setup (who dlopen
>> who?).  Do you have a sample code that reproduces your setup or the issue?
> My applicatin dlopens a shared object files that links against EGL and
> ES2. I was just writing a sample code that turns progs/es2/xegl/tri.c
> into a shared library. Then I dlopen the lib with
> dlopen(RTLD_LAZY|RTLD_LOCAL);  - and then i try to execute an exported
> function of tri.c (turned main into a function with visibility
> default) as it seems RTLD_LOCAL causes the issue. I have to use
> RTLD_GLOBAL instead.  So now it works.
> I have no idea why i used RTLD_LOCAL in the first place.
Glad you solved your problem.  dlopen()ing is one of the part in EGL that I
haven't looked at.  I don't have enough experiences on various setups or Unixes
to say that EGL is doing the right thing.
>>> When I add the following to the makefiles - it seems to work.
>>>
>>> --- a/src/gallium/winsys/drm/swrast/egl/Makefile
>>> +++ b/src/gallium/winsys/drm/swrast/egl/Makefile
>>> @@ -3,7 +3,7 @@ include $(TOP)/configs/current
>>>
>>>  EGL_DRIVER_NAME = swrast
>>>  EGL_DRIVER_SOURCES = dummy.c
>>> -EGL_DRIVER_LIBS =
>>> +EGL_DRIVER_LIBS = -lEGL
>>>
>>>  EGL_DRIVER_PIPES = \
>>>        $(TOP)/src/gallium/winsys/drm/swrast/core/libswrastdrm.a \
>>>
>>> Then the eglInitialize() command still fails because of something else.
>>>
>>> When I run the application with the following settings:
>>> EGL_DRIVER=egl_x11_swrast
>>> EGL_SOFTWARE=1
>>> EGL_DISPLAY=x11
>>> EGL_LOG_LEVEL=debug
>>>
>>> I get:
>>>
>>> libEGL debug: dlopen(/usr/local/lib/egl/egl_x11_swrast.so)
>>> libEGL info: use software fallback
>>> libEGL warning: No supported client API
>>> libEGL debug: no state tracker supports config 0x21
>>> ... till ...
>>> libEGL debug: no state tracker supports config 0x98
>>> libEGL debug: EGL user error 0x3001 (other) in eglInitialize(unable to
>>> add configs)
>>> The demos in mesa/progs/egl give me the same output. While the demos
>>> in mesa/progs/{es2,es1}/xegl and work. Any ideas what I am doing
>>> wrong?
>> From which directory do you build your libGL?  You need to use the one from
>> src/gallium/winsys/xlib (or src/gallium/targets/libgl-xlib/ in today's git).
>> Have a look at the OpenGL section in docs/egl.html.
> I did not build libGL, I was only interested in EGL and GLES1/ES2 and
> VG. Do I have to build GL?
No.  Only if you want to run the demos under progs/egl/.

-- 
ol...@Lu...

Re: [Mesa3d-users] undefined symbol in egl/egl_x11_swrast.so and init problems

[Andreas P. <and...@gm...>]

Hi,

2010/3/11 Chia-I Wu <ol...@gm...>:
> On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny
> <and...@gm...> wrote:
>> Hi,
>>
>> I work on: b8656c4825b9e054f05258773ba012e41d4fcdee
>>
>> I have two rather strange problems using egl. I have implemented a
>> egl/es2/libX11 based renderer shared object file. The shared object
>> file gets loaded and initialized using dlopen/dlsym. Then when the
>> renderer is supposed to initialize EGL, and to create a window I run
>> into runtime symbol lookup errors.
>>
>> ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so:
>> undefined symbol: _eglInitDriverFallbacks

> It seems _eglInitDriverFallbacks in libEGL.so is not resolved when
> egl_x11_swrast.so is loaded.  I am not quite sure about your setup (who dlopen
> who?).  Do you have a sample code that reproduces your setup or the issue?

My applicatin dlopens a shared object files that links against EGL and
ES2. I was just writing a sample code that turns progs/es2/xegl/tri.c
into a shared library. Then I dlopen the lib with
dlopen(RTLD_LAZY|RTLD_LOCAL);  - and then i try to execute an exported
function of tri.c (turned main into a function with visibility
default) as it seems RTLD_LOCAL causes the issue. I have to use
RTLD_GLOBAL instead.  So now it works.

I have no idea why i used RTLD_LOCAL in the first place.

>> When I add the following to the makefiles - it seems to work.
>>
>> --- a/src/gallium/winsys/drm/swrast/egl/Makefile
>> +++ b/src/gallium/winsys/drm/swrast/egl/Makefile
>> @@ -3,7 +3,7 @@ include $(TOP)/configs/current
>>
>>  EGL_DRIVER_NAME = swrast
>>  EGL_DRIVER_SOURCES = dummy.c
>> -EGL_DRIVER_LIBS =
>> +EGL_DRIVER_LIBS = -lEGL
>>
>>  EGL_DRIVER_PIPES = \
>>        $(TOP)/src/gallium/winsys/drm/swrast/core/libswrastdrm.a \
>>
>> Then the eglInitialize() command still fails because of something else.
>>
>> When I run the application with the following settings:
>> EGL_DRIVER=egl_x11_swrast
>> EGL_SOFTWARE=1
>> EGL_DISPLAY=x11
>> EGL_LOG_LEVEL=debug
>>
>> I get:
>>
>> libEGL debug: dlopen(/usr/local/lib/egl/egl_x11_swrast.so)
>> libEGL info: use software fallback
>> libEGL warning: No supported client API
>> libEGL debug: no state tracker supports config 0x21
>> ... till ...
>> libEGL debug: no state tracker supports config 0x98
>> libEGL debug: EGL user error 0x3001 (other) in eglInitialize(unable to
>> add configs)
>> The demos in mesa/progs/egl give me the same output. While the demos
>> in mesa/progs/{es2,es1}/xegl and work. Any ideas what I am doing
>> wrong?

> From which directory do you build your libGL?  You need to use the one from
> src/gallium/winsys/xlib (or src/gallium/targets/libgl-xlib/ in today's git).
> Have a look at the OpenGL section in docs/egl.html.

I did not build libGL, I was only interested in EGL and GLES1/ES2 and
VG. Do I have to build GL?

regards
Andreas Pokorny

Re: [Mesa3d-users] undefined symbol in egl/egl_x11_swrast.so and init problems

[Andreas P. <and...@gm...>]

Hi,
Another minor thing, make install yields:

[...]
/usr/bin/install -c -d /usr/local/lib/pkgconfig
/bin/bash ../../bin/minstall ../../lib/libGL.*so* \
		/usr/local/lib
Unknown type of argument:  ../../lib/libGL.*so*
make[3]: *** [install-libgl] Error 1
make[3]: Leaving directory `/home/mumiee/mesa/src/mesa

There is no libGL in lib/ I could not find the rule that tries to install libGL

regards
Andreas Pokorny

Re: [Mesa3d-users] undefined symbol in egl/egl_x11_swrast.so and init problems

[Andreas P. <and...@gm...>]

Another build problem remained:

make[5]: Entering directory
`/home/mumiee/mesa/src/gallium/winsys/drm/swrast/egl'
gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_ASM
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
-DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o
make[5]: *** No rule to make target
`../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
`egl_x11_swrast.so'.  Stop.
make[5]: Leaving directory `/home/mumiee/mesa/src/gallium/winsys/drm/swrast/egl'

config.status contains:
S["GALLIUM_WINSYS_DIRS"]=" drm"

but i guess it should be
S["GALLIUM_WINSYS_DIRS"]="xlib drm"

i configured the build with
 ./configure --enable-egl --with-egl-displays=x11
--with-state-trackers=egl,vega,es --enable-gallium-swrast.

2010/3/11 Andreas Pokorny <and...@gm...>:
> Hi,
> So far this seems to fix all build problems that I had. I will come
> back as soon as the build is complete. Will take some time .. My home
> system isnt the fasted.
>
> Thank you.
>
> regards
> Andreas
>
> 2010/3/11 Keith Whitwell <ke...@vm...>:
>> This may be related to the attached patch.  Please let me know if this
>> improves things & I'll commit
>>
>> Keith
>>
>> [...]
>

Re: [Mesa3d-users] undefined symbol in egl/egl_x11_swrast.so and init problems

[Andreas P. <and...@gm...>]

Hi,
So far this seems to fix all build problems that I had. I will come
back as soon as the build is complete. Will take some time .. My home
system isnt the fasted.

Thank you.

regards
Andreas

2010/3/11 Keith Whitwell <ke...@vm...>:
> This may be related to the attached patch.  Please let me know if this
> improves things & I'll commit
>
> Keith
>
> [...]

Re: [Mesa3d-users] undefined symbol in egl/egl_x11_swrast.so and init problems

[Keith W. <ke...@vm...>]

This may be related to the attached patch.  Please let me know if this
improves things & I'll commit

Keith

On Thu, 2010-03-11 at 07:57 -0800, Chia-I Wu wrote:
> On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny
> <and...@gm...> wrote:
> > Hi,
> >
> > I work on: b8656c4825b9e054f05258773ba012e41d4fcdee
> >
> > I have two rather strange problems using egl. I have implemented a
> > egl/es2/libX11 based renderer shared object file. The shared object
> > file gets loaded and initialized using dlopen/dlsym. Then when the
> > renderer is supposed to initialize EGL, and to create a window I run
> > into runtime symbol lookup errors.
> >
> > ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so:
> > undefined symbol: _eglInitDriverFallbacks
> It seems _eglInitDriverFallbacks in libEGL.so is not resolved when
> egl_x11_swrast.so is loaded.  I am not quite sure about your setup (who dlopen
> who?).  Do you have a sample code that reproduces your setup or the issue?
> > When I add the following to the makefiles - it seems to work.
> >
> > --- a/src/gallium/winsys/drm/swrast/egl/Makefile
> > +++ b/src/gallium/winsys/drm/swrast/egl/Makefile
> > @@ -3,7 +3,7 @@ include $(TOP)/configs/current
> >
> >  EGL_DRIVER_NAME = swrast
> >  EGL_DRIVER_SOURCES = dummy.c
> > -EGL_DRIVER_LIBS =
> > +EGL_DRIVER_LIBS = -lEGL
> >
> >  EGL_DRIVER_PIPES = \
> >        $(TOP)/src/gallium/winsys/drm/swrast/core/libswrastdrm.a \
> >
> > Then the eglInitialize() command still fails because of something else.
> >
> > When I run the application with the following settings:
> > EGL_DRIVER=egl_x11_swrast
> > EGL_SOFTWARE=1
> > EGL_DISPLAY=x11
> > EGL_LOG_LEVEL=debug
> >
> > I get:
> >
> > libEGL debug: dlopen(/usr/local/lib/egl/egl_x11_swrast.so)
> > libEGL info: use software fallback
> > libEGL warning: No supported client API
> > libEGL debug: no state tracker supports config 0x21
> > ... till ...
> > libEGL debug: no state tracker supports config 0x98
> > libEGL debug: EGL user error 0x3001 (other) in eglInitialize(unable to
> > add configs)
> > The demos in mesa/progs/egl give me the same output. While the demos
> > in mesa/progs/{es2,es1}/xegl and work. Any ideas what I am doing
> > wrong?
> >From which directory do you build your libGL?  You need to use the one from
> src/gallium/winsys/xlib (or src/gallium/targets/libgl-xlib/ in today's git).
> Have a look at the OpenGL section in docs/egl.html.
> 

Re: [Mesa3d-users] undefined symbol in egl/egl_x11_swrast.so and init problems

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

On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny
<and...@gm...> wrote:
> Hi,
>
> I work on: b8656c4825b9e054f05258773ba012e41d4fcdee
>
> I have two rather strange problems using egl. I have implemented a
> egl/es2/libX11 based renderer shared object file. The shared object
> file gets loaded and initialized using dlopen/dlsym. Then when the
> renderer is supposed to initialize EGL, and to create a window I run
> into runtime symbol lookup errors.
>
> ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so:
> undefined symbol: _eglInitDriverFallbacks
It seems _eglInitDriverFallbacks in libEGL.so is not resolved when
egl_x11_swrast.so is loaded.  I am not quite sure about your setup (who dlopen
who?).  Do you have a sample code that reproduces your setup or the issue?
> When I add the following to the makefiles - it seems to work.
>
> --- a/src/gallium/winsys/drm/swrast/egl/Makefile
> +++ b/src/gallium/winsys/drm/swrast/egl/Makefile
> @@ -3,7 +3,7 @@ include $(TOP)/configs/current
>
>  EGL_DRIVER_NAME = swrast
>  EGL_DRIVER_SOURCES = dummy.c
> -EGL_DRIVER_LIBS =
> +EGL_DRIVER_LIBS = -lEGL
>
>  EGL_DRIVER_PIPES = \
>        $(TOP)/src/gallium/winsys/drm/swrast/core/libswrastdrm.a \
>
> Then the eglInitialize() command still fails because of something else.
>
> When I run the application with the following settings:
> EGL_DRIVER=egl_x11_swrast
> EGL_SOFTWARE=1
> EGL_DISPLAY=x11
> EGL_LOG_LEVEL=debug
>
> I get:
>
> libEGL debug: dlopen(/usr/local/lib/egl/egl_x11_swrast.so)
> libEGL info: use software fallback
> libEGL warning: No supported client API
> libEGL debug: no state tracker supports config 0x21
> ... till ...
> libEGL debug: no state tracker supports config 0x98
> libEGL debug: EGL user error 0x3001 (other) in eglInitialize(unable to
> add configs)
> The demos in mesa/progs/egl give me the same output. While the demos
> in mesa/progs/{es2,es1}/xegl and work. Any ideas what I am doing
> wrong?
>From which directory do you build your libGL?  You need to use the one from
src/gallium/winsys/xlib (or src/gallium/targets/libgl-xlib/ in today's git).
Have a look at the OpenGL section in docs/egl.html.

-- 
ol...@Lu...

[Mesa3d-users] undefined symbol in egl/egl_x11_swrast.so and init problems

[Andreas P. <and...@gm...>]

Hi,

I work on: b8656c4825b9e054f05258773ba012e41d4fcdee

I have two rather strange problems using egl. I have implemented a
egl/es2/libX11 based renderer shared object file. The shared object
file gets loaded and initialized using dlopen/dlsym. Then when the
renderer is supposed to initialize EGL, and to create a window I run
into runtime symbol lookup errors.

./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so:
undefined symbol: _eglInitDriverFallbacks

When I add the following to the makefiles - it seems to work.

--- a/src/gallium/winsys/drm/swrast/egl/Makefile
+++ b/src/gallium/winsys/drm/swrast/egl/Makefile
@@ -3,7 +3,7 @@ include $(TOP)/configs/current

 EGL_DRIVER_NAME = swrast
 EGL_DRIVER_SOURCES = dummy.c
-EGL_DRIVER_LIBS =
+EGL_DRIVER_LIBS = -lEGL

 EGL_DRIVER_PIPES = \
        $(TOP)/src/gallium/winsys/drm/swrast/core/libswrastdrm.a \

Then the eglInitialize() command still fails because of something else.

When I run the application with the following settings:
EGL_DRIVER=egl_x11_swrast
EGL_SOFTWARE=1
EGL_DISPLAY=x11
EGL_LOG_LEVEL=debug

I get:

libEGL debug: dlopen(/usr/local/lib/egl/egl_x11_swrast.so)
libEGL info: use software fallback
libEGL warning: No supported client API
libEGL debug: no state tracker supports config 0x21
... till ...
libEGL debug: no state tracker supports config 0x98
libEGL debug: EGL user error 0x3001 (other) in eglInitialize(unable to
add configs)


The demos in mesa/progs/egl give me the same output. While the demos
in mesa/progs/{es2,es1}/xegl and work. Any ideas what I am doing
wrong?

regards
Andreas Pokorny

Re: [Mesa3d-users] Kudos on Radeon performance between Mar. 3 and Mar. 8

[Dave W. <daw...@sb...>]

>> If you believe there was important info in my message that should
>> appear on the developers' list, I'll be glad to forward it over to
>> there.  (Or, you could post a message over there letting people know
>> about this message.)
> 
> It seemed to me like your note about the message you saw from the
> kernel was either surprising or indicative a bug.  I don't use DRM
> though, maybe this is normal, I have no idea.  If it was a bug, it
> should definitely be forwarded.

Oh, that.  Now I understand.

I was not reporting a bug or registering a complaint.  It was just 
really funny that I had the most up-to-date git version for Mesa built 
and installed, but the new 2.6.34-rc1 kernel thought my version of Mesa 
was too old and I should consider updating.  Update to what?!  :-)

None of this should distract Mesa developers for even a split second, so 
I don't think I'll put it on the developer list....


DW

Re: [Mesa3d-users] Kudos on Radeon performance between Mar. 3 and Mar. 8

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

Dave Witbrodt <daw...@sb...> writes:
> tom fogal wrote:
> > Dave Witbrodt <daw...@sb...> writes:
> I didn't post my message to the developer list because I assumed
> that the whole purpose of having two lists was to separate
> code/bug-related messages from general comments.  Since my little
> thank-you message contained no information relevant to the developer
> list, I thought I should not post it there.

I agree with the general logic about separation.  I'm not sure a
"thanks!" falls into either category though.

> If Mesa developers do not want to read user comments (which would be
> strongly suggested in the case of a developer who is NOT subscribed
> to this list), then maybe it is for the best that their time isn't
> wasted by having had to read my message.

I cannot presume to speak for any developer.

> If you believe there was important info in my message that should
> appear on the developers' list, I'll be glad to forward it over to
> there.  (Or, you could post a message over there letting people know
> about this message.)

It seemed to me like your note about the message you saw from the
kernel was either surprising or indicative a bug.  I don't use DRM
though, maybe this is normal, I have no idea.  If it was a bug, it
should definitely be forwarded.

-tom

Re: [Mesa3d-users] Kudos on Radeon performance between Mar. 3 and Mar. 8

[Dave W. <daw...@sb...>]

tom fogal wrote:
> Dave Witbrodt <daw...@sb...> writes:
>> So, after I sent my last message, I took another look at the Mesa git
>> tree and saw there were some new commits relevant to my hardware.  I
>> built yet another, newer version of Mesa (up to commit 4243ca1).
> 
> I haven't taken a look at what, exactly, 4243ca1 is.. but if you're
> using recent git (master) versions of Mesa, as opposed to released
> tarballs, I think the best place for these mails is on the developers
> mailing list.  I'm not sure how many radeon devs follow this list.

The context of providing that commit ID was my previous message, where I 
mentioned ...

     Was using Mesa 7.8-devel (git commit be1b7d1) of Mar. 3; upgraded
     to 7.9-devel (git commit 3ca9336) of Mar. 8.

The 4243ca1 commit ID is also from Mesa 7.9-devel.

I didn't post my message to the developer list because I assumed that 
the whole purpose of having two lists was to separate code/bug-related 
messages from general comments.  Since my little thank-you message 
contained no information relevant to the developer list, I thought I 
should not post it there.

If Mesa developers do not want to read user comments (which would be 
strongly suggested in the case of a developer who is NOT subscribed to 
this list), then maybe it is for the best that their time isn't wasted 
by having had to read my message.

If you believe there was important info in my message that should appear 
on the developers' list, I'll be glad to forward it over to there.  (Or, 
you could post a message over there letting people know about this message.)


Thanks,
Dave W.

Re: [Mesa3d-users] Kudos on Radeon performance between Mar. 3 and Mar. 8

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

Dave Witbrodt <daw...@sb...> writes:
> So, after I sent my last message, I took another look at the Mesa git
> tree and saw there were some new commits relevant to my hardware.  I
> built yet another, newer version of Mesa (up to commit 4243ca1).

I haven't taken a look at what, exactly, 4243ca1 is.. but if you're
using recent git (master) versions of Mesa, as opposed to released
tarballs, I think the best place for these mails is on the developers
mailing list.  I'm not sure how many radeon devs follow this list.

Cheers,

-tom

Re: [Mesa3d-users] Kudos on Radeon performance between Mar. 3 and Mar. 8

[Dave W. <daw...@sb...>]

Dave Witbrodt wrote:
> Was using Mesa 7.8-devel (git commit be1b7d1) of Mar. 3; upgraded to 
> 7.9-devel (git commit 3ca9336) of Mar. 8.  Hardware is Radeon HD 4850 
> (RV770).

So, after I sent my last message, I took another look at the Mesa git 
tree and saw there were some new commits relevant to my hardware.  I 
built yet another, newer version of Mesa (up to commit 4243ca1).  I'm 
very happy with that as well.

Then I noticed that kernel 2.6.34-rc1 has been released.  So I built 
that and installed it.  When I booted, I found this in 'dmesg':

     You have old & broken userspace please consider updating mesa

MUAHAHAHAHAAHAHA


Dave W.

[Mesa3d-users] Kudos on Radeon performance between Mar. 3 and Mar. 8

[Dave W. <daw...@sb...>]

Was using Mesa 7.8-devel (git commit be1b7d1) of Mar. 3; upgraded to 
7.9-devel (git commit 3ca9336) of Mar. 8.  Hardware is Radeon HD 4850 
(RV770).

Don't know who to thank -- most likely candidate seems to be series of 
radeon patches from Maciej Cencora -- but I got a nice (subjective) 
performance boost on the applications I've tested.  One game, torcs, has 
a built-in framerate indicator, and I'm getting roughly 10% more FPS there.

Thanks,
Dave W.

Re: [Mesa3d-users] Mesa 7.6.1 on WinXP

[Karl S. <kar...@gm...>]

Pixel formats with alpha are simply not implemented in the windows gdi
driver.  I don't think it would be that hard to add.

They are supported in the gallium driver (src\gallium\state_trackers\wgl),
ARGB and BGRA.

On Fri, Mar 5, 2010 at 3:08 AM, Szilard Kiss <mit...@ya...> wrote:

>
> Hi,
>
> I am using Mesa on Windows (XP). However, I see that there are only two
> pixel formats that could be used, and none of them has an alpha channel. Is
> it possible to use other pixel formats (with an alpha channel) and how?
>
> I guess I'm using the software render mode (this is what I want to do).
> The GL_RENDERER string says "Mesa Windows GDI Driver".
>
> I'm sorry if this has already been answered, but I just could not find
> enough information about this online.
>
> Regards,
> Szilard
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>
>

[Mesa3d-users] Mesa 7.6.1 on WinXP

[Szilard K. <mit...@ya...>]

                
Hi,

I am 
using Mesa on Windows (XP). However, I see that there are only two
pixel
 formats that could be used, and none of them has an alpha channel. Is
it
 possible to use other pixel formats (with an alpha channel) and how? 

I guess I'm using 
the software render mode (this is what I want to do). 
The GL_RENDERER string says "Mesa Windows 
GDI Driver". 

I'm sorry if this has already been answered, but I 
just could not find
enough information about this online.

Regards,
Szilard