Bug 27924 - [TTM] Illegal buffer object size. Black screen with Compiz
Summary: [TTM] Illegal buffer object size. Black screen with Compiz
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-01 03:05 UTC by Michał Lipski
Modified: 2010-05-05 09:38 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg log (28.36 KB, text/plain)
2010-05-01 03:06 UTC, Michał Lipski
Details
a patch to try. (1.17 KB, patch)
2010-05-04 06:59 UTC, Brian Paul
Details | Splinter Review

Description Michał Lipski 2010-05-01 03:05:32 UTC
Hello,
after commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 (st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures) I get "[TTM] Illegal buffer object size." and black screen with Compiz. I use nouveau nv50 chip.
Comment 1 Michał Lipski 2010-05-01 03:06:32 UTC
Created attachment 35359 [details]
Xorg log
Comment 2 Michał Lipski 2010-05-02 04:18:22 UTC
I've tried
Section "ServerFlags"
...
Option "GlxVisuals" "all"
...
EndSection

but it's still the same.
Comment 3 Brian Paul 2010-05-04 06:59:02 UTC
Maxim provided a stack trace:

Breakpoint 1, st_texture_create (st=0x991ec0, target=PIPE_TEXTURE_2D, format=PIPE_FORMAT_I8_UNORM, last_level=0, width0=512, height0=32, depth0=1, bind=4) at state_tracker/st_texture.c:64
64	{
#0  st_texture_create (st=0x991ec0, target=PIPE_TEXTURE_2D, format=PIPE_FORMAT_I8_UNORM, last_level=0, width0=512, height0=32, depth0=1, bind=4) at state_tracker/st_texture.c:64
#1  0x00007ffff3409224 in reset_cache (st=0x991ec0) at state_tracker/st_cb_bitmap.c:542
#2  0x00007ffff33d519e in st_create_context_priv (pipe=0x900370, visual=<value optimized out>, share=<value optimized out>) at state_tracker/st_context.c:149
#3  st_create_context (pipe=0x900370, visual=<value optimized out>, share=<value optimized out>) at state_tracker/st_context.c:219
#4  0x00007ffff3398bd7 in st_api_create_context (stapi=<value optimized out>, smapi=0x9123e0, visual=0x7fffffffd2a0, shared_stctxi=0x0) at state_tracker/st_manager.c:589
#5  0x00007ffff32a0d5e in dri_create_context (api=<value optimized out>, visual=0x931740, cPriv=<value optimized out>, sharedContextPrivate=<value optimized out>) at dri_context.c:79
#6  0x00007ffff329aeda in dri2CreateNewContextForAPI (screen=0x912170, api=0, config=0x931740, shared=<value optimized out>, data=0x200) at ../../../../src/mesa/drivers/dri/common/dri_util.c:662
#7  0x00007ffff63be1c9 in dri2CreateContext (psc=0x900090, mode=0x904700, gc=0x900160, shareList=<value optimized out>, renderType=<value optimized out>) at dri2_glx.c:150
#8  0x00007ffff6395905 in CreateContext (dpy=0x64ed00, generic_id=33, fbconfig=<value optimized out>, shareList=0x0, allowDirect=<value optimized out>, code=3, renderType=32788, screen=0) at glxcmds.c:403
#9  0x00007ffff6396e38 in glXCreateContext (dpy=0x64ed00, vis=0x8f3860, shareList=0x0, allowDirect=1) at glxcmds.c:527
#10 0x00000000004196ff in addScreen ()
#11 0x0000000000412334 in addDisplay ()
#12 0x000000000040d8dc in main ()

Breakpoint 1, st_texture_create (st=0x991ec0, target=PIPE_TEXTURE_2D, format=PIPE_FORMAT_B8G8R8X8_UNORM, last_level=0, width0=0, height0=0, depth0=0, bind=6) at state_tracker/st_texture.c:64
64	{
#0  st_texture_create (st=0x991ec0, target=PIPE_TEXTURE_2D, format=PIPE_FORMAT_B8G8R8X8_UNORM, last_level=0, width0=0, height0=0, depth0=0, bind=6) at state_tracker/st_texture.c:64
#1  0x00007ffff34174e0 in st_finalize_texture (ctx=0x9495d0, pipe=<value optimized out>, tObj=0xcbbcb0, needFlush=<value optimized out>) at state_tracker/st_cb_texture.c:1910
#2  0x00007ffff340830a in finalize_textures (st=0x991ec0) at state_tracker/st_atom_texture.c:145
#3  0x00007ffff34045d9 in st_validate_state (st=0x991ec0) at state_tracker/st_atom.c:167
#4  0x00007ffff33d5b2a in st_draw_vbo (ctx=<value optimized out>, arrays=0x995608, prims=<value optimized out>, nr_prims=<value optimized out>, ib=0x0, index_bounds_valid=0 '\000', min_index=0, max_index=3) at state_tracker/st_draw.c:577
#5  0x00007ffff33fcf84 in vbo_exec_DrawArrays (mode=7, start=0, count=<value optimized out>) at vbo/vbo_exec_array.c:525
#6  0x0000000000427c9e in ?? ()
#7  0x0000000000427afb in drawWindowTexture ()
#8  0x0000000000427013 in drawWindow ()
#9  0x00007fffef6bbd4f in ?? () from /usr/lib/compiz/libdecoration.so
#10 0x0000000000426ef9 in paintWindow ()
#11 0x00007fffefcd0988 in ?? () from /usr/lib/compiz/libmove.so
#12 0x00007fffefacaa80 in ?? () from /usr/lib/compiz/libresize.so
#13 0x0000000000428c3d in ?? ()
#14 0x00000000004299b5 in paintOutput ()
#15 0x00007fffefacaee0 in ?? () from /usr/lib/compiz/libresize.so
#16 0x0000000000410b67 in paintScreen ()
#17 0x0000000000412a35 in eventLoop ()
#18 0x000000000040d8e9 in main ()
Mesa: User error: GL_OUT_OF_MEMORY in glTexImage
Comment 4 Brian Paul 2010-05-04 06:59:43 UTC
Created attachment 35409 [details] [review]
a patch to try.

Can you try the attached patch?
Comment 5 maximlevitsky 2010-05-04 07:33:27 UTC
patch doesn't help.
Comment 6 Michał Lipski 2010-05-04 09:00:08 UTC
Same results with latest patch.
Comment 7 Brian Paul 2010-05-04 09:39:26 UTC
I've committed another change (2b53f4a9c674e9b02df8a06759e7a2340f257081) that should silence the spurious GL_OUT_OF_MEMORY error.  Not sure if that'll help with the overall problem though.
Comment 8 Michał Lipski 2010-05-04 09:56:45 UTC
(In reply to comment #7)
> I've committed another change (2b53f4a9c674e9b02df8a06759e7a2340f257081) that
> should silence the spurious GL_OUT_OF_MEMORY error.  Not sure if that'll help
> with the overall problem though.

Nope, it doesn't help.
Comment 9 Marek Olšák 2010-05-04 10:27:52 UTC
FWIW I get textures of size 0x0 in resource_create when texture_from_pixmap is used. I guess it might be the reason the buffer allocation is failing. It's reproducible via piglit/tfp.
Comment 10 Xavier 2010-05-04 15:25:38 UTC
(In reply to comment #9)
> FWIW I get textures of size 0x0 in resource_create when texture_from_pixmap is
> used. I guess it might be the reason the buffer allocation is failing. It's
> reproducible via piglit/tfp.

I can indeed reproduce the problem with nv50 on both compiz and tfp.

I've noticed that the commit changed firstImage->base.Width2(,height,depth) to stObj->width0(,height,depth)

I've enabled DBG and added one printf below :
   /* If we already have a gallium texture, check that it matches the texture
    * object's format, target, size, num_levels, etc.
    */
   if (stObj->pt) {
           printf("stobj->pt %dx%dx%d stobj %dx%dx%d firstimage %dx%dx%d\n", stObj->pt->width0, stObj->pt->height0, stObj->pt->depth0,
                           stObj->width0, stObj->height0, stObj->depth0,
                           firstImage->base.Width2, firstImage->base.Height2, firstImage->base.Depth2);

And this is the ouput with tfp :
st_NewTextureObject
st_NewTextureImage
stobj->pt 2x2x1 stobj 0x0x0 firstimage 2x2x1
Mesa: User error: GL_OUT_OF_MEMORY in glTexImage
stobj->pt 2x2x1 stobj 0x0x0 firstimage 2x2x1
st_NewTextureObject
st_NewTextureImage
st_FreeTextureImageData
stobj->pt 2x2x1 stobj 0x0x0 firstimage 2x2x1
stobj->pt 2x2x1 stobj 0x0x0 firstimage 2x2x1

I doubt this helps, but just in case...
I don't understand what stobj, stobj->pt and firstimage are respectively.

I don't understand that comment below either, but from the output above, the image dimensions don't seem to match.
   /* If both firstImage and stObj point to a texture which can contain
    * all active images, favour firstImage.  Note that because of the
    * completeness requirement, we know that the image dimensions
    * will match.
    */
Comment 11 Michał Lipski 2010-05-05 05:08:46 UTC
Okay, seems to be finally fixed in current GIT. Thanks.
Comment 12 Brian Paul 2010-05-05 07:24:47 UTC
Looks like Chia-I Wu found/fixed this with commit 719f7049bb2c7f5ca886055c9cd15b2805bd8e97.  Thanks!
Comment 13 Xavier 2010-05-05 09:38:29 UTC
Confirmed, thanks Chia-I Wu !


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.