I'm using a debian system, if you think some more details can help please let me know. Linux matrix 2.6.29-1-686 #1 SMP Sat Apr 4 17:36:29 UTC 2009 i686 GNU/Linux ii libgl1-mesa-dri 7.4-2 A free implementation of the OpenGL API -- DRI modules (gdb) run Starting program: el.x86.linux.bin [Thread debugging using libthread_db enabled] [New Thread 0xb419bb90 (LWP 6053)] [New Thread 0xb3999b90 (LWP 6058)] [New Thread 0xb29f4b90 (LWP 6070)] [Thread 0xb3999b90 (LWP 6058) exited] do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try adjusting the vblank_mode configuration parameter. [New Thread 0xb21f3b90 (LWP 6086)] el.x86.linux.bin: intel_tex_image.c:355: intelTexImage: Assertion `texImage->RowStride == postConvWidth' failed. Program received signal SIGABRT, Aborted. 0xb7fe1424 in __kernel_vsyscall () (gdb) back #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb78ef640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb78f1008 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb78e85ce in __assert_fail () from /lib/i686/cmov/libc.so.6 #4 0xb6f3c2df in ?? () from /usr/lib/dri/i915_dri.so #5 0xb70fcca8 in ?? () from /usr/lib/dri/i915_dri.so #6 0xb70fcb4d in ?? () from /usr/lib/dri/i915_dri.so #7 0x00000163 in ?? () #8 0xb70fcd49 in ?? () from /usr/lib/dri/i915_dri.so #9 0x00000000 in ?? () (gdb)
installed the libgl1-mesa-dri-dbg libgl1-mesa-glx-dbg and tried tried again (gdb) back #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb78ef640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb78f1008 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb78e85ce in __assert_fail () from /lib/i686/cmov/libc.so.6 #4 0xb6f3c2df in intelTexImage (ctx=0x974ba48, dims=2, target=3553, level=0, internalFormat=6408, width=630, height= 425, depth=1, border=0, format=6408, type=5121, pixels=0x0, unpack=0x9758610, texObj=0x9a37c40, texImage= 0xb99f978, imageSize=0, compressed=0) at intel_tex_image.c:355 #5 0xb6f3c6ae in intelTexImage2D (ctx=0x974ba48, target=3553, level=0, internalFormat=6408, width=630, height=425, border=0, format=6408, type=5121, pixels=0x0, unpack=0x9758610, texObj=0x9a37c40, texImage=0xb99f978) at intel_tex_image.c:582 #6 0xb6f3d241 in intelCopyTexImage2D (ctx=0x974ba48, target=3553, level=0, internalFormat=6408, x=0, y=0, width=630, height=425, border=0) at intel_tex_copy.c:248 #7 0xb6ff4b14 in _mesa_CopyTexImage2D (target=3553, level=0, internalFormat=6408, x=0, y=0, width=1024, height=512, border=0) at main/teximage.c:3024 #8 0x080cd1f4 in take_snapshot (width=630, height=425) at loading_win.c:100 #9 0x080cd242 in create_loading_win (width=630, height=425, snapshot=1) at loading_win.c:113 #10 0x080cf61e in init_map_loading (file_name=0xbfffd15c "./maps/map6nf.elm") at map.c:164 #11 0x080cf658 in el_load_map (file_name=0xbfffd15c "./maps/map6nf.elm") at map.c:196 #12 0x080cf830 in change_map (mapname=0xbfffd15c "./maps/map6nf.elm") at map.c:255 #13 0x080d98a6 in process_message_from_server (in_data=0xb9a14c8 "\a\023", data_length=21) at multiplayer.c:820 #14 0x080cd7e8 in start_rendering () at main.c:166 #15 0x080cdcba in main (argc=1, argv=0xbffff6c4) at main.c:344 (gdb)
Created attachment 25944 [details] A simple test case Actually this bug is rather easy to reproduce, any call to glCopyTexImage2D will trigger it if the requested texture width exceeds OpenGL window width, however any height is ok. I have attached a simple test case for this. In addition, if you allocate memory for the texture with something like this before operation: glTexImage2D (GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_BYTE, NULL); ...glCopyTexImage2D function succeeds. I have used Intel drivers 2.7.1 and Linux 2.6.30.
(In reply to comment #2) > Actually this bug is rather easy to reproduce, any call to glCopyTexImage2D > will trigger it if the requested texture width exceeds OpenGL window width, > however any height is ok. > I have attached a simple test case for this. > > In addition, if you allocate memory for the texture with something like this > before operation: > glTexImage2D (GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_BYTE, > NULL); > ...glCopyTexImage2D function succeeds. It sounds like the driver is allocating the texture based on the clipped-to-window size instead of the requested size.
Created attachment 25977 [details] [review] Clip size after allocating the texture Try this patch. If it fixes the problem, I'll push it to master and the various stable branches.
(In reply to comment #4) > Created an attachment (id=25977) [details] > Clip size after allocating the texture > > Try this patch. If it fixes the problem, I'll push it to master and the > various stable branches. Pushed as commit 129f311673c99eb912d659023e50bc5f0ef53249 on master and commit 16fbd391291de8eddcd01a1a10e6801da299209b on mesa_7_5_branch.
Hi, any chance this could be applied to mesa_7_4_branch? The bug is pretty annoying so it would be nice to have it fixed in distros ASAP. Thanks
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.