[Mesa-dev] Trouble opening OSMesa Created Image
Hello everyone, I have a question regarding to the OSMesa demo code.I have installed OSMesa and trying to play around with the demo code.I have complied the .c file and an executable file has created.After I ran the executable file, a Windows cursor (image/x-win-bitmap) type file was created, however, I could not find a way to open it.Could anyone help me on this? Thanks Andy. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66850] New: glGenerateMipmap crashes when using GL_TEXTURE_2D_ARRAY with compressed internal format
https://bugs.freedesktop.org/show_bug.cgi?id=66850 Priority: medium Bug ID: 66850 Assignee: mesa-dev@lists.freedesktop.org Summary: glGenerateMipmap crashes when using GL_TEXTURE_2D_ARRAY with compressed internal format Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mik...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa Created attachment 82363 -- https://bugs.freedesktop.org/attachment.cgi?id=82363action=edit Test program, using GLUT, to reproduce the crash At least happens on Mesa commit id 1681bd7f2b392d0b379cb0ff43a4fac33da74762 and also on Mesa 9.1.4 that is in Debian testing repositories at the moment. I have attached a short test program to reproduce the crash. The crash occurs if you create and put data to a GL_TEXTURE_2D_ARRAY, using a compressed texture format, while the number of textures in the array is greater than 1 and then call glGenerateMipmap. I'm not entirely sure if you are supposed to be able to generate mipmaps with glGenerateMipmap if the zero layer texture is in compressed format but I'd think it should at least fail gracefully, if this is the case. This is what I could get out of GDB: Program received signal SIGSEGV, Segmentation fault. 0x7452bd38 in do_row (datatype=5121, comps=3, srcWidth=128, srcRowA=0x7fffee90, srcRowB=0x7010, dstWidth=64, dstRow=0x90ffc0) at ../../../src/mesa/main/mipmap.c:183 183 dst[i][0] = (rowA[j][0] + rowA[k][0] + rowB[j][0] + rowB[k][0]) / 4; (gdb) bt #0 0x7452bd38 in do_row (datatype=5121, comps=3, srcWidth=128, srcRowA=0x7fffee90, srcRowB=0x7010, dstWidth=64, dstRow=0x90ffc0) at ../../../src/mesa/main/mipmap.c:183 #1 0x7453992b in make_2d_mipmap (datatype=5121, comps=3, border=0, srcWidth=128, srcHeight=128, srcPtr=0x7fffe590 , srcRowStride=384, dstWidth=64, dstHeight=64, dstPtr=0x90fd80 Sz_\002\023\225_37#, dstRowStride=192) at ../../../src/mesa/main/mipmap.c:1475 #2 0x7453a7f2 in _mesa_generate_mipmap_level (target=35866, datatype=5121, comps=3, border=0, srcWidth=128, srcHeight=128, srcDepth=2, srcData=0x7fffe570, srcRowStride=384, dstWidth=64, dstHeight=64, dstDepth=2, dstData=0x7fffe568, dstRowStride=192) at ../../../src/mesa/main/mipmap.c:1750 #3 0x7453b39f in generate_mipmap_compressed (ctx=0x621170, target=35866, texObj=0x8c1780, srcImage=0x8ede50, maxLevel=13) at ../../../src/mesa/main/mipmap.c:2121 #4 0x7453b55b in _mesa_generate_mipmap (ctx=0x621170, target=35866, texObj=0x8c1780) at ../../../src/mesa/main/mipmap.c:2180 #5 0x746aa33c in _mesa_meta_GenerateMipmap (ctx=0x621170, target=35866, texObj=0x8c1780) at ../../../src/mesa/drivers/common/meta.c:3527 #6 0x744f08e2 in _mesa_GenerateMipmap (target=35866) at ../../../src/mesa/main/fbobject.c:2889 #7 0x7796c527 in glGenerateMipmap (target=35866) at ../../../src/mapi/glapi/glapi_mapi_tmp.h:8178 #8 0x00400954 in main (argc=1, argv=0x7fffe8b8) at test_program.c:31 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: handle srgb-to-linear and linear-to-srgb conversions
Looks good. Thanks for the update. Jose - Original Message - From: Roland Scheidegger srol...@vmware.com srgb-to-linear is using 3rd degree polynomial for now which should be _just_ good enough. Reverse is using some rational polynomials and is quite accurate, though not hooked into llvmpipe's blend code yet and hence unused (untested). Using a table might also be an option (for srgb-to-linear especially). This does not enable any new features yet because EXT_texture_srgb was already supported via util_format fallbacks, but performance was lacking probably due to the external function call (the table used by the util_format_srgb code may not be all that much slower on its own). Some performance figures (taken from modified gloss, replaced both base and sphere texture to use GL_SRGB instead of GL_RGB, measured on 1Ghz Sandy Bridge, the numbers aren't terribly accurate): normal gloss, aos, 8-wide: 47 fps normal gloss, aos, 4-wide: 48 fps normal gloss, forced to soa, 8-wide: 48 fps normal gloss, forced to soa, 4-wide: 47 fps patched gloss, old code, soa, 8-wide: 21 fps patched gloss, old code, soa, 4-wide: 24 fps patched gloss, new code, soa, 8-wide: 41 fps patched gloss, new code, soa, 4-wide: 38 fps So there's a performance hit but it seems acceptable, certainly better than using the fallback. Note the new code only works for 4x8bit srgb formats, others (L8/L8A8) will continue to use the old util_format fallback, because I can't be bothered to write code for formats noone uses anyway (as decoding is done as part of lp_build_unpack_rgba_soa which can only handle block type width of 32). Compressed srgb formats should get their own path though eventually (it is going to be expensive in any case, first decompress, then convert). No piglit regressions. v2: use lp_build_polynomial instead of ad-hoc polynomial construction, also since keeping both linear to srgb functions for now make sure both are compiled (since they share quite some code just integrate into the same function). --- src/gallium/auxiliary/Makefile.sources |1 + src/gallium/auxiliary/gallivm/lp_bld_arit.c|2 +- src/gallium/auxiliary/gallivm/lp_bld_arit.h|6 + src/gallium/auxiliary/gallivm/lp_bld_format.h | 11 + src/gallium/auxiliary/gallivm/lp_bld_format_soa.c | 25 +- src/gallium/auxiliary/gallivm/lp_bld_format_srgb.c | 291 6 files changed, 329 insertions(+), 7 deletions(-) create mode 100644 src/gallium/auxiliary/gallivm/lp_bld_format_srgb.c diff --git a/src/gallium/auxiliary/Makefile.sources b/src/gallium/auxiliary/Makefile.sources index 4751762..8cffeb0 100644 --- a/src/gallium/auxiliary/Makefile.sources +++ b/src/gallium/auxiliary/Makefile.sources @@ -172,6 +172,7 @@ GALLIVM_SOURCES := \ gallivm/lp_bld_format_aos.c \ gallivm/lp_bld_format_aos_array.c \ gallivm/lp_bld_format_float.c \ +gallivm/lp_bld_format_srgb.c \ gallivm/lp_bld_format_soa.c \ gallivm/lp_bld_format_yuv.c \ gallivm/lp_bld_gather.c \ diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c b/src/gallium/auxiliary/gallivm/lp_bld_arit.c index 7d6fe04..e7955aa 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c @@ -2896,7 +2896,7 @@ lp_build_log(struct lp_build_context *bld, * Generate polynomial. * Ex: coeffs[0] + x * coeffs[1] + x^2 * coeffs[2]. */ -static LLVMValueRef +LLVMValueRef lp_build_polynomial(struct lp_build_context *bld, LLVMValueRef x, const double *coeffs, diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.h b/src/gallium/auxiliary/gallivm/lp_bld_arit.h index 920e339..04e180c 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.h +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.h @@ -239,6 +239,12 @@ lp_build_fast_rsqrt(struct lp_build_context *bld, LLVMValueRef a); LLVMValueRef +lp_build_polynomial(struct lp_build_context *bld, +LLVMValueRef x, +const double *coeffs, +unsigned num_coeffs); + +LLVMValueRef lp_build_cos(struct lp_build_context *bld, LLVMValueRef a); diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format.h b/src/gallium/auxiliary/gallivm/lp_bld_format.h index 12a0318..744d002 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_format.h +++ b/src/gallium/auxiliary/gallivm/lp_bld_format.h @@ -158,4 +158,15 @@ lp_build_rgb9e5_to_float(struct gallivm_state *gallivm, LLVMValueRef src, LLVMValueRef *dst); +LLVMValueRef +lp_build_linear_to_srgb(struct gallivm_state *gallivm, +struct lp_type src_type, +LLVMValueRef src); + +LLVMValueRef +lp_build_srgb_to_linear(struct gallivm_state
[Mesa-dev] [Bug 66833] Text rendering problems on Dota 2, all mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=66833 --- Comment #4 from Vedran Rodic vro...@gmail.com --- I've managed to capture the trace with the latest version of apitrace (sigh, ubuntu should really update the in-distro one). http://mjesec.ffzg.hr/~vrodic/dota/dota_linux.225278.trim.trace.bz2 (25MB bz2). This is trimmed on the first frame where the problem can be seen, so glretrace -w is needed (or qapitrace/lookup state) -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.
On 11 July 2013 12:06, Matt Turner matts...@gmail.com wrote: On Mon, Jul 8, 2013 at 10:40 AM, Paul Berry stereotype...@gmail.com wrote: + const glsl_type *typ(const char *name) This must not be a typo, since it's consistent. Heh, type is a reserved word in so many languages that I guess I assumed it was reserved in C++ without even checking. Turns out it isn't. I'm doing a minor re-spin of this patch to address Ian's comments; I'll rename it to type in v2. The series is Reviewed-by: Matt Turner matts...@gmail.com with the caveat that the third patch is hard to review and I could easily have missed something, since it's nearly a total rewrite. But there's no question that the final result is better. Thanks for doing this clean up. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] tgsi: rename the TGSI fragment kill opcodes
The tradition has been to use C suffix for conditional opcodes, instead of _IF. That said, I don't feel too strongly either way. I agree that the current naming is confusing. And I like the fact that the new and old opcodes don't overlap, which means there is no way we inadvertently get the wrong ones when updating out-of-tree state trackers. And it's nice to see this sort of cleanups. I know from experience that that they can be time consuming, but I do believe they pay up eventually. I believe Gallium pipe_screen/pipe_context interfaces are quite lean and straightforward these days, but the opcodes are still a big mess, and shaders are one of the most (if not the most) important parts of the interface. For the series: Reviewed-by: Jose Fonseca jfons...@vmware.com Jose - Original Message - TGSI_OPCODE_KIL and KILP had confusing names. The former was conditional kill (if any src component 0). The later was unconditional kill. At one time KILP was supposed to work with NV-style condition codes/predicates but we never had that in TGSI. This patch renames both opcodes: TGSI_OPCODE_KIL - KILL_IF (kill if src.xyzw 0) TGSI_OPCODE_KILP - KILL (unconditional kill) Note: I didn't just transpose the opcode names to help ensure that I didn't miss updating any code anywhere. I believe I've updated all the relevant code and comments but I'm not 100% sure that some drivers had this right in the first place. For example, the radeon driver might have llvm.AMDGPU.kill and llvm.AMDGPU.kilp mixed up. Driver authors should review their code. --- src/gallium/auxiliary/draw/draw_pipe_aapoint.c |4 ++-- src/gallium/auxiliary/draw/draw_pipe_pstipple.c |8 src/gallium/auxiliary/gallivm/lp_bld_flow.c |2 +- src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c |8 src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c |6 ++ src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 16 src/gallium/auxiliary/postprocess/pp_mlaa.h |6 +++--- src/gallium/auxiliary/tgsi/tgsi_exec.c | 14 +++--- src/gallium/auxiliary/tgsi/tgsi_info.c |4 ++-- src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h |4 ++-- src/gallium/auxiliary/tgsi/tgsi_scan.c |4 ++-- src/gallium/auxiliary/tgsi/tgsi_scan.h |2 +- src/gallium/auxiliary/util/u_pstipple.c | 10 +- src/gallium/auxiliary/vl/vl_mc.c |2 +- src/gallium/docs/source/tgsi.rst |6 -- src/gallium/drivers/i915/i915_fpc_optimize.c |4 ++-- src/gallium/drivers/i915/i915_fpc_translate.c|8 +++- src/gallium/drivers/ilo/shader/ilo_shader_fs.c |2 +- src/gallium/drivers/ilo/shader/toy_tgsi.c| 16 src/gallium/drivers/nv30/nvfx_fragprog.c |6 +++--- .../drivers/nv50/codegen/nv50_ir_from_tgsi.cpp | 10 +- src/gallium/drivers/r300/compiler/r3xx_fragprog.c|2 +- .../drivers/r300/compiler/radeon_program_alu.c | 12 ++-- .../drivers/r300/compiler/radeon_program_alu.h |2 +- src/gallium/drivers/r300/r300_tgsi_to_rc.c |4 ++-- src/gallium/drivers/r600/r600_shader.c | 14 +++--- src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c |8 src/gallium/drivers/softpipe/sp_quad_depth_test.c|2 +- src/gallium/drivers/svga/svga_tgsi_insn.c| 18 +- src/gallium/include/pipe/p_shader_tokens.h |4 ++-- src/mesa/state_tracker/st_glsl_to_tgsi.cpp |6 +++--- src/mesa/state_tracker/st_mesa_to_tgsi.c |5 +++-- 32 files changed, 109 insertions(+), 110 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_aapoint.c b/src/gallium/auxiliary/draw/draw_pipe_aapoint.c index ec703d0..0d7b88e 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_aapoint.c +++ b/src/gallium/auxiliary/draw/draw_pipe_aapoint.c @@ -308,9 +308,9 @@ aa_transform_inst(struct tgsi_transform_context *ctx, newInst.Src[1].Register.SwizzleY = TGSI_SWIZZLE_W; ctx-emit_instruction(ctx, newInst); - /* KIL -tmp0.; # if -tmp0.y 0, KILL */ + /* KILL_IF -tmp0.; # if -tmp0.y 0, KILL */ newInst = tgsi_default_full_instruction(); - newInst.Instruction.Opcode = TGSI_OPCODE_KIL; + newInst.Instruction.Opcode = TGSI_OPCODE_KILL_IF; newInst.Instruction.NumDstRegs = 0; newInst.Instruction.NumSrcRegs = 1; newInst.Src[0].Register.File = TGSI_FILE_TEMPORARY; diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c index 808c7cd..51f5a86 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c +++
Re: [Mesa-dev] [PATCH 1/3] gallium: add expand_resource interface
I admit I haven't fully understood what's being proposed yet. But just a few quick words. I always wanted to have a present method that ensures that the contents of a resource is made visible to whatever the consumer is (full-screen flip, blit to primary surface, a compositor, etc.). We have been using off-the-side interfaces on Windows to achieve this [1] but I believe that this is a cross-platform problem so there should be something in Gallium interfaces for that. So I'd be supportive if there is a proposal that caters for everything. I'd hate to have a new interface aimed at a single use case. Jose [1] See stw_winsys::present and stw_winsys::compose in http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/wgl/stw_winsys.h - Original Message - Let's ignore the function name for now, that's easy to change and I am open to suggestions. flush_window_resource, flush_shared_resource, and sync_shared_resource are possible candidates as well as gonna_put_this_resource_on_the_screen_right_away. :) The idea is to expose a function which will ensure resource coherency between gallium and an external client (it could be another process or another device). Gallium drivers really have no way to know which resource is the window front or back buffer. It has always been like that since I joined Mesa (about 3.5 years ago). The bind flags won't work, because there can be multiple resources with that same flag. Even knowing which resource is front and back is useless, because there is only one resource which needs to be flushed at a given point and only st/dri knows which one it is. Well, there is at least something good about classic drivers: They don't have to share their DRI support code with everybody else. Marek On Thu, Jul 11, 2013 at 10:24 PM, Roland Scheidegger srol...@vmware.com wrote: Am 11.07.2013 20:15, schrieb Marek Olšák: Hi Roland, The fast color clear on Radeon doesn't touch the memory of the texture resource. Instead, it changes some GPU meta data that say the resource is cleared (the location of the meta data is stored in pipe_resource). This works fine as long as the gallium pipe_resource structure is used for accessing the resource. That's not the case with the DDX, which is responsible for putting the resource on the screen and it obviously has no idea about the contents of pipe_resource, so it doesn't know that the resource is in a cleared state and a special flush operation must be done to actually write the cleared pixels (which haven't been overwritten by new geometry of course). The easiest way to solve this is to flush the cleared resource in SwapBuffers and where the front buffer is flushed. The Gallium driver can't do it automatically, because it has no notion of front and back buffers nor does it know which resource must be flushed. That's why a new pipe_context function is being proposed, which was originally my idea. Ok I see now what it's used for. I don't like expand though this is more like a resource flush (i.e. do whatever is necessary to make the contents of this resource accessible by some dumb interface which knows nothing about resources). It isn't quite true that the gallium driver doesn't know this is a resource used as a window fb, as those should have the PIPE_BIND_DISPLAY_TARGET flag set (or maybe PIPE_BIND_SCANOUT). Don't ask me though how they work or if you could figure out what you'd need to flush... As Christoph has said, there pipe_screen.flush_front_buffer which could supposedly do this but it would also present the resource to screen I guess (only really used in sw winsys). So I'm still not really sure if a new function is really needed, I'm not familiar enough with all the interface stuff. If it is though I don't like the name, and it also would need documentation. Roland This commit only fixes r600g for st/dri. Any other co-state tracker (like st/egl and st/xlib) will be broken if it's used with r600g. I think we can ignore st/xlib. Not sure how important st/egl is (not required for EGL under X). Marek On Wed, Jul 10, 2013 at 7:32 PM, Roland Scheidegger srol...@vmware.com wrote: I don't quite understand what this should do, at first sight it looks like a ugly hack (which should really not be part of gallium interface) to make fast color clearing work better with window framebuffers. Seems to go against the idea of resources (which are immutable, well not the contents but the properties). (If anything I wanted an interface to change bind flags for resources after initialization, because they are near impossible to guarantee with OpenGL's (or d3d9 for that matter) distinct texture/fb model, but that would also be quite a hack.) Could you elaborate with some example what that's supposed to do in practice? Roland Am 10.07.2013 18:20, schrieb Grigori Goronzy: This interface
Re: [Mesa-dev] [PATCH 3/3] tgsi: rename the TGSI fragment kill opcodes
On 07/12/2013 08:06 AM, Jose Fonseca wrote: The tradition has been to use C suffix for conditional opcodes, instead of _IF. That said, I don't feel too strongly either way. I agree that the current naming is confusing. And I like the fact that the new and old opcodes don't overlap, which means there is no way we inadvertently get the wrong ones when updating out-of-tree state trackers. And it's nice to see this sort of cleanups. I know from experience that that they can be time consuming, but I do believe they pay up eventually. I believe Gallium pipe_screen/pipe_context interfaces are quite lean and straightforward these days, but the opcodes are still a big mess, and shaders are one of the most (if not the most) important parts of the interface. For the series: Reviewed-by: Jose Fonseca jfons...@vmware.com Thanks. As I've been explaining some of the nuances of gallium/TGSI to our intern this summer it's really obvious when something's wrong or inconsistent. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Trouble opening OSMesa Created Image
On 07/12/2013 12:46 AM, Andy Li wrote: Hello everyone, I have a question regarding to the OSMesa demo code. I have installed OSMesa and trying to play around with the demo code. I have complied the .c file and an executable file has created. After I ran the executable file, a Windows cursor (image/x-win-bitmap) type file was created, however, I could not find a way to open it. Could anyone help me on this? According to the code in osdemo.c, the image is saved in Targa format. If you disable #define SAVE_TARGA it'll use PPM. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66858] New: Missing definition for NVFX_FP_OP_OPCODE_KILL_IF
https://bugs.freedesktop.org/show_bug.cgi?id=66858 Priority: medium Bug ID: 66858 Assignee: mesa-dev@lists.freedesktop.org Summary: Missing definition for NVFX_FP_OP_OPCODE_KILL_IF Severity: normal Classification: Unclassified OS: Linux (All) Reporter: andu...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa I could not compile ./src/gallium/drivers/nv30/nvfx_fragprog.c because it contained undefined constant `NVFX_FP_OP_OPCODE_KILL_IF`. According to this newsletter - http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg41057.html - it is new name for `NVFX_FP_OP_OPCODE_KIL`. So I added new define with the value of NVFX_FP_OP_OPCODE_KIL: #define NVFX_FP_OP_OPCODE_KILL_IF 0x12 To file `./src/gallium/drivers/nv30/nvfx_shader.h`. After this everything went normal. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66858] Missing definition for NVFX_FP_OP_OPCODE_KILL_IF
https://bugs.freedesktop.org/show_bug.cgi?id=66858 --- Comment #1 from Brian Paul bri...@vmware.com --- That's my fault. But I believe this is the correct fix (undo the change to that line): --- a/src/gallium/drivers/nv30/nvfx_fragprog.c +++ b/src/gallium/drivers/nv30/nvfx_fragprog.c @@ -197,7 +197,7 @@ nvfx_fp_emit(struct nvfx_fpc *fpc, struct nvfx_insn insn) hw = fp-insn[fpc-inst_offset]; memset(hw, 0, sizeof(uint32_t) * 4); - if (insn.op == NVFX_FP_OP_OPCODE_KILL_IF) + if (insn.op == NVFX_FP_OP_OPCODE_KIL) fp-fp_control |= NV30_3D_FP_CONTROL_USES_KIL; hw[0] |= (insn.op NVFX_FP_OP_OPCODE_SHIFT); hw[0] |= (insn.mask NVFX_FP_OP_OUTMASK_SHIFT); Can you test that? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66833] Text rendering problems on Dota 2, all mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=66833 --- Comment #5 from Vedran Rodic vro...@gmail.com --- As Chris Forbes already noticed on #intel-gfx (sorry, didn't get to see that), the trace captured on Intel/Mesa machine shows the same problems when played back on a machine with Geforce 9800GT with nVidia proprietary drivers. It suggests that the game takes a different code path on nVidia drivers. I tried capturing the trace on nVidia machine and playing it back and surely, it can't be played back because it uses features not supported on Intel/Mesa. Since Valve commented they'll fix the bug on their side, I guess this could be closed, but I'm leaving it open till we are 100% percent certain that this can be fixed by them. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] draw/llvm: cache LLVM compilation
The series looks alright AFAICT.
The only request I have is the ability to disable the cache, so that we can
iron out any eventual bugs.
Another thing we eventually need to think about is thread safety. Though that's
not a new problem, so it can be addressed in a follow-on change.
Jose
- Original Message -
Shader variants now get their LLVM-made code from a cache if possible
instead of compiling every time. The cache key consists of the TGSI
tokens plus the variant key. Cache items are deleted when no longer
used by any variant.
---
src/gallium/auxiliary/draw/draw_llvm.c | 126
+++--
src/gallium/auxiliary/draw/draw_llvm.h | 15
2 files changed, 137 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 6225e53..a90b471 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -49,7 +49,10 @@
#include tgsi/tgsi_exec.h
#include tgsi/tgsi_dump.h
+#include tgsi/tgsi_parse.h
+#include util/u_hash.h
+#include util/u_hash_table.h
#include util/u_math.h
#include util/u_pointer.h
#include util/u_string.h
@@ -59,6 +62,16 @@
#define DEBUG_STORE 0
+static struct llvm_cache llvm_cache = { NULL };
+
+static struct llvm_cache_item *
+llvm_cache_item_create(struct draw_llvm_variant *variant,
+unsigned num_inputs,
+struct llvm_cache_key *key);
+
+static void
+llvm_cache_item_destroy(struct llvm_cache_item *item);
+
static void
draw_llvm_generate(struct draw_llvm *llvm, struct draw_llvm_variant *var,
boolean elts);
@@ -551,15 +564,117 @@ draw_llvm_destroy(struct draw_llvm *llvm)
}
+static unsigned
+llvm_cache_key_hash(void *v)
+{
+ return ((struct llvm_cache_key *)v)-hash;
+}
+
+
+static int
+llvm_cache_key_compare(void *v1, void *v2)
+{
+ struct llvm_cache_key *k1 = (struct llvm_cache_key *)v1;
+ struct llvm_cache_key *k2 = (struct llvm_cache_key *)v2;
+ if (k1-size k2-size)
+ return -1;
+ if (k1-size k2-size)
+ return 1;
+ return memcmp(k1-data, k2-data, k2-size);
+}
+
+
+static boolean
+llvm_cache_key_make(struct draw_llvm_variant *variant,
+ struct llvm_cache_key *key)
+{
+ struct tgsi_token const *tokens = variant-shader-base.state.tokens;
+ unsigned tsz = tgsi_num_tokens(tokens) * sizeof(*tokens);
+ unsigned ksz = variant-shader-variant_key_size;
+ key-size = tsz + ksz;
+ key-data = MALLOC(key-size);
+ if (!key-data)
+ return false;
+ memcpy(key-data, tokens, tsz);
+ memcpy(((char *)key-data) + tsz, variant-key, ksz);
+ key-hash = util_hash_crc32(key-data, key-size);
+ return true;
+}
+
+
+static void
+llvm_cache_key_free(struct llvm_cache_key *key)
+{
+ FREE(key-data);
+}
+
+
+static void
+llvm_cache_item_ref(struct llvm_cache_item *item)
+{
+ ++item-ref_count;
+}
+
+
+static void
+llvm_cache_item_unref(struct llvm_cache_item *item)
+{
+ assert(item-ref_count 0);
+ --item-ref_count;
+ if (item-ref_count == 0) {
+ llvm_cache_item_destroy(item);
+ }
+}
+
+
+/**
+ * Get LLVM-generated code from cache or make it if needed.
+ */
static struct llvm_cache_item *
-llvm_cache_item_create(struct draw_llvm_variant *variant, unsigned
num_inputs)
+llvm_cache_item_get(struct draw_llvm_variant *variant, unsigned num_inputs)
+{
+ struct llvm_cache_item *item;
+ struct llvm_cache_key key;
+
+ if (!llvm_cache.ht)
+ llvm_cache.ht = util_hash_table_create(llvm_cache_key_hash,
+ llvm_cache_key_compare);
+ if (!llvm_cache.ht)
+ return NULL;
+
+ if (!llvm_cache_key_make(variant, key)) {
+ return NULL;
+ }
+
+ item = (struct llvm_cache_item *) util_hash_table_get(llvm_cache.ht,
key);
+ if (item) {
+ llvm_cache_key_free(key);
+ llvm_cache_item_ref(item);
+ } else {
+ item = llvm_cache_item_create(variant, num_inputs, key);
+ if (item) {
+ item-ref_count = 1;
+ util_hash_table_set(llvm_cache.ht, item-key, item);
+ }
+ }
+
+ return item;
+}
+
+
+static struct llvm_cache_item *
+llvm_cache_item_create(struct draw_llvm_variant *variant,
+unsigned num_inputs,
+struct llvm_cache_key *key)
{
struct llvm_cache_item *item;
LLVMTypeRef vertex_header;
item = MALLOC(sizeof *item);
- if (item == NULL)
+ if (item == NULL) {
+ llvm_cache_key_free(key);
return NULL;
+ }
variant-llvm_item = item;
@@ -590,6 +705,8 @@ llvm_cache_item_create(struct draw_llvm_variant *variant,
unsigned num_inputs)
gallivm_teardown(item-gallivm);
+ memcpy(item-key, key, sizeof(*key));
+
return item;
}
@@ -617,7 +734,7 @@ draw_llvm_create_variant(struct draw_llvm
Re: [Mesa-dev] [PATCH 14/14] glsl: Add support for C-style initializers.
On Thu, Jul 11, 2013 at 8:52 PM, Matt Turner matts...@gmail.com wrote:
I believe that all this grammar is correct, but do we have tests for
spurious curly braces? Things like
vec4 v = {{{1, 2, 3, 4}}};
No, I'll write one.
Nice call on this test. For vectors _mesa_ast_set_aggregate_type would
walk through the right and left hand sides and stop when it ran out of
things to look at in either. For your example, this would leave the
constructor_type NULL for {1, 2, 3, 4}, so it'd blow up in the ::hir
function.
I've mailed a fix and a piglit test.
Thanks!
Matt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Reject C-style initializers with unknown types.
On Fri, Jul 12, 2013 at 11:10 AM, Matt Turner matts...@gmail.com wrote:
Previously, vec3 b = {{ 1.0, 2.0, 3.0 }} would cause a segfault because
the we dereferenced the constructor_type field which was NULL.
Arrays, structs, and matrices were unaffected.
This is a bad commit message. Use this instead:
_mesa_ast_set_aggregate_type walks through declarations initialized with
C-style aggregate initializers and stops when it runs out of LHS
declarations or RHS expressions.
In the example
vec4 v = {{{1, 2, 3, 4}}};
_mesa_ast_set_aggregate_type would not recurse into the subexpressions
(since vec4s do not contain types that can be initialized with an
aggregate initializer) to set their constructor_types. Later in ::hir
we would dereference the NULL pointer and segfault.
If constructor_type is NULL in ::hir we know that the LHS and RHS
were unbalanced and the code is illegal.
Arrays, structs, and matrices were unaffected.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Mesa 9.2 and release process changes
On Thu, Jul 11, 2013 at 1:38 AM, Ian Romanick i...@freedesktop.org wrote: On 07/08/2013 03:12 PM, Marek Olšák wrote: On Tue, Jul 2, 2013 at 10:02 PM, Ian Romanick i...@freedesktop.org wrote: 3. I'd like to make some adjustments to our process for picking patches back to the stable branch. The current process is okay, but it has some kinks. The two big (related) problems are people either under-mark things for the stable branch or over-mark. We also have the problem that things are occasionally marked for stable that, in the end, shouldn't go to stable. Instead of the current system, I'd like to propose creating a mesa-stable mailing list where candidate patches will be sent. The release manage will then have the responsibility to apply patches to the branch. This gives opportunity for subsystem maintainers to ACK or NAK patches before they land. It also gives the opportunity to use a build bot to pre-verify that no patch ever breaks the build on the stable branch. Anyone can nominate a patch for stable by sending it to the list. This provides a means for solving the under-mark problem. It may mean that developers have to do more work (e.g., waiting awhile after a patch lands on master to send it to the stable list), so we may need to come up with some means to mitigate that. As part of this, we need to clearly document the criteria for inclusion in the stable branch. We have some vague criteria now, but we should formalize and agree on the list. I don't like the idea that *we* have to send patches to the stable mailing list. The marking of candidates for stable has pretty much been the same as in the Linux kernel and worked pretty well. From kernel/Documentation/stable_kernel_rules.txt: Yeah, I wasn't terribly in love with that part either. Having to remember to send a patch out again seemed prone to loss. To have the patch automatically included in the stable tree, add the tag Cc: sta...@vger.kernel.org in the sign-off area. Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer. The major difference between the current Mesa and kernel approaches seems to be that there is a -stable maintainer for kernel who decides which candidates go in and which don't. I think we need such a strict maintainer for our stable branches, but I don't think we need anything else. Carl has agreed to be the maintainer at least for the time being. Having a separate list would make it easier for him to sort candidate patches from non-candidate patches because would keep marked-at-commit patches and marked-after-commit patches in one places. Could we just change our Mark the patch with 'NOTE: ...' policy with To have the patch automatically included in the stable tree, add the tag Cc: mesa-sta...@lists.freedesktop.org in the sign-off area... ? Yes. This sounds very good to me. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] tgsi: rename the TGSI fragment kill opcodes
On 12.07.2013 16:06, Jose Fonseca wrote: The tradition has been to use C suffix for conditional opcodes, instead of _IF. That said, I don't feel too strongly either way. Except the 'C' suffix usually (ok, we only have BREAKC) indicates a single condition value where non-zero means true, while KIL operates on all 4 components and executes if either is 0. I'd still prefer to keep the name KIL instead of KILL_IF and simply rename KILP to DISCARD, which is the name used in GLSL and SM4. I agree that the current naming is confusing. And I like the fact that the new and old opcodes don't overlap, which means there is no way we inadvertently get the wrong ones when updating out-of-tree state trackers. And it's nice to see this sort of cleanups. I know from experience that that they can be time consuming, but I do believe they pay up eventually. I believe Gallium pipe_screen/pipe_context interfaces are quite lean and straightforward these days, but the opcodes are still a big mess, and shaders are one of the most (if not the most) important parts of the interface. For the series: Reviewed-by: Jose Fonseca jfons...@vmware.com Jose - Original Message - TGSI_OPCODE_KIL and KILP had confusing names. The former was conditional kill (if any src component 0). The later was unconditional kill. At one time KILP was supposed to work with NV-style condition codes/predicates but we never had that in TGSI. This patch renames both opcodes: TGSI_OPCODE_KIL - KILL_IF (kill if src.xyzw 0) TGSI_OPCODE_KILP - KILL (unconditional kill) Note: I didn't just transpose the opcode names to help ensure that I didn't miss updating any code anywhere. I believe I've updated all the relevant code and comments but I'm not 100% sure that some drivers had this right in the first place. For example, the radeon driver might have llvm.AMDGPU.kill and llvm.AMDGPU.kilp mixed up. Driver authors should review their code. --- src/gallium/auxiliary/draw/draw_pipe_aapoint.c |4 ++-- src/gallium/auxiliary/draw/draw_pipe_pstipple.c |8 src/gallium/auxiliary/gallivm/lp_bld_flow.c |2 +- src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c |8 src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c |6 ++ src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 16 src/gallium/auxiliary/postprocess/pp_mlaa.h |6 +++--- src/gallium/auxiliary/tgsi/tgsi_exec.c | 14 +++--- src/gallium/auxiliary/tgsi/tgsi_info.c |4 ++-- src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h |4 ++-- src/gallium/auxiliary/tgsi/tgsi_scan.c |4 ++-- src/gallium/auxiliary/tgsi/tgsi_scan.h |2 +- src/gallium/auxiliary/util/u_pstipple.c | 10 +- src/gallium/auxiliary/vl/vl_mc.c |2 +- src/gallium/docs/source/tgsi.rst |6 -- src/gallium/drivers/i915/i915_fpc_optimize.c |4 ++-- src/gallium/drivers/i915/i915_fpc_translate.c|8 +++- src/gallium/drivers/ilo/shader/ilo_shader_fs.c |2 +- src/gallium/drivers/ilo/shader/toy_tgsi.c| 16 src/gallium/drivers/nv30/nvfx_fragprog.c |6 +++--- .../drivers/nv50/codegen/nv50_ir_from_tgsi.cpp | 10 +- src/gallium/drivers/r300/compiler/r3xx_fragprog.c|2 +- .../drivers/r300/compiler/radeon_program_alu.c | 12 ++-- .../drivers/r300/compiler/radeon_program_alu.h |2 +- src/gallium/drivers/r300/r300_tgsi_to_rc.c |4 ++-- src/gallium/drivers/r600/r600_shader.c | 14 +++--- src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c |8 src/gallium/drivers/softpipe/sp_quad_depth_test.c|2 +- src/gallium/drivers/svga/svga_tgsi_insn.c| 18 +- src/gallium/include/pipe/p_shader_tokens.h |4 ++-- src/mesa/state_tracker/st_glsl_to_tgsi.cpp |6 +++--- src/mesa/state_tracker/st_mesa_to_tgsi.c |5 +++-- 32 files changed, 109 insertions(+), 110 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_aapoint.c b/src/gallium/auxiliary/draw/draw_pipe_aapoint.c index ec703d0..0d7b88e 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_aapoint.c +++ b/src/gallium/auxiliary/draw/draw_pipe_aapoint.c @@ -308,9 +308,9 @@ aa_transform_inst(struct tgsi_transform_context *ctx, newInst.Src[1].Register.SwizzleY = TGSI_SWIZZLE_W; ctx-emit_instruction(ctx, newInst); - /* KIL -tmp0.; # if -tmp0.y 0, KILL */ + /* KILL_IF -tmp0.; # if -tmp0.y 0, KILL */ newInst = tgsi_default_full_instruction(); - newInst.Instruction.Opcode = TGSI_OPCODE_KIL; + newInst.Instruction.Opcode = TGSI_OPCODE_KILL_IF;
Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.
On Friday 12 July 2013, Chad Versace wrote: On 07/11/2013 10:18 PM, Paul Berry wrote: Another possibility that Chad suggested when I was talking to him this afternoon is to just just return BAD_MATCH if the client supplies the forward-compatibility flag when requesting a 3.0+ context. Rationale: Mesa doesn't really support the forward-compatibility flag anyhow (since the EGL and GLX front-ends just drop it on the floor), and besides we don't know of any shipping apps that require it (the flag is intended as a developer aid, so it's unlikely that published apps rely on it). I don't have a really strong opinion about is, so I'll let Chad weigh in if he wants to champion this alternative. Let's fix Mesa to simply emit EGL_BAD_MATCH if the user requests a forward- compatible context. I don't believe we have the right balance of resources and interest to properly implement and test support for the forward-compatible flag. No one users are asking for it, and it's likely nearly no one will use it. The future may change this situation, but that's a big 'may'. KWin always sets the forward-compatible bit in 4.11, but it's not too late to change that. It appears to be accepted by all implementations and has no negative side effects, so there was no compelling reason to leave it out in a release build. Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/clover: Allow double precision operations
On Tue, Jul 02, 2013 at 10:44:37AM +0200, Niels Ole Salscheider wrote:
Pass cl_khr_fp64 preprocessor definition to clang
I've gone back and forth a few times on this patch, but I think it is
OK, because all it does is enable the prototypes for builtins that use
the double type. This is fine, because an application won't be able to
use those functions unless it explicitly enables fp64 support with :
#pragma OPENCL EXTENSION cl_khr_fp64 : enable
since clang will generate an error if you use doubles types without
enabling the extension.
Reviewed-by: Tom Stellard thomas.stell...@amd.com
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 +
1 Datei geändert, 1 Zeile hinzugefügt(+)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index dae61f7..bc85b61 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -175,6 +175,7 @@ namespace {
// clc.h requires that this macro be defined:
c.getPreprocessorOpts().addMacroDef(cl_clang_storage_class_specifiers);
+ c.getPreprocessorOpts().addMacroDef(cl_khr_fp64);
c.getLangOpts().NoBuiltin = true;
c.getTargetOpts().Triple = triple;
--
1.7.11.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.
On 07/12/2013 12:25 PM, Fredrik Höglund wrote: On Friday 12 July 2013, Chad Versace wrote: On 07/11/2013 10:18 PM, Paul Berry wrote: Another possibility that Chad suggested when I was talking to him this afternoon is to just just return BAD_MATCH if the client supplies the forward-compatibility flag when requesting a 3.0+ context. Rationale: Mesa doesn't really support the forward-compatibility flag anyhow (since the EGL and GLX front-ends just drop it on the floor), and besides we don't know of any shipping apps that require it (the flag is intended as a developer aid, so it's unlikely that published apps rely on it). I don't have a really strong opinion about is, so I'll let Chad weigh in if he wants to champion this alternative. Let's fix Mesa to simply emit EGL_BAD_MATCH if the user requests a forward- compatible context. I don't believe we have the right balance of resources and interest to properly implement and test support for the forward-compatible flag. No one users are asking for it, and it's likely nearly no one will use it. The future may change this situation, but that's a big 'may'. KWin always sets the forward-compatible bit in 4.11, but it's not too late to change that. It appears to be accepted by all implementations and has no negative side effects, so there was no compelling reason to leave it out in a release build. For what GL context versions does KWin set the forward-compatible bit? For 3.0 only? For all versions = 3.0? For that matter, what context versions does KWin request? Why does KWin set the forward-compatible bit? There must be some motivation for that, other than the button is there so let's push it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gallium: add expand_resource interface
On 12.07.2013 16:19, Jose Fonseca wrote: I admit I haven't fully understood what's being proposed yet. But just a few quick words. I always wanted to have a present method that ensures that the contents of a resource is made visible to whatever the consumer is (full-screen flip, blit to primary surface, a compositor, etc.). We have been using off-the-side interfaces on Windows to achieve this [1] but I believe that this is a cross-platform problem so there should be something in Gallium interfaces for that. Of all the suggestions regarding naming so far this sounds the best to me. But I don't know gallium well so I leave the discussion about the interface to those people that do. So I'd be supportive if there is a proposal that caters for everything. So which exactly are all likely use cases, apart from fast clear? Best regards Grigori ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: Avoid use of AC_CHECK_FILE for cross compiling
Hi Jonathan,
Sorry for the delay. I've pushed this patch, thanks!
-Tom
On Wed, Jul 03, 2013 at 11:05:43AM +1000, Jonathan Liu wrote:
Bump.
On 4 June 2013 23:04, Jonathan Liu net...@gmail.com wrote:
The AC_CHECK_FILE macro can't be used for cross compiling as it will
result in error: cannot check for file existence when cross compiling.
Replace it with the AS_IF macro.
Signed-off-by: Jonathan Liu net...@gmail.com
---
configure.ac | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index 521331b..5433dd1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1607,8 +1607,8 @@ if test x$enable_gallium_llvm = xyes; then
CLANG_LIBDIR=${LLVM_LIBDIR}
fi
CLANG_RESOURCE_DIR=$CLANG_LIBDIR/clang/${LLVM_VERSION}
-AC_CHECK_FILE($CLANG_RESOURCE_DIR/include/stddef.h,,
-AC_MSG_ERROR([Could not find clang internal header
stddef.h in $CLANG_RESOURCE_DIR Use --with-clang-libdir to specify the
correct path to the clang libraries.]))
+AS_IF([test ! -f $CLANG_RESOURCE_DIR/include/stddef.h],
+[AC_MSG_ERROR([Could not find clang internal header
stddef.h in $CLANG_RESOURCE_DIR Use --with-clang-libdir to specify the
correct path to the clang libraries.])])
fi
else
MESA_LLVM=0
@@ -1845,7 +1845,7 @@ if test x$MESA_LLVM != x0; then
if test x$with_llvm_shared_libs = xyes; then
dnl We can't use $LLVM_VERSION because it has 'svn' stripped out,
LLVM_SO_NAME=LLVM-`$LLVM_CONFIG --version`
-AC_CHECK_FILE($LLVM_LIBDIR/lib$LLVM_SO_NAME.so,
llvm_have_one_so=yes,)
+AS_IF([test -f $LLVM_LIBDIR/lib$LLVM_SO_NAME.so],
[llvm_have_one_so=yes])
if test x$llvm_have_one_so = xyes; then
dnl LLVM was built using auto*, so there is only one shared
object.
@@ -1853,8 +1853,8 @@ if test x$MESA_LLVM != x0; then
else
dnl If LLVM was built with CMake, there will be one shared
object per
dnl component.
-AC_CHECK_FILE($LLVM_LIBDIR/libLLVMTarget.so,,
-AC_MSG_ERROR([Could not find llvm shared libraries:
+AS_IF([test ! -f $LLVM_LIBDIR/libLLVMTarget.so],
+[AC_MSG_ERROR([Could not find llvm shared libraries:
Please make sure you have built llvm with the --enable-shared option
and that your llvm libraries are installed in $LLVM_LIBDIR
If you have installed your llvm libraries to a different directory
you
@@ -1865,7 +1865,7 @@ if test x$MESA_LLVM != x0; then
--enable-opencl
If you do not want to build with llvm shared libraries and instead
want to
use llvm static libraries then remove these options from your
configure
- invocation and reconfigure.]))
+ invocation and reconfigure.])])
dnl We don't need to update LLVM_LIBS in this case because the
LLVM
dnl install uses a shared object for each compoenent and we have
--
1.8.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66863] New: st_glsl_to_tgsi.cpp:2320:emit_block_mov: Assertion `type-is_scalar() || type-is_vector()' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=66863 Priority: medium Bug ID: 66863 Assignee: mesa-dev@lists.freedesktop.org Summary: st_glsl_to_tgsi.cpp:2320:emit_block_mov: Assertion `type-is_scalar() || type-is_vector()' failed. Severity: critical Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: bf9670270fb3deef8ad194f1a1ee78e253769234 (master) Run piglit in-parameter-nested-struct test. $ ./bin/shader_runner tests/spec/glsl-1.10/execution/samplers/in-parameter-nested-struct.shader_test -auto ../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:2320:emit_block_mov: Assertion `type-is_scalar() || type-is_vector()' failed. Trace/breakpoint trap (core dumped) (gdb) bt #0 0x7fd9b29b69ba in _debug_assert_fail (expr=0x7fd9b2afe7d0 type-is_scalar() || type-is_vector(), file=0x7fd9b2afdef0 ../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp, line=2320, function=0x7fd9b2aff600 glsl_to_tgsi_visitor::emit_block_mov(ir_assignment*, glsl_type const*, st_dst_reg*, st_src_reg*)::__FUNCTION__ emit_block_mov) at util/u_debug.c:278 #1 0x7fd9b2861777 in glsl_to_tgsi_visitor::emit_block_mov (this=0x126ac00, ir=0x1337800, type=0x7fd9b2f310e0 glsl_type::_sampler2D_type, l=0x7fff7f071c60, r=0x7fff7f071c80) at ../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:2320 #2 0x7fd9b2861641 in glsl_to_tgsi_visitor::emit_block_mov (this=0x126ac00, ir=0x1337800, type=0x1275250, l=0x7fff7f071c60, r=0x7fff7f071c80) at ../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:2296 #3 0x7fd9b28621a6 in glsl_to_tgsi_visitor::visit (this=0x126ac00, ir=0x1337800) at ../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:2432 #4 0x7fd9b28c70a0 in ir_assignment::accept (this=0x1337800, v=0x126ac00) at ../../../src/glsl/ir.h:885 #5 0x7fd9b285b258 in glsl_to_tgsi_visitor::visit (this=0x126ac00, ir=0x1320530) at ../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:1225 #6 0x7fd9b28c6ff0 in ir_function::accept (this=0x1320530, v=0x126ac00) at ../../../src/glsl/ir.h:711 #7 0x7fd9b28c4470 in visit_exec_list (list=0x13616c0, visitor=0x126ac00) at ../../../src/glsl/ir.cpp:1682 #8 0x7fd9b286c622 in get_mesa_program (ctx=0x11c9960, shader_program=0x13604c0, shader=0x1361540) at ../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:5046 #9 0x7fd9b286ce3b in st_link_shader (ctx=0x11c9960, prog=0x13604c0) at ../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:5272 #10 0x7fd9b29114ef in _mesa_glsl_link_shader (ctx=0x11c9960, prog=0x13604c0) at ../../../src/mesa/program/ir_to_mesa.cpp:3120 #11 0x7fd9b2791694 in link_program (ctx=0x11c9960, program=3) at ../../src/mesa/main/shaderapi.c:819 #12 0x7fd9b2792822 in _mesa_LinkProgram (programObj=3) at ../../src/mesa/main/shaderapi.c:1302 #13 0x7fd9b6425423 in stub_glLinkProgram (program=3) at piglit/tests/util/generated_dispatch.c:17556 #14 0x0040553f in link_and_use_shaders () at piglit/tests/shaders/shader_runner.c:787 #15 0x0040912c in piglit_init (argc=2, argv=0x7fff7f072248) at piglit/tests/shaders/shader_runner.c:1999 #16 0x7fd9b6400052 in run_test (gl_fw=0x7fd9b66e8060 glut_fw, argc=2, argv=0x7fff7f072248) at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:140 #17 0x7fd9b63fe0f6 in piglit_gl_test_run (argc=2, argv=0x7fff7f072248, config=0x7fff7f072130) at piglit/tests/util/piglit-framework-gl.c:137 #18 0x00403f06 in main (argc=3, argv=0x7fff7f072248) at piglit/tests/shaders/shader_runner.c:56 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glapi: Do not use backtrace on OpenBSD.
execinfo.h is not available on OpenBSD. Signed-off-by: Vinson Lee v...@freedesktop.org --- src/mapi/glapi/gen/gl_gentable.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mapi/glapi/gen/gl_gentable.py b/src/mapi/glapi/gen/gl_gentable.py index a3c9898..5c35271 100644 --- a/src/mapi/glapi/gen/gl_gentable.py +++ b/src/mapi/glapi/gen/gl_gentable.py @@ -42,7 +42,7 @@ header = /* GLXEXT is the define used in the xserver when the GLX extension i #endif #if (defined(GLXEXT) defined(HAVE_BACKTRACE)) \\ - || (!defined(GLXEXT) defined(DEBUG) !defined(_WIN32_WCE) !defined(__CYGWIN__) !defined(__MINGW32__)) + || (!defined(GLXEXT) defined(DEBUG) !defined(_WIN32_WCE) !defined(__CYGWIN__) !defined(__MINGW32__) !defined(__OpenBSD__)) #define USE_BACKTRACE #endif -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Mesa 9.2 and release process changes
Brian Paul bri...@vmware.com writes: Carl, it would be good if you could put all the above info in Mesa docs/. The devinfo.html page mentions the This is a candidate for the stable branches convention, etc. The docs/lists.html file describes all the mailing lists. And so on. Great idea. Thanks for pointing me to where this documentation should live. I'll have a patch soon which incorporates all the feedback from this thread, (along with some ideas culled from the kernel guidelines as recommended). Meanwhile, what's the correct process for updating the website itself? I notice that www.mesa3d.org/devinfo.html page on the web currently talks about pushing tar files out to sourceforge.net and copying files to /home/users/b/br/brianp/mesa-www/htdocs/ . Are those instructions still current? Do I have permission to do those steps? (I'm quite certain I don't' even have a sourceforge account.) I also notice that mesa3d.org/index.html hasn't been updated for new releases since 9.1.2 on April 30. -Carl -- carl.d.wo...@intel.com pgp7gacTrrdPV.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Initialize ast_aggregate_initializer::constructor_type.
Fixes Uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/glsl/ast.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 9b119ed..c0350e7 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -307,7 +307,8 @@ private:
class ast_aggregate_initializer : public ast_expression {
public:
ast_aggregate_initializer()
- : ast_expression(ast_aggregate, NULL, NULL, NULL)
+ : ast_expression(ast_aggregate, NULL, NULL, NULL),
+constructor_type(NULL)
{
/* empty */
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66809] Compiz segfault with latest mesa-git
https://bugs.freedesktop.org/show_bug.cgi?id=66809 Marek Olšák mar...@gmail.com changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |nouveau@lists.freedesktop.o |org |rg Component|Mesa core |Drivers/DRI/nouveau --- Comment #5 from Marek Olšák mar...@gmail.com --- Thanks. The backtrace suggests it's a bug in the nouveau driver and my commit only uncovered it. Reassigning to Nouveau. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/5] glsl: Rework builtin_variables.cpp to reduce code duplication.
Previously, we had a separate function for setting up the built-in
variables for each combination of shader stage and GLSL version
(e.g. generate_110_vs_variables to generate the built-in variables for
GLSL 1.10 vertex shaders). The functions called each other in ad-hoc
ways, leading to unexpected inconsistencies (for example,
generate_120_fs_variables was called for GLSL versions 1.20 and above,
but generate_130_fs_variables was called only for GLSL version 1.30).
In addition, it led to a lot of code duplication, since many varyings
had to be duplicated in both the FS and VS code paths. With the
advent of geometry shaders (and later, tessellation control and
tessellation evaluation shaders), this code duplication was going to
get a lot worse.
So this patch reworks things so that instead of having a separate
function for each shader type and GLSL version, we have a function for
constants, one for uniforms, one for varyings, and one for the special
variables that are specific to each shader type.
In addition, we use a class, builtin_variable_generator, to keep track
of the instruction exec_list, the GLSL parse state, commonly-used
types, and a few other variables, so that we don't have to pass them
around as function arguments. This makes the code a lot more compact.
Where it was feasible to do so without introducing compilation errors,
I've also gone ahead and introduced the variables needed for
{ARB,EXT}_geometry_shader4 style geometry shaders. This patch takes
care of everything except the GS variable gl_VerticesIn, the FS
variable gl_PrimitiveID, and GLSL 1.50 style geometry shader inputs
(using the gl_in interface block). Those remaining features will be
added later.
I've also made a slight nomenclature change: previously we used the
word deprecated to refer to variables which are marked in GLSL 1.40
as requiring the ARB_compatibility extension, and are marked in GLSL
1.50 onward as requiring the compatibilty profile. This was
misleading, since not all deprecated variables require the
compatibility profile (for example gl_FragData and gl_FragColor, which
have been deprecated since GLSL 1.30, but do not require the
compatibility profile until GLSL 4.20). We now consistently use the
word compatibility to refer to these variables.
This patch doesn't introduce any functional changes (since geometry
shaders haven't been enabled yet).
Reviewed-by: Matt Turner matts...@gmail.com
v2: Rename typ - type. Add blank line between inline functions
and declarations in builtin_variable_generator class. Use the
standard comment /* FALLTHROUGH */ for compatibility with static
code analysis tools.
---
src/glsl/builtin_variables.cpp | 1129 +---
1 file changed, 368 insertions(+), 761 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index eccd15a..1e88b6a 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -30,116 +30,6 @@
#include program/prog_statevars.h
#include program/prog_instruction.h
-static void generate_ARB_draw_buffers_variables(exec_list *,
- struct _mesa_glsl_parse_state *,
- bool,
_mesa_glsl_parser_targets);
-
-static void
-generate_ARB_draw_instanced_variables(exec_list *,
- struct _mesa_glsl_parse_state *,
- bool, _mesa_glsl_parser_targets);
-
-static void
-generate_AMD_vertex_shader_layer_variables(exec_list *instructions,
- struct _mesa_glsl_parse_state
*state,
- bool warn,
- _mesa_glsl_parser_targets target);
-
-struct builtin_variable {
- enum ir_variable_mode mode;
- int slot;
- const char *type;
- const char *name;
-};
-
-static const builtin_variable builtin_core_vs_variables[] = {
- { ir_var_shader_out, VARYING_SLOT_POS, vec4, gl_Position },
- { ir_var_shader_out, VARYING_SLOT_PSIZ, float, gl_PointSize },
-};
-
-static const builtin_variable builtin_core_fs_variables[] = {
- { ir_var_shader_in, VARYING_SLOT_POS, vec4, gl_FragCoord },
- { ir_var_shader_in, VARYING_SLOT_FACE, bool, gl_FrontFacing },
- { ir_var_shader_out, FRAG_RESULT_COLOR, vec4, gl_FragColor },
-};
-
-static const builtin_variable builtin_100ES_fs_variables[] = {
- { ir_var_shader_in, VARYING_SLOT_PNTC, vec2, gl_PointCoord },
-};
-
-static const builtin_variable builtin_300ES_vs_variables[] = {
- { ir_var_system_value, SYSTEM_VALUE_VERTEX_ID, int, gl_VertexID },
-};
-
-static const builtin_variable builtin_300ES_fs_variables[] = {
- { ir_var_shader_in, VARYING_SLOT_POS, vec4, gl_FragCoord },
- { ir_var_shader_in, VARYING_SLOT_FACE, bool, gl_FrontFacing },
- { ir_var_shader_out, FRAG_RESULT_DEPTH, float, gl_FragDepth },
- { ir_var_shader_in, VARYING_SLOT_PNTC, vec2,
[Mesa-dev] [PATCH v2 2/5] main: do nothing in the ff fragment shader when using the core profile.
When the core profile is active, there is no fixed function fragment shader functionality. However, we still need to generate a dummy fragment shader program in case the back-end expects it (e.g. to cover the case where GL_RASTERIZER_DISCARD is active and the client hasn't supplied a fragment shader). This patch makes the dummy fragment shader program do nothing when the core profile is active. This will prevent breakages in later patches, when we stop exposing compatibility-only builtin variables in the core profile. --- src/mesa/main/ff_fragment_shader.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/ff_fragment_shader.cpp b/src/mesa/main/ff_fragment_shader.cpp index 86317ef..713e52a 100644 --- a/src/mesa/main/ff_fragment_shader.cpp +++ b/src/mesa/main/ff_fragment_shader.cpp @@ -1331,7 +1331,7 @@ create_new_program(struct gl_context *ctx, struct state_key *key) main_f-add_signature(main_sig); p.instructions = main_sig-body; - if (key-num_draw_buffers) + if (key-num_draw_buffers ctx-API != API_OPENGL_CORE) emit_instructions(p); validate_ir_tree(p.shader-ir); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 3/5] glsl: Add const safety to _mesa_glsl_parse_state::is_version()
Needed for the patch that follows.
---
src/glsl/glsl_parser_extras.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 7f478df..ad8b063 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -113,7 +113,7 @@ struct _mesa_glsl_parse_state {
* feature.
*/
bool is_version(unsigned required_glsl_version,
- unsigned required_glsl_es_version)
+ unsigned required_glsl_es_version) const
{
unsigned required_version = this-es_shader ?
required_glsl_es_version : required_glsl_version;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 4/5] glsl: Stop exposing compatibility-only builtin vars in the core profile.
GL 3.2 and GLSL 1.50 specify that several builtin variables
(e.g. gl_FrontColor) are available only in the compatibility profile.
GL 3.1 and GLSL 1.40 make a similar stipulation (except phrased in
terms of ARB_compatibility).
Previous versions of GLSL make no such stipulation. However, since GL
versions 3.1 and above are allowed to be mixed with older versions of
GLSL, we need to avoid exposing those compatibility-only builtin
variables for older GLSL versions too. Otherwise we open up a
loophole to allow compatibility-only features to be used in a core
context.
In the process I've moved the logic for determining whether
compatibility-only GLSL features are active into
_mesa_glsl_parse_state, so that we'll be able to use it to switch
other GLSL features on and off (this will be used in the next patch,
which fixes ftransform()).
---
src/glsl/builtin_variables.cpp | 19 +--
src/glsl/glsl_parser_extras.h | 26 ++
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 1e88b6a..ac54d41 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -342,14 +342,6 @@ private:
exec_list * const instructions;
struct _mesa_glsl_parse_state * const state;
glsl_symbol_table * const symtab;
-
- /**
-* True if compatibility-profile-only variables should be included. (In
-* desktop GL, these are always included when the GLSL version is 1.30 and
-* or below).
-*/
- const bool compatibility;
-
const glsl_type * const bool_t;
const glsl_type * const int_t;
const glsl_type * const float_t;
@@ -364,7 +356,6 @@ private:
builtin_variable_generator::builtin_variable_generator(
exec_list *instructions, struct _mesa_glsl_parse_state *state)
: instructions(instructions), state(state), symtab(state-symbols),
- compatibility(!state-is_version(140, 100)),
bool_t(glsl_type::bool_type), int_t(glsl_type::int_type),
float_t(glsl_type::float_type), vec2_t(glsl_type::vec2_type),
vec3_t(glsl_type::vec3_type), vec4_t(glsl_type::vec4_type),
@@ -534,7 +525,7 @@ builtin_variable_generator::generate_constants()
add_const(gl_MaxVaryingComponents, state-Const.MaxVaryingFloats);
}
- if (compatibility) {
+ if (state-compatibility()) {
/* Note: gl_MaxLights stopped being listed as an explicit constant in
* GLSL 1.30, however it continues to be referred to (as a minimum size
* for compatibility-mode uniforms) all the way up through GLSL 4.30, so
@@ -568,7 +559,7 @@ builtin_variable_generator::generate_uniforms()
add_uniform(array(vec4_t, VERT_ATTRIB_MAX), gl_CurrentAttribVertMESA);
add_uniform(array(vec4_t, VARYING_SLOT_MAX), gl_CurrentAttribFragMESA);
- if (compatibility) {
+ if (state-compatibility()) {
add_uniform(mat4_t, gl_ModelViewMatrix);
add_uniform(mat4_t, gl_ProjectionMatrix);
add_uniform(mat4_t, gl_ModelViewProjectionMatrix);
@@ -650,7 +641,7 @@ builtin_variable_generator::generate_vs_special_vars()
add_system_value(SYSTEM_VALUE_INSTANCE_ID, int_t, gl_InstanceID);
if (state-AMD_vertex_shader_layer_enable)
add_output(VARYING_SLOT_LAYER, int_t, gl_Layer);
- if (compatibility) {
+ if (state-compatibility()) {
add_input(VERT_ATTRIB_POS, vec4_t, gl_Vertex);
add_input(VERT_ATTRIB_NORMAL, vec3_t, gl_Normal);
add_input(VERT_ATTRIB_COLOR0, vec4_t, gl_Color);
@@ -706,7 +697,7 @@ builtin_variable_generator::generate_fs_special_vars()
* 1.30, and were relegated to the compatibility profile in GLSL 4.20.
* They were removed from GLSL ES 3.00.
*/
- if (compatibility || !state-is_version(420, 300)) {
+ if (state-compatibility() || !state-is_version(420, 300)) {
add_output(FRAG_RESULT_COLOR, vec4_t, gl_FragColor);
add_output(FRAG_RESULT_DATA0,
array(vec4_t, state-Const.MaxDrawBuffers), gl_FragData);
@@ -780,7 +771,7 @@ builtin_variable_generator::generate_varyings()
gl_ClipDistance);
}
- if (compatibility) {
+ if (state-compatibility()) {
ADD_VARYING(VARYING_SLOT_TEX0, array(vec4_t, 0), gl_TexCoord);
ADD_VARYING(VARYING_SLOT_FOGC, float_t, gl_FogFragCoord);
if (state-target == fragment_shader) {
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index ad8b063..7ff7faa 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -139,6 +139,32 @@ struct _mesa_glsl_parse_state {
void process_version_directive(YYLTYPE *locp, int version,
const char *ident);
+ /**
+* Determine whether compatibility-profile-only features should be included.
+*/
+ bool compatibility() const
+ {
+ if (this-es_shader)
+ return false;
+
+ /* Mesa doesn't support compatibility-only features in GLSL 1.40+.
+ * Note: under
[Mesa-dev] [PATCH v2 5/5] glsl/builtins: Stop exposing ftransform in the core profile.
GL 3.2 and GLSL 1.50 specify that the ftransform() function is
available only in the compatibility profile. GL 3.1 and GLSL 1.40
make a similar stipulation (except phrased in terms of
ARB_compatibility).
Previous versions of GLSL make no such stipulation. However, since GL
versions 3.1 and above are allowed to be mixed with older versions of
GLSL, we need to avoid exposing ftransform() in the core profile for
older GLSL versions too. Otherwise we open up a loophole to allow
compatibility-only features to be used in a core context.
To avoid exposing ftransform() in core contexts in GLSL 1.30, I had to
remove it from the 110.vert, 120.vert, and 130.vert profile files, and
move it to a new profile file called compatibility.vert, which takes
effect only when state-compatibility() returns true.
---
src/glsl/builtins/profiles/110.vert | 2 --
src/glsl/builtins/profiles/120.vert | 2 --
src/glsl/builtins/profiles/130.vert | 2 --
src/glsl/builtins/profiles/compatibility.vert | 3 +++
src/glsl/builtins/tools/generate_builtins.py | 4
5 files changed, 7 insertions(+), 6 deletions(-)
delete mode 100644 src/glsl/builtins/profiles/130.vert
create mode 100644 src/glsl/builtins/profiles/compatibility.vert
diff --git a/src/glsl/builtins/profiles/110.vert
b/src/glsl/builtins/profiles/110.vert
index 2d32341..c10a2e9 100644
--- a/src/glsl/builtins/profiles/110.vert
+++ b/src/glsl/builtins/profiles/110.vert
@@ -1,7 +1,5 @@
#version 110
-vec4 ftransform();
-
/*
* 8.7 - Texture Lookup Functions
* The built-ins suffixed with Lod are only allowed in a vertex shader.
diff --git a/src/glsl/builtins/profiles/120.vert
b/src/glsl/builtins/profiles/120.vert
index 41a1d96..a8bff18 100644
--- a/src/glsl/builtins/profiles/120.vert
+++ b/src/glsl/builtins/profiles/120.vert
@@ -1,7 +1,5 @@
#version 120
-vec4 ftransform();
-
vec4 texture1DLod(sampler1D sampler, float coord, float lod);
vec4 texture1DProjLod(sampler1D sampler, vec2 coord, float lod);
vec4 texture1DProjLod(sampler1D sampler, vec4 coord, float lod);
diff --git a/src/glsl/builtins/profiles/130.vert
b/src/glsl/builtins/profiles/130.vert
deleted file mode 100644
index 99d127e..000
--- a/src/glsl/builtins/profiles/130.vert
+++ /dev/null
@@ -1,2 +0,0 @@
-#version 130
-vec4 ftransform();
diff --git a/src/glsl/builtins/profiles/compatibility.vert
b/src/glsl/builtins/profiles/compatibility.vert
new file mode 100644
index 000..a8c7a70
--- /dev/null
+++ b/src/glsl/builtins/profiles/compatibility.vert
@@ -0,0 +1,3 @@
+#version 110
+
+vec4 ftransform();
diff --git a/src/glsl/builtins/tools/generate_builtins.py
b/src/glsl/builtins/tools/generate_builtins.py
index 85bd5dd..83c8e12 100755
--- a/src/glsl/builtins/tools/generate_builtins.py
+++ b/src/glsl/builtins/tools/generate_builtins.py
@@ -289,6 +289,10 @@ _mesa_glsl_initialize_functions(struct
_mesa_glsl_parse_state *state)
version = version[:-2]
check += 'state-language_version == ' + version
check += ' {0}state-es_shader'.format('' if is_es else '!')
+elif version == 'compatibility':
+# Special case: this profile should be included whenever
+# compatibility-profile features are allowed.
+check += 'state-compatibility()'
else: # an extension name
check += 'state-' + version + '_enable'
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Initialize ast_aggregate_initializer::constructor_type.
On Fri, Jul 12, 2013 at 5:24 PM, Vinson Lee v...@freedesktop.org wrote:
Fixes Uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/glsl/ast.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 9b119ed..c0350e7 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -307,7 +307,8 @@ private:
class ast_aggregate_initializer : public ast_expression {
public:
ast_aggregate_initializer()
- : ast_expression(ast_aggregate, NULL, NULL, NULL)
+ : ast_expression(ast_aggregate, NULL, NULL, NULL),
+constructor_type(NULL)
{
/* empty */
}
--
1.8.1.2
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] glsl: Disallow return with a void argument from void functions.
On 07/12/2013 06:04 PM, Carl Worth wrote: Carl Worth cwo...@cworth.org writes: From: Matt Turner matts...@gmail.com Reviewed-by: Kenneth Graunke kenn...@whitecape.org (cherry picked from commit fcaa48d9cc8937e0ceb59dfd22ef5b6e6fd1a273) Conflicts (resolved by Carl Worth cwo...@cworth.org): src/glsl/ast_to_hir.cpp [Oops. I meant to pass the --compose option to git send-email to add a bit of explanation before sending this patch out. Adding that explanation here as a reply instead.] Hi Matt, Here's a version of your patch as I updated it to apply to the stable branch. It didn't cherry-pick cleanly in the first place since master has since added code based on ARB_shading_language_420pack to coerce some return types. The stable branch doesn't add that code, so the context got confused when applying this patch. Below is my resolution of the conflict. My reading is that even without support for shading_language_420pack on the stable branch, adding this additional error case makes sense, (though perhaps the comment here, which references 420pack looks a little out of place, but I'm not concerned about that.) Please review what I did here, and let me know if you approve or if something different should be done, (cherry-picking additional dependent patches or dropping this from stable or other). -Carl Hey Carl, Matt, There are two kinds of bug fixes: 1. Patches that make valid programs work 2. Patches that disallow invalid programs This is in category 2 - it won't fix any applications, but runs a risk of breaking working programs. We often avoid backporting these. In this case, it's a very small risk, and your backport looks fine, so I'm fine with it going to stable. Either way. --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 4/5] glsl: Stop exposing compatibility-only builtin vars in the core profile.
On 07/12/2013 06:25 PM, Paul Berry wrote:
GL 3.2 and GLSL 1.50 specify that several builtin variables
(e.g. gl_FrontColor) are available only in the compatibility profile.
GL 3.1 and GLSL 1.40 make a similar stipulation (except phrased in
terms of ARB_compatibility).
Previous versions of GLSL make no such stipulation. However, since GL
versions 3.1 and above are allowed to be mixed with older versions of
GLSL, we need to avoid exposing those compatibility-only builtin
variables for older GLSL versions too. Otherwise we open up a
loophole to allow compatibility-only features to be used in a core
context.
In the process I've moved the logic for determining whether
compatibility-only GLSL features are active into
_mesa_glsl_parse_state, so that we'll be able to use it to switch
other GLSL features on and off (this will be used in the next patch,
which fixes ftransform()).
---
src/glsl/builtin_variables.cpp | 19 +--
src/glsl/glsl_parser_extras.h | 26 ++
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 1e88b6a..ac54d41 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -342,14 +342,6 @@ private:
exec_list * const instructions;
struct _mesa_glsl_parse_state * const state;
glsl_symbol_table * const symtab;
-
- /**
-* True if compatibility-profile-only variables should be included. (In
-* desktop GL, these are always included when the GLSL version is 1.30 and
-* or below).
-*/
- const bool compatibility;
-
const glsl_type * const bool_t;
const glsl_type * const int_t;
const glsl_type * const float_t;
@@ -364,7 +356,6 @@ private:
builtin_variable_generator::builtin_variable_generator(
exec_list *instructions, struct _mesa_glsl_parse_state *state)
: instructions(instructions), state(state), symtab(state-symbols),
- compatibility(!state-is_version(140, 100)),
bool_t(glsl_type::bool_type), int_t(glsl_type::int_type),
float_t(glsl_type::float_type), vec2_t(glsl_type::vec2_type),
vec3_t(glsl_type::vec3_type), vec4_t(glsl_type::vec4_type),
@@ -534,7 +525,7 @@ builtin_variable_generator::generate_constants()
add_const(gl_MaxVaryingComponents, state-Const.MaxVaryingFloats);
}
- if (compatibility) {
+ if (state-compatibility()) {
/* Note: gl_MaxLights stopped being listed as an explicit constant in
* GLSL 1.30, however it continues to be referred to (as a minimum size
* for compatibility-mode uniforms) all the way up through GLSL 4.30, so
@@ -568,7 +559,7 @@ builtin_variable_generator::generate_uniforms()
add_uniform(array(vec4_t, VERT_ATTRIB_MAX), gl_CurrentAttribVertMESA);
add_uniform(array(vec4_t, VARYING_SLOT_MAX), gl_CurrentAttribFragMESA);
- if (compatibility) {
+ if (state-compatibility()) {
add_uniform(mat4_t, gl_ModelViewMatrix);
add_uniform(mat4_t, gl_ProjectionMatrix);
add_uniform(mat4_t, gl_ModelViewProjectionMatrix);
@@ -650,7 +641,7 @@ builtin_variable_generator::generate_vs_special_vars()
add_system_value(SYSTEM_VALUE_INSTANCE_ID, int_t, gl_InstanceID);
if (state-AMD_vertex_shader_layer_enable)
add_output(VARYING_SLOT_LAYER, int_t, gl_Layer);
- if (compatibility) {
+ if (state-compatibility()) {
add_input(VERT_ATTRIB_POS, vec4_t, gl_Vertex);
add_input(VERT_ATTRIB_NORMAL, vec3_t, gl_Normal);
add_input(VERT_ATTRIB_COLOR0, vec4_t, gl_Color);
@@ -706,7 +697,7 @@ builtin_variable_generator::generate_fs_special_vars()
* 1.30, and were relegated to the compatibility profile in GLSL 4.20.
* They were removed from GLSL ES 3.00.
*/
- if (compatibility || !state-is_version(420, 300)) {
+ if (state-compatibility() || !state-is_version(420, 300)) {
add_output(FRAG_RESULT_COLOR, vec4_t, gl_FragColor);
add_output(FRAG_RESULT_DATA0,
array(vec4_t, state-Const.MaxDrawBuffers), gl_FragData);
@@ -780,7 +771,7 @@ builtin_variable_generator::generate_varyings()
gl_ClipDistance);
}
- if (compatibility) {
+ if (state-compatibility()) {
ADD_VARYING(VARYING_SLOT_TEX0, array(vec4_t, 0), gl_TexCoord);
ADD_VARYING(VARYING_SLOT_FOGC, float_t, gl_FogFragCoord);
if (state-target == fragment_shader) {
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index ad8b063..7ff7faa 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -139,6 +139,32 @@ struct _mesa_glsl_parse_state {
void process_version_directive(YYLTYPE *locp, int version,
const char *ident);
+ /**
+* Determine whether compatibility-profile-only features should be included.
+*/
+ bool compatibility() const
+ {
+ if (this-es_shader)
+ return false;
+
+ /* Mesa
[Mesa-dev] [PATCH] r600g/sb: Initialize ra_constraint::cost.
Fixes Uninitialized scalar field reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/drivers/r600/sb/sb_shader.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_shader.h
b/src/gallium/drivers/r600/sb/sb_shader.h
index ca9d29e..040dbf4 100644
--- a/src/gallium/drivers/r600/sb/sb_shader.h
+++ b/src/gallium/drivers/r600/sb/sb_shader.h
@@ -113,7 +113,7 @@ typedef std::vectorra_chunk* chunk_vector;
class ra_constraint {
public:
- ra_constraint(constraint_kind kind) : kind(kind) {}
+ ra_constraint(constraint_kind kind) : kind(kind), cost(0) {}
constraint_kind kind;
vvec values;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/5] glsl: Rework builtin_variables.cpp to reduce code duplication.
On 07/12/2013 06:25 PM, Paul Berry wrote: So this patch reworks things so that instead of having a separate function for each shader type and GLSL version, we have a function for constants, one for uniforms, one for varyings, and one for the special variables that are specific to each shader type. Brilliant. Series is: Reviewed-by: Kenneth Graunke kenn...@whitecape.org Like Ian, I'm not super crazy about the local type variables, just to fix whitespace issues - I'd almost rather just go over the 80 character limit. I gave up on meeting that requirement for the built-in type code, since I felt it was more readable to keep things on one line. But, I don't really care that much, so whatever you like. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: better detection of LLVM version
On Thu, Jun 27, 2013 at 11:13:37PM +0200, Klemens Baum wrote:
Pushed, thanks for the patch! Sorry for the delay.
-Tom
---
configure.ac | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/configure.ac b/configure.ac
index 6832b0d..3cabfe8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1577,8 +1577,26 @@ if test x$enable_gallium_llvm = xyes; then
fi
if test x$LLVM_CONFIG != xno; then
- LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'`
- LLVM_VERSION_INT=`echo $LLVM_VERSION | sed -e
's/\([[0-9]]\)\.\([[0-9]]\)/\10\2/g'`
+LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'`
+LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
+LLVM_BINDIR=`$LLVM_CONFIG --bindir`
+LLVM_CPPFLAGS=`strip_unwanted_llvm_flags $LLVM_CONFIG --cppflags`
+LLVM_CFLAGS=$LLVM_CPPFLAGS # CPPFLAGS seem to be sufficient
+LLVM_CXXFLAGS=`strip_unwanted_llvm_flags $LLVM_CONFIG --cxxflags`
+LLVM_INCLUDEDIR=`$LLVM_CONFIG --includedir`
+LLVM_LIBDIR=`$LLVM_CONFIG --libdir`
+
+AC_COMPUTE_INT([LLVM_VERSION_MAJOR], [LLVM_VERSION_MAJOR],
+[#include ${LLVM_INCLUDEDIR}/llvm/Config/llvm-config.h])
+AC_COMPUTE_INT([LLVM_VERSION_MINOR], [LLVM_VERSION_MINOR],
+[#include ${LLVM_INCLUDEDIR}/llvm/Config/llvm-config.h])
+
+if test x${LLVM_VERSION_MAJOR} != x; then
+LLVM_VERSION_INT=${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}
+else
+LLVM_VERSION_INT=`echo $LLVM_VERSION | sed -e
's/\([[0-9]]\)\.\([[0-9]]\)/\10\2/g'`
+fi
+
LLVM_COMPONENTS=engine bitwriter
if $LLVM_CONFIG --components | grep -q '\mcjit\'; then
LLVM_COMPONENTS=${LLVM_COMPONENTS} mcjit
@@ -1591,17 +1609,10 @@ if test x$enable_gallium_llvm = xyes; then
LLVM_COMPONENTS=${LLVM_COMPONENTS} irreader
fi
fi
- LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
- LLVM_BINDIR=`$LLVM_CONFIG --bindir`
- LLVM_CPPFLAGS=`strip_unwanted_llvm_flags $LLVM_CONFIG --cppflags`
- LLVM_CFLAGS=$LLVM_CPPFLAGS # CPPFLAGS seem to be sufficient
- LLVM_CXXFLAGS=`strip_unwanted_llvm_flags $LLVM_CONFIG --cxxflags`
- LLVM_INCLUDEDIR=`$LLVM_CONFIG --includedir`
- LLVM_LIBDIR=`$LLVM_CONFIG --libdir`
- DEFINES=${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT
- MESA_LLVM=1
-
- dnl Check for Clang interanl headers
+DEFINES=${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT
+MESA_LLVM=1
+
+dnl Check for Clang internal headers
if test x$enable_opencl = xyes; then
if test x$CLANG_LIBDIR = x; then
CLANG_LIBDIR=${LLVM_LIBDIR}
@@ -1611,8 +1622,8 @@ if test x$enable_gallium_llvm = xyes; then
AC_MSG_ERROR([Could not find clang internal header stddef.h
in $CLANG_RESOURCE_DIR Use --with-clang-libdir to specify the correct path to
the clang libraries.]))
fi
else
- MESA_LLVM=0
- LLVM_VERSION_INT=0
+MESA_LLVM=0
+LLVM_VERSION_INT=0
fi
else
MESA_LLVM=0
--
1.8.1.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Reject C-style initializers with unknown types.
On 07/12/2013 11:24 AM, Matt Turner wrote:
On Fri, Jul 12, 2013 at 11:10 AM, Matt Turner matts...@gmail.com wrote:
Previously, vec3 b = {{ 1.0, 2.0, 3.0 }} would cause a segfault because
the we dereferenced the constructor_type field which was NULL.
Arrays, structs, and matrices were unaffected.
This is a bad commit message. Use this instead:
_mesa_ast_set_aggregate_type walks through declarations initialized with
C-style aggregate initializers and stops when it runs out of LHS
declarations or RHS expressions.
In the example
vec4 v = {{{1, 2, 3, 4}}};
_mesa_ast_set_aggregate_type would not recurse into the subexpressions
(since vec4s do not contain types that can be initialized with an
aggregate initializer) to set their constructor_types. Later in ::hir
we would dereference the NULL pointer and segfault.
If constructor_type is NULL in ::hir we know that the LHS and RHS
were unbalanced and the code is illegal.
Arrays, structs, and matrices were unaffected.
Seems reasonable!
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Reject C-style initializers with unknown types.
Reviewed-by: Chris Forbes chr...@ijw.co.nz ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Combine URB code emission into a single group.
All four URB packets need to be programmed together in order for the GPU
state to be valid. Putting them in separate BEGIN..ADVANCE blocks is
risky: if we're nearing the end of a batch, the batch could be flushed
inbetween two of the commands, causing the URB programming to be split
into two batchbuffers.
This -might- be okay with hardware contexts, but it offers no advantages
over keeping them together, and has a potential for hangs.
Putting them into a single BEGIN..ADVANCE block ensures they'll be kept
in the same batch, which seems wise.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen7_urb.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c
b/src/mesa/drivers/dri/i965/gen7_urb.c
index ce01dda..350f644 100644
--- a/src/mesa/drivers/dri/i965/gen7_urb.c
+++ b/src/mesa/drivers/dri/i965/gen7_urb.c
@@ -60,12 +60,10 @@ gen7_allocate_push_constants(struct brw_context *brw)
if (brw-is_haswell brw-gt == 3)
size = 16;
- BEGIN_BATCH(2);
+ BEGIN_BATCH(4);
OUT_BATCH(_3DSTATE_PUSH_CONSTANT_ALLOC_VS 16 | (2 - 2));
OUT_BATCH(size);
- ADVANCE_BATCH();
- BEGIN_BATCH(2);
OUT_BATCH(_3DSTATE_PUSH_CONSTANT_ALLOC_PS 16 | (2 - 2));
OUT_BATCH(size | size GEN7_PUSH_CONSTANT_BUFFER_OFFSET_SHIFT);
ADVANCE_BATCH();
@@ -105,27 +103,21 @@ void
gen7_emit_urb_state(struct brw_context *brw, GLuint nr_vs_entries,
GLuint vs_size, GLuint vs_start)
{
- BEGIN_BATCH(2);
+ BEGIN_BATCH(8);
OUT_BATCH(_3DSTATE_URB_VS 16 | (2 - 2));
OUT_BATCH(nr_vs_entries |
((vs_size - 1) GEN7_URB_ENTRY_SIZE_SHIFT) |
(vs_start GEN7_URB_STARTING_ADDRESS_SHIFT));
- ADVANCE_BATCH();
/* Allocate the GS, HS, and DS zero space - we don't use them. */
- BEGIN_BATCH(2);
OUT_BATCH(_3DSTATE_URB_GS 16 | (2 - 2));
OUT_BATCH((0 GEN7_URB_ENTRY_SIZE_SHIFT) |
(vs_start GEN7_URB_STARTING_ADDRESS_SHIFT));
- ADVANCE_BATCH();
- BEGIN_BATCH(2);
OUT_BATCH(_3DSTATE_URB_HS 16 | (2 - 2));
OUT_BATCH((0 GEN7_URB_ENTRY_SIZE_SHIFT) |
(vs_start GEN7_URB_STARTING_ADDRESS_SHIFT));
- ADVANCE_BATCH();
- BEGIN_BATCH(2);
OUT_BATCH(_3DSTATE_URB_DS 16 | (2 - 2));
OUT_BATCH((0 GEN7_URB_ENTRY_SIZE_SHIFT) |
(vs_start GEN7_URB_STARTING_ADDRESS_SHIFT));
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
