Hi Kwin starts with a black screen if I use r600-llvm-compiler on my RS880 When I switched off the llvm parts and just ran glxgears using r600-llvm-compiler the gears looked like they were layered wrongly and slightly darker I'm not sure when this regression appeared - I'm guessing within the last two weeks - I mostly ssh into the box I'm always running the latest llvm, clang, libdrm and mesa I didn't see anything strange in my dmesg or .xsession-errors or from the glxgears text output Could this be due to RS880 being singled out in llvm as a separate processor variant? ie r600g/llvm: Update radeon family mappings for LLVM backend or [PATCH 1/2] R600: Add some new processor variants
Any chance you could bisect? It might be a duplicate of bug 64193.
Is it mesa or llvm that needs bisecting or both?
Could be either, but you generally need matching Git snapshots anyway.
I just pushed the Mesa patch that updates the GPU mappings to account for the new processors in LLVM. Can you re-test with the latest code from the git repository?
I'm afraid it doesn't fix it - I'm going to be out of the country for a week now - I'll bisect it when I get back if it still isn't working
Created attachment 79269 [details] output of R600_DEBUG=vs,fp,ps working glxgears
Created attachment 79270 [details] output of R600_DEBUG=vs,fp,ps with "dark" glxgears
fixed for me with patch proposed in bug 64193.
I too can confirm that the two patches to llvm fix things for me Is there any chance they could be applied to llvm 3.3 before it's released?
I've now recompiled everything from upstream - kwin now renders however it has a pinkish hugh to the bottom right - this didn't happen when I tested the patches separately
(In reply to comment #10) > I've now recompiled everything from upstream - kwin now renders however it > has a pinkish hugh to the bottom right - this didn't happen when I tested > the patches separately It's possible that the recent scheduling changes have caused an unrelated regression. Does kwin render correctly if you use the LLVM 3.3 branch?
(In reply to comment #11) > (In reply to comment #10) > > I've now recompiled everything from upstream - kwin now renders however it > > has a pinkish hugh to the bottom right - this didn't happen when I tested > > the patches separately > > It's possible that the recent scheduling changes have caused an unrelated > regression. Does kwin render correctly if you use the LLVM 3.3 branch? No time currently to test my rv670 or bisect, but on current heads my rv790 is rendering Unigine heaven with various incorrect hues.
I'm having issues compiling from branches/release_33/ Will try again tonight
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > I've now recompiled everything from upstream - kwin now renders however it > > > has a pinkish hugh to the bottom right - this didn't happen when I tested > > > the patches separately > > > > It's possible that the recent scheduling changes have caused an unrelated > > regression. Does kwin render correctly if you use the LLVM 3.3 branch? > > No time currently to test my rv670 or bisect, but on current heads my rv790 > is rendering Unigine heaven with various incorrect hues. Does a similar regression happens on less complex application ? (ie mesa demo)
(In reply to comment #14) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > I've now recompiled everything from upstream - kwin now renders however it > > > > has a pinkish hugh to the bottom right - this didn't happen when I tested > > > > the patches separately > > > > > > It's possible that the recent scheduling changes have caused an unrelated > > > regression. Does kwin render correctly if you use the LLVM 3.3 branch? > > > > No time currently to test my rv670 or bisect, but on current heads my rv790 > > is rendering Unigine heaven with various incorrect hues. > > Does a similar regression happens on less complex application ? (ie mesa > demo) Demos look OK, and a quick run of openarena and nexuix looked OK. etqw is showing some transient corruptions.
Created attachment 79717 [details] Possible fix Does this patch fix any of the outstanding RS880 issues?
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #12) > > > (In reply to comment #11) > > > > (In reply to comment #10) > > > > > I've now recompiled everything from upstream - kwin now renders however it > > > > > has a pinkish hugh to the bottom right - this didn't happen when I tested > > > > > the patches separately > > > > > > > > It's possible that the recent scheduling changes have caused an unrelated > > > > regression. Does kwin render correctly if you use the LLVM 3.3 branch? > > > > > > No time currently to test my rv670 or bisect, but on current heads my rv790 > > > is rendering Unigine heaven with various incorrect hues. > > > > Does a similar regression happens on less complex application ? (ie mesa > > demo) > > Demos look OK, and a quick run of openarena and nexuix looked OK. > > etqw is showing some transient corruptions. Was going to try and pin this down last night but ended up finding a further regression instead. commit 061ff3409d4f6db313448fa8d916313233789516 Author: Aaron Ballman <aaron@aaronballman.com> Date: Thu May 23 14:55:00 2013 +0000 Setting the default value (fixes CRT assertions about uninitialized variable use when doing debug MSVC builds), and fixing coding style. borks everything for me.
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > I've now recompiled everything from upstream - kwin now renders however it > > > has a pinkish hugh to the bottom right - this didn't happen when I tested > > > the patches separately > > > > It's possible that the recent scheduling changes have caused an unrelated > > regression. Does kwin render correctly if you use the LLVM 3.3 branch? > > No time currently to test my rv670 or bisect, but on current heads my rv790 > is rendering Unigine heaven with various incorrect hues. On my rv790 the heaven regression is caused by - dcfcf1d1ffe72d9c25564a2b8b53763a28648e97 is the first bad commit commit dcfcf1d1ffe72d9c25564a2b8b53763a28648e97 Author: Vincent Lejeune <vljn@ovi.com> Date: Fri May 17 16:49:55 2013 +0000 R600: Factorize Fetch size limit inside AMDGPUSubTarget
Created attachment 79821 [details] KWin with corruption OK I'm just back and I've recompiled everything from master - unfortunately things have regressed further. I'm not sure if there's colour corruption or not but things do look a little funky
similar error with webgl: http://www.gooengine.com/demofiles/pearl-boy/index.html (in firefox).
I got KDE up and running by putting: #!/bin/bash export R600_LLVM=0 into ~/kde4/env/r600_llvm.sh I then ran R600_LLVM=1 vblank_mode=0 glxgears The machine locked up and I wasn't able to SSH in - this however was in /var/log/messages May 29 20:49:19 quark kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10000msec May 29 20:49:19 quark kernel: radeon 0000:01:05.0: GPU lockup (waiting for 0x000000000000c695 last fence id 0x000000000000c694) May 29 20:49:19 quark kernel: [drm] Disabling audio support May 29 20:49:19 quark kernel: radeon 0000:01:05.0: Saved 1081 dwords of commands on ring 0. May 29 20:49:19 quark kernel: radeon 0000:01:05.0: GPU softreset: 0x00000019 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_008010_GRBM_STATUS = 0xA00024AC May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_008014_GRBM_STATUS2 = 0x00000003 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_000E50_SRBM_STATUS = 0x20000040 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_008674_CP_STALLED_STAT1 = 0x04000000 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_008678_CP_STALLED_STAT2 = 0x00040002 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_00867C_CP_BUSY_STAT = 0x00008486 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_008680_CP_STAT = 0x80858645 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_008020_GRBM_SOFT_RESET=0x00007FEF May 29 20:49:19 quark kernel: radeon 0000:01:05.0: SRBM_SOFT_RESET=0x00000100 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_008010_GRBM_STATUS = 0xA0003030 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_008014_GRBM_STATUS2 = 0x00000003 May 29 20:49:19 quark kernel: radeon 0000:01:05.0: R_000E50_SRBM_STATUS = 0x20008040 May 29May 29 21:07:10 quark syslog-ng[2189]: syslog-ng starting up; version='3.4.1'
Does Tom's patch in comment 16 help?
What is the revision of llvm ? You may try this patch : http://cgit.freedesktop.org/~vlj/llvm/commit/?h=textures&id=5e9129b7626738ff3cc539cc30f28536cd9d5662
I can confirm that the patch from comment 16 does not fix the issue I'll now try both patches I'm working from revision 182879
That second patch seems to have fixed the corruption - I was able to play Padman at ~40fps at 1080p Kwin still shows some colour issues I'll attach a screen shot
Created attachment 79986 [details] KWin color corruption Green to the top left and pink to the bottom right
(In reply to comment #23) > What is the revision of llvm ? > You may try this patch : > http://cgit.freedesktop.org/~vlj/llvm/commit/ > ?h=textures&id=5e9129b7626738ff3cc539cc30f28536cd9d5662 fixes the regression caused by - commit 061ff3409d4f6db313448fa8d916313233789516 so most things work on rv770. Heaven is still wrong, though.
patch in comment 23 fixes gpu lockups for me in several webgl apps! Can this please be applied to llvm 3.3 branch?
Created attachment 80202 [details] render defects in webgl demo still having issues with some webgl demos, e.g. http://www.chromeexperiments.com/detail/pearl-boy/?f=webgl see attached screenshot
Can you try this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=r600-gen-fixes I think it should fix the remaining issues.
still the same. chrome still shows the triangles instead of the boy in the boat (even worse than before) and firefox does not render the boy at all. http://www.chromeexperiments.com/detail/pearl-boy/?f=webgl
(In reply to comment #30) > Can you try this branch: > http://cgit.freedesktop.org/~tstellar/llvm/log/?h=r600-gen-fixes > > I think it should fix the remaining issues. Doesn't fix heaven or pearl boy on my rv790, though in the case of pearl boy corruption didn't start until I dived.
looks like my chrome version (27) has a bug with coordinates, so ignore this browser. still firefox doesn't render anything at all.
Out of interest has the previous two patches been applied upstream?
All of the proposed fixes have been merged to the LLVM tree, so what would be helpful now is if people could post the output of R600_DEBUG=vs,fs,ps,sbdisasm from the applications that don't work. It would also be helpful if you could post the same shader dumps from an older version of Mesa/LLVM when the application was working.
I attached the output of firefox http://www.gooengine.com/demofiles/pearl-boy/index.html with R600_LLVM=0/1 (large!). I'll try with an older llvm/mesa combo later.
Created attachment 80665 [details] R600_LLVM=0
Created attachment 80666 [details] R600_LLVM=1
maybe unrelated, but R600_DEBUG=sb crashes firefox Program received signal SIGSEGV, Segmentation fault. 0x00007fffb5586c2e in r600_sb::bc_parser::prepare_alu_group(r600_sb::cf_node*, r600_sb::alu_group_node*) () from /usr/lib64/dri/r600_dri.so (gdb) bt #0 0x00007fffb5586c2e in r600_sb::bc_parser::prepare_alu_group(r600_sb::cf_node*, r600_sb::alu_group_node*) () from /usr/lib64/dri/r600_dri.so #1 0x00007fffb55871ce in r600_sb::bc_parser::prepare_alu_clause(r600_sb::cf_node*) () from /usr/lib64/dri/r600_dri.so #2 0x00007fffb5587b6f in r600_sb::bc_parser::prepare_ir() () from /usr/lib64/dri/r600_dri.so #3 0x00007fffb558a26a in r600_sb_bytecode_process () from /usr/lib64/dri/r600_dri.so #4 0x00007fffb5561564 in r600_pipe_shader_create () from /usr/lib64/dri/r600_dri.so #5 0x00007fffb5575a6d in r600_shader_select () from /usr/lib64/dri/r600_dri.so #6 0x00007fffb5575f1a in r600_create_vs_state () from /usr/lib64/dri/r600_dri.so #7 0x00007fffb52e6e47 in st_get_vp_variant () from /usr/lib64/dri/r600_dri.so #8 0x00007fffb52a646c in update_vp () from /usr/lib64/dri/r600_dri.so #9 0x00007fffb52a271f in st_validate_state () from /usr/lib64/dri/r600_dri.so #10 0x00007fffb52b91f2 in st_draw_vbo () from /usr/lib64/dri/r600_dri.so #11 0x00007fffb5284cb2 in vbo_validated_drawrangeelements () from /usr/lib64/dri/r600_dri.so #12 0x00007fffb5285053 in vbo_exec_DrawElements () from /usr/lib64/dri/r600_dri.so #13 0x00007ffff459dbf5 in ?? () from /usr/lib64/firefox/libxul.so
Created attachment 80679 [details] rv790 dump of heaven current heads broken (compressed)
Created attachment 80680 [details] rv 790 current heads working with R600_LLVM=0 (compressed)
Created attachment 80682 [details] rv790 dump of heaven working with older llvm/mesa llvm is at commit 9a9e936650bb82244f38dbddf6c4e427c2ae49f9 mesa is at commit ff256ec0686bad0ccf3c9df99ba442773efbc181
the commit mentioned in comment 42 almost fixes the misrendering, but not completely. R600_DEBUG=sbdisasm crashes, so I cannot provide the output with it. Anyway, attaching output with current mesa/llvm and commits from comment 42. The diff is really short ...
Created attachment 80690 [details] output with commit from comment 42 this one shows much less misrendered triangles (no not zero)
Created attachment 80691 [details] output with current mesa lots of misrendered triangles all across the screen
(In reply to comment #43) > the commit mentioned in comment 42 almost fixes the misrendering, but not > completely. R600_DEBUG=sbdisasm crashes, so I cannot provide the output with > it. > Anyway, attaching output with current mesa/llvm and commits from comment 42. > The diff is really short ... Can you post a backtrace from the crash with R600_DEBUG=sbdisasm This may provide a clue as to what is wrong.
Created attachment 80701 [details] [review] Work Around It looks like the stack size calculations are wrong in some cases, does this patch help?
seems to be fixed in master now, but using the commits in comment 42 it crashes like this. Program received signal SIGSEGV, Segmentation fault. 0x00007fffb4481f44 in r600_sb::bc_decoder::decode_alu(unsigned int&, r600_sb::bc_alu&) () from /usr/lib64/dri/r600_dri.so (gdb) bt #0 0x00007fffb4481f44 in r600_sb::bc_decoder::decode_alu(unsigned int&, r600_sb::bc_alu&) () from /usr/lib64/dri/r600_dri.so #1 0x00007fffb4488822 in r600_sb::bc_parser::decode_alu_group(r600_sb::cf_node*, unsigned int&, unsigned int&) () from /usr/lib64/dri/r600_dri.so #2 0x00007fffb4488a3b in r600_sb::bc_parser::decode_alu_clause(r600_sb::cf_node*) () from /usr/lib64/dri/r600_dri.so #3 0x00007fffb4488b73 in r600_sb::bc_parser::decode_cf(unsigned int&, bool&) () from /usr/lib64/dri/r600_dri.so #4 0x00007fffb4488c14 in r600_sb::bc_parser::decode_shader() () from /usr/lib64/dri/r600_dri.so #5 0x00007fffb4488cf7 in r600_sb::bc_parser::decode() () from /usr/lib64/dri/r600_dri.so #6 0x00007fffb448c5f7 in r600_sb_bytecode_process () from /usr/lib64/dri/r600_dri.so #7 0x00007fffb4463a24 in r600_pipe_shader_create () from /usr/lib64/dri/r600_dri.so #8 0x00007fffb4477ead in r600_shader_select () from /usr/lib64/dri/r600_dri.so #9 0x00007fffb447835a in r600_create_vs_state () from /usr/lib64/dri/r600_dri.so #10 0x00007fffb41ec5c7 in st_get_vp_variant () from /usr/lib64/dri/r600_dri.so #11 0x00007fffb41ab96c in update_vp () from /usr/lib64/dri/r600_dri.so #12 0x00007fffb41a7cbf in st_validate_state () from /usr/lib64/dri/r600_dri.so #13 0x00007fffb41be732 in st_draw_vbo () from /usr/lib64/dri/r600_dri.so #14 0x00007fffb418a2d2 in vbo_validated_drawrangeelements () from /usr/lib64/dri/r600_dri.so #15 0x00007fffb418a673 in vbo_exec_DrawElements () from /usr/lib64/dri/r600_dri.so #16 0x00007ffff459dbf5 in ?? () from /usr/lib64/firefox/libxul.so
Created attachment 80739 [details] [review] Force max tex size of 8 Does this patch help ? I assumed a max tex clause size of 16 for anything from HD4000 using mesa classic backend as reference, but apparently the hw cannot support more than 8 instructions in a tex clause. On the other hand I don't think that classic backend create clauses that big, so it may be the reason this wrong limit was unspotted.
6xx has a max tex/vtx clause size of 8. 7xx+ has a max tex/vtx clause size of 16. In CF_WORD1, make sure you are setting the MSB of the count field. Bits 12:10 and bit 19 make up the total count field. I suspect you are not setting bit 19 properly.
Created attachment 80740 [details] [review] Properly set COUNT_3 Indeed, I was always setting COUNT_3 to 0. This new patch should solve the issue (at least if it's related to tex clause size). I can't test on Unigine because Unigine doesn't want to start anymore since I updated my fedora beta, however oversatured hue in some Lightmark scene is gone.
(In reply to comment #51) > Created attachment 80740 [details] [review] [review] > Properly set COUNT_3 > > Indeed, I was always setting COUNT_3 to 0. > > This new patch should solve the issue (at least if it's related to tex > clause size). I can't test on Unigine because Unigine doesn't want to start > anymore since I updated my fedora beta, however oversatured hue in some > Lightmark scene is gone. This doesn't fix it and I also got a GPU reset. The other patch - Force max tex size of 8 does fix it.
Created attachment 80750 [details] [review] Properly set COUNT_3 v2 Dos this new patch help ? It's almost the same as the previous one, but I swaped bit order in the COUNT field.
vincent, it seems you applied the patch to master already. I cannot find any difference with perl boy demo. Can someone provide me a link to heaven 3.0? I can only find 4.0 which requires opengl 3.3...
(In reply to comment #54) > vincent, it seems you applied the patch to master already. I cannot find any > difference with perl boy demo. Can someone provide me a link to heaven 3.0? > I can only find 4.0 which requires opengl 3.3... http://downloads.guru3d.com/Unigine-Heaven-DX11-Benchmark-3.0-Linux-download-2875.html The patch - doesn't apply maybe it's the wrong one - 0001-R600-Use-a-refined-heuristic-to-choose-when-switchin.patch
(In reply to comment #55) > (In reply to comment #54) > > Can someone provide me a link to heaven 3.0? > http://downloads.guru3d.com/Unigine-Heaven-DX11-Benchmark-3.0-Linux-download- > 2875.html Forgot to put that you need to run heaven 3.0 like - MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_bit_encoding force_glsl_extensions_warn=true ./heaven
Ok, found heaven - unfortunately, crashes with R600_LLVM=1 and works fine with R600_LLVM=0: MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_bit_encoding force_glsl_extensions_warn=true ./heaven ATTENTION: default value of option force_glsl_extensions_warn overridden by environment. Loading "/home/marc/.Heaven/heaven_3.0.cfg"... Loading "libGL.so.1"... Loading "libopenal.so.1"... Set 1280x1024 fullscreen video mode ATTENTION: default value of option force_glsl_extensions_warn overridden by environment. Set 1.00 gamma value Unigine engine http://unigine.com/ Binary: Linux 64bit GCC 4.4.5 Release Mar 7 2012 Features: OpenGL OpenAL XPad360 Joystick Flash Editor App path: /work/Unigine-Heaven-3.0/bin/ Data path: /work/Unigine-Heaven-3.0/data/ Save path: /home/marc/.Heaven/ ---- System ---- System: Linux 3.9.4-11.g51bf0ff-desktop x86_64 CPU: AMD Phenom(tm) II X4 B55 Processor 3214MHz MMX+ 3DNow!+ SSE SSE2 SSE3 SSE4A HTT x4 GPU: Gallium 0.4 on AMD RS880 3.0 Mesa 9.2.0-devel (git-6057d7b) x1 System memory: 3958 Mb Video memory: 256 Mb Sync threads: 3 Async threads: 4 ---- MathLib ---- Set SSE2 simd processor ---- Sound ---- Renderer: OpenAL Soft OpenAL vendor: OpenAL Community OpenAL renderer: OpenAL Soft OpenAL version: 1.1 ALSOFT 1.15 Found AL_EXT_LINEAR_DISTANCE Found AL_EXT_OFFSET Found ALC_EXT_EFX Found EFX Filter Found EFX Reverb Found EAX Reverb Found QUAD16 format Found 51CHN16 format Found 61CHN16 format Found 71CHN16 format Maximum sources: 256 Maximum effect slots: 4 Maximum auxiliary sends: 2 ---- Render ---- GLRender::GLRender(): Unknown GPU OpenGL vendor: X.Org OpenGL renderer: Gallium 0.4 on AMD RS880 OpenGL version: 3.0 Mesa 9.2.0-devel (git-6057d7b) Found required GL_ARB_vertex_array_object Found required GL_ARB_vertex_buffer_object Found required GL_ARB_half_float_vertex Found required GL_ARB_half_float_pixel Found required GL_ARB_occlusion_query Found required GL_EXT_texture3D Found required GL_EXT_texture_cube_map Found required GL_EXT_texture_sRGB Found required GL_EXT_texture_swizzle Found required GL_ARB_shader_object Found required GL_ARB_vertex_shader Found required GL_ARB_fragment_shader Found required GL_ARB_draw_buffers Found required GL_ARB_framebuffer_object Found required GL_EXT_framebuffer_blit Found required GL_EXT_framebuffer_multisample Found optional GL_ARB_map_buffer_range Found optional GL_ARB_transform_feedback Found optional GL_ARB_draw_elements_base_vertex Found optional GL_ARB_draw_instanced Found optional GL_EXT_draw_buffers2 Found optional GL_ARB_blend_func_extended Found optional GL_ARB_uniform_buffer_object Found optional GL_ARB_gpu_shader4 Found optional GL_ARB_texture_rg Found optional GL_ARB_texture_array Found optional GL_ARB_texture_multisample Found optional GL_ARB_texture_compression Found optional GL_ARB_texture_compression_rgtc Found optional GL_ARB_seamless_cube_map Shading language: 1.30 Vertex instructions: 16384 Fragment instructions: 16384 Maximum texture size: 8192 Maximum texture units: 32 Maximum texture renders: 8 ---- Physics ---- Physics: Multi-threaded ---- PathFind ---- PathFind: Multi-threaded ---- Interpreter ---- Version: 2.47 Unigine~# d3d11_render_use_tessellation 0 && gl_render_use_arb_tessellation_shader 0 && render_shaders 2 && render_anisotropy 2 && render_restart Loading "demos/heaven/unigine.cpp" 45ms Loading "heaven/locale/unigine.en" dictionary Loading "core/materials/default/unigine_post.mat" 20 materials 44 shaders 1ms Loading "core/materials/default/unigine_render.mat" 40 materials 4666 shaders 35ms Loading "core/materials/default/unigine_mesh.mat" 5 materials 3386 shaders 24ms Loading "core/materials/default/unigine_mesh_paint.mat" 2 materials 1134 shaders 11ms Loading "core/materials/default/unigine_mesh_tessellation.mat" 5 materials 3332 shaders 25ms Loading "core/materials/default/unigine_mesh_tessellation_paint.mat" 2 materials 2268 shaders 16ms Loading "core/materials/default/unigine_mesh_triplanar.mat" 1 material 112 shaders 2ms Loading "core/materials/default/unigine_mesh_overlay.mat" 1 material 220 shaders 3ms Loading "core/materials/default/unigine_mesh_terrain.mat" 1 material 53 shaders 3ms Loading "core/materials/default/unigine_mesh_layer.mat" 1 material 84 shaders 3ms Loading "core/materials/default/unigine_mesh_noise.mat" 1 material 106 shaders 4ms Loading "core/materials/default/unigine_mesh_stem.mat" 2 materials 1268 shaders 20ms Loading "core/materials/default/unigine_terrain.mat" 1 material 312 shaders 1ms Loading "core/materials/default/unigine_grass.mat" 1 material 138 shaders 6ms Loading "core/materials/default/unigine_particles.mat" 1 material 101 shaders 3ms Loading "core/materials/default/unigine_billboard.mat" 1 material 51 shaders 2ms Loading "core/materials/default/unigine_billboards.mat" 1 material 816 shaders 10ms Loading "core/materials/default/unigine_volume.mat" 6 materials 45 shaders 11ms Loading "core/materials/default/unigine_gui.mat" 1 material 82 shaders 1ms Loading "core/materials/default/unigine_water.mat" 1 material 205 shaders 29ms Loading "core/materials/default/unigine_sky.mat" 1 material 17 shaders 24ms Loading "core/materials/default/unigine_decal.mat" 1 material 99 shaders 4ms Loading "core/properties/unigine.prop" 2 properties 0ms GLFfp::create_shader(): can't create shader 0:3(92): error: Could not implicitly convert operands to arithmetic operator 0:3(42): error: cannot construct `ivec2' from a non-numeric data type 0:0(0): error: no matching function for call to `texelFetch(sampler2DMS, , int)' 0:0(0): error: candidates are: vec4 texelFetch(sampler2DMS, ivec2, int) 0:0(0): error: ivec4 texelFetch(isampler2DMS, ivec2, int) 0:0(0): error: uvec4 texelFetch(usampler2DMS, ivec2, int) 0:0(0): error: vec4 texelFetch(sampler2DMSArray, ivec3, int) 0:0(0): error: ivec4 texelFetch(isampler2DMSArray, ivec3, int) 0:0(0): error: uvec4 texelFetch(usampler2DMSArray, ivec3, int) 0:3(107): error: Operands to arithmetic operators must be numeric OpenGL error: invalid value Unigine~# world_load heaven Unknown command "d3d11_render_use_tessellation" Loading "heaven.cpp" 225ms Loading "demos/heaven/materials/heaven_base.mat" 7 materials 2ms Loading "demos/heaven/materials/heaven_environment.mat" 12 materials 832ms Loading "demos/heaven/materials/heaven_ruins.mat" 27 materials 2082ms Loading "demos/heaven/materials/heaven_buildings.mat" 51 materials 2171ms Loading "demos/heaven/materials/heaven_props.mat" 10 materials 437ms Loading "demos/heaven/materials/heaven_sfx.mat" 11 materials 14ms Loading "demos/heaven/materials/heaven_fort.mat" 15 materials 577ms Loading "demos/heaven/materials/heaven_airship.mat" 26 materials 3262ms Loading "heaven.world" 23787ms Unigine~# render_hdr 2 && render_restart LLVM ERROR: Cannot select: 0x13eaa9b0: f32 = fcos 0x13eaa5b0 [ORD=195] [ID=220] 0x13eaa5b0: f32 = fmul 0x13eaa3b0, 0x13eaa4b0 [ORD=192] [ID=216] 0x13eaa3b0: f32 = fadd 0x13eac8d0, 0x13ea1f50 [ORD=191] [ID=212] 0x13eac8d0: f32 = <<Unknown Target Node #204>> 0x13ea6b90, 0x13ea1a50, 0x13ea6d90, 0x13ea1a50, 0x13ea3760, 0x13ea3760, 0x13ea3760, 0x13ea3760 [ORD=188] [ID=206] 0x13ea6b90: f32 = fadd 0x13ea6390, 0x13eac9d0 [ORD=167] [ID=200] 0x13ea6390: f32 = fadd 0x13ea6290, 0x13ea5980 [ORD=160] [ID=195] 0x13ea6290: f32 = fmul 0x13eae3f0, 0x13ea0740 [ORD=159] [ID=173] 0x13eae3f0: f32 = bitcast 0x13ea6090 [ORD=158] [ID=111] 0x13ea6090: i32 = CONST_ADDRESS 0x13ea5580 [ORD=157] [ID=76] 0x13ea5580: i32 = Constant<9808> [ID=30] 0x13ea0740: f32 = extract_vector_elt 0x13ea3660, 0x13e9c4f0 [ORD=76] [ID=161] 0x13ea3660: v4f32 = bitcast 0x13ea0230 [ORD=63] [ID=155] 0x13ea0230: v4i32 = CONST_ADDRESS 0x13e9f830, 0x13e9cb00 [ORD=63] [ID=152] 0x13e9c4f0: i32 = Constant<3> [ID=1] 0x13ea5980: f32 = fadd 0x13ea5880, 0x13ea5180 [ORD=152] [ID=190] 0x13ea5880: f32 = fmul 0x13ea3c60, 0x13e9fe30 [ORD=151] [ID=177] 0x13ea3c60: f32 = bitcast 0x13ea5680 [ORD=150] [ID=109] 0x13ea5680: i32 = CONST_ADDRESS 0x13ea4d70 [ORD=149] [ID=74] 0x13e9fe30: f32 = extract_vector_elt 0x13ea0d40, 0x13e9c4f0 [ORD=59] [ID=165] 0x13ea0d40: v4f32 = bitcast 0x13ebd680 [ORD=46] [ID=156] 0x13e9c4f0: i32 = Constant<3> [ID=1] 0x13ea5180: f32 = fmul 0x13ea0f40, 0x13e9d900 [ORD=145] [ID=181] 0x13ea0f40: f32 = bitcast 0x13e9d300 [ORD=144] [ID=107] 0x13e9d300: i32 = CONST_ADDRESS 0x13ea4f80 [ORD=143] [ID=72] 0x13e9d900: f32 = extract_vector_elt 0x13ea3560, 0x13e9c4f0 [ORD=42] [ID=169] 0x13ea3560: v4f32 = bitcast 0x13ebd880 [ORD=29] [ID=157] 0x13e9c4f0: i32 = Constant<3> [ID=1] 0x13eac9d0: f32 = bitcast 0x13ea6990 [ORD=166] [ID=113] 0x13ea6990: i32 = CONST_ADDRESS 0x13ea5f90 [ORD=165] [ID=78] 0x13ea5f90: i32 = Constant<9824> [ID=32] 0x13ea1a50: f32 = bitcast 0x13ea1950 [ORD=177] [ID=115] 0x13ea1950: i32 = CONST_ADDRESS 0x13ea6890 [ORD=171] [ID=80] 0x13ea6890: i32 = Constant<9744> [ID=34] 0x13ea6d90: f32 = fadd 0x13ea6690, 0x13ea6a90 [ORD=170] [ID=199] 0x13ea6690: f32 = fadd 0x13ea6590, 0x13ea5c80 [ORD=164] [ID=194] 0x13ea6590: f32 = fmul 0x13ea6190, 0x13ea0740 [ORD=163] [ID=172] 0x13ea6190: f32 = bitcast 0x13ea3360 [ORD=162] [ID=112] 0x13ea3360: i32 = CONST_ADDRESS 0x13ea3460 [ORD=157] [ID=77] 0x13ea3460: i32 = Constant<9812> [ID=31] 0x13ea0740: f32 = extract_vector_elt 0x13ea3660, 0x13e9c4f0 [ORD=76] [ID=161] 0x13ea3660: v4f32 = bitcast 0x13ea0230 [ORD=63] [ID=155] 0x13ea0230: v4i32 = CONST_ADDRESS 0x13e9f830, 0x13e9cb00 [ORD=63] [ID=152] 0x13e9c4f0: i32 = Constant<3> [ID=1] 0x13ea5c80: f32 = fadd 0x13ea5b80, 0x13ea5380 [ORD=156] [ID=189] 0x13ea5b80: f32 = fmul 0x13ea5780, 0x13e9fe30 [ORD=155] [ID=176] 0x13ea5780: f32 = bitcast 0x13ea1140 [ORD=154] [ID=110] 0x13ea1140: i32 = CONST_ADDRESS 0x13ea0940 [ORD=149] [ID=75] 0x13e9fe30: f32 = extract_vector_elt 0x13ea0d40, 0x13e9c4f0 [ORD=59] [ID=165] 0x13ea0d40: v4f32 = bitcast 0x13ebd680 [ORD=46] [ID=156] 0x13e9c4f0: i32 = Constant<3> [ID=1] 0x13ea5380: f32 = fmul 0x13ea5080, 0x13e9d900 [ORD=148] [ID=180] 0x13ea5080: f32 = bitcast 0x13e9f730 [ORD=147] [ID=108] 0x13e9f730: i32 = CONST_ADDRESS 0x13e9d100 [ORD=143] [ID=73] 0x13e9d900: f32 = extract_vector_elt 0x13ea3560, 0x13e9c4f0 [ORD=42] [ID=169] 0x13ea3560: v4f32 = bitcast 0x13ebd880 [ORD=29] [ID=157] 0x13e9c4f0: i32 = Constant<3> [ID=1] 0x13ea6a90: f32 = bitcast 0x13ea1e50 [ORD=169] [ID=114] 0x13ea1e50: i32 = CONST_ADDRESS 0x13ea1d50 [ORD=165] [ID=79] 0x13ea1d50: i32 = Constant<9828> [ID=33] 0x13ea1a50: f32 = bitcast 0x13ea1950 [ORD=177] [ID=115] 0x13ea1950: i32 = CONST_ADDRESS 0x13ea6890 [ORD=171] [ID=80] 0x13ea6890: i32 = Constant<9744> [ID=34] 0x13ea3760: f32 = ConstantFP<0.000000e+00> [ID=6] 0x13ea3760: f32 = ConstantFP<0.000000e+00> [ID=6] 0x13ea3760: f32 = ConstantFP<0.000000e+00> [ID=6] 0x13ea3760: f32 = ConstantFP<0.000000e+00> [ID=6] 0x13ea1f50: f32 = bitcast 0x13eacad0 [ORD=190] [ID=118] 0x13eacad0: i32 = CONST_ADDRESS 0x13eac4d0 [ORD=171] [ID=83] 0x13eac4d0: i32 = Constant<9756> [ID=37] 0x13eaa4b0: f32 = ConstantFP<3.000000e-01> [ID=8] In function: main AL lib: (EE) alc_cleanup: 1 device not closed
Has anyone tested the patch from comment 47?
just did, no change in perl boy (misrendered triangles) or heaven (still crash).
Created attachment 80781 [details] [review] Properly set COUNT_3 v2 Sorry I sent the wrong patch.
(In reply to comment #58) > Has anyone tested the patch from comment 47? Oops almost missed that - It does fix heaven and pearl boy on my rv790.
(In reply to comment #60) > Created attachment 80781 [details] [review] [review] > Properly set COUNT_3 v2 > > Sorry I sent the wrong patch. This one also fixes heaven and pearl boy on rv790.
(In reply to comment #61) > (In reply to comment #58) > > Has anyone tested the patch from comment 47? > > Oops almost missed that - It does fix heaven and pearl boy on my rv790. Aggh ignore that it doesn't fix it - I applied the wrong patch.
patch in comment 60 does not fix the issues (no change).
regarding crash in comment 57, there seems to be something wrong with cosine: https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/conformance/glsl/functions/glsl-function-cos.html reproduces the crash.
crash happens with firefox only, chrome reports test failed. both browser pass the test with R600_LLVM=0
ok, maybe cos, sin, tan, are all broken because of bug 50317.
Trig functions need slightly different setup on r6xx and r7xx+. See tgsi_setup_trig() in r600_shader.c: /* * r600 - trunc to -PI..PI range * r700 - normalize by dividing by 2PI * see fdo bug 27901 */
I mean it cannot find the intrinsic at all: # ./Release/bin/llc < test/CodeGen/R600/llvm.sin.ll -march=r600 -mcpu=r600 LLVM ERROR: Cannot select: 0x8a5570: f32 = fsin 0x8a5670 [ORD=2] [ID=3] 0x8a5670: f32,ch = CopyFromReg 0x871928, 0x8a5970 [ID=2] 0x8a5970: f32 = Register %T0_X [ID=1] In function: test litte different with eg. -mcpu=hainan: # ./Release/bin/llc < test/CodeGen/R600/llvm.sin.ll -march=r600 -mcpu=hainan LLVM ERROR: Cannot select: target intrinsic %llvm.AMDGPU.store.output
Created attachment 81040 [details] [review] Add a cos/sin pattern Andy, does current master work on your rv790 and Unigine ? Marc, can you try the attached patch and Unigine Heaven ? I'm not sure it'll work (the cos/sin pattern does not trunc anything, but it should at least not crash)
(In reply to comment #70) > Andy, does current master work on your rv790 and Unigine ? Yes, Heaven 3.0 is working for me on master.
yup, heaven works, kronos test suite reports doesn't crash anymore, but fail (misrenders) on sin/cos as expected.
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.