Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target
Ping! Can somebody *please* commit this patch? It fixes an FTBFS, has two T-b and one A-b. Kai Wasserbäch wrote on 07.05.2018 16:48: > Jan Vesely wrote on 02.05.2018 22:38: >> On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote: >>> [...] >> >> Thank for looking into this. We probably need CLANG_LIBS handling >> similar to LLVM_LIBS. I agree this is the best fix for now. >> >> Acked-by: Jan Vesely >> >> libclang.so might be a solkution, but I'm not sure how it interacts >> with older or static build clang. It's also weird that we are linking >> to clang here instead of clover which actually uses clang symbols. >> >> @Emil, are you OK with this patch? > > Gentle ping. > >>> -lclangDriver \ >>> -lclangSerialization \ >>> - -lclangCodeGen \ >> >> Is this change related? > > Not really, just a minor clean-up while I was busy a few lines above. > "clangCodeGen" is already named on the first Clang library line. ah, all right, maybe mention it in the commit message? >>> >>> Do I need to resend the patch for that or can you just add a line like "This >>> change also removes the duplicate clangCodeGen line (trivial change)." >>> before >>> pushing, considering, that there are two T-b tags to be added anyway? >> >> I'll add it on my side before pushing the patch. > > Thanks a lot! > > Cheers, > Kai > > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- Kai Wasserbäch (Kai Wasserbaech) E-Mail: k...@dev.carbon-project.org signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk
Quoting Michel Thierry (2018-05-11 16:07:55) > On 5/11/2018 5:43 AM, Mika Kuoppala wrote: > > Chris Wilson writes: > > > >> Quoting Mika Kuoppala (2018-05-11 10:56:49) > >>> Michel Thierry writes: > >>> > Factor in clear values wherever required while updating destination > min/max. > > References: HSDES#160184 > Signed-off-by: Michel Thierry > Cc: mesa-dev@lists.freedesktop.org > Cc: Mika Kuoppala > Cc: Oscar Mateo > >>> > >>> Reviewed-by: Mika Kuoppala > >> > >> Cc: stable? > > > > Yes, we should. > > > > I think so too, although stable doesn't have the workaround refactoring > yet, the change will be in intel_engine_cs.c instead. Added the cc for stable, and pushed. We may need to send a fixup patch later if we want it backported all the way. Thanks, -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106480] A2B10G10R10_SNORM vertex attribute doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=106480 --- Comment #11 from mais...@archlinux.us --- The patches seem to have fixed the issue for me :) -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105494] UT2004 cube map reflection problem
https://bugs.freedesktop.org/show_bug.cgi?id=105494 --- Comment #7 from almos --- Here's a trace. I tried to capture the switch between showing only the top half or the bottom half of the reflection, but it ran at 1fps even with minimum graphics settings and capturing to a ramdisk. https://drive.google.com/open?id=1Labnt8OuvPVSsxEUHvJaQ6YbAdJicaiD -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106502] Running game with wine fullscreen freezes the system
https://bugs.freedesktop.org/show_bug.cgi?id=106502 Bug ID: 106502 Summary: Running game with wine fullscreen freezes the system Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: dark.shad...@web.de QA Contact: mesa-dev@lists.freedesktop.org I don't know where to put this bug, because I don't know the category. When running a specific game with wine in fullscreen, it freezes the system until I reboot. windowed works, but switching to fullscreen causes a freeze. It used to work, I tried downgrading mesa, linux and wine, but I can't get it to work anymore. I really don't know what causes this. Only relevant output I see in dmesg logs is > Mai 13 17:08:23 arch kernel: [drm:drm_atomic_helper_wait_for_flip_done > [drm_kms_helper]] *ERROR* [CRTC:43:crtc-0] flip_done timed out But I don't know if that's really the problem here. What kind of logs/debugging would help figure out the problem? System info: - Using Mesa 18.2.0-devel (git-26ddc4f9e1) / 18.0.3 - Linux 4.16.8 / 4.16.3 - plasma-desktop 5.12.5 - Arch Linux x64 - Radeon R9 285 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] compiler/spirv: reject invalid shader code properly
Ugh... I know this worked correctly when I did it. I think the setjmp must not have quite survived over of the refactors. I need to take a serious look at out on Monday. On May 13, 2018 09:02:24 Martin Pelikán wrote: After bebe3d626e5, b->fail_jump is prepared after vtn_create_builder which can longjmp(3) to it through its vtx_assert()s. This corrupts the stack and creates confusing core dumps, so we need to avoid it. While there, I decided to print the offending values for debugability. --- src/compiler/spirv/spirv_to_nir.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/src/compiler/spirv/spirv_to_nir.c b/src/compiler/spirv/spirv_to_nir.c index 78437428aa..a05364ba2f 100644 --- a/src/compiler/spirv/spirv_to_nir.c +++ b/src/compiler/spirv/spirv_to_nir.c @@ -4011,19 +4011,35 @@ vtn_create_builder(const uint32_t *words, size_t word_count, b->entry_point_name = entry_point_name; b->options = options; - /* Handle the SPIR-V header (first 4 dwords) */ - vtn_assert(word_count > 5); + /* +* Handle the SPIR-V header (first 4 dwords). +* Can't use vtx_assert() as the setjmp(3) target isn't initialized yet. +*/ + if (word_count <= 5) + goto fail; - vtn_assert(words[0] == SpvMagicNumber); - vtn_assert(words[1] >= 0x1); + if (words[0] != SpvMagicNumber) { + vtn_warn("words[0] was 0x%x, want 0x%x", words[0], SpvMagicNumber); + goto fail; + } + if (words[1] < 0x1) { + vtn_warn("words[1] was 0x%x, want >= 0x1", words[1]); + goto fail; + } /* words[2] == generator magic */ unsigned value_id_bound = words[3]; - vtn_assert(words[4] == 0); + if (words[4] != 0) { + vtn_warn("words[4] was %u, want 0", words[4]); + goto fail; + } b->value_id_bound = value_id_bound; b->values = rzalloc_array(b, struct vtn_value, value_id_bound); return b; + fail: + ralloc_free(b); + return NULL; } nir_function * -- 2.17.0.441.gb46fe60e1d-goog ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target
Hi, sorry for the delay. I thought maybe Emil is on holiday. I plan to push this on Monday evening (EDT) if there is no response by then. Jan On Sun, May 13, 2018 at 3:56 AM, Kai Wasserbäch wrote: > Ping! Can somebody *please* commit this patch? It fixes an FTBFS, has two > T-b > and one A-b. > > > Kai Wasserbäch wrote on 07.05.2018 16:48: > > Jan Vesely wrote on 02.05.2018 22:38: > >> On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote: > >>> [...] > >> > >> Thank for looking into this. We probably need CLANG_LIBS handling > >> similar to LLVM_LIBS. I agree this is the best fix for now. > >> > >> Acked-by: Jan Vesely > >> > >> libclang.so might be a solkution, but I'm not sure how it interacts > >> with older or static build clang. It's also weird that we are linking > >> to clang here instead of clover which actually uses clang symbols. > >> > >> @Emil, are you OK with this patch? > > > > Gentle ping. > > > >>> -lclangDriver \ > >>> -lclangSerialization \ > >>> - -lclangCodeGen \ > >> > >> Is this change related? > > > > Not really, just a minor clean-up while I was busy a few lines above. > > "clangCodeGen" is already named on the first Clang library line. > > ah, all right, maybe mention it in the commit message? > >>> > >>> Do I need to resend the patch for that or can you just add a line like > "This > >>> change also removes the duplicate clangCodeGen line (trivial change)." > before > >>> pushing, considering, that there are two T-b tags to be added anyway? > >> > >> I'll add it on my side before pushing the patch. > > > > Thanks a lot! > > > > Cheers, > > Kai > > > > > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > -- > > Kai Wasserbäch (Kai Wasserbaech) > > E-Mail: k...@dev.carbon-project.org > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106502] Running game with wine fullscreen freezes the system when missing xf86-video-amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=106502 Fabian Maurer changed: What|Removed |Added Summary|Running game with wine |Running game with wine |fullscreen freezes the |fullscreen freezes the |system |system when missing ||xf86-video-amdgpu --- Comment #1 from Fabian Maurer --- Okay, I figured out what causes it: It's due to a corrupt installation of xf86-video-amdgpu. When this package is not installed, I get the freeze. However, this is nothing that should happen. I think this package is part of mesa, but I'm not sure. So feel free to point me to another bugtracker if I'm mistaken. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: Fix multiview queries.
This moves the extra queries to after the main query ended, instead of doing it after the begin and hence doing nesting. We also emit only (view count - 1) extra queries, as the main query is already there for the first view. This fixes the CTS occasiionally getting stuck in dEQP-VK.multiview.queries* waiting on results. Fixes: 32b4f3c38dc "radv/query: handle multiview queries properly. (v3)" C: 18.1 --- src/amd/vulkan/radv_query.c | 39 +++-- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c index 2b2e80f4e5b..3749e2f43d1 100644 --- a/src/amd/vulkan/radv_query.c +++ b/src/amd/vulkan/radv_query.c @@ -1204,25 +1204,6 @@ void radv_CmdBeginQuery( va += pool->stride * query; emit_begin_query(cmd_buffer, va, pool->type, flags); - - /* -* For multiview we have to emit a query for each bit in the mask, -* however the first query we emit will get the totals for all the -* operations, so we don't want to get a real value in the other -* queries. This emits a fake begin/end sequence so the waiting -* code gets a completed query value and doesn't hang, but the -* query returns 0. -*/ - if (cmd_buffer->state.subpass && cmd_buffer->state.subpass->view_mask) { - uint64_t avail_va = va + pool->availability_offset + 4 * query; - - for (unsigned i = 0; i < util_bitcount(cmd_buffer->state.subpass->view_mask); i++) { - va += pool->stride; - avail_va += 4; - emit_begin_query(cmd_buffer, va, pool->type, flags); - emit_end_query(cmd_buffer, va, avail_va, pool->type); - } - } } @@ -1241,6 +1222,26 @@ void radv_CmdEndQuery( * currently be active, which means the BO is already in the list. */ emit_end_query(cmd_buffer, va, avail_va, pool->type); + + /* +* For multiview we have to emit a query for each bit in the mask, +* however the first query we emit will get the totals for all the +* operations, so we don't want to get a real value in the other +* queries. This emits a fake begin/end sequence so the waiting +* code gets a completed query value and doesn't hang, but the +* query returns 0. +*/ + if (cmd_buffer->state.subpass && cmd_buffer->state.subpass->view_mask) { + uint64_t avail_va = va + pool->availability_offset + 4 * query; + + + for (unsigned i = 1; i < util_bitcount(cmd_buffer->state.subpass->view_mask); i++) { + va += pool->stride; + avail_va += 4; + emit_begin_query(cmd_buffer, va, pool->type, 0); + emit_end_query(cmd_buffer, va, avail_va, pool->type); + } + } } void radv_CmdWriteTimestamp( -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: Fix multiview queries.
On 14 May 2018 at 06:07, Bas Nieuwenhuizen wrote: > This moves the extra queries to after the main query ended, instead > of doing it after the begin and hence doing nesting. > > We also emit only (view count - 1) extra queries, as the main query > is already there for the first view. > > This fixes the CTS occasiionally getting stuck in > dEQP-VK.multiview.queries* waiting on results. > > Fixes: 32b4f3c38dc "radv/query: handle multiview queries properly. (v3)" > C: 18.1 Seems sane: Reviewed-by: Dave Airlie > --- > src/amd/vulkan/radv_query.c | 39 +++-- > 1 file changed, 20 insertions(+), 19 deletions(-) > > diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c > index 2b2e80f4e5b..3749e2f43d1 100644 > --- a/src/amd/vulkan/radv_query.c > +++ b/src/amd/vulkan/radv_query.c > @@ -1204,25 +1204,6 @@ void radv_CmdBeginQuery( > va += pool->stride * query; > > emit_begin_query(cmd_buffer, va, pool->type, flags); > - > - /* > -* For multiview we have to emit a query for each bit in the mask, > -* however the first query we emit will get the totals for all the > -* operations, so we don't want to get a real value in the other > -* queries. This emits a fake begin/end sequence so the waiting > -* code gets a completed query value and doesn't hang, but the > -* query returns 0. > -*/ > - if (cmd_buffer->state.subpass && > cmd_buffer->state.subpass->view_mask) { > - uint64_t avail_va = va + pool->availability_offset + 4 * > query; > - > - for (unsigned i = 0; i < > util_bitcount(cmd_buffer->state.subpass->view_mask); i++) { > - va += pool->stride; > - avail_va += 4; > - emit_begin_query(cmd_buffer, va, pool->type, flags); > - emit_end_query(cmd_buffer, va, avail_va, pool->type); > - } > - } > } > > > @@ -1241,6 +1222,26 @@ void radv_CmdEndQuery( > * currently be active, which means the BO is already in the list. > */ > emit_end_query(cmd_buffer, va, avail_va, pool->type); > + > + /* > +* For multiview we have to emit a query for each bit in the mask, > +* however the first query we emit will get the totals for all the > +* operations, so we don't want to get a real value in the other > +* queries. This emits a fake begin/end sequence so the waiting > +* code gets a completed query value and doesn't hang, but the > +* query returns 0. > +*/ > + if (cmd_buffer->state.subpass && > cmd_buffer->state.subpass->view_mask) { > + uint64_t avail_va = va + pool->availability_offset + 4 * > query; > + > + > + for (unsigned i = 1; i < > util_bitcount(cmd_buffer->state.subpass->view_mask); i++) { > + va += pool->stride; > + avail_va += 4; > + emit_begin_query(cmd_buffer, va, pool->type, 0); > + emit_end_query(cmd_buffer, va, avail_va, pool->type); > + } > + } > } > > void radv_CmdWriteTimestamp( > -- > 2.17.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106504] vulkan SPIR-V parsing failed at ../src/compiler/spirv/vtn_cfg.c:381
https://bugs.freedesktop.org/show_bug.cgi?id=106504 Bug ID: 106504 Summary: vulkan SPIR-V parsing failed at ../src/compiler/spirv/vtn_cfg.c:381 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/Common Assignee: mesa-dev@lists.freedesktop.org Reporter: xavi...@gmail.com CC: airl...@freedesktop.org, chadvers...@chromium.org, dan...@fooishbar.org, ja...@jlekstrand.net Created attachment 139548 --> https://bugs.freedesktop.org/attachment.cgi?id=139548&action=edit vkrunner file hello, I get an error with both radv and intel SPIR-V parsing FAILED: In file ../src/compiler/spirv/vtn_cfg.c:381 block->node.link.next == NULL 0 bytes into the SPIR-V binary when using this hlsl shader (compiled with glslang): float4 main(float4 fragCoord : SV_POSITION) : SV_Target0 { float4 Sum = 0; for (int i=0; i<2; i++) { for (int j=0; j<2; j++) { Sum += fragCoord; } } return Sum / 4; } (the spirv source file is attached.) This report is a follow-up to https://github.com/KhronosGroup/SPIRV-Tools/issues/1456 "The outer loop's continue block ends up as the same block as the inner loop's continue block. I wonder if the Mesa compiler doesn't expect this (assuming there are no other bugs)." -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target
Hello Jan and Kai, would be nice if this lands (have T-b from me). Dieter Am 13.05.2018 19:10, schrieb Jan Vesely: Hi, sorry for the delay. I thought maybe Emil is on holiday. I plan to push this on Monday evening (EDT) if there is no response by then. Jan On Sun, May 13, 2018 at 3:56 AM, Kai Wasserbäch wrote: Ping! Can somebody *please* commit this patch? It fixes an FTBFS, has two T-b and one A-b. Kai Wasserbäch wrote on 07.05.2018 16:48: Jan Vesely wrote on 02.05.2018 22:38: On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote: [...] Thank for looking into this. We probably need CLANG_LIBS handling similar to LLVM_LIBS. I agree this is the best fix for now. Acked-by: Jan Vesely libclang.so might be a solkution, but I'm not sure how it interacts with older or static build clang. It's also weird that we are linking to clang here instead of clover which actually uses clang symbols. @Emil, are you OK with this patch? Gentle ping. -lclangDriver \ -lclangSerialization \ - -lclangCodeGen \ Is this change related? Not really, just a minor clean-up while I was busy a few lines above. "clangCodeGen" is already named on the first Clang library line. ah, all right, maybe mention it in the commit message? Do I need to resend the patch for that or can you just add a line like "This change also removes the duplicate clangCodeGen line (trivial change)." before pushing, considering, that there are two T-b tags to be added anyway? I'll add it on my side before pushing the patch. Thanks a lot! Cheers, Kai ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev [1] -- Kai Wasserbäch (Kai Wasserbaech) E-Mail: k...@dev.carbon-project.org Links: -- [1] https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105119] Desktop-wide input freeze when vulkan (radv)
https://bugs.freedesktop.org/show_bug.cgi?id=105119 Bas Nieuwenhuizen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 12/21] compiler/link: add linker_util.h, move linker_error/warning to it
Reviewed-by: Timothy Arceri On 12/05/18 19:40, Alejandro Piñeiro wrote: Linker utilities common to the GLSL IR and NIR linker (the latter to be used for ARB_gl_spirv). We need to move it to a new header as the NIR linker doesn't need to know about ir_variable, and others, included at linker.h. v2: move from src/compiler to src/compiler/glsl (Timothy Arceri) --- src/compiler/Makefile.sources | 1 + .../glsl/link_uniform_block_active_visitor.cpp | 1 + src/compiler/glsl/linker.h | 8 +--- src/compiler/glsl/linker_util.h| 43 ++ src/compiler/glsl/meson.build | 1 + src/compiler/glsl/program.h| 8 6 files changed, 48 insertions(+), 14 deletions(-) create mode 100644 src/compiler/glsl/linker_util.h diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources index 3daa2c51334..96af23fcd2c 100644 --- a/src/compiler/Makefile.sources +++ b/src/compiler/Makefile.sources @@ -71,6 +71,7 @@ LIBGLSL_FILES = \ glsl/ir_visitor.h \ glsl/linker.cpp \ glsl/linker.h \ + glsl/linker_util.h \ glsl/link_atomics.cpp \ glsl/link_functions.cpp \ glsl/link_interface_blocks.cpp \ diff --git a/src/compiler/glsl/link_uniform_block_active_visitor.cpp b/src/compiler/glsl/link_uniform_block_active_visitor.cpp index cd1baf78e80..368981852c0 100644 --- a/src/compiler/glsl/link_uniform_block_active_visitor.cpp +++ b/src/compiler/glsl/link_uniform_block_active_visitor.cpp @@ -23,6 +23,7 @@ #include "link_uniform_block_active_visitor.h" #include "program.h" +#include "linker_util.h" static link_uniform_block_active * process_block(void *mem_ctx, struct hash_table *ht, ir_variable *var) diff --git a/src/compiler/glsl/linker.h b/src/compiler/glsl/linker.h index 454b65aebdf..6e9b4861673 100644 --- a/src/compiler/glsl/linker.h +++ b/src/compiler/glsl/linker.h @@ -25,6 +25,8 @@ #ifndef GLSL_LINKER_H #define GLSL_LINKER_H +#include "linker_util.h" + struct gl_shader_program; struct gl_shader; struct gl_linked_shader; @@ -192,12 +194,6 @@ private: const glsl_struct_field *named_ifc_member); }; -void -linker_error(gl_shader_program *prog, const char *fmt, ...); - -void -linker_warning(gl_shader_program *prog, const char *fmt, ...); - /** * Sometimes there are empty slots left over in UniformRemapTable after we * allocate slots to explicit locations. This struct represents a single diff --git a/src/compiler/glsl/linker_util.h b/src/compiler/glsl/linker_util.h new file mode 100644 index 000..162db3e532f --- /dev/null +++ b/src/compiler/glsl/linker_util.h @@ -0,0 +1,43 @@ +/* + * Copyright © 2018 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ + +#ifndef GLSL_LINKER_UTIL_H +#define GLSL_LINKER_UTIL_H + +struct gl_shader_program; + +#ifdef __cplusplus +extern "C" { +#endif + +void +linker_error(struct gl_shader_program *prog, const char *fmt, ...); + +void +linker_warning(struct gl_shader_program *prog, const char *fmt, ...); + +#ifdef __cplusplus +} +#endif + +#endif /* GLSL_LINKER_UTIL_H */ diff --git a/src/compiler/glsl/meson.build b/src/compiler/glsl/meson.build index 055a84714c1..686a5a4ac0b 100644 --- a/src/compiler/glsl/meson.build +++ b/src/compiler/glsl/meson.build @@ -112,6 +112,7 @@ files_libglsl = files( 'ir_visitor.h', 'linker.cpp', 'linker.h', + 'linker_util.h', 'link_atomics.cpp', 'link_functions.cpp', 'link_interface_blocks.cpp', diff --git a/src/compiler/glsl/program.h b/src/compiler/glsl/program.h index 480379b10b8..9df42ddc1c4 100644 --- a/src/compiler/glsl/program.h +++ b/src/compiler/glsl/program.h @@ -48,14 +48,6 @@ extern void build_program_resource_list(struct gl_context *ctx, struct gl_shader_pr
Re: [Mesa-dev] [PATCH v2 15/21] compiler/link: move add_program_resource to linker_util
Reviewed-by: Timothy Arceri On 12/05/18 19:40, Alejandro Piñeiro wrote: So it could be used by the GLSL and NIR linker. v2: (Timothy Arceri) * Moved from compiler to compiler/glsl * Method renamed to link_util_add_program_resource --- src/compiler/Makefile.sources | 1 + src/compiler/glsl/linker.cpp | 76 +++ src/compiler/glsl/linker_util.cpp | 64 + src/compiler/glsl/linker_util.h | 5 +++ src/compiler/glsl/meson.build | 1 + 5 files changed, 91 insertions(+), 56 deletions(-) create mode 100644 src/compiler/glsl/linker_util.cpp diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources index 27c135e913b..8104dd32002 100644 --- a/src/compiler/Makefile.sources +++ b/src/compiler/Makefile.sources @@ -75,6 +75,7 @@ LIBGLSL_FILES = \ glsl/linker.cpp \ glsl/linker.h \ glsl/linker_util.h \ + glsl/linker_util.cpp \ glsl/link_atomics.cpp \ glsl/link_functions.cpp \ glsl/link_interface_blocks.cpp \ diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp index f060c5316fa..f201a566c29 100644 --- a/src/compiler/glsl/linker.cpp +++ b/src/compiler/glsl/linker.cpp @@ -3613,42 +3613,6 @@ should_add_buffer_variable(struct gl_shader_program *shProg, return false; } -static bool -add_program_resource(struct gl_shader_program *prog, - struct set *resource_set, - GLenum type, const void *data, uint8_t stages) -{ - assert(data); - - /* If resource already exists, do not add it again. */ - if (_mesa_set_search(resource_set, data)) - return true; - - prog->data->ProgramResourceList = - reralloc(prog->data, - prog->data->ProgramResourceList, - gl_program_resource, - prog->data->NumProgramResourceList + 1); - - if (!prog->data->ProgramResourceList) { - linker_error(prog, "Out of memory during linking.\n"); - return false; - } - - struct gl_program_resource *res = - &prog->data->ProgramResourceList[prog->data->NumProgramResourceList]; - - res->Type = type; - res->Data = data; - res->StageReferences = stages; - - prog->data->NumProgramResourceList++; - - _mesa_set_add(resource_set, data); - - return true; -} - /* Function checks if a variable var is a packed varying and * if given name is part of packed varying's list. * @@ -3942,8 +3906,8 @@ add_shader_variable(const struct gl_context *ctx, if (!sha_v) return false; - return add_program_resource(shProg, resource_set, - programInterface, sha_v, stage_mask); + return link_util_add_program_resource(shProg, resource_set, +programInterface, sha_v, stage_mask); } } } @@ -4372,9 +4336,9 @@ build_program_resource_list(struct gl_context *ctx, /* Add transform feedback varyings. */ if (linked_xfb->NumVarying > 0) { for (int i = 0; i < linked_xfb->NumVarying; i++) { -if (!add_program_resource(shProg, resource_set, - GL_TRANSFORM_FEEDBACK_VARYING, - &linked_xfb->Varyings[i], 0)) +if (!link_util_add_program_resource(shProg, resource_set, +GL_TRANSFORM_FEEDBACK_VARYING, +&linked_xfb->Varyings[i], 0)) return; } } @@ -4383,9 +4347,9 @@ build_program_resource_list(struct gl_context *ctx, for (unsigned i = 0; i < ctx->Const.MaxTransformFeedbackBuffers; i++) { if ((linked_xfb->ActiveBuffers >> i) & 1) { linked_xfb->Buffers[i].Binding = i; -if (!add_program_resource(shProg, resource_set, - GL_TRANSFORM_FEEDBACK_BUFFER, - &linked_xfb->Buffers[i], 0)) +if (!link_util_add_program_resource(shProg, resource_set, +GL_TRANSFORM_FEEDBACK_BUFFER, +&linked_xfb->Buffers[i], 0)) return; } } @@ -4421,29 +4385,29 @@ build_program_resource_list(struct gl_context *ctx, &shProg->data->UniformStorage[i]); } - if (!add_program_resource(shProg, resource_set, type, -&shProg->data->UniformStorage[i], stageref)) + if (!link_util_add_program_resource(shProg, resource_set, type, + &shProg->data->UniformStorage[i], stageref)) return; } /* Add program uniform blocks. */ for (unsigned i = 0; i < shProg->data->NumUniformBlocks; i++) { - if (!add_program_resource(shProg, resource_set, GL_UNIFO
Re: [Mesa-dev] [PATCH v2 16/21] nir/linker: Add nir_build_program_resource_list()
On 12/05/18 19:40, Alejandro Piñeiro wrote: From: Eduardo Lima Mitev This function is equivalent to the linker.cpp build_program_resource_list() but will extract the resources from NIR shaders instead. For now, only uniforms and program inputs are implemented. v2: move from compiler/nir to compiler/glsl (Timothy Arceri) Signed-off-by: Eduardo Lima Signed-off-by: Alejandro Piñeiro --- src/compiler/Makefile.sources | 1 + src/compiler/glsl/gl_nir_linker.c | 93 +++ src/compiler/glsl/gl_nir_linker.h | 3 ++ src/compiler/glsl/meson.build | 1 + 4 files changed, 98 insertions(+) create mode 100644 src/compiler/glsl/gl_nir_linker.c diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources index 8104dd32002..409252ee587 100644 --- a/src/compiler/Makefile.sources +++ b/src/compiler/Makefile.sources @@ -30,6 +30,7 @@ LIBGLSL_FILES = \ glsl/gl_nir_lower_samplers_as_deref.c \ glsl/gl_nir_link_uniform_initializers.c \ glsl/gl_nir_link_uniforms.c \ + glsl/gl_nir_linker.c \ glsl/gl_nir_linker.h \ glsl/gl_nir.h \ glsl/glsl_parser_extras.cpp \ diff --git a/src/compiler/glsl/gl_nir_linker.c b/src/compiler/glsl/gl_nir_linker.c new file mode 100644 index 000..155d94ef966 --- /dev/null +++ b/src/compiler/glsl/gl_nir_linker.c @@ -0,0 +1,93 @@ +/* + * Copyright © 2018 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + */ + +#include "nir.h" +#include "gl_nir_linker.h" +#include "linker_util.h" +#include "main/mtypes.h" +#include "ir_uniform.h" /* for gl_uniform_storage */ + +/* This file included general link methods, using NIR, instead of IR as + * the counter-part glsl/linker.cpp + * + * Also note that this is tailored for ARB_gl_spirv needs and particularities + */ + +void +nir_build_program_resource_list(struct gl_context *ctx, +struct gl_shader_program *prog) +{ + /* Rebuild resource list. */ + if (prog->data->ProgramResourceList) { + ralloc_free(prog->data->ProgramResourceList); + prog->data->ProgramResourceList = NULL; + prog->data->NumProgramResourceList = 0; + } + + struct set *resource_set = _mesa_set_create(NULL, + _mesa_hash_pointer, + _mesa_key_pointer_equal); + + /* Add uniforms +* +* Here, it is expected that nir_link_uniforms() has already been +* called, so that UniformStorage table is already available. +*/ + for (unsigned i = 0; i < prog->data->NumUniformStorage; i++) { + struct gl_uniform_storage *uniform = &prog->data->UniformStorage[i]; + + if (!link_util_add_program_resource(prog, resource_set, GL_UNIFORM, uniform, + uniform->active_shader_mask)) { + return; + } + } + + /* Add inputs */ + struct gl_linked_shader *sh = prog->_LinkedShaders[MESA_SHADER_VERTEX]; + if (sh) { + nir_shader *nir = sh->Program->nir; + assert(nir); + + nir_foreach_variable(var, &nir->inputs) { + struct gl_shader_variable *sh_var = +rzalloc(prog, struct gl_shader_variable); + + /* ARB_gl_spirv: names are considered optional debug info, so the linker + * needs to work without them, and returning them is optional. For + * simplicity we ignore names. + */ + sh_var->name = NULL; + sh_var->type = var->type; + sh_var->location = var->data.location; This doesn't look right to me. Don't we need to handle structs, ifcs and arrays just like in the glsl code? + + /* @TODO: Fill in the rest of gl_shader_variable data. */ + + if (!link_util_add_program_resource(prog, resource_set, GL_PROGRAM_INPUT, + sh_var, 1 << MESA_SHADER_VERTE
[Mesa-dev] [PATCH] radv: Translate logic ops.
radeonsi could pass them through but the enum changed between Gallium and Vulkan, so we have to translate. In progress I made the register defines a bit more readable. CC: 18.0 18.1 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100430 --- src/amd/common/sid.h | 44 +- src/amd/vulkan/radv_pipeline.c | 43 - 2 files changed, 58 insertions(+), 29 deletions(-) diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h index 3588d39d62b..e922b38ae3a 100644 --- a/src/amd/common/sid.h +++ b/src/amd/common/sid.h @@ -6892,34 +6892,22 @@ #define S_028808_ROP3(x) (((unsigned)(x) & 0xFF) << 16) #define G_028808_ROP3(x)(((x) >> 16) & 0xFF) #define C_028808_ROP3 0xFF00 -#define V_028808_X_0X00 0x00 -#define V_028808_X_0X05 0x05 -#define V_028808_X_0X0A 0x0A -#define V_028808_X_0X0F 0x0F -#define V_028808_X_0X11 0x11 -#define V_028808_X_0X22 0x22 -#define V_028808_X_0X33 0x33 -#define V_028808_X_0X44 0x44 -#define V_028808_X_0X50 0x50 -#define V_028808_X_0X55 0x55 -#define V_028808_X_0X5A 0x5A -#define V_028808_X_0X5F 0x5F -#define V_028808_X_0X66 0x66 -#define V_028808_X_0X77 0x77 -#define V_028808_X_0X88 0x88 -#define V_028808_X_0X99 0x99 -#define V_028808_X_0XA0 0xA0 -#define V_028808_X_0XA5 0xA5 -#define V_028808_X_0XAA 0xAA -#define V_028808_X_0XAF 0xAF -#define V_028808_X_0XBB 0xBB -#define V_028808_X_0XCC 0xCC -#define V_028808_X_0XDD 0xDD -#define V_028808_X_0XEE 0xEE -#define V_028808_X_0XF0 0xF0 -#define V_028808_X_0XF5 0xF5 -#define V_028808_X_0XFA 0xFA -#define V_028808_X_0XFF 0xFF +#define V_028808_ROP3_CLEAR 0x00 +#define V_028808_ROP3_NOR 0x11 +#define V_028808_ROP3_AND_INVERTED 0x22 +#define V_028808_ROP3_COPY_INVERTED 0x33 +#define V_028808_ROP3_AND_REVERSE 0x44 +#define V_028808_ROP3_INVERT0x55 +#define V_028808_ROP3_XOR 0x66 +#define V_028808_ROP3_NAND 0x77 +#define V_028808_ROP3_AND 0x88 +#define V_028808_ROP3_EQUIVALENT0x99 +#define V_028808_ROP3_NO_OP 0xaa +#define V_028808_ROP3_OR_INVERTED 0xbb +#define V_028808_ROP3_COPY 0xcc +#define V_028808_ROP3_OR_REVERSE0xdd +#define V_028808_ROP3_OR0xee +#define V_028808_ROP3_SET 0xff #define R_02880C_DB_SHADER_CONTROL 0x02880C #define S_02880C_Z_EXPORT_ENABLE(x) (((unsigned)(x) & 0x1) << 0) #define G_02880C_Z_EXPORT_ENABLE(x) (((x) >> 0) & 0x1) diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c index 7a9c1faaa87..3481f6b4cb7 100644 --- a/src/amd/vulkan/radv_pipeline.c +++ b/src/amd/vulkan/radv_pipeline.c @@ -181,6 +181,47 @@ radv_pipeline_scratch_init(struct radv_device *device, return VK_SUCCESS; } +static uint32_t si_translate_blend_logic_op(VkLogicOp op) +{ + switch (op) { + case VK_LOGIC_OP_CLEAR: + return V_028808_ROP3_CLEAR; + case VK_LOGIC_OP_AND: + return V_028808_ROP3_AND; + case VK_LOGIC_OP_AND_REVERSE: +
[Mesa-dev] [Bug 100430] [radv] graphical glitches on dolphin emulator
https://bugs.freedesktop.org/show_bug.cgi?id=100430 --- Comment #18 from Bas Nieuwenhuizen --- This should fix the rectangle in Mario Kart: https://patchwork.freedesktop.org/patch/222558/ -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)
https://bugs.freedesktop.org/show_bug.cgi?id=103852 --- Comment #20 from Bas Nieuwenhuizen --- Does https://patchwork.freedesktop.org/patch/222558/ fix the background rendering for you? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106232] LLVM unit tests have error in random number handling
https://bugs.freedesktop.org/show_bug.cgi?id=106232 Roland Scheidegger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Roland Scheidegger --- While it's not perfect, fixed by cf3fb42fb5eb6130693a4be0a7b5ea06b184ce2d. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: Translate logic ops.
On Sun, May 13, 2018 at 9:14 PM, Bas Nieuwenhuizen wrote: > radeonsi could pass them through but the enum changed between > Gallium and Vulkan, so we have to translate. > > In progress I made the register defines a bit more readable. > > CC: 18.0 18.1 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100430 > --- > src/amd/common/sid.h | 44 +- > src/amd/vulkan/radv_pipeline.c | 43 - > 2 files changed, 58 insertions(+), 29 deletions(-) > > diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h > index 3588d39d62b..e922b38ae3a 100644 > --- a/src/amd/common/sid.h > +++ b/src/amd/common/sid.h > @@ -6892,34 +6892,22 @@ > #define S_028808_ROP3(x) > (((unsigned)(x) & 0xFF) << 16) > #define G_028808_ROP3(x)(((x) > >> 16) & 0xFF) > #define C_028808_ROP3 > 0xFF00 > -#define V_028808_X_0X00 0x00 > -#define V_028808_X_0X05 0x05 > -#define V_028808_X_0X0A 0x0A > -#define V_028808_X_0X0F 0x0F > -#define V_028808_X_0X11 0x11 > -#define V_028808_X_0X22 0x22 > -#define V_028808_X_0X33 0x33 > -#define V_028808_X_0X44 0x44 > -#define V_028808_X_0X50 0x50 > -#define V_028808_X_0X55 0x55 > -#define V_028808_X_0X5A 0x5A > -#define V_028808_X_0X5F 0x5F > -#define V_028808_X_0X66 0x66 > -#define V_028808_X_0X77 0x77 > -#define V_028808_X_0X88 0x88 > -#define V_028808_X_0X99 0x99 > -#define V_028808_X_0XA0 0xA0 > -#define V_028808_X_0XA5 0xA5 > -#define V_028808_X_0XAA 0xAA > -#define V_028808_X_0XAF 0xAF > -#define V_028808_X_0XBB 0xBB > -#define V_028808_X_0XCC 0xCC > -#define V_028808_X_0XDD 0xDD > -#define V_028808_X_0XEE 0xEE > -#define V_028808_X_0XF0 0xF0 > -#define V_028808_X_0XF5 0xF5 > -#define V_028808_X_0XFA 0xFA > -#define V_028808_X_0XFF 0xFF > +#define V_028808_ROP3_CLEAR 0x00 > +#define V_028808_ROP3_NOR 0x11 > +#define V_028808_ROP3_AND_INVERTED 0x22 > +#define V_028808_ROP3_COPY_INVERTED 0x33 > +#define V_028808_ROP3_AND_REVERSE 0x44 > +#define V_028808_ROP3_INVERT0x55 > +#define V_028808_ROP3_XOR 0x66 > +#define V_028808_ROP3_NAND 0x77 > +#define V_028808_ROP3_AND 0x88 > +#define V_028808_ROP3_EQUIVALENT0x99 > +#define V_028808_ROP3_NO_OP 0xaa > +#define V_028808_ROP3_OR_INVERTED 0xbb > +#define V_028808_ROP3_COPY 0xcc > +#define V_028808_ROP3_OR_REVERSE0xdd > +#define V_028808_ROP3_OR0xee > +#define V_028808_ROP3_SET 0xff > #define R_02880C_DB_SHADER_CONTROL > 0x02880C > #define S_02880C_Z_EXPORT_ENABLE(x) > (((unsigned)(x) & 0x1) << 0) > #define G_02880C_Z_EXPORT_ENABLE(x) (((x) > >> 0) & 0x1) > diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c > index 7a9c1faaa87..3481f6b4cb7 100644 > --- a/src/amd/vulkan/radv_pipeline.c > +++ b/src/amd/vulkan/radv_pipeline.c > @@ -181,6 +181,47 @@ radv_pipeline_scratch_init(struct radv_device *device, > return VK_SUCCESS; > } > > +static uint32_t si_translate_blend_logic_op(VkLogicOp
Re: [Mesa-dev] [PATCH] radv: Translate logic ops.
On 05/13/2018 06:14 PM, Bas Nieuwenhuizen wrote: -#define V_028808_X_0X00 0x00 -#define V_028808_X_0X05 0x05 -#define V_028808_X_0X0A 0x0A -#define V_028808_X_0X0F 0x0F -#define V_028808_X_0X11 0x11 -#define V_028808_X_0X22 0x22 -#define V_028808_X_0X33 0x33 -#define V_028808_X_0X44 0x44 -#define V_028808_X_0X50 0x50 -#define V_028808_X_0X55 0x55 -#define V_028808_X_0X5A 0x5A -#define V_028808_X_0X5F 0x5F -#define V_028808_X_0X66 0x66 -#define V_028808_X_0X77 0x77 -#define V_028808_X_0X88 0x88 -#define V_028808_X_0X99 0x99 -#define V_028808_X_0XA0 0xA0 -#define V_028808_X_0XA5 0xA5 -#define V_028808_X_0XAA 0xAA -#define V_028808_X_0XAF 0xAF -#define V_028808_X_0XBB 0xBB -#define V_028808_X_0XCC 0xCC -#define V_028808_X_0XDD 0xDD -#define V_028808_X_0XEE 0xEE -#define V_028808_X_0XF0 0xF0 -#define V_028808_X_0XF5 0xF5 -#define V_028808_X_0XFA 0xFA -#define V_028808_X_0XFF 0xFF +#define V_028808_ROP3_CLEAR 0x00 +#define V_028808_ROP3_NOR 0x11 +#define V_028808_ROP3_AND_INVERTED 0x22 +#define V_028808_ROP3_COPY_INVERTED 0x33 +#define V_028808_ROP3_AND_REVERSE 0x44 +#define V_028808_ROP3_INVERT0x55 +#define V_028808_ROP3_XOR 0x66 +#define V_028808_ROP3_NAND 0x77 +#define V_028808_ROP3_AND 0x88 +#define V_028808_ROP3_EQUIVALENT0x99 +#define V_028808_ROP3_NO_OP 0xaa +#define V_028808_ROP3_OR_INVERTED 0xbb +#define V_028808_ROP3_COPY 0xcc +#define V_028808_ROP3_OR_REVERSE0xdd +#define V_028808_ROP3_OR0xee +#define V_028808_ROP3_SET 0xff This change removes names for some of the ternary raster operations supported by the hardware and also invents entirely new names for already named raster operations. Also I think this header is generated? If it isn't, perhaps the constants should be: #define V_028808_ROP3_0_BLACKNESS 0x00 #define V_028808_ROP3_DPon 0x05 #define V_028808_ROP3_DPna 0x0A #define V_028808_ROP3_Pn0x0F #define V_028808_ROP3_DSon_NOTSRCERASE 0x11 #define V_028808_ROP3_DSna 0x22 #define V_028808_ROP3_Sn_NOTSRCCOPY 0x33 #define V_028808_ROP3_SDna_SRCERASE 0x44 #define V_028808_ROP3_PDna 0x50 #define V_028808_ROP3_Dn_DSTINVERT 0x55 #define V_028808_ROP3_DPx_PATINVERT 0x5A #define V_028808_ROP3_DPan 0x5F #define V_028808_ROP3_DSx_SRCINVERT 0x66 #define V_028808_ROP3_DSan 0x77 #define V_028808_ROP3_DSa_SRCAND0x88 #define V_028808_ROP3_DSxn 0x99 #define V_028808_ROP3_DPa 0xA0 #define V_028808_ROP3_PDxn 0xA5 #define V_028808_ROP3_D 0xAA #define V_028808_ROP3_DPno
[Mesa-dev] [PATCH] docs: update shading.html
This just drops a buch of outdated information. --- docs/shading.html | 104 +- 1 file changed, 2 insertions(+), 102 deletions(-) diff --git a/docs/shading.html b/docs/shading.html index a0bbe997c1b..0d61c9df3ea 100644 --- a/docs/shading.html +++ b/docs/shading.html @@ -14,10 +14,10 @@ -Shading Language Support +OpenGL Shading Language -This page describes the features and status of Mesa's support for the +This page describes some features from Mesa's implementation of the https://opengl.org/documentation/glsl/";> OpenGL Shading Language. @@ -27,12 +27,7 @@ Contents Environment variables -GLSL 1.40 support -Unsupported Features -Implementation Notes -Programming Hints Stand-alone GLSL Compiler -Compiler Implementation Compiler Validation @@ -94,83 +89,6 @@ Notably, this captures linked GLSL shaders - with all stages together - as well as ARB programs. -GLSL Version - - -The GLSL compiler currently supports version 3.30 of the shading language. - - - -Several GLSL extensions are also supported: - - -GL_ARB_draw_buffers -GL_ARB_fragment_coord_conventions -GL_ARB_shader_bit_encoding - - - -Unsupported Features - -XXX update this section - - -The following features of the shading language are not yet fully supported -in Mesa: - - - -Linking of multiple shaders does not always work. Currently, linking -is implemented through shader concatenation and re-compiling. This -doesn't always work because of some #pragma and preprocessor issues. -The gl_Color and gl_SecondaryColor varying vars are interpolated -without perspective correction - - - -All other major features of the shading language should function. - - - -Implementation Notes - - -Shading language programs are compiled into low-level programs -very similar to those of GL_ARB_vertex/fragment_program. -All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full -float[4] registers. -Float constants and variables are packed so that up to four floats -can occupy one program parameter/register. -All function calls are inlined. -Shaders which use too many registers will not compile. -The quality of generated code is pretty good, register usage is fair. -Shader error detection and reporting of errors (InfoLog) is not -very good yet. -The ftransform() function doesn't necessarily match the results of -fixed-function transformation. - - - -These issues will be addressed/resolved in the future. - - - -Programming Hints - - -Use the built-in library functions whenever possible. -For example, instead of writing this: - -float x = 1.0 / sqrt(y); - -Write this: - -float x = inversesqrt(y); - - - - - Stand-alone GLSL Compiler @@ -211,24 +129,6 @@ without any header or separator --version - [Mandatory] define the GLSL version to use - -Compiler Implementation - - -The source code for Mesa's shading language compiler is in the -src/compiler/glsl/ directory. - - - -XXX provide some info about the compiler - - - -The final vertex and fragment programs may be interpreted in software -(see prog_execute.c) or translated into a specific hardware architecture -(see drivers/dri/i915/i915_fragprog.c for example). - - Compiler Validation -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev