dri-devel January 2012

dri-devel@lists.freedesktop.org

91 participants
570 discussions

[Bug 43768] New: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:1101:i915_translate_token: Assertion `ifs->constant_flags[i] == 0x0' failed.
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=43768 Bug #: 43768 Summary: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:1101:i91 5_translate_token: Assertion `ifs->constant_flags[i] == 0x0' failed. Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: vlee(a)vmware.com mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master) Run piglit glsl-fs-convolution-1 test on i915g. $ ./bin/shader_runner tests/shaders/glsl-fs-convolution-1.shader_test -auto src/gallium/drivers/i915/i915_fpc_translate.c:1101:i915_translate_token: Assertion `ifs->constant_flags[i] == 0x0' failed. Trace/breakpoint trap (core dumped) (gdb) bt #0 0x010eee18 in _debug_assert_fail (expr=0x1a68743 "ifs->constant_flags[i] == 0x0", file=0x1a683d8 "src/gallium/drivers/i915/i915_fpc_translate.c", line=1101, function=0x1a6884b "i915_translate_token") at src/gallium/auxiliary/util/u_debug.c:278 #1 0x0109e0ad in i915_translate_token (p=0x98611f8, token=0x98a23f8, fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1101 #2 0x0109e372 in i915_translate_instructions (p=0x98611f8, tokens=0x9867890, fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1178 #3 0x0109e90c in i915_translate_fragment_program (i915=0x96ce8c0, fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1340 #4 0x010967d6 in i915_create_fs_state (pipe=0x96ce8c0, templ=0x98d977c) at src/gallium/drivers/i915/i915_state.c:577 #5 0x010c0910 in aaline_create_fs_state (pipe=0x96ce8c0, fs=0x98d977c) at src/gallium/auxiliary/draw/draw_pipe_aaline.c:856 #6 0x010c2a2f in aapoint_create_fs_state (pipe=0x96ce8c0, fs=0x98d977c) at src/gallium/auxiliary/draw/draw_pipe_aapoint.c:839 #7 0x0191d608 in st_translate_fragment_program (st=0x97bc488, stfp=0x98c9420, key=0xbfa60ca0) at src/mesa/state_tracker/st_program.c:710 #8 0x0191d729 in st_get_fp_variant (st=0x97bc488, stfp=0x98c9420, key=0xbfa60ca0) at src/mesa/state_tracker/st_program.c:747 #9 0x019c913d in update_fp (st=0x97bc488) at src/mesa/state_tracker/st_atom_shader.c:86 #10 0x019c543b in st_validate_state (st=0x97bc488) at src/mesa/state_tracker/st_atom.c:177 #11 0x01918144 in st_draw_vbo (ctx=0x97663d8, arrays=0x97bf8a0, prims=0xbfa60dec, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at src/mesa/state_tracker/st_draw.c:979 #12 0x019ab5ff in vbo_draw_arrays (ctx=0x97663d8, mode=7, start=0, count=4, numInstances=1) at src/mesa/vbo/vbo_exec_array.c:620 #13 0x019ab757 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at src/mesa/vbo/vbo_exec_array.c:651 #14 0x0809cbf6 in piglit_draw_rect (x=-1, y=-1, w=2, h=2) at piglit/tests/util/piglit-util-gl.c:647 #15 0x0807289d in piglit_display () at piglit/tests/shaders/shader_runner.c:1095 #16 0x08074147 in display () at piglit/tests/util/piglit-framework.c:56 #17 0x0062ec1e in fghRedrawWindow (window=0x96c6a28) at freeglut_main.c:210 #18 fghcbDisplayWindow (window=0x96c6a28, enumerator=0xbfa61118) at freeglut_main.c:227 #19 0x00632590 in fgEnumWindows (enumCallback=0x62eb20 <fghcbDisplayWindow>, enumerator=0xbfa61118) at freeglut_structure.c:394 #20 0x0062f02e in fghDisplayAll () at freeglut_main.c:249 #21 glutMainLoopEvent () at freeglut_main.c:1450 #22 0x0062f935 in glutMainLoop () at freeglut_main.c:1498 #23 0x0807487e in main (argc=2, argv=0xbfa61384) at piglit/tests/util/piglit-framework.c:294 (gdb) frame 1 #1 0x0109e0ad in i915_translate_token (p=0x98611f8, token=0x98a23f8, fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1101 1101 assert(ifs->constant_flags[i] == 0x0); (gdb) info locals i = 32 ifs = 0x98602f8 __FUNCTION__ = "i915_translate_token" (gdb) print ifs->constant_flags[i] $1 = 255 '\377' -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 38265] New: [945gm] gl output in mplayer is wonky
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=38265 Summary: [945gm] gl output in mplayer is wonky Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: erappleman(a)gmail.com Whenever I test 915g with mplayer's gl output, my screen starts to bug out. The effects are difficult to capture with a screenshot, but they can be summarized as follows. * gl output will overlay and interact strangely with other windows * in fullscreen, letterboxing will be exaggerated or create a black bar on the right side -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 42025] New: [RADEON:KMS:R600] wine, Halo Trial: glPointSize error = INVALID_VALUE
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=42025 Bug #: 42025 Summary: [RADEON:KMS:R600] wine, Halo Trial: glPointSize error = INVALID_VALUE Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: bpaterni(a)gmail.com I'm trying to get the Halo: Combat Evolved Trial to launch on my machine and I'm thinking this may be a mesa bug rather than a wine bug. So I'm posting here first. The game looks like it launches okay, but as soon as the menu pops up, the game screen starts to flicker different solid colors. I can hear the halo theme in the background so I know the application hasn't crashed entirely. I've tried mesa's software renderer (llvmpipe). It does not experience the same solid color flickering as r600g does. Although another (unrelated) exception occurs if I do use llvmpipe. An apitrace of what I'm experiencing should be located here: http://bayfiles.com/file/18s1/EWVVJ9/halo-trial.trace.gz You should be able to find the halo trial install/executable online for free somewhere with a google search. I don't think Bungie or Microsoft host the file themselves anymore, but you should be able to find it on one of the many free hosting sites available. environment info: Debian unstable/experimental with distro provided kernel 3.0.0-2-amd644 OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 2.1 Mesa 7.12-devel (git-3560027) wine-1.3.30-293-g7fa15c5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 40790] New: r600g readPixSanity failure on RS880 Radeon HD 4250
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=40790 Summary: r600g readPixSanity failure on RS880 Radeon HD 4250 Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: nmiell(a)gmail.com Created an attachment (id=51059) --> (https://bugs.freedesktop.org/attachment.cgi?id=51059) Results for glean/readPixSanity readPixSanity fails with both Mesa 7.11 and current git (2154c672b3f2a0f3de7aaacd9260954b9310262a) on ATI Technologies Inc RS880 [Radeon HD 4250] using the Gallium R600 driver. Test failure is: readPixSanity: FAIL rgba8, db, z24, s8, win+pmap, id 33 Depth worst-case error was 8.39711 bits at (31, 31) expected 0.10967; got 0.10965. RGBA largest readback error was 0 bits Depth largest readback error was 8.39711 bits readPixSanity: FAIL rgba8, db, z24, s8, win+pmap, id 34 Depth worst-case error was 8.39711 bits at (31, 31) expected 0.10967; got 0.10965. RGBA largest readback error was 0 bits Depth largest readback error was 8.39711 bits readPixSanity: FAIL rgba8, db, z24, s8, win+pmap, id 109 Depth worst-case error was 8.39711 bits at (31, 31) expected 0.10967; got 0.10965. RGBA largest readback error was 0 bits Depth largest readback error was 8.39711 bits In addition, the following X error is generated: X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 136 (DRI2) Minor opcode of failed request: 8 (DRI2SwapBuffers ) Resource id in failed request: 0x220000b Serial number of failed request: 1280 Current serial number in output stream: 1280 Relevant packages: xorg-x11-server-Xorg-1.10.4-1.fc15.x86_64 xorg-x11-drv-ati-6.14.1-2.20110525gitfe5c42f51.fc15.x86_64 kernel-2.6.40.4-5.fc15.x86_64 (that's 3.0.4 with a mangled version) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 22

[Bug 39714] New: Slow and choppy 3D performace on evergreen after pm-suspend
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=39714 Summary: Slow and choppy 3D performace on evergreen after pm-suspend Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: bugs.xorg(a)boris64.net Created an attachment (id=49783) --> (https://bugs.freedesktop.org/attachment.cgi?id=49783) dmesg including pm-suspend event I get very slow and choppy 3d performance after suspending my computer. This is valid for glxgears (i-know-it's-not-a-benchmark), kwin and others. After restarting the 3d application speed seems to be normal/ok again. Example: [glxgears output] 17641 frames in 5.0 seconds = 3528.125 FPS 18396 frames in 5.0 seconds = 3679.087 FPS 22768 frames in 5.0 seconds = 4553.543 FPS 18280 frames in 5.0 seconds = 3655.863 FPS 16051 frames in 5.0 seconds = 3210.111 FPS 16030 frames in 5.0 seconds = 3205.946 FPS 18157 frames in 5.0 seconds = 3628.626 FPS 18182 frames in 5.0 seconds = 3636.259 FPS ... (-> pm-msuspend here <-) ... 12270 frames in 19.1 seconds = 641.561 FPS 4518 frames in 5.0 seconds = 903.255 FPS 4721 frames in 5.0 seconds = 944.181 FPS 4750 frames in 5.0 seconds = 949.833 FPS 4724 frames in 5.0 seconds = 944.745 FPS 4759 frames in 5.0 seconds = 951.687 FPS 4535 frames in 5.0 seconds = 905.757 FPS 4557 frames in 5.0 seconds = 911.264 FPS [/glxgears output] Used drivers+software: -xorg-server-1.10.3 -mesa(r600g)/ddx/libdrm from git (latest) -kernel-3.0.0 If you need more infos/logs, please do not hesitate to ask. Thank you in advance! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 15

[Bug 38941] New: Wrong render in Blender with clipping border active in edit mode
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=38941 Summary: Wrong render in Blender with clipping border active in edit mode Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: kam1kaz3(a)gmail.com Created an attachment (id=48737) --> (https://bugs.freedesktop.org/attachment.cgi?id=48737) wrong render When we enable the clipping border (Alt+B) in Blender and enter edit mode, the vertex handles (small quads) are misplaced and huge. This is better seen after rotating the camera. LIBGL_ALWAYS_SOFTWARE=1 works fine. Correct rendering: http://wiki.blender.org/index.php/Doc:Manual/3D_interaction/Navigating/3D_V… Wrong rendering: See attached screenshot. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 38710] New: GTA Vice City hangs in initial menu
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=38710 Summary: GTA Vice City hangs in initial menu Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: j.suarez.agapito(a)gmail.com I am filing this bug as requested in this wine bug report since the bug seems to affect the r600g driver rather than wine itself. http://bugs.winehq.org/show_bug.cgi?id=27609 Please, if any additional information is needed, let me know. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 37417] New: No Alpha Channel for all XPixmaps with KWin+GLES
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=37417 Summary: No Alpha Channel for all XPixmaps with KWin+GLES Product: Mesa Version: 7.10 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: mgraesslin(a)kde.org Created an attachment (id=46961) --> (https://bugs.freedesktop.org/attachment.cgi?id=46961) ARGB window without alpha channel After updating mesa on Debian Testing to package version 7.10.2-2 everything mapped from a XPixmap lost the Alpha Channel. ARGB windows are no longer translucent (screenshot attached) as well everything else mapped from an XPixmap. This only affects OpenGL ES/EGL build of KWin, building against desktop GL/GLX does not show the symptoms. Debug output of KWin with GLES: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV710 OpenGL version string: OpenGL ES 2.0 Mesa 7.10.2 OpenGL shading language version string: OpenGL ES GLSL ES 1.0.16 Driver: R600G GPU class: R700 OpenGL version: 2.0 GLSL version: 1.0.16 Mesa version: 7.10.2 X server version: 1.10.1 Linux kernel version: 2.6.38 Direct rendering: yes Requires strict binding: yes GLSL shaders: yes Texture NPOT support: yes Debug output of KWin with GLX: OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: Mesa DRI R600 (RV710 954F) 20090101 TCL DRI2 OpenGL version string: 2.1 Mesa 7.10.2 OpenGL shading language version string: 1.20 Driver: R600C GPU class: R700 OpenGL version: 2.1 GLSL version: 1.20 Mesa version: 7.10.2 X server version: 1.10.1 Linux kernel version: 2.6.38 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes This worked fine until update of the package. KWin has not changed (recent master, build from today). If you need any help to investigate, please ask. We want to push the GLES build of KWin with our upcoming release (beta 1 next week). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 9

[Bug 37193] New: Crash while switching between OpenGL window and other window
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=37193 Summary: Crash while switching between OpenGL window and other window Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: info(a)noctus.net Thanks to the Unigine Heaven demo I was finally able to reliably reproduce an issue which I only experienced with Mplayer before. Upon switching back and forth between one window where OpenGL is used and another one, quickly the whole input and output of X freezes followed by a hard restart of my system a few moments later. Conditions to reproduce here: 1) Have the Composite extension enabled - the crash does not occur without the Composite extension - disabling Compositing in my WM (Xfwm4, uses XRender) does prevent the crashes 2) Have rencer acceleration enabled - Setting RenderAccel to "Off" prevents the crashes - Crashes occur both with EXA as well as XAA 3) Start an application which opens an OpenGL context with a least amount of complexity wrt the graphics - Crash is reproducible with Mplayer using the GL video output - Also reproducible with the Unigine Heaven demo - Not reproducible with glxgears (seemingly too simple) 4) Open another application window and start switching back and forth between those two Due to the hard restart I am currently unable to find any traces of debugging information so help for getting started on this is greatly appreciated. I am aware that there are quite a few other reports which sound similar to this one and I thought about adding a comment on these. However, without any additional info to add, my comment wouldn’t be that much worth. Thus I am mostly hoping for help on gathering as much information as possible. Aside from using the latest Mesa git master I am also using the latest git master of the xf86-video-ati DDX. (I also wanted to spare you from this lengthy message in #dri-devel ;-) ) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 9

[Bug 34708] New: running piglit on r600 causes gkrellm to lose text color
by bugzilla-daemon＠freedesktop.org 18 Sep '19

18 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=34708 Summary: running piglit on r600 causes gkrellm to lose text color Product: Mesa Version: 7.10 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: hramrach(a)gmail.com Created an attachment (id=43790) --> (https://bugs.freedesktop.org/attachment.cgi?id=43790) screenshot of part of the gkrellm window After running some 3d apps (eg. piglit) parts of gkrellm lose text color. Firefox does not seem affected, nor are terminals. While taking the screenshot the Lock and Shoot buttons which were previously OK lost color while they were redrawn. As all the text that loses color is the value text (as opposed to the label text) it looks like any newly drawn text is not colored (black). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

← Newer
1
...
6
7
8
9
10
11
12
...
57
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2012