Re: [Mesa3d-dev] Merging gallium-st-api
On Tue, Mar 30, 2010 at 5:53 AM, José Fonseca jfons...@vmware.com wrote:
This is visinfo:
{visual = 0x617588, visualid = 37, screen = 0, depth = 16, class = 4,
red_mask = 63, green_mask = 1984, blue_mask = 63488, colormap_size =
64,
bits_per_rgb = 8}
The problem is that {red,green,blue,alpha}_bits are {6, 5, 5, 0}, but
Gallium only supports {5, 6, 5, 0}, i.e. PIPE_FORMAT_B5G6R5_UNORM.
Somewhere before we should be marking this visual as unsupported, but we
don't.
Thanks. This should be fixed by commit c1a392. Unsupported visuals are now
ignored.
--
o...@lunarg.com
--
Download Intel#174; 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-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Merging gallium-st-api
On Tue, 2010-03-16 at 01:41 -0700, Chia-I Wu wrote:
On Tue, Mar 16, 2010 at 9:40 AM, Chia-I Wu olva...@gmail.com wrote:
On Mon, Mar 15, 2010 at 8:04 PM, Keith Whitwell kei...@vmware.com wrote:
I'm very happy to see it merged - it's a nice cleanup of the
state-tracker behaviours.
Great! I would like to do the merge later today.
Done.
I will go on to convert the remaining co state trackers, i.e. st/dri and
st/wgl, and hopefully drop st_public.h support soon.
olv,
I'm seeing an assertion failure with a softpipe/llvmpipe libGL.so
together with vncserver, running any GL application. (It appears to work
fine with a regular Xorg server).
I can't look into this immediately. Can you tell what's the problem?
Jose
Core was generated by `./glean --run results --overwrite --quick --tests
basic --visuals id == 33'.
Program terminated with signal 5, Trace/breakpoint trap.
#0 0x7fefb746b59a in _debug_assert_fail (expr=0x7fefb7b30157 0,
file=0x7fefb7b30110 src/gallium/state_trackers/glx/xlib/xm_api.c,
line=308, function=0x7fefb7b30430 choose_pixel_format)
at src/gallium/auxiliary/util/u_debug.c:201
in src/gallium/auxiliary/util/u_debug.c
#0 0x7fefb746b59a in _debug_assert_fail (expr=0x7fefb7b30157 0,
file=0x7fefb7b30110 src/gallium/state_trackers/glx/xlib/xm_api.c,
line=308, function=0x7fefb7b30430 choose_pixel_format)
at src/gallium/auxiliary/util/u_debug.c:201
No locals.
#1 0x7fefb7249adf in choose_pixel_format (v=0x2279fb0)
at src/gallium/state_trackers/glx/xlib/xm_api.c:308
native_byte_order = 1 '\001'
__FUNCTION__ = choose_pixel_format
#2 0x7fefb724a3a9 in XMesaCreateVisual (display=0x222ecb0,
visinfo=0x2238dd0, rgb_flag=1 '\001', alpha_flag=0 '\000',
db_flag=1 '\001', stereo_flag=0 '\000', ximage_flag=1 '\001',
depth_size=24, stencil_size=8, accum_red_size=16, accum_green_size=16,
accum_blue_size=16, accum_alpha_size=16, num_samples=0, level=0,
visualCaveat=32768) at src/gallium/state_trackers/glx/xlib/xm_api.c:712
xmdpy = 0x7fefb80473e0
v = 0x2279fb0
red_bits = 6
green_bits = 5
blue_bits = 5
alpha_bits = 0
__FUNCTION__ = XMesaCreateVisual
#3 0x7fefb724c0a1 in save_glx_visual (dpy=0x222ecb0, vinfo=0x2238dd0,
rgbFlag=1 '\001', alphaFlag=0 '\000', dbFlag=1 '\001',
stereoFlag=0 '\000', depth_size=24, stencil_size=8, accumRedSize=16,
accumGreenSize=16, accumBlueSize=16, accumAlphaSize=16, level=0,
numAuxBuffers=0) at src/gallium/state_trackers/glx/xlib/glx_api.c:241
ximageFlag = 1 '\001'
xmvis = 0x7fffec105a40
i = 1
comparePointers = 0 '\000'
#4 0x7fefb724c266 in create_glx_visual (dpy=0x222ecb0, visinfo=0x2238dd0)
at src/gallium/state_trackers/glx/xlib/glx_api.c:325
zBits = 16
accBits = 16
alphaFlag = 0 '\000'
#5 0x7fefb724e5e9 in glXGetConfig (dpy=0x222ecb0, visinfo=0x2238dd0,
attrib=1, value=0x7fffec105c1c)
at src/gallium/state_trackers/glx/xlib/glx_api.c:1619
xmvis = 0x0
k = 0
#6 0x00418ef6 in WindowSystem (this=0x7fffec106178, o=...)
at glean/winsys.cpp:87
supportsOpenGL = 1
i = 1
error_base = 0
event_base = 0
vit = {visual = 0x222eb10, visualid = 140737153884488, screen = 0,
depth = 32767, c_class = 4242407, red_mask = 140737153884488,
green_mask = 35841728, blue_mask = 35842840,
colormap_size = -334470648, bits_per_rgb = 32767}
n = 2
glxv = {std::_Vector_baseGLEAN::DrawingSurfaceConfig*,
std::allocatorGLEAN::DrawingSurfaceConfig* = {
_M_impl = {std::allocatorGLEAN::DrawingSurfaceConfig* =
{__gnu_cxx::new_allocatorGLEAN::DrawingSurfaceConfig* = {No data fields},
No data fields}, _M_start = 0x2279430, _M_finish = 0x2279438,
_M_end_of_storage = 0x2279438}}, No data fields}
f = {condition = {std::_Vector_baseint, std::allocatorint = {
_M_impl = {std::allocatorint =
{__gnu_cxx::new_allocatorint = {No data fields}, No data fields},
_M_start = 0x7fffec106380,
_M_finish = 0x222e6c8,
_M_end_of_storage = 0x222eb18}}, No data fields},
sortKeys = {std::_Vector_baseGLEAN::DrawingSurfaceFilter::Token,
std::allocatorGLEAN::DrawingSurfaceFilter::Token = {
_M_impl = {std::allocatorGLEAN::DrawingSurfaceFilter::Token =
{__gnu_cxx::new_allocatorGLEAN::DrawingSurfaceFilter::Token = {No data
fields}, No data fields}, _M_start = 0x222e6c0, _M_finish = 0x7fffec106148,
_M_end_of_storage = 0x0}}, No data fields}, lex = {
input = 0x7fffec105ba0 ,
p = 0x40bd27
\311\303UH\211\345H\203\354\020H\211}\370H\211u\360H\213U\360H\213E\370H\211\326H\211\307\350\212\001,
ignoringCase = true,
token = GLEAN::Lex::ERROR, id = {
static npos = 18446744073709551615,
Re: [Mesa3d-dev] Merging gallium-st-api
On Tue, Mar 16, 2010 at 9:45 PM, José Fonseca jfons...@vmware.com wrote: On Tue, 2010-03-16 at 01:41 -0700, Chia-I Wu wrote: On Tue, Mar 16, 2010 at 9:40 AM, Chia-I Wu olva...@gmail.com wrote: On Mon, Mar 15, 2010 at 8:04 PM, Keith Whitwell kei...@vmware.com wrote: I'm very happy to see it merged - it's a nice cleanup of the state-tracker behaviours. Great! I would like to do the merge later today. Done. I will go on to convert the remaining co state trackers, i.e. st/dri and st/wgl, and hopefully drop st_public.h support soon. I'm seeing an assertion failure with a softpipe/llvmpipe libGL.so together with vncserver, running any GL application. (It appears to work fine with a regular Xorg server). I can't look into this immediately. Can you tell what's the problem? Jose Core was generated by `./glean --run results --overwrite --quick --tests basic --visuals id == 33'. Program terminated with signal 5, Trace/breakpoint trap. #0 0x7fefb746b59a in _debug_assert_fail (expr=0x7fefb7b30157 0, file=0x7fefb7b30110 src/gallium/state_trackers/glx/xlib/xm_api.c, line=308, function=0x7fefb7b30430 choose_pixel_format) at src/gallium/auxiliary/util/u_debug.c:201 in src/gallium/auxiliary/util/u_debug.c #0 0x7fefb746b59a in _debug_assert_fail (expr=0x7fefb7b30157 0, file=0x7fefb7b30110 src/gallium/state_trackers/glx/xlib/xm_api.c, line=308, function=0x7fefb7b30430 choose_pixel_format) at src/gallium/auxiliary/util/u_debug.c:201 No locals. #1 0x7fefb7249adf in choose_pixel_format (v=0x2279fb0) at src/gallium/state_trackers/glx/xlib/xm_api.c:308 native_byte_order = 1 '\001' __FUNCTION__ = choose_pixel_format #2 0x7fefb724a3a9 in XMesaCreateVisual (display=0x222ecb0, visinfo=0x2238dd0, rgb_flag=1 '\001', alpha_flag=0 '\000', db_flag=1 '\001', stereo_flag=0 '\000', ximage_flag=1 '\001', depth_size=24, stencil_size=8, accum_red_size=16, accum_green_size=16, accum_blue_size=16, accum_alpha_size=16, num_samples=0, level=0, visualCaveat=32768) at src/gallium/state_trackers/glx/xlib/xm_api.c:712 xmdpy = 0x7fefb80473e0 v = 0x2279fb0 red_bits = 6 green_bits = 5 blue_bits = 5 alpha_bits = 0 __FUNCTION__ = XMesaCreateVisual I cannot reproduce the assertion failure here. Can you print the contents of visinfo in this stack frame so help me diagnose the issue? -- o...@lunarg.com -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Merging gallium-st-api
Hi list, gallium-st-api has come to the point that st/glx passes as many piglit quick tests as st/glx in master does. I'd like to merge it to master some time this week. gallium-st-api implements a new interface, st_api.h, that aims to be a replacement for st_public.h. The new interface paves the way to implement various EGL specific features. Meanwhile, it is hopefully st_public.h done right. pipe_screen::flush_frontbuffer, which needs a pipe_screen-specific winsys drawable handle, is no longer called directly by st/mesa. pipe_screen::update_buffer is no longer needed, and the validation of drawables is done only when the drawable has changed (resized or buffers swapped). st_api.h can coexist with st_public.h. It has been implemented by both st/mesa and st/vega. Co state trackers, however, can only choose to use one of the interfaces. st/glx and st/egl have been converted to use st_api.h. The plan is to convert st/dri and st/wgl to st_api.h after the merge, and then drop st_public.h support. Work on EGLImage extensions will start also after the merge. Let me know if there is any concern. -- o...@lunarg.com -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Merging gallium-st-api
On Mon, Mar 15, 2010 at 8:04 PM, Keith Whitwell kei...@vmware.com wrote: On Mon, 2010-03-15 at 04:27 -0700, Chia-I Wu wrote: Hi list, gallium-st-api has come to the point that st/glx passes as many piglit quick tests as st/glx in master does. I'd like to merge it to master some time this week. gallium-st-api implements a new interface, st_api.h, that aims to be a replacement for st_public.h. The new interface paves the way to implement various EGL specific features. Meanwhile, it is hopefully st_public.h done right. pipe_screen::flush_frontbuffer, which needs a pipe_screen-specific winsys drawable handle, is no longer called directly by st/mesa. pipe_screen::update_buffer is no longer needed, and the validation of drawables is done only when the drawable has changed (resized or buffers swapped). st_api.h can coexist with st_public.h. It has been implemented by both st/mesa and st/vega. Co state trackers, however, can only choose to use one of the interfaces. st/glx and st/egl have been converted to use st_api.h. The plan is to convert st/dri and st/wgl to st_api.h after the merge, and then drop st_public.h support. Work on EGLImage extensions will start also after the merge. Let me know if there is any concern. I'm very happy to see it merged - it's a nice cleanup of the state-tracker behaviours. Great! I would like to do the merge later today. -- o...@lunarg.com -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
