[Mesa-dev] [Bug 107508] Crash in st_renderbuffer_delete()
https://bugs.freedesktop.org/show_bug.cgi?id=107508 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #7 from Timothy Arceri --- Fixed accepted in xserver. Closing. -- 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
[Mesa-dev] [Bug 109131] cc1plus: error: unrecognized command line option "-std=c++11"
https://bugs.freedesktop.org/show_bug.cgi?id=109131 Timothy Arceri changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #6 from Timothy Arceri --- autotools builds have been removed from Mesa. Closing. -- 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 108933] Unreal Tournament (UT99) segfault on opengl init
https://bugs.freedesktop.org/show_bug.cgi?id=108933 Timothy Arceri changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #15 from Timothy Arceri --- *** This bug has been marked as a duplicate of bug 37637 *** -- 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 37637] unreal tournament crashes with mesa 7.11-dev
https://bugs.freedesktop.org/show_bug.cgi?id=37637 Timothy Arceri changed: What|Removed |Added CC||network...@rkmail.ru --- Comment #14 from Timothy Arceri --- *** Bug 108933 has been marked as a duplicate of this bug. *** -- 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
[Mesa-dev] [Bug 88275] [865G] Intel OpenGL rendering isn't starting
https://bugs.freedesktop.org/show_bug.cgi?id=88275 Timothy Arceri changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Mesa core |Drivers/DRI/i915 -- 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] radv: call constant folding before opt algebraic
ping!
On 2/5/19 1:38 pm, Timothy Arceri wrote:
The pattern of calling opt algebraic first seems to have originated
in i965. The order in OpenGL drivers generally doesn't matter
because the GLSL IR optimisations do constant folding before
opt algebraic.
However in Vulkan drivers calling opt algebraic first can result
in missed constant folding opportunities.
vkpipeline-db results (VEGA64):
Totals from affected shaders:
SGPRS: 3160 -> 3176 (0.51 %)
VGPRS: 3588 -> 3580 (-0.22 %)
Spilled SGPRs: 52 -> 44 (-15.38 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 12 -> 12 (0.00 %) dwords per thread
Code Size: 261812 -> 261036 (-0.30 %) bytes
LDS: 7 -> 7 (0.00 %) blocks
Max Waves: 346 -> 348 (0.58 %)
Wait states: 0 -> 0 (0.00 %)
---
src/amd/vulkan/radv_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index cd5a9f2afb4..ad7b2439735 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -162,8 +162,8 @@ radv_optimize_nir(struct nir_shader *shader, bool
optimize_conservatively,
NIR_PASS(progress, shader, nir_opt_dead_cf);
NIR_PASS(progress, shader, nir_opt_cse);
NIR_PASS(progress, shader, nir_opt_peephole_select, 8, true,
true);
-NIR_PASS(progress, shader, nir_opt_algebraic);
NIR_PASS(progress, shader, nir_opt_constant_folding);
+NIR_PASS(progress, shader, nir_opt_algebraic);
NIR_PASS(progress, shader, nir_opt_undef);
NIR_PASS(progress, shader, nir_opt_conditional_discard);
if (shader->options->max_unroll_iterations) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110632] "glx: Fix synthetic error generation in __glXSendError" broke wine games on 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=110632
--- Comment #4 from Andrew Randrianasulu ---
(In reply to Andrew Randrianasulu from comment #2)
> Created attachment 144184 [details]
> apitrace from failed run (mesa git without revert)
hm, last line from apitrace:
12665 glXCreateContextAttribsARB(dpy = 0x7cbb2e18, config = 0x7c880b90,
share_context = NULL, direct = True, attrib_list =
{GLX_CONTEXT_MAJOR_VERSION_ARB, 4, GLX_CONTEXT_MINOR_VERSION_ARB, 4, 0}) //
incomplete
does this mean it tries to create 4.4 core context? If so, my hardware doesn't
support this (nv92 with nouveau drivers, only up to OpenGL 3.3)
--
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
[Mesa-dev] [Bug 37274] Crash in draw_llvm_shader23 (r300g, rs690, in warzone2100)
https://bugs.freedesktop.org/show_bug.cgi?id=37274 Timothy Arceri changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Mesa core |Drivers/Gallium/r300 -- 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
[Mesa-dev] [Bug 110632] "glx: Fix synthetic error generation in __glXSendError" broke wine games on 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=110632 --- Comment #3 from Andrew Randrianasulu --- (In reply to Ian Romanick from comment #1) > Is it possible to get a backtrace from __glXSendError? I don't understand > why this particular commit would change behavior from "not error" to "error". sorry, not familiar enough with gdb. Should I set breakpoint somewhere in libGL? -- 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
[Mesa-dev] [Bug 106351] Freezes with plasmashell and steam client
https://bugs.freedesktop.org/show_bug.cgi?id=106351 --- Comment #17 from Timothy Arceri --- Did a fix for this end up landing? -- 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
[Mesa-dev] [Bug 110632] "glx: Fix synthetic error generation in __glXSendError" broke wine games on 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=110632 --- Comment #2 from Andrew Randrianasulu --- Created attachment 144184 --> https://bugs.freedesktop.org/attachment.cgi?id=144184=edit apitrace from failed run (mesa git without revert) -- 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 44344] [i915g] state_tracker/st_glsl_to_tgsi.cpp:3082:simplify_cmp: Assertion `inst->dst.index < 4096' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=44344 Timothy Arceri changed: What|Removed |Added Component|Mesa core |Drivers/Gallium/i915g Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org -- 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
[Mesa-dev] [Bug 109184] tgsi_to_nir: nir_build_alu: Assertion `src_bit_size == nir_alu_type_get_type_size(op_info->input_types[i])' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=109184 --- Comment #2 from Timothy Arceri --- Does this still fail? There were a bunch of updates to ttn recently. -- 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
[Mesa-dev] [Bug 110632] "glx: Fix synthetic error generation in __glXSendError" broke wine games on 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=110632 --- Comment #1 from Ian Romanick --- Is it possible to get a backtrace from __glXSendError? I don't understand why this particular commit would change behavior from "not error" to "error". -- 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] Revert "glx: Fix synthetic error generation in __glXSendError"
This reverts commit e91ee763c378d03883eb88cf0eadd8aa916f7878. This seems to have broken a number of wine games. Cc: Adam Jackson Cc: Ian Romanick Cc: Hal Gentz Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110632 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110590 --- src/glx/glx_error.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/glx/glx_error.c b/src/glx/glx_error.c index 712ecf8213d..653cbeb2d2a 100644 --- a/src/glx/glx_error.c +++ b/src/glx/glx_error.c @@ -54,7 +54,7 @@ __glXSendError(Display * dpy, int_fast8_t errorCode, uint_fast32_t resourceID, error.errorCode = glx_dpy->codes->first_error + errorCode; } - error.sequenceNumber = dpy->last_request_read; + error.sequenceNumber = dpy->request; error.resourceID = resourceID; error.minorCode = minorCode; error.majorCode = glx_dpy->majorOpcode; @@ -73,7 +73,7 @@ __glXSendErrorForXcb(Display * dpy, const xcb_generic_error_t *err) error.type = X_Error; error.errorCode = err->error_code; - error.sequenceNumber = dpy->last_request_read; + error.sequenceNumber = err->sequence; error.resourceID = err->resource_id; error.minorCode = err->minor_code; error.majorCode = err->major_code; -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110632] "glx: Fix synthetic error generation in __glXSendError" broke wine games on 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=110632
Bug ID: 110632
Summary: "glx: Fix synthetic error generation in
__glXSendError" broke wine games on 32-bit
Product: Mesa
Version: git
Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: GLX
Assignee: mesa-dev@lists.freedesktop.org
Reporter: rand...@mail.ru
QA Contact: mesa-dev@lists.freedesktop.org
with normal mesa build (up to commit d4a249aa09d0571e07859f847494f728acb6ee77):
wine UnrealTournament.exe
0029:err:ntoskrnl:ZwLoadDriver failed to create driver
L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\zntport": c142
0015:err:service:process_send_command service protocol error - failed to write
pipe!
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"zntport"
failed to start: 1114
0009:fixme:process:GetProcessWorkingSetSizeEx
(0x,0x32f39c,0x32f394,(nil)): stub
0009:err:winediag:wined3d_dll_init Setting multithreaded command stream to 0.
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32c0c8,0x), stub!
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 890
Current serial number in output stream: 890
--
with e91ee763c378d03883eb88cf0eadd8aa916f7878 reverted locally:
wine UnrealTournament.exe
002a:err:ntoskrnl:ZwLoadDriver failed to create driver
L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\zntport": c142
0014:err:service:process_send_command service protocol error - failed to write
pipe!
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"zntport"
failed to start: 1114
0009:fixme:process:GetProcessWorkingSetSizeEx
(0x,0x32f39c,0x32f394,(nil)): stub
0009:err:winediag:wined3d_dll_init Setting multithreaded command stream to 0.
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32c0c8,0x), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32c488,0x), stub!
0009:fixme:ddraw:ddraw7_Initialize Ignoring guid
{----}.
0009:fixme:ddraw:ddraw_surface7_Flip Ignoring flags 0x1.
0009:err:ole:CoGetClassObject class {92fa2c24-253c-11d2-90fb-006008a1f441} not
registered
0009:err:ole:CoGetClassObject no class object
{92fa2c24-253c-11d2-90fb-006008a1f441} could be created for context 0x1
0009:err:ole:CoGetClassObject class {d8f1eee0-f634-11cf-8700-00a0245d918b} not
registered
0009:err:ole:CoGetClassObject no class object
{d8f1eee0-f634-11cf-8700-00a0245d918b} could be created for context 0x1
0009:fixme:d3d:state_linepattern_w Setting line patterns is not supported in
OpenGL core contexts.
and game starts normally.
wine version:
wine-4.5
--
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 108952] mesa-git broke cinnamon, temporary downgrade fix
https://bugs.freedesktop.org/show_bug.cgi?id=108952 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 107699] Account and Access request
https://bugs.freedesktop.org/show_bug.cgi?id=107699 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Timothy Arceri --- Seems to have been granted at some point. Closing. -- 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
[Mesa-dev] [PATCH 1/2] nir: Add is_divergent_vector search helper
This allows algebraic optimizations to check if the argument accesses
multiple distinct components of a vector. So a swizzle like "xyz" will
return true, but "yyy" will return false, as will a scalar. This can be
useful for optimizations on vector processors, where a convergent
swizzle can be done in one clock (replicating as if a scalar) but a
divergent one must be scalarized. In these cases, it is useful to
optimize differently based on whether the swizzle diverges. (Use case is
the "csel" condition on Midgard).
Signed-off-by: Alyssa Rosenzweig
Cc: Jason Ekstrand
---
src/compiler/nir/nir_search_helpers.h | 16
1 file changed, 16 insertions(+)
diff --git a/src/compiler/nir/nir_search_helpers.h
b/src/compiler/nir/nir_search_helpers.h
index 1624508993d..46d7c300643 100644
--- a/src/compiler/nir/nir_search_helpers.h
+++ b/src/compiler/nir/nir_search_helpers.h
@@ -143,6 +143,22 @@ is_not_const(nir_alu_instr *instr, unsigned src, UNUSED
unsigned num_components,
return !nir_src_is_const(instr->src[src].src);
}
+/* I.e. a vector that actually accesses multiple channels */
+
+static inline bool
+is_divergent_vector(nir_alu_instr *instr, UNUSED unsigned src, unsigned
num_components,
+ const uint8_t *swizzle)
+{
+ unsigned first_component = swizzle[0];
+
+ for (unsigned i = 1; i < num_components; ++i) {
+ if (swizzle[i] != first_component)
+ return true;
+ }
+
+ return false;
+}
+
static inline bool
is_used_more_than_once(nir_alu_instr *instr)
{
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] panfrost/midgard: Cleanup csel lowering
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 151 +++---
.../panfrost/midgard/midgard_nir_algebraic.py | 12 +-
2 files changed, 37 insertions(+), 126 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 29f3ce7ff71..9ffc0d893fa 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -715,58 +715,6 @@ midgard_nir_lower_fdot2_body(nir_builder *b, nir_alu_instr
*alu)
nir_ssa_def_rewrite_uses(>dest.dest.ssa, nir_src_for_ssa(sum));
}
-/* Lower csel with mixed condition channels to mulitple csel instructions. For
- * context, the csel ops on Midgard are vector in *outputs*, but not in
- * *conditions*. So, if the condition is e.g. , a single op can select a
- * vec4. But if the condition is e.g. xyzw, four ops are needed as the ISA
- * can't cope with the divergent channels.*/
-
-static void
-midgard_nir_lower_mixed_csel_body(nir_builder *b, nir_alu_instr *alu)
-{
-if (alu->op != nir_op_bcsel)
-return;
-
-b->cursor = nir_before_instr(>instr);
-
-/* Must be run before registering */
-assert(alu->dest.dest.is_ssa);
-
-/* Check for mixed condition */
-
-unsigned comp = alu->src[0].swizzle[0];
-unsigned nr_components = alu->dest.dest.ssa.num_components;
-
-bool mixed = false;
-
-for (unsigned c = 1; c < nr_components; ++c)
-mixed |= (alu->src[0].swizzle[c] != comp);
-
-if (!mixed)
-return;
-
-/* We're mixed, so lower */
-
-assert(nr_components <= 4);
-nir_ssa_def *results[4];
-
-nir_ssa_def *cond = nir_ssa_for_alu_src(b, alu, 0);
-nir_ssa_def *choice0 = nir_ssa_for_alu_src(b, alu, 1);
-nir_ssa_def *choice1 = nir_ssa_for_alu_src(b, alu, 2);
-
-for (unsigned c = 0; c < nr_components; ++c) {
-results[c] = nir_bcsel(b,
-nir_channel(b, cond, c),
-nir_channel(b, choice0, c),
-nir_channel(b, choice1, c));
-}
-
-/* Replace with our scalarized version */
-
-nir_ssa_def *result = nir_vec(b, results, nr_components);
-nir_ssa_def_rewrite_uses(>dest.dest.ssa, nir_src_for_ssa(result));
-}
-
static int
midgard_nir_sysval_for_intrinsic(nir_intrinsic_instr *instr)
{
@@ -851,36 +799,6 @@ midgard_nir_lower_fdot2(nir_shader *shader)
return progress;
}
-static bool
-midgard_nir_lower_mixed_csel(nir_shader *shader)
-{
-bool progress = false;
-
-nir_foreach_function(function, shader) {
-if (!function->impl) continue;
-
-nir_builder _b;
-nir_builder *b = &_b;
-nir_builder_init(b, function->impl);
-
-nir_foreach_block(block, function->impl) {
-nir_foreach_instr_safe(instr, block) {
-if (instr->type != nir_instr_type_alu)
continue;
-
-nir_alu_instr *alu = nir_instr_as_alu(instr);
-midgard_nir_lower_mixed_csel_body(b, alu);
-
-progress |= true;
-}
-}
-
-nir_metadata_preserve(function->impl, nir_metadata_block_index
| nir_metadata_dominance);
-
-}
-
-return progress;
-}
-
static void
optimise_nir(nir_shader *nir)
{
@@ -888,7 +806,6 @@ optimise_nir(nir_shader *nir)
NIR_PASS(progress, nir, nir_lower_regs_to_ssa);
NIR_PASS(progress, nir, midgard_nir_lower_fdot2);
-NIR_PASS(progress, nir, midgard_nir_lower_mixed_csel);
nir_lower_tex_options lower_tex_options = {
.lower_rect = true
@@ -932,6 +849,11 @@ optimise_nir(nir_shader *nir)
} while (progress);
NIR_PASS(progress, nir, nir_opt_algebraic_late);
+
+/* We implement booleans as 32-bit 0/~0 */
+NIR_PASS(progress, nir, nir_lower_bool_to_int32);
+
+/* Now that booleans are lowered, we can run out late opts */
NIR_PASS(progress, nir, midgard_nir_lower_algebraic_late);
/* Lower mods for float ops only. Integer ops don't support modifiers
@@ -942,9 +864,6 @@ optimise_nir(nir_shader *nir)
NIR_PASS(progress, nir, nir_copy_prop);
NIR_PASS(progress, nir, nir_opt_dce);
-/* We implement booleans as 32-bit 0/~0 */
-NIR_PASS(progress, nir, nir_lower_bool_to_int32);
-
/* Take us out of SSA */
NIR_PASS(progress, nir, nir_lower_locals_to_regs);
NIR_PASS(progress, nir, nir_convert_from_ssa, true);
@@ -1164,7 +1083,6 @@ emit_indirect_offset(compiler_context *ctx, nir_src *src)
case nir_op_##nir: \
op =
[Mesa-dev] [Bug 107667] [regression, bisected] 2.5% performance drop in Middle Earth: Shadow of Mordor
https://bugs.freedesktop.org/show_bug.cgi?id=107667 Timothy Arceri changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #1 from Timothy Arceri --- This is a correct bugfix. It's likely any gain in performance was due to not doing the correct thing. -- 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
[Mesa-dev] [Bug 108927] anaconda3 spyder fails to launch on Centos 7
https://bugs.freedesktop.org/show_bug.cgi?id=108927 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Timothy Arceri --- Mesa 11.0.7 has not been supported in many years. I suspect if this really is a bug it was probably fixed long ago. -- 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
[Mesa-dev] [Bug 103152] Mesa 17.2 cannot be built on ARM with GCC 7.2
https://bugs.freedesktop.org/show_bug.cgi?id=103152 Timothy Arceri 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
[Mesa-dev] [Bug 88766] codegen/nv50_ir.h:585:9: error: no member named 'tr1' in namespace 'std'
https://bugs.freedesktop.org/show_bug.cgi?id=88766 Timothy Arceri changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #9 from Timothy Arceri --- Lets just close this and worry about it if FreeBSD ever adds nouveau support. -- 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 30443] translate_test crashes on Mac OS X x86_64
https://bugs.freedesktop.org/show_bug.cgi?id=30443 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Timothy Arceri --- Either this was fixed or nobody cares. -- 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
[Mesa-dev] [Bug 109323] [TRACKER] mesa: Remove autotools
https://bugs.freedesktop.org/show_bug.cgi?id=109323 Bug 109323 depends on bug 109326, which changed state. Bug 109326 Summary: mesa: Meson configuration summary should be printed https://bugs.freedesktop.org/show_bug.cgi?id=109326 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: 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 109326] mesa: Meson configuration summary should be printed
https://bugs.freedesktop.org/show_bug.cgi?id=109326 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Timothy Arceri --- This has been merged. -- You are receiving this mail because: 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] gallivm: fix broken 8-wide s3tc decoding
LGTM. Just two little nits below.
Reviewed-by: Brian Paul
Perhaps you could review the 5-patch series of clean-ups I posted on
Saturday?
On 05/06/2019 06:12 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
Brian noticed there was an uninitialized var for the 8-wide case and 128
bit blocks, which made it always crash. Likewise, the 64bit block case
had another crash bug due to type mismatch.
Color decode (used for all s3tc formats) also had a bogus shuffle for
this case, leading to decode artifacts.
Fix these all up, which makes the code actually work 8-wide. Note that
it's still not used - I've verified it works, and the generated assembly
does look quite a bit simpler actually (20-30% less instructions for the
s3tc decode part with avx2), however in practice it still seems to be
sligthly slower for some unknown reason (tested with openarena) on my
haswell box, so for now continue to split things into 4-wide vectors
before decoding.
---
.../auxiliary/gallivm/lp_bld_format_s3tc.c| 33 +--
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
index 9561c349dad..8f6e9bec18a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
@@ -77,24 +77,17 @@ lp_build_uninterleave2_half(struct gallivm_state *gallivm,
unsigned lo_hi)
{
LLVMValueRef shuffle, elems[LP_MAX_VECTOR_LENGTH];
- unsigned i, j;
+ unsigned i;
assert(type.length <= LP_MAX_VECTOR_LENGTH);
assert(lo_hi < 2);
if (type.length * type.width == 256) {
- assert(type.length >= 4);
- for (i = 0, j = 0; i < type.length; ++i) {
- if (i == type.length / 4) {
-j = type.length;
- } else if (i == type.length / 2) {
-j = type.length / 2;
- } else if (i == 3 * type.length / 4) {
-j = 3 * type.length / 4;
- } else {
-j += 2;
- }
- elems[i] = lp_build_const_int32(gallivm, j + lo_hi);
+ assert(type.length == 8);
+ assert(type.width == 32);
+ const unsigned shufvals[8] = {0, 2, 8, 10, 4, 6, 12, 14};
could be static
+ for (i = 0; i < type.length; ++i) {
+ elems[i] = lp_build_const_int32(gallivm, shufvals[i] + lo_hi);
}
} else {
for (i = 0; i < type.length; ++i) {
@@ -277,7 +270,7 @@ lp_build_gather_s3tc(struct gallivm_state *gallivm,
}
else {
LLVMValueRef tmp[4], cc01, cc23;
- struct lp_type lp_type32, lp_type64, lp_type32dxt;
+ struct lp_type lp_type32, lp_type64;
memset(_type32, 0, sizeof lp_type32);
lp_type32.width = 32;
lp_type32.length = length;
@@ -309,10 +302,14 @@ lp_build_gather_s3tc(struct gallivm_state *gallivm,
lp_build_const_extend_shuffle(gallivm, 2,
4), "");
}
if (length == 8) {
+struct lp_type lp_type32_4;
+memset(_type32_4, 0, sizeof lp_type32_4);
Maybe we could move toward using initializers in these case? struct
lp_type lp_type32_4 = {0}; ?
+lp_type32_4.width = 32;
+lp_type32_4.length = 4;
for (i = 0; i < 4; ++i) {
tmp[0] = elems[i];
tmp[1] = elems[i+4];
- elems[i] = lp_build_concat(gallivm, tmp, lp_type32, 2);
+ elems[i] = lp_build_concat(gallivm, tmp, lp_type32_4, 2);
}
}
cc01 = lp_build_interleave2_half(gallivm, lp_type32, elems[0],
elems[1], 0);
@@ -811,7 +808,7 @@ s3tc_dxt3_to_rgba_aos(struct gallivm_state *gallivm,
tmp = lp_build_select(, sel_mask, alpha_low, alpha_hi);
bit_pos = LLVMBuildAnd(builder, bit_pos,
lp_build_const_int_vec(gallivm, type, 0xffdf),
"");
- /* Warning: slow shift with per element count */
+ /* Warning: slow shift with per element count (without avx2) */
/*
* Could do pshufb here as well - just use appropriate 2 bits in bit_pos
* to select the right byte with pshufb. Then for the remaining one bit
@@ -1640,7 +1637,6 @@ s3tc_decode_block_dxt5(struct gallivm_state *gallivm,
lp_build_const_int_vec(gallivm, type16, 8), "");
alpha = LLVMBuildBitCast(builder, alpha, i64t, "");
shuffle1 = lp_build_const_shuffle1(gallivm, 0, 8);
- /* XXX this shuffle broken with LLVM 2.8 */
alpha0 = LLVMBuildShuffleVector(builder, alpha0, alpha0, shuffle1, "");
alpha1 = LLVMBuildShuffleVector(builder, alpha1, alpha1, shuffle1, "");
@@ -2176,6 +2172,9 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state *gallivm,
return rgba;
}
+ /*
+* Could use n > 8 here with avx2, but doesn't seem faster.
+*/
if (n > 4) {
unsigned count;
LLVMTypeRef i8_vectype =
[Mesa-dev] [PATCH] radeonsi: add an AMD_TEX_ANISO environment variable
This brings it inline with the recently added AMD_DEBUG.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109619
---
src/gallium/drivers/radeonsi/si_pipe.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index b0e0ca7af05..4d36fd46a9b 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -950,6 +950,10 @@ struct pipe_screen *radeonsi_screen_create(struct
radeon_winsys *ws,
sizeof(struct si_transfer), 64);
sscreen->force_aniso = MIN2(16, debug_get_num_option("R600_TEX_ANISO",
-1));
+ if (sscreen->force_aniso == -1) {
+ sscreen->force_aniso = MIN2(16,
debug_get_num_option("AMD_TEX_ANISO", -1));
+ }
+
if (sscreen->force_aniso >= 0) {
printf("radeonsi: Forcing anisotropy filter to %ix\n",
/* round down to a power of two */
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90908] osx: src/mesa/x86-64/xform4.S does not build
https://bugs.freedesktop.org/show_bug.cgi?id=90908 --- Comment #3 from Timothy Arceri --- Looks like you never addressed the feedback. -- 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] gallivm: fix broken 8-wide s3tc decoding
From: Roland Scheidegger
Brian noticed there was an uninitialized var for the 8-wide case and 128
bit blocks, which made it always crash. Likewise, the 64bit block case
had another crash bug due to type mismatch.
Color decode (used for all s3tc formats) also had a bogus shuffle for
this case, leading to decode artifacts.
Fix these all up, which makes the code actually work 8-wide. Note that
it's still not used - I've verified it works, and the generated assembly
does look quite a bit simpler actually (20-30% less instructions for the
s3tc decode part with avx2), however in practice it still seems to be
sligthly slower for some unknown reason (tested with openarena) on my
haswell box, so for now continue to split things into 4-wide vectors
before decoding.
---
.../auxiliary/gallivm/lp_bld_format_s3tc.c| 33 +--
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
index 9561c349dad..8f6e9bec18a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
@@ -77,24 +77,17 @@ lp_build_uninterleave2_half(struct gallivm_state *gallivm,
unsigned lo_hi)
{
LLVMValueRef shuffle, elems[LP_MAX_VECTOR_LENGTH];
- unsigned i, j;
+ unsigned i;
assert(type.length <= LP_MAX_VECTOR_LENGTH);
assert(lo_hi < 2);
if (type.length * type.width == 256) {
- assert(type.length >= 4);
- for (i = 0, j = 0; i < type.length; ++i) {
- if (i == type.length / 4) {
-j = type.length;
- } else if (i == type.length / 2) {
-j = type.length / 2;
- } else if (i == 3 * type.length / 4) {
-j = 3 * type.length / 4;
- } else {
-j += 2;
- }
- elems[i] = lp_build_const_int32(gallivm, j + lo_hi);
+ assert(type.length == 8);
+ assert(type.width == 32);
+ const unsigned shufvals[8] = {0, 2, 8, 10, 4, 6, 12, 14};
+ for (i = 0; i < type.length; ++i) {
+ elems[i] = lp_build_const_int32(gallivm, shufvals[i] + lo_hi);
}
} else {
for (i = 0; i < type.length; ++i) {
@@ -277,7 +270,7 @@ lp_build_gather_s3tc(struct gallivm_state *gallivm,
}
else {
LLVMValueRef tmp[4], cc01, cc23;
- struct lp_type lp_type32, lp_type64, lp_type32dxt;
+ struct lp_type lp_type32, lp_type64;
memset(_type32, 0, sizeof lp_type32);
lp_type32.width = 32;
lp_type32.length = length;
@@ -309,10 +302,14 @@ lp_build_gather_s3tc(struct gallivm_state *gallivm,
lp_build_const_extend_shuffle(gallivm, 2, 4), "");
}
if (length == 8) {
+struct lp_type lp_type32_4;
+memset(_type32_4, 0, sizeof lp_type32_4);
+lp_type32_4.width = 32;
+lp_type32_4.length = 4;
for (i = 0; i < 4; ++i) {
tmp[0] = elems[i];
tmp[1] = elems[i+4];
- elems[i] = lp_build_concat(gallivm, tmp, lp_type32, 2);
+ elems[i] = lp_build_concat(gallivm, tmp, lp_type32_4, 2);
}
}
cc01 = lp_build_interleave2_half(gallivm, lp_type32, elems[0],
elems[1], 0);
@@ -811,7 +808,7 @@ s3tc_dxt3_to_rgba_aos(struct gallivm_state *gallivm,
tmp = lp_build_select(, sel_mask, alpha_low, alpha_hi);
bit_pos = LLVMBuildAnd(builder, bit_pos,
lp_build_const_int_vec(gallivm, type, 0xffdf),
"");
- /* Warning: slow shift with per element count */
+ /* Warning: slow shift with per element count (without avx2) */
/*
* Could do pshufb here as well - just use appropriate 2 bits in bit_pos
* to select the right byte with pshufb. Then for the remaining one bit
@@ -1640,7 +1637,6 @@ s3tc_decode_block_dxt5(struct gallivm_state *gallivm,
lp_build_const_int_vec(gallivm, type16, 8), "");
alpha = LLVMBuildBitCast(builder, alpha, i64t, "");
shuffle1 = lp_build_const_shuffle1(gallivm, 0, 8);
- /* XXX this shuffle broken with LLVM 2.8 */
alpha0 = LLVMBuildShuffleVector(builder, alpha0, alpha0, shuffle1, "");
alpha1 = LLVMBuildShuffleVector(builder, alpha1, alpha1, shuffle1, "");
@@ -2176,6 +2172,9 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state
*gallivm,
return rgba;
}
+ /*
+* Could use n > 8 here with avx2, but doesn't seem faster.
+*/
if (n > 4) {
unsigned count;
LLVMTypeRef i8_vectype = LLVMVectorType(i8t, 4 * n);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Bug 77449 depends on bug 100239, which changed state. Bug 100239 Summary: Incorrect rendering in CS:GO https://bugs.freedesktop.org/show_bug.cgi?id=100239 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- 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] configure.ac: check for libdrm when using VL with X11
Wrong Alyssa, cc'ing the right one :) On Mon, May 06, 2019 at 04:32:38PM +0100, Emil Velikov wrote: > From: Emil Velikov > > The X11 specific code uses libdrm, yet we are missing the dependency. > This has gone unnoticed since all drivers which use VL already mandate > the library. > > Note: this is applicable only for the stable branches. > > Cc: Alyssa Rosenzweig > Cc: > Signed-off-by: Emil Velikov > --- > Alyssa this should resolve the failure with minimal churn. Please let > me know if it works on your end or not. > --- > configure.ac | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index 1ef68fe68e6..b288ecbd265 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2357,7 +2357,7 @@ if test "x$enable_xvmc" = xyes -o \ > "x$enable_omx_tizonia" = xyes -o \ > "x$enable_va" = xyes; then > if echo $platforms | grep -q "x11"; then > -PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED]) > +PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED > libdrm >= $LIBDRM_REQUIRED]) > fi > need_gallium_vl_winsys=yes > fi > -- > 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110603] Blocky and black opacity/alpha using RADV on some games
https://bugs.freedesktop.org/show_bug.cgi?id=110603 --- Comment #4 from Lucas Francesco --- Created attachment 144180 --> https://bugs.freedesktop.org/attachment.cgi?id=144180=edit screnshot taken with scrot The strange thing for me is that the renderdoc capture looks 100% fine on ubuntu or in a friend's computer that haves similar hardware with arch, but on my PC both arch and gentoo, the renderdoc AND the game itself produces that blocky 100% black here's an screenshot I've taken just now of how it looks on my side, now I'm on the latest Mesa commit and the latest LLVM commit i'm trying to do another RenderDoc capture but i'm not being able to compile renderdoc due to a random dns issue right now -- 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
[Mesa-dev] [Bug 109401] [DXVK] Project Cars rendering problems
https://bugs.freedesktop.org/show_bug.cgi?id=109401 Samuel Pitoiset changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #8 from Samuel Pitoiset --- Are you sure? Just tried with 1.0.3 and the issue still happens. Less frequently but still. -- 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
[Mesa-dev] [Bug 100789] Mesa (Padoka Pkppa), Textures become corrupt in counterstrike 1.6 and in steam overlay after indeterminate amount of time
https://bugs.freedesktop.org/show_bug.cgi?id=100789 --- Comment #8 from calexil --- Created attachment 144179 --> https://bugs.freedesktop.org/attachment.cgi?id=144179=edit screen 4 -- 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
[Mesa-dev] [Bug 100789] Mesa (Padoka Pkppa), Textures become corrupt in counterstrike 1.6 and in steam overlay after indeterminate amount of time
https://bugs.freedesktop.org/show_bug.cgi?id=100789 --- Comment #7 from calexil --- Created attachment 144178 --> https://bugs.freedesktop.org/attachment.cgi?id=144178=edit screen 3 -- 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
[Mesa-dev] [Bug 100789] Mesa (Padoka Pkppa), Textures become corrupt in counterstrike 1.6 and in steam overlay after indeterminate amount of time
https://bugs.freedesktop.org/show_bug.cgi?id=100789 calexil changed: What|Removed |Added Attachment #131024|image if issue |screen 1 description|| -- 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 100789] Mesa (Padoka Pkppa), Textures become corrupt in counterstrike 1.6 and in steam overlay after indeterminate amount of time
https://bugs.freedesktop.org/show_bug.cgi?id=100789 --- Comment #6 from calexil --- Created attachment 144177 --> https://bugs.freedesktop.org/attachment.cgi?id=144177=edit screen 2 -- 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
[Mesa-dev] [Bug 109401] [DXVK] Project Cars rendering problems
https://bugs.freedesktop.org/show_bug.cgi?id=109401 Gregor Münch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Gregor Münch --- Sorry for the late response. Without testing your patch, I think the reflection issue went away with a proton update. I suspect going from DXVK 1.01 to 1.03 fixed the issue. Thx for your support! -- 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 109500] rpcs3 diagonal lines
https://bugs.freedesktop.org/show_bug.cgi?id=109500 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #1 from Samuel Pitoiset --- Enabling the "Strict Rendering Mode" "fixes" the lines problem. This is because RPCS3 violates the Vulkan spec and some barrier are probably missing. The problem can also be reproduced with AMDVLK. This should be fixed in RPCS3, closing. -- 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 v4] anv: fix alphaToCoverage when there is no color attachment
On Mon, May 6, 2019 at 9:01 AM Iago Toral Quiroga wrote:
> From: Samuel Iglesias Gonsálvez
>
> There are tests in CTS for alpha to coverage without a color attachment
> that are failing. This happens because we remove the shader color
> outputs when we don't have a valid color attachment for them, but when
> alpha to coverage is enabled we still want to preserve the the output
> at location 0 since we need the alpha component. In that case we will
> also need to create a null render target for RT 0.
>
> v2:
> - We already create a null rt when we don't have any, so reuse that
> for this case (Jason)
> - Simplify the code a bit (Iago)
>
> v3:
> - Take alpha to coverage from the key and don't tie this to depth-only
> rendering only, we want the same behavior if we have multiple render
> targets but the one at location 0 is not used. (Jason).
> - Rewrite commit message (Iago)
>
> v4:
> - Make sure we take into account the array length of the shader outputs,
> which we were no handling correctly either and make sure we also
> create null render targets for any invalid array entries too. (Jason)
>
> Fixes the following CTS tests:
> dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
>
> Signed-off-by: Samuel Iglesias Gonsálvez
> Signed-off-by: Iago Toral Quiroga
> ---
> src/intel/vulkan/anv_pipeline.c | 56 -
> 1 file changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_pipeline.c
> b/src/intel/vulkan/anv_pipeline.c
> index 20eab548fb2..f15f0896266 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -823,14 +823,24 @@ anv_pipeline_link_fs(const struct brw_compiler
> *compiler,
> continue;
>
>const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
> - /* Unused or out-of-bounds */
> - if (rt >= MAX_RTS || !(stage->key.wm.color_outputs_valid & (1 <<
> rt)))
> + /* Out-of-bounds */
> + if (rt >= MAX_RTS)
> continue;
>
>const unsigned array_len =
> glsl_type_is_array(var->type) ? glsl_get_length(var->type) : 1;
>assert(rt + array_len <= max_rt);
>
> + /* Unused */
> + if (!(stage->key.wm.color_outputs_valid & BITFIELD_RANGE(rt,
> array_len))) {
> + /* If this is the RT at location 0 and we have alpha to coverage
> + * enabled we will have to create a null RT for it, so mark it as
> + * used.
> + */
> + if (rt > 0 || !stage->key.wm.alpha_to_coverage)
> +continue;
> + }
> +
>for (unsigned i = 0; i < array_len; i++)
> rt_used[rt + i] = true;
> }
> @@ -841,11 +851,22 @@ anv_pipeline_link_fs(const struct brw_compiler
> *compiler,
> continue;
>
>rt_to_bindings[i] = num_rts;
> - rt_bindings[rt_to_bindings[i]] = (struct anv_pipeline_binding) {
> - .set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
> - .binding = 0,
> - .index = i,
> - };
> +
> + if (stage->key.wm.color_outputs_valid & (1 << i)) {
> + rt_bindings[rt_to_bindings[i]] = (struct anv_pipeline_binding) {
> +.set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
> +.binding = 0,
> +.index = i,
> + };
> + } else {
> + /* Setup a null render target */
> + rt_bindings[rt_to_bindings[i]] = (struct anv_pipeline_binding) {
> +.set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
> +.binding = 0,
> +.index = UINT32_MAX,
> + };
> + }
> +
>num_rts++;
> }
>
> @@ -855,14 +876,21 @@ anv_pipeline_link_fs(const struct brw_compiler
> *compiler,
> continue;
>
>const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
> + const unsigned array_len =
> + glsl_type_is_array(var->type) ? glsl_get_length(var->type) : 1;
> +
>if (rt >= MAX_RTS ||
> - !(stage->key.wm.color_outputs_valid & (1 << rt))) {
> - /* Unused or out-of-bounds, throw it away */
> - deleted_output = true;
> - var->data.mode = nir_var_function_temp;
> - exec_node_remove(>node);
> - exec_list_push_tail(>locals, >node);
> - continue;
> + !(stage->key.wm.color_outputs_valid & BITFIELD_RANGE(rt,
> array_len))) {
> + /* Unused or out-of-bounds, throw it away, unless it is the first
> + * RT and we have alpha to coverage enabled.
> + */
> + if (rt != 0 || !stage->key.wm.alpha_to_coverage) {
> +deleted_output = true;
> +var->data.mode = nir_var_function_temp;
> +exec_node_remove(>node);
> +exec_list_push_tail(>locals, >node);
> +continue;
> + }
>
I think we can simplify this yet further and just do
if (rt >= MAX_RTS || !rt_used[rt])
That way, all the logic stays in one place.
With that change,
Reviewed-by: Jason Ekstrand
>
Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] swr/rast: don't create wrapper for every Create LLVM call
We have a few internal patches that precede this that I am trying to get pushed through first. Some of these internal patches also touch gen_llvm_ir_macros.py, so there may be an edit to this patch before we do a merge request. -Alok > -Original Message- > From: Emil Velikov [mailto:emil.l.veli...@gmail.com] > Sent: Monday, May 6, 2019 10:56 AM > To: Hota, Alok > Cc: Dylan Baker ; Cherniak, Bruce > ; mesa-dev@lists.freedesktop.org; mesa- > sta...@lists.freedesktop.org > Subject: Re: [Mesa-stable] [Mesa-dev] [PATCH 1/2] swr/rast: don't create > wrapper for every Create LLVM call > > On Fri, 19 Apr 2019 at 16:36, Hota, Alok wrote: > > > > Just wanted to give a quick update on this. We have agreed on moving > forward with this patch. > > I'm working on it now to get it through our CI and run some basic tests. > > I'll > keep you updated. > > Thanks again for the patch, Emil! > > > Thanks Alok. > > I'm struggling to see this or equivalent in master. What's happening? > > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108952] mesa-git broke cinnamon, temporary downgrade fix
https://bugs.freedesktop.org/show_bug.cgi?id=108952 --- Comment #2 from walter.bis...@protonmail.com --- Yes, since 19.0 is live the problem is gone. Thx. -- 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] Move adriconf to mesa repositories
On Mon, May 6, 2019 at 5:43 PM Emil Velikov wrote: > > On Sun, 28 Apr 2019 at 19:38, Jean Hertel wrote: > > > > >Could not find my original notes, but the idea is roughly as follows: > > >- introduce a separate (user only?) library - say libmesa-config.so > > > - ^^ provides an API to query/set attributes, via numerical tokens > > > - any localisation is built on top of ^^ as standalone files > > > > > >Reasoning: > > >- library reused by anyone to make a pretty config tool in their > > >toolkit and/or language > > > - numerical tokens are trivial to handle and cheap - can be > > >binned/deprecated easily > > > - translation lives outside of the driver - the driver doesn't care > > >about it, so don't bloat > > > - translators do not need access to mesa - one less hurdle/obstacle > > > > > > > > >Hope it makes sense, not sure if coffee has kicked in fully ;-) > > >-Emil > > > > Hey Emil, > > > > I really liked this idea, specially since right now I have a lot of issues > > to query which option is exactly supported by each driver. Like in the > > scenarios when you have multiple drivers that support the same GPU, or when > > you have a difference between userspace and kernel space driver naming. > > > > Can you give me more details on the idea? > > If I got it right, this library would be independent and mesa will itself > > use it to query the options it wants/needs. > > > This is the tricky part - wish I could find my notes they have better > brain-dump. > It's OK to have the library as both front (config tool) and backend > (used by mesa) although: > - special care on splitting and annotating the API is needed > - handling this "extra" dependency would be fiddly for slower moving distros > > > What about the current configuration files? Do you think there is a better > > way to handle them? > > They are for in a xml format, which is far from optimal. > > > What seems to be the problem with XML? The files are meant to be > read/written to $app. > > > What about Vulkan? > > As far as I known the current setup only handles OpenGL driver > > configurations. > > > The current setup handles GLX, DRI and Nine IIRC. One of my goals was > to split and structure this in a more obvious way. FYI We have Vulkan integrated with driconf configs now too. > > HTH > Emil > ___ > 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 100789] Mesa 17.0.4 pkppa, Textures become corrupt in counterstrike 1.6 and in steam overlay after indeterminate amount of time
https://bugs.freedesktop.org/show_bug.cgi?id=100789 --- Comment #5 from calexil --- I'm on the padoka pkppa version of mesa and llvm -- 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
[Mesa-dev] [Bug 100789] Mesa (Padoka Pkppa), Textures become corrupt in counterstrike 1.6 and in steam overlay after indeterminate amount of time
https://bugs.freedesktop.org/show_bug.cgi?id=100789 calexil changed: What|Removed |Added Summary|Mesa 17.0.4 pkppa, Textures |Mesa (Padoka Pkppa), |become corrupt in |Textures become corrupt in |counterstrike 1.6 and in|counterstrike 1.6 and in |steam overlay after |steam overlay after |indeterminate amount of |indeterminate amount of |time|time Version|17.0|19.0 -- 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
[Mesa-dev] [Bug 100789] Mesa 17.0.4 pkppa, Textures become corrupt in counterstrike 1.6 and in steam overlay after indeterminate amount of time
https://bugs.freedesktop.org/show_bug.cgi?id=100789 --- Comment #4 from calexil --- yes, in fact I was just playing cs 1.6 last night and it was happening. -- 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
[Mesa-dev] [Bug 108325] radv_GetImageSubresourceLayout likely returns the wrong pitch on GFX9
https://bugs.freedesktop.org/show_bug.cgi?id=108325 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Samuel Pitoiset --- Fixed with https://cgit.freedesktop.org/mesa/mesa/commit/?id=c10808441cc479b715caf21d993866dc396397d9 -- 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 90908] osx: src/mesa/x86-64/xform4.S does not build
https://bugs.freedesktop.org/show_bug.cgi?id=90908 --- Comment #2 from Julien Isorce --- https://patchwork.freedesktop.org/patch/52161/ -- 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] GitLab Merge Request stable workflow question
When doing an MR via GitLab, is adding the Cc: mesa-stable item enough to nominate it for inclusion in stable or does it still need to be separately sent to the stable mailing list? The question is specifically wrt https://gitlab.freedesktop.org/mesa/mesa/merge_requests/806 since I'd like to see the fix in the next stable release, but it's really a broader workflow question of how stable is dealt with while both the MR and ML processes are active. -- Chuck Atkins Staff R Engineer, Scientific Computing Kitware, Inc. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] swr/rast: don't create wrapper for every Create LLVM call
On Fri, 19 Apr 2019 at 16:36, Hota, Alok wrote: > > Just wanted to give a quick update on this. We have agreed on moving forward > with this patch. > I'm working on it now to get it through our CI and run some basic tests. I'll > keep you updated. > Thanks again for the patch, Emil! > Thanks Alok. I'm struggling to see this or equivalent in master. What's happening? -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move adriconf to mesa repositories
On Sun, 28 Apr 2019 at 19:38, Jean Hertel wrote: > > >Could not find my original notes, but the idea is roughly as follows: > >- introduce a separate (user only?) library - say libmesa-config.so > > - ^^ provides an API to query/set attributes, via numerical tokens > > - any localisation is built on top of ^^ as standalone files > > > >Reasoning: > >- library reused by anyone to make a pretty config tool in their > >toolkit and/or language > > - numerical tokens are trivial to handle and cheap - can be > >binned/deprecated easily > > - translation lives outside of the driver - the driver doesn't care > >about it, so don't bloat > > - translators do not need access to mesa - one less hurdle/obstacle > > > > > >Hope it makes sense, not sure if coffee has kicked in fully ;-) > >-Emil > > Hey Emil, > > I really liked this idea, specially since right now I have a lot of issues to > query which option is exactly supported by each driver. Like in the scenarios > when you have multiple drivers that support the same GPU, or when you have a > difference between userspace and kernel space driver naming. > > Can you give me more details on the idea? > If I got it right, this library would be independent and mesa will itself use > it to query the options it wants/needs. > This is the tricky part - wish I could find my notes they have better brain-dump. It's OK to have the library as both front (config tool) and backend (used by mesa) although: - special care on splitting and annotating the API is needed - handling this "extra" dependency would be fiddly for slower moving distros > What about the current configuration files? Do you think there is a better > way to handle them? > They are for in a xml format, which is far from optimal. > What seems to be the problem with XML? The files are meant to be read/written to $app. > What about Vulkan? > As far as I known the current setup only handles OpenGL driver configurations. > The current setup handles GLX, DRI and Nine IIRC. One of my goals was to split and structure this in a more obvious way. HTH Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: check for libdrm when using VL with X11
From: Emil Velikov The X11 specific code uses libdrm, yet we are missing the dependency. This has gone unnoticed since all drivers which use VL already mandate the library. Note: this is applicable only for the stable branches. Cc: Alyssa Rosenzweig Cc: Signed-off-by: Emil Velikov --- Alyssa this should resolve the failure with minimal churn. Please let me know if it works on your end or not. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 1ef68fe68e6..b288ecbd265 100644 --- a/configure.ac +++ b/configure.ac @@ -2357,7 +2357,7 @@ if test "x$enable_xvmc" = xyes -o \ "x$enable_omx_tizonia" = xyes -o \ "x$enable_va" = xyes; then if echo $platforms | grep -q "x11"; then -PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED]) +PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED libdrm >= $LIBDRM_REQUIRED]) fi need_gallium_vl_winsys=yes fi -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Sat, 4 May 2019 at 04:18, Marek Olšák wrote: > > On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich > wrote: >> >> Good Morning, >> >> On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote: >> > BTW, swrast doesn't have to exist on the system. It's not uncommon for me >> > to have no swrast on my development system. >> >> Ok. I see. I use swrast regularly to test changes with different backend >> drivers. >> Also especially classic swrast as something that is close to the good old >> swtnl >> drivers - to catch bad interactions with those. >> >> Anyhow, with a very old swrast I think you will get test failures. >> But else if the system swrast is found in the hopefully not so distant future >> the tests should even pass - well depends on what Emil now does to get a >> better overall swrast behavior. >> On a production system with a full set of driver packages I do expect to >> find swrast, right? At least on a workstation grade linux distribution. >> >> I start to see the actual problem for AMD there. >> Not your test system at home, but the pro driver that needs to ship >> and QA swrast then. >> >> Anyhow, I do not actually understand the way how we walk all >> installed egl driver implementations - including closed drivers - finally >> and present all those devices. In a perfect world *for the customer* >> I could enumerate all devices - including oss i965 and the closed nvidia >> bumblebee device - on my laptop for example. >> >> Means - if that works fine AMD could hook into that mechanism and >> provide further devices. Well - in the long term. > > > We include libGL and libEGL along with radeonsi in our binary driver > installer. We probably don't include swrast, but I'm not 100% sure. > The series I just sent out covers everything but the "don't expose the software device". It does include a hack which can be toggled to achieve that though ;-) My line of thinking is as follows: Preamble: A software device is only listed when the user requests the full device list via QueryDevices and even then, it's the last one in the list. Thus it's close to impossible to get it "by mistake". Case A - average Joe: Getting Mesa from their distribution - swrast is build and shipped. Case B - tailored solution like AMDGPU-PRO, Yocto builders or others: People doing the platform integration know if swrast will be built/available. If listing the software device is not something they're interested, the trivial hack can be applied locally. This seems like a perfectly good middle-ground, don't you agree? HTH Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/9] egl/dri: flesh out and use dri2_create_drawable()
From: Emil Velikov
Wrap the loader->createNewDrawable() dance into a helper and use it
throughout the codebase.
This addresses a cases like surfaceless (SL) on swrast (SL on kms_swrast
is fine) where we'd attempt using the wrong driver and crash out.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/egl_dri2.c | 24 +
src/egl/drivers/dri2/egl_dri2.h | 5 +
src/egl/drivers/dri2/platform_android.c | 12 +--
src/egl/drivers/dri2/platform_drm.c | 17 +--
src/egl/drivers/dri2/platform_surfaceless.c | 7 +-
src/egl/drivers/dri2/platform_wayland.c | 14 +---
src/egl/drivers/dri2/platform_x11.c | 15 +
7 files changed, 34 insertions(+), 60 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index d584bccdebe..586bdd3b046 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1424,6 +1424,30 @@ dri2_surf_update_fence_fd(_EGLContext *ctx,
dri2_surface_set_out_fence_fd(surf, fence_fd);
}
+EGLBoolean
+dri2_create_drawable(struct dri2_egl_display *dri2_dpy,
+ const __DRIconfig *config,
+ struct dri2_egl_surface *dri2_surf)
+{
+ __DRIcreateNewDrawableFunc createNewDrawable;
+
+ if (dri2_dpy->image_driver)
+ createNewDrawable = dri2_dpy->image_driver->createNewDrawable;
+ else if (dri2_dpy->dri2)
+ createNewDrawable = dri2_dpy->dri2->createNewDrawable;
+ else if (dri2_dpy->swrast)
+ createNewDrawable = dri2_dpy->swrast->createNewDrawable;
+ else
+ return _eglError(EGL_BAD_ALLOC, "no createNewDrawable");
+
+ dri2_surf->dri_drawable = (*createNewDrawable)(dri2_dpy->dri_screen,
+ config, dri2_surf);
+ if (dri2_surf->dri_drawable == NULL)
+ return _eglError(EGL_BAD_ALLOC, "createNewDrawable");
+
+ return EGL_TRUE;
+}
+
/**
* Called via eglMakeCurrent(), drv->API.MakeCurrent().
*/
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index aa143deb867..e7ff5c9184b 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -540,6 +540,11 @@ dri2_init_surface(_EGLSurface *surf, _EGLDisplay *disp,
EGLint type,
void
dri2_fini_surface(_EGLSurface *surf);
+EGLBoolean
+dri2_create_drawable(struct dri2_egl_display *dri2_dpy,
+ const __DRIconfig *config,
+ struct dri2_egl_surface *dri2_surf);
+
static inline uint64_t
combine_u32_into_u64(uint32_t hi, uint32_t lo)
{
diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
index e9ea9e6002b..270d342ac6d 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -341,7 +341,6 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp,
EGLint type,
_EGLConfig *conf, void *native_window,
const EGLint *attrib_list)
{
- __DRIcreateNewDrawableFunc createNewDrawable;
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
struct dri2_egl_config *dri2_conf = dri2_egl_config(conf);
struct dri2_egl_surface *dri2_surf;
@@ -385,17 +384,8 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp,
EGLint type,
goto cleanup_surface;
}
- if (dri2_dpy->image_driver)
- createNewDrawable = dri2_dpy->image_driver->createNewDrawable;
- else
- createNewDrawable = dri2_dpy->dri2->createNewDrawable;
-
- dri2_surf->dri_drawable = (*createNewDrawable)(dri2_dpy->dri_screen, config,
- dri2_surf);
- if (dri2_surf->dri_drawable == NULL) {
- _eglError(EGL_BAD_ALLOC, "createNewDrawable");
+ if (!dri2_create_drawable(dri2_dpy, config, dri2_surf))
goto cleanup_surface;
- }
if (window) {
window->common.incRef(>common);
diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/drivers/dri2/platform_drm.c
index c1ab1c9b0f6..ec66ac3866e 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -171,23 +171,8 @@ dri2_drm_create_window_surface(_EGLDriver *drv,
_EGLDisplay *disp,
dri2_surf->base.Height = surf->base.height;
surf->dri_private = dri2_surf;
- if (dri2_dpy->dri2) {
- dri2_surf->dri_drawable =
- dri2_dpy->dri2->createNewDrawable(dri2_dpy->dri_screen, config,
- dri2_surf->gbm_surf);
-
- } else {
- assert(dri2_dpy->swrast != NULL);
-
- dri2_surf->dri_drawable =
- dri2_dpy->swrast->createNewDrawable(dri2_dpy->dri_screen, config,
- dri2_surf->gbm_surf);
-
- }
- if (dri2_surf->dri_drawable == NULL) {
- _eglError(EGL_BAD_ALLOC, "createNewDrawable()");
+ if (!dri2_create_drawable(dri2_dpy, config, dri2_surf))
goto
[Mesa-dev] [PATCH 8/9] egl: add EGL_platform_device support
This new 'platform' is added by default with no guards.
It is effectively a copy of the surfaceless one, with updated function
names and brand new probe function.
Due to the reuse, some of the ifdef HAVE_SURFACELESS_PLATFORM guards
have been dropped.
A worthy mention are the changes in _egFindDisplay, since the original
and dup'd fd are required, we make use of the plat_opt argument.
Note that no hacks for eglGetDisplay are added - the API works only with
the eglGetPlatformDisplay* API.
v2:
- s/_eglCompareDeviceDisplay/_eglSameDeviceDisplay/ (Eric)
- let ^^ return bool (Eric)
- fixup meson build, move files() further up (Eric)
- copy from plat. surfaceless w/o the visual cleanups
- close and free when destroying the dpy
- sprinkle a few _eglDeviceSupports
- split fd handling into separate function
- use directly the render node if no FD is given (Mathias)
v3:
- s/dpy/disp/g
- drop swap_buffers* callbacks
- drop loader_set_logger()
- drop local define
- re-introduce _eglGetDRMDeviceRenderNode()
- EGL_WARN on ForceSoftware with HW device - continue using the HW device
- bail out for "EGL_MESA_device_software" until it's fixed
- wire-up the Android build
v4:
- use new style _eglFindDisplay()
- split hw vs sw code paths
- don't close the internal fd (already handled in FiniDisplay())
- make swrast work (bit hacky bit will do for now)
- Android for real, drop autotools
- Correct HW + LIBGL_ALWAYS_SOFTWARE check
- use the dri2_create_drawable() helper
Cc: Mathias Fröhlich
Cc: Marek Olšák
Signed-off-by: Emil Velikov
---
src/egl/Android.mk | 1 +
src/egl/drivers/dri2/egl_dri2.c| 3 +
src/egl/drivers/dri2/egl_dri2.h| 13 +-
src/egl/drivers/dri2/platform_device.c | 432 +
src/egl/main/eglapi.c | 13 +-
src/egl/main/egldevice.c | 16 +
src/egl/main/egldevice.h | 3 +
src/egl/main/egldisplay.c | 64
src/egl/main/egldisplay.h | 7 +-
src/egl/main/eglglobals.c | 1 +
src/egl/meson.build| 1 +
11 files changed, 543 insertions(+), 11 deletions(-)
create mode 100644 src/egl/drivers/dri2/platform_device.c
diff --git a/src/egl/Android.mk b/src/egl/Android.mk
index a9319f56ae7..01c33298ee7 100644
--- a/src/egl/Android.mk
+++ b/src/egl/Android.mk
@@ -36,6 +36,7 @@ include $(CLEAR_VARS)
LOCAL_SRC_FILES := \
$(LIBEGL_C_FILES) \
$(dri2_backend_core_FILES) \
+ drivers/dri2/platform_device.c \
drivers/dri2/platform_android.c
LOCAL_CFLAGS := \
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 586bdd3b046..c4dcfc364ac 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -874,6 +874,9 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
case _EGL_PLATFORM_SURFACELESS:
ret = dri2_initialize_surfaceless(drv, disp);
break;
+ case _EGL_PLATFORM_DEVICE:
+ ret = dri2_initialize_device(drv, disp);
+ break;
case _EGL_PLATFORM_X11:
ret = dri2_initialize_x11(drv, disp);
break;
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index e7ff5c9184b..cd17b0a7036 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -331,10 +331,10 @@ struct dri2_egl_surface
} color_buffers[3], *back;
#endif
-#if defined(HAVE_SURFACELESS_PLATFORM)
- __DRIimage *front;
- unsigned int visual;
-#endif
+ /* surfaceless and device */
+ __DRIimage *front;
+ unsigned int visual;
+
int out_fence_fd;
EGLBoolean enable_out_fence;
};
@@ -492,6 +492,11 @@ dri2_initialize_surfaceless(_EGLDriver *drv, _EGLDisplay
*disp)
}
#endif
+EGLBoolean
+dri2_initialize_device(_EGLDriver *drv, _EGLDisplay *disp);
+static inline void
+dri2_teardown_device(struct dri2_egl_display *dri2_dpy) { /* noop */ }
+
void
dri2_flush_drawable_for_swapbuffers(_EGLDisplay *disp, _EGLSurface *draw);
diff --git a/src/egl/drivers/dri2/platform_device.c
b/src/egl/drivers/dri2/platform_device.c
new file mode 100644
index 000..0d9046c91b2
--- /dev/null
+++ b/src/egl/drivers/dri2/platform_device.c
@@ -0,0 +1,432 @@
+/*
+ * Mesa 3-D graphics library
+ *
+ * Copyright 2018 Collabora
+ *
+ * Based on platform_surfaceless, which has:
+ *
+ * Copyright (c) 2014 The Chromium OS Authors.
+ * Copyright © 2011 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
[Mesa-dev] [PATCH 7/9] egl: keep the software device at the end of the list
From: Emil Velikov
By default, the user is likely to pick the first device so it should
not be the least performant (aka software) one.
Suggested-by: Marek Olšák
Signed-off-by: Emil Velikov
---
src/egl/main/egldevice.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/egl/main/egldevice.c b/src/egl/main/egldevice.c
index c5c9a21273a..328d9ea08c5 100644
--- a/src/egl/main/egldevice.c
+++ b/src/egl/main/egldevice.c
@@ -293,13 +293,26 @@ _eglQueryDevicesEXT(EGLint max_devices,
goto out;
}
+ /* Push the first device (the software one) to the end of the list.
+* Sending it to the user only if they've requested the full list.
+*
+* By default, the user is likely to pick the first device so having the
+* software (aka least performant) one is not a good idea.
+*/
*num_devices = MIN2(num_devs, max_devices);
- for (i = 0, dev = devs; i < *num_devices; i++) {
+ for (i = 0, dev = devs->Next; dev && i < max_devices; i++) {
devices[i] = dev;
dev = dev->Next;
}
+ /* User requested the full device list, add the sofware device. */
+ if (max_devices >= num_devs) {
+ /* The first device is always software */
+ assert(_eglDeviceSupports(devs, _EGL_DEVICE_SOFTWARE));
+ devices[num_devs - 1] = devs;
+ }
+
out:
mtx_unlock(_eglGlobal.Mutex);
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 9/9] HACK: eg: hack to drop SOFTWARE egl device
For some extreme corner-cases where you'd want to do it.
---
src/egl/main/egldevice.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/egl/main/egldevice.c b/src/egl/main/egldevice.c
index 3e8c0e5aeb5..4a3127d7d62 100644
--- a/src/egl/main/egldevice.c
+++ b/src/egl/main/egldevice.c
@@ -321,15 +321,20 @@ _eglQueryDevicesEXT(EGLint max_devices,
devices[i] = dev;
dev = dev->Next;
}
-
+#define HACK_DROP_SOFTWARE_DEVICE 0
+#if !HACK_DROP_SOFTWARE_DEVICE
/* User requested the full device list, add the sofware device. */
if (max_devices >= num_devs) {
/* The first device is always software */
assert(_eglDeviceSupports(devs, _EGL_DEVICE_SOFTWARE));
devices[num_devs - 1] = devs;
}
+#endif
out:
+#if HACK_DROP_SOFTWARE_DEVICE
+ *num_devices--;
+#endif
mtx_unlock(_eglGlobal.Mutex);
return EGL_TRUE;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/9] egl/x11: pick the user requested screen
From: Adam Jackson
At the moment the user will pass the screen number via attribs, yet we
would throw that away. Reason being that the int *screen passed to
xcb_connect() is output only.
v2 (Emil):
- split from a larger patch
- use xcb_connect() returned screen, as fallback
- use helper function only as needed
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/platform_x11.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_x11.c
b/src/egl/drivers/dri2/platform_x11.c
index c8c676d2f00..ba0379c1177 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -1276,21 +1276,34 @@ static const __DRIextension *swrast_loader_extensions[]
= {
NULL,
};
+static int
+dri2_find_screen_for_display(const _EGLDisplay *disp, int fallback_screen)
+{
+ const EGLAttrib *attr;
+
+ for (attr = disp->Options.Attribs; attr; attr += 2) {
+ if (attr[0] == EGL_PLATFORM_X11_SCREEN_EXT)
+ return attr[1];
+ }
+
+ return fallback_screen;
+}
+
static EGLBoolean
dri2_get_xcb_connection(_EGLDriver *drv, _EGLDisplay *disp,
struct dri2_egl_display *dri2_dpy)
{
xcb_screen_iterator_t s;
- int screen = (uintptr_t)disp->Options.Platform;
+ int screen;
const char *msg;
disp->DriverData = (void *) dri2_dpy;
if (disp->PlatformDisplay == NULL) {
dri2_dpy->conn = xcb_connect(NULL, );
dri2_dpy->own_device = true;
+ screen = dri2_find_screen_for_display(disp, screen);
} else {
Display *dpy = disp->PlatformDisplay;
-
dri2_dpy->conn = XGetXCBConnection(dpy);
screen = DefaultScreen(dpy);
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/9] egl: remove Options::Platform handling
From: Adam Jackson
The full set of attributes is already handled with previous patches.
Thus all this is not dead code.
v2 (Emil) - split from a larger patch.
Signed-off-by: Emil Velikov
---
src/egl/main/egldisplay.c | 13 -
src/egl/main/egldisplay.h | 1 -
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c
index 9a2ac48e8bc..418ab0ec9b8 100644
--- a/src/egl/main/egldisplay.c
+++ b/src/egl/main/egldisplay.c
@@ -497,17 +497,12 @@ _eglParseX11DisplayAttribList(_EGLDisplay *display,
return EGL_TRUE;
}
+ /* EGL_EXT_platform_x11 recognizes exactly one attribute,
+* EGL_PLATFORM_X11_SCREEN_EXT, which is optional.
+*/
for (i = 0; attrib_list[i] != EGL_NONE; i += 2) {
- EGLAttrib attrib = attrib_list[i];
- EGLAttrib value = attrib_list[i + 1];
-
- /* EGL_EXT_platform_x11 recognizes exactly one attribute,
- * EGL_PLATFORM_X11_SCREEN_EXT, which is optional.
- */
- if (attrib != EGL_PLATFORM_X11_SCREEN_EXT)
+ if (attrib_list[i] != EGL_PLATFORM_X11_SCREEN_EXT)
return _eglError(EGL_BAD_ATTRIBUTE, "eglGetPlatformDisplay");
-
- display->Options.Platform = (void *)(uintptr_t)value;
}
return EGL_TRUE;
diff --git a/src/egl/main/egldisplay.h b/src/egl/main/egldisplay.h
index 2c9fd6c3399..369ab31187f 100644
--- a/src/egl/main/egldisplay.h
+++ b/src/egl/main/egldisplay.h
@@ -167,7 +167,6 @@ struct _egl_display
/* options that affect how the driver initializes the display */
struct {
EGLBoolean ForceSoftware; /**< Use software path only */
- void *Platform; /**< Platform-specific options */
EGLAttrib *Attribs; /**< Platform-specific options */
} Options;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/9] egl: fold X11 attrib handling like other platforms
From: Emil Velikov
Since we no longer need special handling for X11, refactor the code to
follow the style used by all other platforms.
Signed-off-by: Emil Velikov
---
src/egl/main/egldisplay.c | 45 ++-
1 file changed, 11 insertions(+), 34 deletions(-)
diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c
index 418ab0ec9b8..422b473844e 100644
--- a/src/egl/main/egldisplay.c
+++ b/src/egl/main/egldisplay.c
@@ -487,45 +487,22 @@ _eglUnlinkResource(_EGLResource *res, _EGLResourceType
type)
}
#ifdef HAVE_X11_PLATFORM
-static EGLBoolean
-_eglParseX11DisplayAttribList(_EGLDisplay *display,
- const EGLAttrib *attrib_list)
-{
- int i;
-
- if (attrib_list == NULL) {
- return EGL_TRUE;
- }
-
- /* EGL_EXT_platform_x11 recognizes exactly one attribute,
-* EGL_PLATFORM_X11_SCREEN_EXT, which is optional.
-*/
- for (i = 0; attrib_list[i] != EGL_NONE; i += 2) {
- if (attrib_list[i] != EGL_PLATFORM_X11_SCREEN_EXT)
- return _eglError(EGL_BAD_ATTRIBUTE, "eglGetPlatformDisplay");
- }
-
- return EGL_TRUE;
-}
-
_EGLDisplay*
_eglGetX11Display(Display *native_display,
const EGLAttrib *attrib_list)
{
- _EGLDisplay *display = _eglFindDisplay(_EGL_PLATFORM_X11,
- native_display,
- attrib_list);
-
- if (!display) {
- _eglError(EGL_BAD_ALLOC, "eglGetPlatformDisplay");
- return NULL;
- }
-
- if (!_eglParseX11DisplayAttribList(display, attrib_list)) {
- return NULL;
+ /* EGL_EXT_platform_x11 recognizes exactly one attribute,
+* EGL_PLATFORM_X11_SCREEN_EXT, which is optional.
+*/
+ if (attrib_list != NULL) {
+ for (int i = 0; attrib_list[i] != EGL_NONE; i += 2) {
+ if (attrib_list[i] != EGL_PLATFORM_X11_SCREEN_EXT) {
+_eglError(EGL_BAD_ATTRIBUTE, "eglGetPlatformDisplay");
+return NULL;
+ }
+ }
}
-
- return display;
+ return _eglFindDisplay(_EGL_PLATFORM_X11, native_display, attrib_list);
}
#endif /* HAVE_X11_PLATFORM */
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/9] egl: handle the full attrib list in display::options
From: Adam Jackson
Earlier spec is vague, although EGL 1.5 makes it clear:
Multiple calls made to eglGetPlatformDisplay with the same
parameters will return the same EGLDisplay handle.
With this commit we store and compare the full attrib list.
v2 (Emil):
- Split into separate patches
- Use EGLBoolean over int masked as such
- Don't return free'd pointed on calloc failure
Signed-off-by: Emil Velikov
---
src/egl/main/eglapi.c | 2 +-
src/egl/main/egldisplay.c | 61 +--
src/egl/main/egldisplay.h | 3 +-
3 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 4481eb9cd0f..f77df8ff437 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -373,7 +373,7 @@ eglGetDisplay(EGLNativeDisplayType nativeDisplay)
native_display_ptr = (void*) nativeDisplay;
plat = _eglGetNativePlatform(native_display_ptr);
- disp = _eglFindDisplay(plat, native_display_ptr);
+ disp = _eglFindDisplay(plat, native_display_ptr, NULL);
return _eglGetDisplayHandle(disp);
}
diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c
index ba5f84510fe..9a2ac48e8bc 100644
--- a/src/egl/main/egldisplay.c
+++ b/src/egl/main/egldisplay.c
@@ -202,20 +202,49 @@ _eglFiniDisplay(void)
}
}
+ free(disp->Options.Attribs);
free(disp);
}
_eglGlobal.DisplayList = NULL;
}
+static EGLBoolean
+_eglSameAttribs(const EGLAttrib *a, const EGLAttrib *b)
+{
+ size_t na = _eglNumAttribs(a);
+ size_t nb = _eglNumAttribs(b);
+
+ /* different numbers of attributes must be different */
+ if (na != nb)
+ return EGL_FALSE;
+
+ /* both lists NULL are the same */
+ if (!a && !b)
+ return EGL_TRUE;
+
+ /* otherwise, compare the lists */
+ return memcmp(a, b, na) == 0 ? EGL_TRUE : EGL_FALSE;
+}
/**
* Find the display corresponding to the specified native display, or create a
- * new one.
+ * new one. EGL 1.5 says:
+ *
+ * Multiple calls made to eglGetPlatformDisplay with the same parameters
+ * will return the same EGLDisplay handle.
+ *
+ * We read this extremely strictly, and treat a call with NULL attribs as
+ * different from a call with attribs only equal to { EGL_NONE }. Similarly
+ * we do not sort the attribute list, so even if all attribute _values_ are
+ * identical, different attribute orders will be considered different
+ * parameters.
*/
_EGLDisplay *
-_eglFindDisplay(_EGLPlatformType plat, void *plat_dpy)
+_eglFindDisplay(_EGLPlatformType plat, void *plat_dpy,
+const EGLAttrib *attrib_list)
{
_EGLDisplay *disp;
+ size_t num_attribs;
if (plat == _EGL_INVALID_PLATFORM)
return NULL;
@@ -225,7 +254,8 @@ _eglFindDisplay(_EGLPlatformType plat, void *plat_dpy)
/* search the display list first */
disp = _eglGlobal.DisplayList;
while (disp) {
- if (disp->Platform == plat && disp->PlatformDisplay == plat_dpy)
+ if (disp->Platform == plat && disp->PlatformDisplay == plat_dpy &&
+ _eglSameAttribs(disp->Options.Attribs, attrib_list))
break;
disp = disp->Next;
}
@@ -237,13 +267,24 @@ _eglFindDisplay(_EGLPlatformType plat, void *plat_dpy)
mtx_init(>Mutex, mtx_plain);
disp->Platform = plat;
disp->PlatformDisplay = plat_dpy;
-
- /* add to the display list */
+ num_attribs = _eglNumAttribs(attrib_list);
+ if (num_attribs) {
+disp->Options.Attribs = calloc(num_attribs, sizeof(EGLAttrib));
+if (!disp->Options.Attribs) {
+ free(disp);
+ disp = NULL;
+ goto out;
+}
+memcpy(disp->Options.Attribs, attrib_list,
+ num_attribs * sizeof(EGLAttrib));
+ }
+ /* add to the display list */
disp->Next = _eglGlobal.DisplayList;
_eglGlobal.DisplayList = disp;
}
}
+out:
mtx_unlock(_eglGlobal.Mutex);
return disp;
@@ -477,7 +518,8 @@ _eglGetX11Display(Display *native_display,
const EGLAttrib *attrib_list)
{
_EGLDisplay *display = _eglFindDisplay(_EGL_PLATFORM_X11,
- native_display);
+ native_display,
+ attrib_list);
if (!display) {
_eglError(EGL_BAD_ALLOC, "eglGetPlatformDisplay");
@@ -503,7 +545,7 @@ _eglGetGbmDisplay(struct gbm_device *native_display,
return NULL;
}
- return _eglFindDisplay(_EGL_PLATFORM_DRM, native_display);
+ return _eglFindDisplay(_EGL_PLATFORM_DRM, native_display, attrib_list);
}
#endif /* HAVE_DRM_PLATFORM */
@@ -518,7 +560,7 @@ _eglGetWaylandDisplay(struct wl_display *native_display,
return NULL;
}
- return _eglFindDisplay(_EGL_PLATFORM_WAYLAND, native_display);
+ return _eglFindDisplay(_EGL_PLATFORM_WAYLAND, native_display,
[Mesa-dev] [PATCH 0/9] Final round: EGL_EXT_platform_device
*** BLURB HERE *** Hi all, Here is, hopefully the final series, which add support for the extension. Note that pbuffers are broken (afaict have been since day 1) so one need fixes like the following [1]. Changes since last version: - split and fixup the EGLAttrib patch from Adam - less hacky eglFindDisplay - drop _eglParseX11DisplayAttribList() - minor polish - introduce dri2_create_drawable() helper - fixes a crash in platform_surfaceless and by extension platform_device with swrast - list software device in QueryDevices only when the full list is requested and even then - keep if the last device - get platform_device + swrast working - architecturally hacky, but will do for now - HACK: POC drop the software devices from QueryDevices Meant for Marek, if their stack does not build/ship swrast_dri.so Review and comments are appreciated :-) Thanks Emil Cc: Mathias Fröhlich Cc: Marek Olšák [1] https://patchwork.freedesktop.org/series/60018/ Adam Jackson (3): egl: handle the full attrib list in display::options egl/x11: pick the user requested screen egl: remove Options::Platform handling Emil Velikov (6): egl: flesh out a _eglNumAttribs() helper egl: fold X11 attrib handling like other platforms egl/dri: flesh out and use dri2_create_drawable() egl: keep the software device at the end of the list egl: add EGL_platform_device support HACK: eg: hack to drop SOFTWARE egl device src/egl/Android.mk | 1 + src/egl/drivers/dri2/egl_dri2.c | 27 ++ src/egl/drivers/dri2/egl_dri2.h | 18 +- src/egl/drivers/dri2/platform_android.c | 12 +- src/egl/drivers/dri2/platform_device.c | 432 src/egl/drivers/dri2/platform_drm.c | 17 +- src/egl/drivers/dri2/platform_surfaceless.c | 7 +- src/egl/drivers/dri2/platform_wayland.c | 14 +- src/egl/drivers/dri2/platform_x11.c | 32 +- src/egl/main/eglapi.c | 27 +- src/egl/main/egldevice.c| 36 +- src/egl/main/egldevice.h| 3 + src/egl/main/egldisplay.c | 171 +--- src/egl/main/egldisplay.h | 24 +- src/egl/main/eglglobals.c | 1 + src/egl/meson.build | 1 + 16 files changed, 691 insertions(+), 132 deletions(-) create mode 100644 src/egl/drivers/dri2/platform_device.c -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/9] egl: flesh out a _eglNumAttribs() helper
From: Emil Velikov
Signed-off-by: Emil Velikov
---
src/egl/main/eglapi.c | 12 +++-
src/egl/main/egldisplay.h | 13 +
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 588c6a5f1eb..4481eb9cd0f 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -340,22 +340,16 @@ _eglConvertIntsToAttribs(const EGLint *int_list,
EGLAttrib **out_attrib_list)
static EGLint *
_eglConvertAttribsToInt(const EGLAttrib *attr_list)
{
+ size_t size = _eglNumAttribs(attr_list);
EGLint *int_attribs = NULL;
/* Convert attributes from EGLAttrib[] to EGLint[] */
- if (attr_list) {
- int i, size = 0;
-
- while (attr_list[size] != EGL_NONE)
- size += 2;
-
- size += 1; /* add space for EGL_NONE */
-
+ if (size) {
int_attribs = calloc(size, sizeof(int_attribs[0]));
if (!int_attribs)
return NULL;
- for (i = 0; i < size; i++)
+ for (size_t i = 0; i < size; i++)
int_attribs[i] = attr_list[i];
}
return int_attribs;
diff --git a/src/egl/main/egldisplay.h b/src/egl/main/egldisplay.h
index cfd0ff66d64..f37b633b466 100644
--- a/src/egl/main/egldisplay.h
+++ b/src/egl/main/egldisplay.h
@@ -274,6 +274,19 @@ _eglIsResourceLinked(_EGLResource *res)
return res->IsLinked;
}
+static inline size_t
+_eglNumAttribs(const EGLAttrib *attribs)
+{
+ size_t len = 0;
+
+ if (attribs) {
+ while (attribs[len] != EGL_NONE)
+ len += 2;
+ len++;
+ }
+ return len;
+}
+
#ifdef HAVE_X11_PLATFORM
_EGLDisplay*
_eglGetX11Display(Display *native_display, const EGLAttrib *attrib_list);
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110625] [TRACKER] Mesa 19.1 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=110625 Bug ID: 110625 Summary: [TRACKER] Mesa 19.1 release tracker Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: jasua...@igalia.com QA Contact: mesa-dev@lists.freedesktop.org This is a tracker for all regressions from 19.0 until 19.1 release -- 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
[Mesa-dev] [Bug 110439] [TRACKER] Mesa 19.1 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=110439 Juan A. Suarez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 v4] anv: fix alphaToCoverage when there is no color attachment
From: Samuel Iglesias Gonsálvez
There are tests in CTS for alpha to coverage without a color attachment
that are failing. This happens because we remove the shader color
outputs when we don't have a valid color attachment for them, but when
alpha to coverage is enabled we still want to preserve the the output
at location 0 since we need the alpha component. In that case we will
also need to create a null render target for RT 0.
v2:
- We already create a null rt when we don't have any, so reuse that
for this case (Jason)
- Simplify the code a bit (Iago)
v3:
- Take alpha to coverage from the key and don't tie this to depth-only
rendering only, we want the same behavior if we have multiple render
targets but the one at location 0 is not used. (Jason).
- Rewrite commit message (Iago)
v4:
- Make sure we take into account the array length of the shader outputs,
which we were no handling correctly either and make sure we also
create null render targets for any invalid array entries too. (Jason)
Fixes the following CTS tests:
dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
Signed-off-by: Samuel Iglesias Gonsálvez
Signed-off-by: Iago Toral Quiroga
---
src/intel/vulkan/anv_pipeline.c | 56 -
1 file changed, 42 insertions(+), 14 deletions(-)
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 20eab548fb2..f15f0896266 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -823,14 +823,24 @@ anv_pipeline_link_fs(const struct brw_compiler *compiler,
continue;
const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
- /* Unused or out-of-bounds */
- if (rt >= MAX_RTS || !(stage->key.wm.color_outputs_valid & (1 << rt)))
+ /* Out-of-bounds */
+ if (rt >= MAX_RTS)
continue;
const unsigned array_len =
glsl_type_is_array(var->type) ? glsl_get_length(var->type) : 1;
assert(rt + array_len <= max_rt);
+ /* Unused */
+ if (!(stage->key.wm.color_outputs_valid & BITFIELD_RANGE(rt,
array_len))) {
+ /* If this is the RT at location 0 and we have alpha to coverage
+ * enabled we will have to create a null RT for it, so mark it as
+ * used.
+ */
+ if (rt > 0 || !stage->key.wm.alpha_to_coverage)
+continue;
+ }
+
for (unsigned i = 0; i < array_len; i++)
rt_used[rt + i] = true;
}
@@ -841,11 +851,22 @@ anv_pipeline_link_fs(const struct brw_compiler *compiler,
continue;
rt_to_bindings[i] = num_rts;
- rt_bindings[rt_to_bindings[i]] = (struct anv_pipeline_binding) {
- .set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
- .binding = 0,
- .index = i,
- };
+
+ if (stage->key.wm.color_outputs_valid & (1 << i)) {
+ rt_bindings[rt_to_bindings[i]] = (struct anv_pipeline_binding) {
+.set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
+.binding = 0,
+.index = i,
+ };
+ } else {
+ /* Setup a null render target */
+ rt_bindings[rt_to_bindings[i]] = (struct anv_pipeline_binding) {
+.set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
+.binding = 0,
+.index = UINT32_MAX,
+ };
+ }
+
num_rts++;
}
@@ -855,14 +876,21 @@ anv_pipeline_link_fs(const struct brw_compiler *compiler,
continue;
const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
+ const unsigned array_len =
+ glsl_type_is_array(var->type) ? glsl_get_length(var->type) : 1;
+
if (rt >= MAX_RTS ||
- !(stage->key.wm.color_outputs_valid & (1 << rt))) {
- /* Unused or out-of-bounds, throw it away */
- deleted_output = true;
- var->data.mode = nir_var_function_temp;
- exec_node_remove(>node);
- exec_list_push_tail(>locals, >node);
- continue;
+ !(stage->key.wm.color_outputs_valid & BITFIELD_RANGE(rt,
array_len))) {
+ /* Unused or out-of-bounds, throw it away, unless it is the first
+ * RT and we have alpha to coverage enabled.
+ */
+ if (rt != 0 || !stage->key.wm.alpha_to_coverage) {
+deleted_output = true;
+var->data.mode = nir_var_function_temp;
+exec_node_remove(>node);
+exec_list_push_tail(>locals, >node);
+continue;
+ }
}
/* Give it the new location */
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: add config entry for Counter-Strike Global Offensive
a-b On Mon, May 6, 2019 at 6:39 AM Timothy Arceri wrote: > > This fixes rendering issues with gun scopes which is rather > important. > > Cc: "19.0" "19.1" > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100239 > --- > src/util/00-mesa-defaults.conf | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf > index c704a1756ae..6389b796d33 100644 > --- a/src/util/00-mesa-defaults.conf > +++ b/src/util/00-mesa-defaults.conf > @@ -468,6 +468,9 @@ TODO: document the other workarounds. > > /> > > + executable="csgo_linux64"> > + > + > > > > -- > 2.20.1 > > ___ > 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 110525] [CTS] dEQP-VK.api.invariance.random crashes
https://bugs.freedesktop.org/show_bug.cgi?id=110525 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #4 from Samuel Pitoiset --- This is a CTS bug, see Gerrit #3909 (Bas sent a fix). -- 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 110526] [CTS] dEQP-VK.ycbcr.{conversion, format}.* fail
https://bugs.freedesktop.org/show_bug.cgi?id=110526 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Samuel Pitoiset --- Should be fixed with https://cgit.freedesktop.org/mesa/mesa/commit/?id=5cbe12ad1b8934c932f19070044563b9f3b9ab21 -- 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 110268] enable storageBuffer16BitAccess feature in radv for SI and CIK
https://bugs.freedesktop.org/show_bug.cgi?id=110268 Samuel Pitoiset changed: What|Removed |Added Severity|normal |enhancement -- 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 109822] Texture holes in simple vulkan examples.
https://bugs.freedesktop.org/show_bug.cgi?id=109822 Samuel Pitoiset changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #4 from Samuel Pitoiset --- Your thing doesn't build, also are you sure it's correct? $ make make -C lib make -C tri make -C 0001uniform-buffer-object make -C 0002lighting make -C 0003index-buffer make -C 0004cube make -C 0005texture make -C 0006multi-model make -C 0007shared-ubo make -C 0008multi-material make -C 0009modify-instances-count make -C 0010tasks-during-render make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/lib' g++ -I../include -c -o cimgui/cimgui/cimgui.o cimgui/cimgui/cimgui.cpp make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/tri' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/tri' make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/0004cube' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/0004cube' make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/0001uniform-buffer-object' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/0001uniform-buffer-object' make: *** [Makefile:9: tri] Error 2 make: *** Waiting for unfinished jobs make: *** [Makefile:9: 0004cube] Error 2 g++ -I../include -c -o cimgui/cimgui/fontAtlas.o cimgui/cimgui/fontAtlas.cpp make: *** [Makefile:9: 0001uniform-buffer-object] Error 2 make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/0002lighting' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/0002lighting' g++ -I../include -c -o cimgui/cimgui/drawList.o cimgui/cimgui/drawList.cpp make: *** [Makefile:9: 0002lighting] Error 2 make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/0003index-buffer' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/0003index-buffer' g++ -I../include -c -o cimgui/cimgui/listClipper.o cimgui/cimgui/listClipper.cpp make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/0005texture' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/0005texture' make: *** [Makefile:9: 0003index-buffer] Error 2 g++ -I../include -c -o cimgui/imgui/imgui.o cimgui/imgui/imgui.cpp make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/0006multi-model' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/0006multi-model' make: *** [Makefile:9: 0005texture] Error 2 make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/0007shared-ubo' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/0007shared-ubo' g++ -I../include -c -o cimgui/imgui/imgui_draw.o cimgui/imgui/imgui_draw.cpp make: *** [Makefile:9: 0006multi-model] Error 2 make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/0008multi-material' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/0008multi-material' make: *** [Makefile:9: 0007shared-ubo] Error 2 g++ -I../include -c -o cimgui/imgui/imgui_demo.o cimgui/imgui/imgui_demo.cpp make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/0009modify-instances-count' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/0009modify-instances-count' make: *** [Makefile:9: 0008multi-material] Error 2 g++ -Icimgui/imgui -I../include -c -o cimgui/imgui/examples/vulkan_example/imgui_impl_glfw_vulkan.o cimgui/imgui/examples/vulkan_example/imgui_impl_glfw_vulkan.cpp make: *** [Makefile:9: 0009modify-instances-count] Error 2 make[1]: *** No rule to make target 'imguicolortextedit/Makefile', needed by 'imguicolortextedit/libtexteditor.a'. Stop. make[1]: *** Waiting for unfinished jobs make[1]: Entering directory '/home/hakzsam/wip/cheako-vulkan/0010tasks-during-render' make[1]: *** No rule to make target '../lib/vk_mem_alloc.a', needed by 'vulkan'. Stop. make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/0010tasks-during-render' make: *** [Makefile:9: 0010tasks-during-render] Error 2 make[1]: Leaving directory '/home/hakzsam/wip/cheako-vulkan/lib' make: *** [Makefile:9: lib] Error 2 -- You
[Mesa-dev] [Bug 110603] Blocky and black opacity/alpha using RADV on some games
https://bugs.freedesktop.org/show_bug.cgi?id=110603 --- Comment #3 from Samuel Pitoiset --- Created attachment 144172 --> https://bugs.freedesktop.org/attachment.cgi?id=144172=edit screenshot Attached screenshot with: OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.27.0, 4.20.0-rc3-58450-g9698024e8a19, LLVM 8.0.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.1.0-devel (git-b98955e128) What's the problem actually? It looks good to me. (Also tried with mesa-git/llvm-git, same output) -- 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
[Mesa-dev] [Bug 110603] Blocky and black opacity/alpha using RADV on some games
https://bugs.freedesktop.org/show_bug.cgi?id=110603 --- Comment #2 from Samuel Pitoiset --- Please ignore my previous comment, you posted it already. :-) -- 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
[Mesa-dev] [Bug 102522] [radeonsi, bisected] commit 147d7fb772 causes full-window map to flash green in Crea
https://bugs.freedesktop.org/show_bug.cgi?id=102522 --- Comment #6 from Timothy Arceri --- I still can't reproduce. If you run apitrace with the following environment variable does it help? radeonsi_zerovram=true apitrace You can also launch steam and try crea directly: radeonsi_zerovram=true steam -- 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 110603] Blocky and black opacity/alpha using RADV on some games
https://bugs.freedesktop.org/show_bug.cgi?id=110603 --- Comment #1 from Samuel Pitoiset --- What LLVM/Mesa versions are you using? Can you attach the output of glxinfo (or vulkaninfo) please? -- 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] [Panfrost] [Bifrost] Add a few missing ops to disassembler
On Mon, May 6, 2019 at 1:26 AM wrote:
>
> From: Ryan Houdek
>
> Adds Round, RoundEven, and the two Trunc variants to the disassembler.
> Additionally adds two control register types that were used with these
> instructions.
>
> Signed-off-by: Ryan Houdek
> ---
> src/gallium/drivers/panfrost/bifrost/disassemble.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/gallium/drivers/panfrost/bifrost/disassemble.c
> b/src/gallium/drivers/panfrost/bifrost/disassemble.c
> index daadf257896..585f6ced107 100644
> --- a/src/gallium/drivers/panfrost/bifrost/disassemble.c
> +++ b/src/gallium/drivers/panfrost/bifrost/disassemble.c
> @@ -287,6 +287,7 @@ static struct bifrost_reg_ctrl DecodeRegCtrl(struct
> bifrost_regs regs)
> case 1:
> decoded.fma_write_unit = REG_WRITE_TWO;
> break;
> +case 2:
New modes for something as simple as an instruction that rounds seems
highly suspicious... maybe this is the 64-bit clause mode? That has an
entirely different reg ctrl, and I haven't ported the changes needed
from SPD to Mesa yet. I also can't reproduce it myself with the
offline compiler. Can you share an example where the blob uses one of
these?
> case 3:
> decoded.fma_write_unit = REG_WRITE_TWO;
> decoded.read_reg3 = true;
> @@ -318,6 +319,8 @@ static struct bifrost_reg_ctrl DecodeRegCtrl(struct
> bifrost_regs regs)
> decoded.add_write_unit = REG_WRITE_TWO;
> decoded.clause_start = true;
> break;
> +
> +case 7:
> case 15:
> decoded.fma_write_unit = REG_WRITE_THREE;
> decoded.add_write_unit = REG_WRITE_TWO;
> @@ -681,10 +684,13 @@ static const struct fma_op_info FMAOpInfos[] = {
> { 0xe0bc0, "UMAX3", FMA_THREE_SRC },
> { 0xe0c00, "IMIN3", FMA_THREE_SRC },
> { 0xe0c40, "UMIN3", FMA_THREE_SRC },
> +{ 0xe0ec5, "ROUND", FMA_ONE_SRC },
> { 0xe0f40, "CSEL", FMA_THREE_SRC }, // src2 != 0 ? src1 : src0
> { 0xe0fc0, "MUX.i32", FMA_THREE_SRC }, // see ADD comment
> +{ 0xe1805, "ROUNDEVEN", FMA_ONE_SRC },
> { 0xe1845, "CEIL", FMA_ONE_SRC },
> { 0xe1885, "FLOOR", FMA_ONE_SRC },
> +{ 0xe18c5, "TRUNC", FMA_ONE_SRC },
> { 0xe19b0, "ATAN_LDEXP.Y.f32", FMA_TWO_SRC },
> { 0xe19b8, "ATAN_LDEXP.X.f32", FMA_TWO_SRC },
> // These instructions in the FMA slot, together with
> LSHIFT_ADD_HIGH32.i32
> @@ -1177,6 +1183,7 @@ static const struct add_op_info add_op_infos[] = {
> { 0x07bc5, "FLOG_FREXPE", ADD_ONE_SRC },
> { 0x07d45, "CEIL", ADD_ONE_SRC },
> { 0x07d85, "FLOOR", ADD_ONE_SRC },
> +{ 0x07dc5, "TRUNC", ADD_ONE_SRC },
You can add to the list:
7d05 -> roundEven
although bizarrely ROUND doesn't seem to have an ADD equivalent.
> { 0x07f18, "LSHIFT_ADD_HIGH32.i32", ADD_TWO_SRC },
> { 0x08000, "LD_ATTR.f16", ADD_LOAD_ATTR, true },
> { 0x08100, "LD_ATTR.v2f16", ADD_LOAD_ATTR, true },
> --
> 2.20.1
>
> ___
> 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 29431] Nurb demos fail when callists are executed.
https://bugs.freedesktop.org/show_bug.cgi?id=29431 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Timothy Arceri --- There is no longer any error generated. Seems to have been fixed some time in the last 9 years :P -- 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
[Mesa-dev] [Bug 110350] DOOM 2016 crash + severe artifacting on RADV + Vega VII
https://bugs.freedesktop.org/show_bug.cgi?id=110350 --- Comment #11 from Samuel Pitoiset --- Thanks for confirming! -- 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 39017] [bisected] Segfault in Gallium drivers in Mupen64Plus
https://bugs.freedesktop.org/show_bug.cgi?id=39017 --- Comment #11 from Timothy Arceri --- It has been a very long time since this was reported. Can you confirm if this issue has been fixed in recent Gallium drivers? -- 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
[Mesa-dev] [Bug 81785] MESA checks on configure for llvm 3.4.2 and fails to build with 3.4.2 being installed
https://bugs.freedesktop.org/show_bug.cgi?id=81785 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #12 from Timothy Arceri --- Autotools build scripts have been removed. Please open a new bug if there is a problem with Meson -- 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
[Mesa-dev] [Bug 90908] osx: src/mesa/x86-64/xform4.S does not build
https://bugs.freedesktop.org/show_bug.cgi?id=90908 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Timothy Arceri --- Seems nobody cares to much about osx support. If you still want to land this patch, please create a merge request at: https://gitlab.freedesktop.org/mesa/mesa -- 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 89199] u_math.h:591:4: error: implicit declaration of function 'ffsll'
https://bugs.freedesktop.org/show_bug.cgi?id=89199
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Timothy Arceri ---
We now have:
#ifdef HAVE___BUILTIN_FFSLL
#define ffsll __builtin_ffsll
#elif defined(_MSC_VER) && (_M_AMD64 || _M_ARM || _M_IA64)
static inline int
ffsll(long long int i)
{
unsigned long index;
if (_BitScanForward64(, i))
return index + 1;
else
return 0;
}
#else
extern int
ffsll(long long int val);
#endif
So I'm assuming this was fixed long ago and closing.
--
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
