Re: [Mesa-dev] [PATCH 5/9] intel/compiler: relax brw_eu_validate for byte raw movs
On Tue, Jan 22, 2019 at 10:26 PM Matt Turner wrote:
> Was this just something that you noticed by inspection?
With the patch reverted I see some validation failures in
dEQP-VK.spirv_assembly.instruction.compute.8bit_storage.push_constant_8_to_16.scalar_uint
and friends.
mov(16) g10<4>B g[a0]B { align1 1H };
ERROR: Destination stride must be equal to the ratio of the sizes of
the execution data type to the destination type
Wow. I don't think I've ever seen an instruction like that before. I
can definitely see how the validator might not be equipped to handle
it.
I'll think about it some more.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/8] i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.
On 1/22/19 9:25 PM, Nanley Chery wrote: [...] > > The performance difference should be negligible if the function is > declared static inline in the intel_mipmap_tree.h header. The compiler > should include the body of function (which should be small) and avoid > the overhead of a function call. [...] > > Firstly, it's not information that's generally useful for most > intel_mipmap_tree objects. Having too much of such state makes debugging > and reading the struct definition more difficult. > > Secondly, it adds to the amount of state-dependent variables I have to > keep in mind when looking at the code. I have to start asking, when is > needs_fake_etc initialized? Is needs_fake_etc ever modified later? I'm > already familiar with the other variables needs_fake_etc can be computed > by: the gen, the miptree format, and the shadow_mt. I hope that helps. > > -Nanley > Ok, I understand, I am going to change the code to use an inline function then. Thank you very much, Eleni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/9] intel/compiler: relax brw_eu_validate for byte raw movs
On Sun, Jul 8, 2018 at 5:27 PM, Jose Maria Casanova Crespo
wrote:
> When the destination is a BYTE type allow raw movs
> even if the stride is not exact multiple of destination
> type and exec type, execution type is Word and its size is 2.
>
> This restriction was only allowing stride==2 destinations
> for 8-bit types.
Super late review, obviously... it's been on my todo list but fp64 was
taking all my time.
I can't figure this commit out. What I know:
- byte destination
- raw mov (which means destination stride == 1)
- execution type of a byte operation is "word"
The original code
> if (exec_type_size > dst_type_size) {
>ERROR_IF(dst_stride * dst_type_size != exec_type_size,
> "Destination stride must be equal to the ratio of the sizes
> of "
> "the execution data type to the destination type");
> }
would not have worked for an instruction like
> mov(8) g0<1>B g0<8,8,1>B
But, that's okay because it didn't need to since the block right above
it does this:
if (dst_type_is_byte) {
if (is_packed(exec_size * dst_stride, exec_size, dst_stride)) {
if (!inst_is_raw_move(devinfo, inst)) {
ERROR("Only raw MOV supports a packed-byte destination");
return error_msg;
} else {
return (struct string){};
}
}
}
That is, if it's a raw move, return no-error.
It would be easier to understand what you were fixing if you had added
a unit test to test_eu_validate.cpp, or (if my suspicions are correct)
it would have proven to you that this patch wasn't correct.
Was this just something that you noticed by inspection?
> Reviewed-by: Jason Ekstrand
Sigh.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109361] [KBL-G][GL-es] several shader test cases failed to compile
https://bugs.freedesktop.org/show_bug.cgi?id=109361 --- Comment #3 from Hai --- If no next step, I will mark it as won't 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 108877] OpenGL CTS gl43 test cases were interrupted due to segment fault
https://bugs.freedesktop.org/show_bug.cgi?id=108877 Hai changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 108877] OpenGL CTS gl43 test cases were interrupted due to segment fault
https://bugs.freedesktop.org/show_bug.cgi?id=108877 --- Comment #5 from Hai --- With these two patches, this issue can't reproduce. -- 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 94273] Clover on RadeonSI OpenCL segfault during testing of clBLAS
https://bugs.freedesktop.org/show_bug.cgi?id=94273 Peter changed: What|Removed |Added CC||pbrobin...@gmail.com -- 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 100105] Make Theano OpenCL support work on Clover and RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=100105 Peter changed: What|Removed |Added CC||pbrobin...@gmail.com -- 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] nir: propagate known constant values into the if-then branch
On 23/1/19 3:27 pm, Caio Marcelo de Oliveira Filho wrote:
Hi,
The different problem I've found was that uses in the phi instruction
after the then/else blocks was being replaced, causing churn in the
optimizations further on. As a hack, I've ignored phi instructions in
the use loop above. HURTs are gone and HELPs continued.
The real issue seems to be use_block not being what we expect when we
have a use_src from a phi instruction. For example, in the snippet
below
vec1 1 ssa_2543 = ieq ssa_7429, ssa_6
/* succs: block_9 block_10 */
if ssa_2543 {
block block_9:
/* preds: block_8 */
vec2 32 ssa_2550 = vec2 ssa_7744, ssa_7745
vec4 32 ssa_2553 = txl ssa_468 (texture_deref), ssa_468
(sampler_deref), ssa_2550 (coord), ssa_6 (lod),
vec1 32 ssa_7434 = imov ssa_2553.w
/* succs: block_11 */
} else {
block block_10:
/* preds: block_8 */
/* succs: block_11 */
}
block block_11:
/* preds: block_9 block_10 */
vec1 32 ssa_7433 = phi block_9: ssa_7420, block_10: ssa_7420
vec1 32 ssa_7436 = phi block_9: ssa_7434, block_10: ssa_7423
vec1 32 ssa_7439 = phi block_9: ssa_7426, block_10: ssa_7426
vec1 32 ssa_7442 = phi block_9: ssa_7429, block_10: ssa_7429
the use_src that is part of the instruction "... ssa_7442 = phi ...",
was being considered use_block == 9 (the 'then'-block), so replace was
happening.
I'm not sure I see the problem, replacing the phi src is valid. The question
is why is it causing HURT?
What happens is that the phi becomes
vec1 32 ssa_7442 = phi block_9: ssa_6, block_10: ssa_7429
instead of remaining
vec1 32 ssa_7442 = phi block_9: ssa_7429, block_10: ssa_7429
and the next pass that cause effect (in this case) is
nir_opt_remove_phis, which will not be able to remove this phi.
Further passes will still keep this phi around, and it sticks until
SSA work is done. This is the SSA form (replacing the phi, 23 NIR
instructions)
block block_11:
/* preds: block_9 block_10 */
vec1 32 ssa_127 = phi block_9: ssa_126, block_10: ssa_101
vec1 32 ssa_128 = phi block_9: ssa_0, block_10: ssa_104<
vec1 32 ssa_129 = fadd -ssa_96, ssa_122
vec1 32 ssa_130 = b32csel ssa_106, ssa_122, ssa_129
vec1 32 ssa_131 = fadd -ssa_96, ssa_127
vec1 32 ssa_132 = ine32 ssa_128, ssa_0
vec1 32 ssa_133 = b32csel ssa_132, ssa_127, ssa_131
Looks like the two above instructions and the phi could possibly be
replaced by a single phi:
vec1 32 ssa_133 = phi block_9: ssa_131, block_10: ssa_127
vec1 32 ssa_134 = fge32 abs(ssa_133), ssa_95
vec1 32 ssa_135 = b2i32 ssa_134
vec1 32 ssa_136 = imov -ssa_135
vec1 32 ssa_137 = ffma -ssa_78, ssa_6, ssa_107
vec1 32 ssa_138 = fge32 abs(ssa_130), ssa_95
vec1 32 ssa_139 = b32csel ssa_138, ssa_107, ssa_137
vec1 32 ssa_140 = ffma -ssa_79, ssa_6, ssa_109
vec1 32 ssa_141 = b32csel ssa_138, ssa_109, ssa_140
vec1 32 ssa_142 = iand ssa_134, ssa_138
vec1 32 ssa_143 = b2i32 ssa_142
vec1 32 ssa_144 = ffma ssa_78, ssa_6, ssa_113
vec1 32 ssa_145 = b32csel ssa_134, ssa_113, ssa_144
vec1 32 ssa_146 = ffma ssa_79, ssa_6, ssa_115
vec1 32 ssa_147 = b32csel ssa_134, ssa_115, ssa_146
vec1 32 ssa_148 = inot -ssa_143
vec1 32 ssa_149 = ine32 ssa_148, ssa_0
/* succs: block_12 block_37 */
compare to skipping the phi (19 NIR intructions)
block block_11:
/* preds: block_9 block_10 */
vec1 32 ssa_125 = phi block_9: ssa_124, block_10: ssa_101
vec1 32 ssa_126 = fadd -ssa_96, ssa_120
vec1 32 ssa_127 = b32csel ssa_103, ssa_120, ssa_126
vec1 32 ssa_128 = fadd -ssa_96, ssa_125
vec1 32 ssa_129 = b32csel ssa_107, ssa_125, ssa_128
vec1 32 ssa_130 = ffma -ssa_78, ssa_6, ssa_104
vec1 32 ssa_131 = fge32 abs(ssa_127), ssa_95
vec1 32 ssa_132 = b32csel ssa_131, ssa_104, ssa_130
vec1 32 ssa_133 = ffma -ssa_79, ssa_6, ssa_106
vec1 32 ssa_134 = b32csel ssa_131, ssa_106, ssa_133
vec1 32 ssa_135 = fge32 abs(ssa_129), ssa_95
vec1 32 ssa_136 = iand ssa_135, ssa_131
vec1 32 ssa_137 = b2i32 ssa_136
vec1 32 ssa_138 = ffma ssa_78, ssa_6, ssa_111
vec1 32 ssa_139 = b32csel ssa_135, ssa_111, ssa_138
vec1 32 ssa_140 = ffma ssa_79, ssa_6, ssa_113
vec1 32 ssa_141 = b32csel ssa_135, ssa_113, ssa_140
vec1 32 ssa_142 = inot -ssa_137
vec1 32 ssa_143 = ine32 ssa_142, ssa_0
/* succs: block_12 block_37 */
There could be other interactions preventing it to get rid of that I'm
missing. But I think a good approach here could be: if there's
another source in the phi that is the same as the one being replaced,
just skip it since it would prevent the phi being directly removed.
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedeskto
[Mesa-dev] [Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 Julien Isorce changed: What|Removed |Added CC||julien.iso...@gmail.com -- 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 109334] OpenGL-OpenCL interop support
https://bugs.freedesktop.org/show_bug.cgi?id=109334 Peter changed: What|Removed |Added CC||pbrobin...@gmail.com -- 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 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 Peter changed: What|Removed |Added CC||pbrobin...@gmail.com -- 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] nir: propagate known constant values into the if-then branch
Hi,
> > The different problem I've found was that uses in the phi instruction
> > after the then/else blocks was being replaced, causing churn in the
> > optimizations further on. As a hack, I've ignored phi instructions in
> > the use loop above. HURTs are gone and HELPs continued.
> >
> > The real issue seems to be use_block not being what we expect when we
> > have a use_src from a phi instruction. For example, in the snippet
> > below
> >
> > vec1 1 ssa_2543 = ieq ssa_7429, ssa_6
> > /* succs: block_9 block_10 */
> > if ssa_2543 {
> > block block_9:
> > /* preds: block_8 */
> > vec2 32 ssa_2550 = vec2 ssa_7744, ssa_7745
> > vec4 32 ssa_2553 = txl ssa_468 (texture_deref), ssa_468
> > (sampler_deref), ssa_2550 (coord), ssa_6 (lod),
> > vec1 32 ssa_7434 = imov ssa_2553.w
> > /* succs: block_11 */
> > } else {
> > block block_10:
> > /* preds: block_8 */
> > /* succs: block_11 */
> > }
> > block block_11:
> > /* preds: block_9 block_10 */
> > vec1 32 ssa_7433 = phi block_9: ssa_7420, block_10: ssa_7420
> > vec1 32 ssa_7436 = phi block_9: ssa_7434, block_10: ssa_7423
> > vec1 32 ssa_7439 = phi block_9: ssa_7426, block_10: ssa_7426
> > vec1 32 ssa_7442 = phi block_9: ssa_7429, block_10: ssa_7429
> >
> > the use_src that is part of the instruction "... ssa_7442 = phi ...",
> > was being considered use_block == 9 (the 'then'-block), so replace was
> > happening.
>
> I'm not sure I see the problem, replacing the phi src is valid. The question
> is why is it causing HURT?
What happens is that the phi becomes
vec1 32 ssa_7442 = phi block_9: ssa_6, block_10: ssa_7429
instead of remaining
vec1 32 ssa_7442 = phi block_9: ssa_7429, block_10: ssa_7429
and the next pass that cause effect (in this case) is
nir_opt_remove_phis, which will not be able to remove this phi.
Further passes will still keep this phi around, and it sticks until
SSA work is done. This is the SSA form (replacing the phi, 23 NIR
instructions)
block block_11:
/* preds: block_9 block_10 */
vec1 32 ssa_127 = phi block_9: ssa_126, block_10: ssa_101
vec1 32 ssa_128 = phi block_9: ssa_0, block_10: ssa_104<
vec1 32 ssa_129 = fadd -ssa_96, ssa_122
vec1 32 ssa_130 = b32csel ssa_106, ssa_122, ssa_129
vec1 32 ssa_131 = fadd -ssa_96, ssa_127
vec1 32 ssa_132 = ine32 ssa_128, ssa_0
vec1 32 ssa_133 = b32csel ssa_132, ssa_127, ssa_131
vec1 32 ssa_134 = fge32 abs(ssa_133), ssa_95
vec1 32 ssa_135 = b2i32 ssa_134
vec1 32 ssa_136 = imov -ssa_135
vec1 32 ssa_137 = ffma -ssa_78, ssa_6, ssa_107
vec1 32 ssa_138 = fge32 abs(ssa_130), ssa_95
vec1 32 ssa_139 = b32csel ssa_138, ssa_107, ssa_137
vec1 32 ssa_140 = ffma -ssa_79, ssa_6, ssa_109
vec1 32 ssa_141 = b32csel ssa_138, ssa_109, ssa_140
vec1 32 ssa_142 = iand ssa_134, ssa_138
vec1 32 ssa_143 = b2i32 ssa_142
vec1 32 ssa_144 = ffma ssa_78, ssa_6, ssa_113
vec1 32 ssa_145 = b32csel ssa_134, ssa_113, ssa_144
vec1 32 ssa_146 = ffma ssa_79, ssa_6, ssa_115
vec1 32 ssa_147 = b32csel ssa_134, ssa_115, ssa_146
vec1 32 ssa_148 = inot -ssa_143
vec1 32 ssa_149 = ine32 ssa_148, ssa_0
/* succs: block_12 block_37 */
compare to skipping the phi (19 NIR intructions)
block block_11:
/* preds: block_9 block_10 */
vec1 32 ssa_125 = phi block_9: ssa_124, block_10: ssa_101
vec1 32 ssa_126 = fadd -ssa_96, ssa_120
vec1 32 ssa_127 = b32csel ssa_103, ssa_120, ssa_126
vec1 32 ssa_128 = fadd -ssa_96, ssa_125
vec1 32 ssa_129 = b32csel ssa_107, ssa_125, ssa_128
vec1 32 ssa_130 = ffma -ssa_78, ssa_6, ssa_104
vec1 32 ssa_131 = fge32 abs(ssa_127), ssa_95
vec1 32 ssa_132 = b32csel ssa_131, ssa_104, ssa_130
vec1 32 ssa_133 = ffma -ssa_79, ssa_6, ssa_106
vec1 32 ssa_134 = b32csel ssa_131, ssa_106, ssa_133
vec1 32 ssa_135 = fge32 abs(ssa_129), ssa_95
vec1 32 ssa_136 = iand ssa_135, ssa_131
vec1 32 ssa_137 = b2i32 ssa_136
vec1 32 ssa_138 = ffma ssa_78, ssa_6, ssa_111
vec1 32 ssa_139 = b32csel ssa_135, ssa_111, ssa_138
vec1 32 ssa_140 = ffma ssa_79, ssa_6, ssa_113
vec1 32 ssa_141 = b32csel ssa_135, ssa_113, ssa_140
vec1 32 ssa_142 = inot -ssa_137
vec1 32 ssa_143 = ine32 ssa_142, ssa_0
/* succs: block_12 block_37 */
There could be other interactions preventing it to get rid of that I'm
missing. But I think a good approach here could be: if there's
another source in the phi that is the same as the one being replaced,
just skip it since it would prevent the phi being directly removed.
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nvc0: don't put text segment into bufctx
The text segment is shared among multiple contexts, while each one has
its own bufctx. So when reallocating the text segment, some contexts may
end up with stale values in their bufctx's. Instead limit the exposure
to the bufctx to within a single draw.
Signed-off-by: Ilia Mirkin
---
nv50 doesn't resize its code segment. Karol -- this is slightly
different than the patch you tested earlier.
src/gallium/drivers/nouveau/nvc0/nvc0_compute.c | 5 -
src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 2 --
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 10 --
src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 3 +++
src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 5 +
src/gallium/drivers/nouveau/nvc0/nve4_compute.c | 3 +++
6 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
index 4963493877b..1bd1732c8d5 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
@@ -423,6 +423,7 @@ void
nvc0_launch_grid(struct pipe_context *pipe, const struct pipe_grid_info *info)
{
struct nvc0_context *nvc0 = nvc0_context(pipe);
+ struct nvc0_screen *screen = nvc0->screen;
struct nouveau_pushbuf *push = nvc0->base.pushbuf;
struct nvc0_program *cp = nvc0->compprog;
int ret;
@@ -463,12 +464,14 @@ nvc0_launch_grid(struct pipe_context *pipe, const struct
pipe_grid_info *info)
PUSH_DATA (push, (info->block[1] << 16) | info->block[0]);
PUSH_DATA (push, info->block[2]);
+ nouveau_pushbuf_space(push, 16, 2, 1);
+ PUSH_REFN(push, screen->text, NV_VRAM_DOMAIN(&screen->base) |
NOUVEAU_BO_RD);
+
if (unlikely(info->indirect)) {
struct nv04_resource *res = nv04_resource(info->indirect);
uint32_t offset = res->offset + info->indirect_offset;
unsigned macro = NVC0_CP_MACRO_LAUNCH_GRID_INDIRECT;
- nouveau_pushbuf_space(push, 16, 0, 1);
PUSH_REFN(push, res->bo, NOUVEAU_BO_RD | res->domain);
PUSH_DATA(push, NVC0_FIFO_PKHDR_1I(1, macro, 3));
nouveau_pushbuf_data(push, res->bo, offset,
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index 08ca0a204d3..356016c7225 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -449,11 +449,9 @@ nvc0_create(struct pipe_screen *pscreen, void *priv,
unsigned ctxflags)
flags = NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RD;
- BCTX_REFN_bo(nvc0->bufctx_3d, 3D_TEXT, flags, screen->text);
BCTX_REFN_bo(nvc0->bufctx_3d, 3D_SCREEN, flags, screen->uniform_bo);
BCTX_REFN_bo(nvc0->bufctx_3d, 3D_SCREEN, flags, screen->txc);
if (screen->compute) {
- BCTX_REFN_bo(nvc0->bufctx_cp, CP_TEXT, flags, screen->text);
BCTX_REFN_bo(nvc0->bufctx_cp, CP_SCREEN, flags, screen->uniform_bo);
BCTX_REFN_bo(nvc0->bufctx_cp, CP_SCREEN, flags, screen->txc);
}
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index 57d98753f45..1bbfa4a9428 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
@@ -831,16 +831,6 @@ nvc0_program_upload(struct nvc0_context *nvc0, struct
nvc0_program *prog)
NOUVEAU_ERR("Error allocating TEXT area: %d\n", ret);
return false;
}
- nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_TEXT);
- BCTX_REFN_bo(nvc0->bufctx_3d, 3D_TEXT,
- NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RD,
- screen->text);
- if (screen->compute) {
-nouveau_bufctx_reset(nvc0->bufctx_cp, NVC0_BIND_CP_TEXT);
-BCTX_REFN_bo(nvc0->bufctx_cp, CP_TEXT,
- NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RD,
- screen->text);
- }
/* Re-upload the builtin function into the new code segment. */
nvc0_program_library_upload(nvc0);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index ccfe7ffb18b..c4d64c134c1 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
@@ -1178,6 +1178,7 @@ nvc0_blitctx_post_blit(struct nvc0_blitctx *blit)
nvc0->cond_cond, nvc0->cond_mode);
nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_VTX_TMP);
+ nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_TEXT);
nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_FB);
nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_TEX(4, 0));
nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_TEX(4, 1));
@@ -1301,6 +1302,8 @@ nvc0_blit_3d(struct nvc0_context *nvc0, const struct
pipe_blit_info *info)
BCTX_REFN_bo(nvc0->bufctx_3d, 3D_VTX_TMP,
[Mesa-dev] [PATCH] ac/nir_to_llvm: fix clamp shadow reference for more hardware
Fixes the following piglit test on my VEGA and matches the behaviour in the
tgsi backend.
tests/spec/glsl-1.10/execution/samplers/glsl-fs-shadow2D-clamp-z.shader_test
Fixes: 625dcbbc4566 ("amd/common: pass address components individually to
ac_build_image_intrinsic")
---
src/amd/common/ac_nir_to_llvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index f509fc31df..b60ef86986 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3586,7 +3586,7 @@ static void visit_tex(struct ac_nir_context *ctx,
nir_tex_instr *instr)
* It's unnecessary if the original texture format was
* Z32_FLOAT, but we don't know that here.
*/
- if (args.compare && ctx->ac.chip_class == VI &&
ctx->abi->clamp_shadow_reference)
+ if (args.compare && ctx->ac.chip_class >= VI &&
ctx->abi->clamp_shadow_reference)
args.compare = ac_build_clamp(&ctx->ac, ac_to_float(&ctx->ac,
args.compare));
/* pack derivatives */
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109258] Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1
https://bugs.freedesktop.org/show_bug.cgi?id=109258 --- Comment #7 from Daniel van Vugt --- > This revert makes Mesa ignore LIBGL_ALWAYS_SOFTWARE for the drm (and android) > platforms. That might be what it looks like, but as I understand it the opposite is true... The bug being fixed here is that Mesa is already ignoring LIBGL_ALWAYS_SOFTWARE right now. I recall it used to work a few years ago, but at present LIBGL_ALWAYS_SOFTWARE is being ignored. I'm not saying that 'Options.ForceSoftware' was how it used to work, I don't know. But for certain LIBGL_ALWAYS_SOFTWARE=1 did used to work on DRM because I used to use it in Mir server development. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: propagate known constant values into the if-then branch
On 23/1/19 11:27 am, Caio Marcelo de Oliveira Filho wrote:
Hi,
Did you look at any of the HURT? The problem I was seeing was this could end
up stopping copy propagation from working on some UBOs etc.
They were not UBO cases like yours, but looking at them I've found a
different problem.
However with this patch we end up with:
load UBO at offset offset_a;
if (offset_a == 10) {
load UBO at offset 10;
...
}
copy prop no longer recognizes that we are reusing the same UBO and reloads
it again.
Note that: when/if we keep derefs for UBOs longer enough to let
nir_opt_copy_prop_vars act on them, this won't be a problem as we
perform those propagations. I'm not sure you are doing the same,
though.
See also
https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/nir-ssbo-opt
-- in particular the last few patches.
+static bool
+opt_for_known_values(nir_builder *b, nir_if *nif)
+{
+ bool progress = false;
Turns out we need this one...
+ assert(nif->condition.is_ssa);
+ nir_ssa_def *if_cond = nif->condition.ssa;
+
+ if (if_cond->parent_instr->type != nir_instr_type_alu)
+ return false;
+
+ nir_alu_instr *alu = nir_instr_as_alu(if_cond->parent_instr);
+ switch (alu->op) {
+ case nir_op_feq:
+ case nir_op_ieq: {
+ nir_load_const_instr *load_const = NULL;
+ nir_ssa_def *unknown_val = NULL;
+
+ nir_ssa_def *src0 = alu->src[0].src.ssa;
+ nir_ssa_def *src1 = alu->src[1].src.ssa;
+ if (src0a->parent_instr->type == nir_instr_type_load_const) {
+ load_const = nir_instr_as_load_const(src0->parent_instr);
+ unknown_val = src1;
+ } else if (src1->parent_instr->type == nir_instr_type_load_const) {
+ load_const = nir_instr_as_load_const(src1->parent_instr);
+ unknown_val = src0;
+ }
+
+ if (!load_const)
+return false;
+
+ /* TODO: remove this and support swizzles? */
+ if (unknown_val->num_components != 1)
+return false;
+
+ /* Replace unknown ssa uses with the known constant */
+ nir_foreach_use_safe(use_src, unknown_val) {
+ nir_cursor cursor = nir_before_src(use_src, false);
+ nir_block *use_block = nir_cursor_current_block(cursor);
+ if (nir_block_dominates(nir_if_first_then_block(nif), use_block)) {
+nir_instr_rewrite_src(use_src->parent_instr, use_src,
+ nir_src_for_ssa(&load_const->def));
+return true;
...but we are returning too early here. This should be "progress =
true;" instead of the return, otherwise we just replace a single use.
Then fix the final return to "return progress;".
Ah yes. Good catch.
The different problem I've found was that uses in the phi instruction
after the then/else blocks was being replaced, causing churn in the
optimizations further on. As a hack, I've ignored phi instructions in
the use loop above. HURTs are gone and HELPs continued.
The real issue seems to be use_block not being what we expect when we
have a use_src from a phi instruction. For example, in the snippet
below
vec1 1 ssa_2543 = ieq ssa_7429, ssa_6
/* succs: block_9 block_10 */
if ssa_2543 {
block block_9:
/* preds: block_8 */
vec2 32 ssa_2550 = vec2 ssa_7744, ssa_7745
vec4 32 ssa_2553 = txl ssa_468 (texture_deref), ssa_468
(sampler_deref), ssa_2550 (coord), ssa_6 (lod),
vec1 32 ssa_7434 = imov ssa_2553.w
/* succs: block_11 */
} else {
block block_10:
/* preds: block_8 */
/* succs: block_11 */
}
block block_11:
/* preds: block_9 block_10 */
vec1 32 ssa_7433 = phi block_9: ssa_7420, block_10: ssa_7420
vec1 32 ssa_7436 = phi block_9: ssa_7434, block_10: ssa_7423
vec1 32 ssa_7439 = phi block_9: ssa_7426, block_10: ssa_7426
vec1 32 ssa_7442 = phi block_9: ssa_7429, block_10: ssa_7429
the use_src that is part of the instruction "... ssa_7442 = phi ...",
was being considered use_block == 9 (the 'then'-block), so replace was
happening.
I'm not sure I see the problem, replacing the phi src is valid. The
question is why is it causing HURT?
Unless I'm missing something, replacing nir_before_src /
nir_cursor_current_block with use_src->parent_instr->block is what we
want here.
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] gallivm: Return true from arch_rounding_available() if NEON is available
I have no clue on aarch64, but looks all good to me.
For the series:
Reviewed-by: Roland Scheidegger
Am 23.01.19 um 00:12 schrieb Matt Turner:
> LLVM uses the single instruction "FRINTI" to implement llvm.nearbyint.
> Fixes the rounding tests of lp_test_arit.
>
> Bug:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.gentoo.org%2F665570&data=02%7C01%7Csroland%40vmware.com%7C3592bd2ab3a14996f0b208d680bf1f90%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636837955687364906&sdata=N0br4dLkbNwWMj4H%2FEq3VSYHUCmkLcJZAxAFId4jClQ%3D&reserved=0
> ---
> src/gallium/auxiliary/gallivm/lp_bld_arit.c | 4 +++-
> src/gallium/drivers/llvmpipe/lp_test_arit.c | 3 ++-
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> index c050bfdb936..057c50ed278 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> @@ -1992,6 +1992,8 @@ arch_rounding_available(const struct lp_type type)
> else if ((util_cpu_caps.has_altivec &&
> (type.width == 32 && type.length == 4)))
>return TRUE;
> + else if (util_cpu_caps.has_neon)
> + return TRUE;
>
> return FALSE;
> }
> @@ -2099,7 +2101,7 @@ lp_build_round_arch(struct lp_build_context *bld,
> LLVMValueRef a,
> enum lp_build_round_mode mode)
> {
> - if (util_cpu_caps.has_sse4_1) {
> + if (util_cpu_caps.has_sse4_1 || util_cpu_caps.has_neon) {
>LLVMBuilderRef builder = bld->gallivm->builder;
>const struct lp_type type = bld->type;
>const char *intrinsic_root;
> diff --git a/src/gallium/drivers/llvmpipe/lp_test_arit.c
> b/src/gallium/drivers/llvmpipe/lp_test_arit.c
> index acba7ed44a8..eb3f67dc1fe 100644
> --- a/src/gallium/drivers/llvmpipe/lp_test_arit.c
> +++ b/src/gallium/drivers/llvmpipe/lp_test_arit.c
> @@ -458,7 +458,8 @@ test_unary(unsigned verbose, FILE *fp, const struct
> unary_test_t *test, unsigned
> continue;
> }
>
> - if (test->ref == &nearbyintf && length == 2 &&
> + if (!util_cpu_caps.has_neon &&
> + test->ref == &nearbyintf && length == 2 &&
> ref != roundf(testval)) {
> /* FIXME: The generic (non SSE) path in lp_build_iround, which is
> * always taken for length==2 regardless of native round support,
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 24/42] intel/compiler: fix ddy for half-float in gen8
On Tue, Jan 15, 2019 at 5:54 AM Iago Toral Quiroga wrote:
>
> We use ALign16 mode for this, since it is more convenient, but the PRM
> for Broadwell states in Volume 3D Media GPGPU, Chapter 'Register region
> restrictions', Section '1. Special Restrictions':
>
>"In Align16 mode, the channel selects and channel enables apply to a
> pair of half-floats, because these parameters are defined for DWord
> elements ONLY. This is applicable when both source and destination
> are half-floats."
>
> This means that we cannot select individual HF elements using swizzles
> like we do with 32-bit floats so we can't implement the required
> regioning for this.
>
> Use the gen11 path for this instead, which uses Align1 mode.
>
> The restriction is not present in gen9 or gen10, where the Align16
> implementation seems to work just fine.
>
> Reviewed-by: Jason Ekstrand
> ---
> src/intel/compiler/brw_fs_generator.cpp | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_generator.cpp
> b/src/intel/compiler/brw_fs_generator.cpp
> index d0cc4a6d231..4310f0b7fdc 100644
> --- a/src/intel/compiler/brw_fs_generator.cpp
> +++ b/src/intel/compiler/brw_fs_generator.cpp
> @@ -1339,8 +1339,14 @@ fs_generator::generate_ddy(const fs_inst *inst,
> const uint32_t type_size = type_sz(src.type);
>
> if (inst->opcode == FS_OPCODE_DDY_FINE) {
> - /* produce accurate derivatives */
> - if (devinfo->gen >= 11) {
> + /* produce accurate derivatives. We can do this easily in Align16
> + * but this is not supported in gen11+ and gen8 Align16 swizzles
> + * for Half-Float operands work in units of 32-bit and always
> + * select pairs of consecutive half-float elements, so we can't use
> + * use it for this.
> + */
Let's break this comment up and include (or move) the BSpec text from
the commit message here. I wouldn't mention the "this is not supported
in gen11+" because it's slightly unclear whether you're talking about
"accurate derivatives" or "Align16". How about:
/* produce accurate derivatives.
*
* From the Broadwell PRM, Volume 7 (3D-Media-GPGPU)
* "Register Region Restrictions", Section "1. Special Restrictions":
*
*"In Align16 mode, the channel selects and channel enables apply to
* a pair of half-floats, because these parameters are defined for
* DWord elements ONLY. This is applicable when both source and
* destination are half-floats."
*
* So for half-float operations we use the Gen11+ Align1 path. CHV
* inherits its FP16 hardware from SKL, so it is not affected.
*/
> + if (devinfo->gen >= 11 ||
> + (devinfo->gen == 8 && src.type == BRW_REGISTER_TYPE_HF)) {
The docs are bad about telling us whether a BDW restriction applies to
CHV as well, but in this case I suspect the answer is no. CHV seems to
inherit its FP16 hw from SKL, which doesn't have the restriction as
you say.
So I suspect you want devinfo->is_broadwell instead of devinfo->gen == 8.
With that (and confirmation that CHV isn't affected), this patch is
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: propagate known constant values into the if-then branch
Hi,
> Did you look at any of the HURT? The problem I was seeing was this could end
> up stopping copy propagation from working on some UBOs etc.
They were not UBO cases like yours, but looking at them I've found a
different problem.
> However with this patch we end up with:
>
> load UBO at offset offset_a;
>
> if (offset_a == 10) {
>load UBO at offset 10;
>...
> }
>
> copy prop no longer recognizes that we are reusing the same UBO and reloads
> it again.
Note that: when/if we keep derefs for UBOs longer enough to let
nir_opt_copy_prop_vars act on them, this won't be a problem as we
perform those propagations. I'm not sure you are doing the same,
though.
See also
https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/nir-ssbo-opt
-- in particular the last few patches.
> +static bool
> +opt_for_known_values(nir_builder *b, nir_if *nif)
> +{
> + bool progress = false;
Turns out we need this one...
> + assert(nif->condition.is_ssa);
> + nir_ssa_def *if_cond = nif->condition.ssa;
> +
> + if (if_cond->parent_instr->type != nir_instr_type_alu)
> + return false;
> +
> + nir_alu_instr *alu = nir_instr_as_alu(if_cond->parent_instr);
> + switch (alu->op) {
> + case nir_op_feq:
> + case nir_op_ieq: {
> + nir_load_const_instr *load_const = NULL;
> + nir_ssa_def *unknown_val = NULL;
> +
> + nir_ssa_def *src0 = alu->src[0].src.ssa;
> + nir_ssa_def *src1 = alu->src[1].src.ssa;
> + if (src0a->parent_instr->type == nir_instr_type_load_const) {
> + load_const = nir_instr_as_load_const(src0->parent_instr);
> + unknown_val = src1;
> + } else if (src1->parent_instr->type == nir_instr_type_load_const) {
> + load_const = nir_instr_as_load_const(src1->parent_instr);
> + unknown_val = src0;
> + }
> +
> + if (!load_const)
> +return false;
> +
> + /* TODO: remove this and support swizzles? */
> + if (unknown_val->num_components != 1)
> +return false;
> +
> + /* Replace unknown ssa uses with the known constant */
> + nir_foreach_use_safe(use_src, unknown_val) {
> + nir_cursor cursor = nir_before_src(use_src, false);
> + nir_block *use_block = nir_cursor_current_block(cursor);
> + if (nir_block_dominates(nir_if_first_then_block(nif), use_block)) {
> +nir_instr_rewrite_src(use_src->parent_instr, use_src,
> + nir_src_for_ssa(&load_const->def));
> +return true;
...but we are returning too early here. This should be "progress =
true;" instead of the return, otherwise we just replace a single use.
Then fix the final return to "return progress;".
The different problem I've found was that uses in the phi instruction
after the then/else blocks was being replaced, causing churn in the
optimizations further on. As a hack, I've ignored phi instructions in
the use loop above. HURTs are gone and HELPs continued.
The real issue seems to be use_block not being what we expect when we
have a use_src from a phi instruction. For example, in the snippet
below
vec1 1 ssa_2543 = ieq ssa_7429, ssa_6
/* succs: block_9 block_10 */
if ssa_2543 {
block block_9:
/* preds: block_8 */
vec2 32 ssa_2550 = vec2 ssa_7744, ssa_7745
vec4 32 ssa_2553 = txl ssa_468 (texture_deref), ssa_468
(sampler_deref), ssa_2550 (coord), ssa_6 (lod),
vec1 32 ssa_7434 = imov ssa_2553.w
/* succs: block_11 */
} else {
block block_10:
/* preds: block_8 */
/* succs: block_11 */
}
block block_11:
/* preds: block_9 block_10 */
vec1 32 ssa_7433 = phi block_9: ssa_7420, block_10: ssa_7420
vec1 32 ssa_7436 = phi block_9: ssa_7434, block_10: ssa_7423
vec1 32 ssa_7439 = phi block_9: ssa_7426, block_10: ssa_7426
vec1 32 ssa_7442 = phi block_9: ssa_7429, block_10: ssa_7429
the use_src that is part of the instruction "... ssa_7442 = phi ...",
was being considered use_block == 9 (the 'then'-block), so replace was
happening.
Unless I'm missing something, replacing nir_before_src /
nir_cursor_current_block with use_src->parent_instr->block is what we
want here.
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 23/42] intel/compiler: fix ddx and ddy for 16-bit float
Obviously you cannot test the Gen11 code, but it looks believable. Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 22/42] intel/compiler: don't propagate HF immediates to 3-src instructions
On Tue, Jan 15, 2019 at 5:54 AM Iago Toral Quiroga wrote: > > 3-src instructions don't support immediates, but since 36bc5f06dd22, > we allow them on MAD and LRP relying on the combine constants pass to > fix it up later. However, that pass is specialized for 32-bit float > immediates and can't handle HF constants at present, so this patch > ensures that copy-propagation only does this for 32-bit constants. There's a patch later in the series that adds HF support to constant combining (and presumably removes this code). Maybe it's the best thing to add and remove the code in the same series, but it's good to at least mention that in the commit message so that reviewers understand what the plan is. I see from a later thread that you're going to try to handle more than just F/HF types in constant combining, and I guess you'll resend this series. If that's the case, I'd just leave this patch out if it's possible to reorder things. Oh, another thing: Gen10+ can take *1* immediate HF argument in 3-src instructions. We haven't added that support yet, though all the low-level brw_inst_* functions exist. Not asking you to do that without hardware, but just thought you'd be interested to know :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 21/42] intel/compiler: set correct precision fields for 3-source float instructions
On Thu, Jan 17, 2019 at 12:18 PM Jason Ekstrand wrote: > > On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga wrote: >> >> Source0 and Destination extract the floating-point precision automatically >> from the SrcType and DstType instruction fields respectively when they are >> set to types :F or :HF. For Source1 and Source2 operands, we use the new >> 1-bit fields Src1Type and Src2Type, where 0 means normal precision and 1 >> means half-precision. Since we always use the type of the destination for >> all operands when we emit 3-source instructions, we only need set Src1Type >> and Src2Type to 1 when we are emitting a half-precision instruction. >> >> v2: >> - Set the bit separately for each source based on its type so we can >>do mixed floating-point mode in the future (Topi). >> >> Reviewed-by: Topi Pohjolainen >> --- >> src/intel/compiler/brw_eu_emit.c | 16 >> 1 file changed, 16 insertions(+) >> >> diff --git a/src/intel/compiler/brw_eu_emit.c >> b/src/intel/compiler/brw_eu_emit.c >> index a785f96b650..2fa89f8a2a3 100644 >> --- a/src/intel/compiler/brw_eu_emit.c >> +++ b/src/intel/compiler/brw_eu_emit.c >> @@ -801,6 +801,22 @@ brw_alu3(struct brw_codegen *p, unsigned opcode, struct >> brw_reg dest, >>*/ >> brw_inst_set_3src_a16_src_type(devinfo, inst, dest.type); >> brw_inst_set_3src_a16_dst_type(devinfo, inst, dest.type); >> + >> + /* From the Bspec: Instruction types >> + * >> + * Three source instructions can use operands with mixed-mode >> + * precision. When SrcType field is set to :f or :hf it defines >> + * precision for source 0 only, and fields Src1Type and Src2Type >> + * define precision for other source operands: >> + * >> + * 0b = :f. Single precision Float (32-bit). >> + * 1b = :hf. Half precision Float (16-bit). >> + */ I'd put this in our typical block-quote style. >> + if (src1.type == BRW_REGISTER_TYPE_HF) >> +brw_inst_set_3src_a16_src1_type(devinfo, inst, 1); > > > Maybe worth throwing in an > > assert(src0.type == BRW_REGISTER_TYPE_F || src0.type == BRW_REGISTER_TYPE_HF); Please don't. Stuff like this should go in brw_eu_validate.c. If you add asserts to the emission code, it'll assert fail when you write a negative test for brw_eu_validate.c. The code as-is is Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 20/42] intel/compiler: allow half-float on 3-source instructions since gen8
Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 19/42] intel/compiler: don't compact 3-src instructions with Src1Type or Src2Type bits
On Tue, Jan 15, 2019 at 5:55 AM Iago Toral Quiroga wrote: > > We are now using these bits, so don't assert that they are not set, just > avoid compaction in that case. > > Reviewed-by: Topi Pohjolainen > --- > src/intel/compiler/brw_eu_compact.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/src/intel/compiler/brw_eu_compact.c > b/src/intel/compiler/brw_eu_compact.c > index ae14ef10ec0..20fed254331 100644 > --- a/src/intel/compiler/brw_eu_compact.c > +++ b/src/intel/compiler/brw_eu_compact.c > @@ -928,8 +928,11 @@ has_3src_unmapped_bits(const struct gen_device_info > *devinfo, >assert(!brw_inst_bits(src, 127, 126) && > !brw_inst_bits(src, 105, 105) && > !brw_inst_bits(src, 84, 84) && > - !brw_inst_bits(src, 36, 35) && > !brw_inst_bits(src, 7, 7)); > + > + /* Src1Type and Src2Type, used for mixed-precision floating point */ > + if (brw_inst_bits(src, 36, 35)) > + return true; > } These bits are used on SKL+ and CHV (which is handled immediately above this hunk), so this is only modifying BDW. All looks correct to me. Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 17/42] intel/compiler: add new half-float register type for 3-src instructions
On Tue, Jan 15, 2019 at 5:55 AM Iago Toral Quiroga wrote:
>
> This is available since gen8.
>
> v2: restore previously existing assertion.
>
> Reviewed-by: Topi Pohjolainen (v1)
> ---
> src/intel/compiler/brw_reg_type.c | 36 +++
> 1 file changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/compiler/brw_reg_type.c
> b/src/intel/compiler/brw_reg_type.c
> index 60240ba1513..09b3ea61d4c 100644
> --- a/src/intel/compiler/brw_reg_type.c
> +++ b/src/intel/compiler/brw_reg_type.c
> @@ -138,6 +138,7 @@ enum hw_3src_reg_type {
> GEN7_3SRC_TYPE_D = 1,
> GEN7_3SRC_TYPE_UD = 2,
> GEN7_3SRC_TYPE_DF = 3,
> + GEN8_3SRC_TYPE_HF = 4,
>
> /** When ExecutionDatatype is 1: @{ */
> GEN10_ALIGN1_3SRC_REG_TYPE_HF = 0b000,
> @@ -166,6 +167,14 @@ static const struct hw_3src_type {
> [BRW_REGISTER_TYPE_D] = { GEN7_3SRC_TYPE_D },
> [BRW_REGISTER_TYPE_UD] = { GEN7_3SRC_TYPE_UD },
> [BRW_REGISTER_TYPE_DF] = { GEN7_3SRC_TYPE_DF },
> +}, gen8_hw_3src_type[] = {
> + [0 ... BRW_REGISTER_TYPE_LAST] = { INVALID },
> +
> + [BRW_REGISTER_TYPE_F] = { GEN7_3SRC_TYPE_F },
> + [BRW_REGISTER_TYPE_D] = { GEN7_3SRC_TYPE_D },
> + [BRW_REGISTER_TYPE_UD] = { GEN7_3SRC_TYPE_UD },
> + [BRW_REGISTER_TYPE_DF] = { GEN7_3SRC_TYPE_DF },
> + [BRW_REGISTER_TYPE_HF] = { GEN8_3SRC_TYPE_HF },
> }, gen10_hw_3src_align1_type[] = {
> #define E(x) BRW_ALIGN1_3SRC_EXEC_TYPE_##x
> [0 ... BRW_REGISTER_TYPE_LAST] = { INVALID },
> @@ -249,6 +258,20 @@ brw_hw_type_to_reg_type(const struct gen_device_info
> *devinfo,
> unreachable("not reached");
> }
>
> +static inline const struct hw_3src_type *
> +get_hw_3src_type_map(const struct gen_device_info *devinfo, uint32_t *size)
> +{
> + if (devinfo->gen < 8) {
> + if (size)
> + *size = ARRAY_SIZE(gen7_hw_3src_type);
> + return gen7_hw_3src_type;
> + } else {
> + if (size)
> + *size = ARRAY_SIZE(gen8_hw_3src_type);
> + return gen8_hw_3src_type;
> + }
> +}
I would rather inline this code and remove the function, like we
already do for example:
const struct hw_type *table;
if (devinfo->gen >= 11) {
assert(type < ARRAY_SIZE(gen11_hw_type));
table = gen11_hw_type;
} else {
assert(type < ARRAY_SIZE(gen4_hw_type));
table = gen4_hw_type;
}
But I'm not even sure that separate gen7 vs gen8 tables are required,
since gen8 just adds one additional value. I thought we had some code
that essentially did assert(devinfo->gen >= 8 || type !=
BRW_REGISTER_TYPE_HF), but I don't see it now.
We have checks that Q/UQ/DF are only used when 64-bit hw support is
available, so maybe that's what I'm thinking of.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: Reset default flag register in brw_find_live_channel()
On Tue, Jan 22, 2019 at 3:25 PM Francisco Jerez wrote: > > Matt Turner writes: > > > emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its > > flag_subreg set, so that the IR knows which flag is accessed. However > > the flag is only used on Gen7 in Align1 mode. > > > > To avoid setting unnecessary bits in the instruction words, get the > > information we need and reset the default flag register. This allows > > round-tripping through the assembler/disassembler. > > --- > > src/intel/compiler/brw_eu_emit.c | 12 ++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/src/intel/compiler/brw_eu_emit.c > > b/src/intel/compiler/brw_eu_emit.c > > index 45e2552783b..7c5b40af3ae 100644 > > --- a/src/intel/compiler/brw_eu_emit.c > > +++ b/src/intel/compiler/brw_eu_emit.c > > @@ -3312,6 +3312,13 @@ brw_find_live_channel(struct brw_codegen *p, struct > > brw_reg dst, > > > > brw_push_insn_state(p); > > > > + /* The flag register is only used on Gen7 in align1 mode, so avoid > > setting > > +* unnecessary bits in the instruction words, get the information we > > need > > +* and reset the default flag register. > > Maybe mention here that this also allows more instructions to be > compacted. Looks good otherwise: > > Reviewed-by: Francisco Jerez Sure, will do. Thanks Curro! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: Reset default flag register in brw_find_live_channel()
Matt Turner writes:
> emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
> flag_subreg set, so that the IR knows which flag is accessed. However
> the flag is only used on Gen7 in Align1 mode.
>
> To avoid setting unnecessary bits in the instruction words, get the
> information we need and reset the default flag register. This allows
> round-tripping through the assembler/disassembler.
> ---
> src/intel/compiler/brw_eu_emit.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/compiler/brw_eu_emit.c
> b/src/intel/compiler/brw_eu_emit.c
> index 45e2552783b..7c5b40af3ae 100644
> --- a/src/intel/compiler/brw_eu_emit.c
> +++ b/src/intel/compiler/brw_eu_emit.c
> @@ -3312,6 +3312,13 @@ brw_find_live_channel(struct brw_codegen *p, struct
> brw_reg dst,
>
> brw_push_insn_state(p);
>
> + /* The flag register is only used on Gen7 in align1 mode, so avoid setting
> +* unnecessary bits in the instruction words, get the information we need
> +* and reset the default flag register.
Maybe mention here that this also allows more instructions to be
compacted. Looks good otherwise:
Reviewed-by: Francisco Jerez
> +*/
> + const unsigned flag_subreg = p->current->flag_subreg;
> + brw_set_default_flag_reg(p, 0, 0);
> +
> if (brw_get_default_access_mode(p) == BRW_ALIGN_1) {
>brw_set_default_mask_control(p, BRW_MASK_DISABLE);
>
> @@ -3345,8 +3352,7 @@ brw_find_live_channel(struct brw_codegen *p, struct
> brw_reg dst,
>*/
> inst = brw_FBL(p, vec1(dst), exec_mask);
>} else {
> - const struct brw_reg flag = brw_flag_reg(p->current->flag_subreg /
> 2,
> - p->current->flag_subreg %
> 2);
> + const struct brw_reg flag = brw_flag_subreg(flag_subreg);
>
> brw_set_default_exec_size(p, BRW_EXECUTE_1);
> brw_MOV(p, retype(flag, BRW_REGISTER_TYPE_UD), brw_imm_ud(0));
> @@ -3366,6 +3372,8 @@ brw_find_live_channel(struct brw_codegen *p, struct
> brw_reg dst,
> brw_inst_set_group(devinfo, inst, lower_size * i + 8 *
> qtr_control);
> brw_inst_set_cond_modifier(devinfo, inst, BRW_CONDITIONAL_Z);
> brw_inst_set_exec_size(devinfo, inst, cvt(lower_size) - 1);
> +brw_inst_set_flag_reg_nr(devinfo, inst, flag_subreg / 2);
> +brw_inst_set_flag_subreg_nr(devinfo, inst, flag_subreg % 2);
> }
>
> /* Find the first bit set in the exec_size-wide portion of the flag
> --
> 2.19.2
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/compiler: Reset default flag register in brw_find_live_channel()
emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
flag_subreg set, so that the IR knows which flag is accessed. However
the flag is only used on Gen7 in Align1 mode.
To avoid setting unnecessary bits in the instruction words, get the
information we need and reset the default flag register. This allows
round-tripping through the assembler/disassembler.
---
src/intel/compiler/brw_eu_emit.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 45e2552783b..7c5b40af3ae 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -3312,6 +3312,13 @@ brw_find_live_channel(struct brw_codegen *p, struct
brw_reg dst,
brw_push_insn_state(p);
+ /* The flag register is only used on Gen7 in align1 mode, so avoid setting
+* unnecessary bits in the instruction words, get the information we need
+* and reset the default flag register.
+*/
+ const unsigned flag_subreg = p->current->flag_subreg;
+ brw_set_default_flag_reg(p, 0, 0);
+
if (brw_get_default_access_mode(p) == BRW_ALIGN_1) {
brw_set_default_mask_control(p, BRW_MASK_DISABLE);
@@ -3345,8 +3352,7 @@ brw_find_live_channel(struct brw_codegen *p, struct
brw_reg dst,
*/
inst = brw_FBL(p, vec1(dst), exec_mask);
} else {
- const struct brw_reg flag = brw_flag_reg(p->current->flag_subreg / 2,
- p->current->flag_subreg % 2);
+ const struct brw_reg flag = brw_flag_subreg(flag_subreg);
brw_set_default_exec_size(p, BRW_EXECUTE_1);
brw_MOV(p, retype(flag, BRW_REGISTER_TYPE_UD), brw_imm_ud(0));
@@ -3366,6 +3372,8 @@ brw_find_live_channel(struct brw_codegen *p, struct
brw_reg dst,
brw_inst_set_group(devinfo, inst, lower_size * i + 8 *
qtr_control);
brw_inst_set_cond_modifier(devinfo, inst, BRW_CONDITIONAL_Z);
brw_inst_set_exec_size(devinfo, inst, cvt(lower_size) - 1);
+brw_inst_set_flag_reg_nr(devinfo, inst, flag_subreg / 2);
+brw_inst_set_flag_subreg_nr(devinfo, inst, flag_subreg % 2);
}
/* Find the first bit set in the exec_size-wide portion of the flag
--
2.19.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] gallivm: Return true from arch_rounding_available() if NEON is available
LLVM uses the single instruction "FRINTI" to implement llvm.nearbyint.
Fixes the rounding tests of lp_test_arit.
Bug: https://bugs.gentoo.org/665570
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 4 +++-
src/gallium/drivers/llvmpipe/lp_test_arit.c | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index c050bfdb936..057c50ed278 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -1992,6 +1992,8 @@ arch_rounding_available(const struct lp_type type)
else if ((util_cpu_caps.has_altivec &&
(type.width == 32 && type.length == 4)))
return TRUE;
+ else if (util_cpu_caps.has_neon)
+ return TRUE;
return FALSE;
}
@@ -2099,7 +2101,7 @@ lp_build_round_arch(struct lp_build_context *bld,
LLVMValueRef a,
enum lp_build_round_mode mode)
{
- if (util_cpu_caps.has_sse4_1) {
+ if (util_cpu_caps.has_sse4_1 || util_cpu_caps.has_neon) {
LLVMBuilderRef builder = bld->gallivm->builder;
const struct lp_type type = bld->type;
const char *intrinsic_root;
diff --git a/src/gallium/drivers/llvmpipe/lp_test_arit.c
b/src/gallium/drivers/llvmpipe/lp_test_arit.c
index acba7ed44a8..eb3f67dc1fe 100644
--- a/src/gallium/drivers/llvmpipe/lp_test_arit.c
+++ b/src/gallium/drivers/llvmpipe/lp_test_arit.c
@@ -458,7 +458,8 @@ test_unary(unsigned verbose, FILE *fp, const struct
unary_test_t *test, unsigned
continue;
}
- if (test->ref == &nearbyintf && length == 2 &&
+ if (!util_cpu_caps.has_neon &&
+ test->ref == &nearbyintf && length == 2 &&
ref != roundf(testval)) {
/* FIXME: The generic (non SSE) path in lp_build_iround, which is
* always taken for length==2 regardless of native round support,
--
2.19.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallium: Enable aarch64 NEON CPU detection.
NEON (now called ASIMD) is available on all aarch64 CPUs. It seems that
our code was missing an aarch64 path, leading to util_cpu_caps.has_neon
always being false on aarch64. I think that means that the NEON tiling
code in vc4 would not be enabled on aarch64 (vc4_load_lt_image_neon,
etc).
---
I have very little clue about aarch64 ABIs, so I don't know if there's
another case that needs to be handled -- aarch32 maybe? Does
PIPE_ARCH_AARCH64 just mean ARMv8 and so we should check something else
for the ABI and choose Elf{32,64} based on that?
Also, Android is not handled.
src/util/u_cpu_detect.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/src/util/u_cpu_detect.c b/src/util/u_cpu_detect.c
index 52b9ae547d4..e9cdb78e458 100644
--- a/src/util/u_cpu_detect.c
+++ b/src/util/u_cpu_detect.c
@@ -328,7 +328,7 @@ PIPE_ALIGN_STACK static inline boolean sse2_has_daz(void)
#endif /* X86 or X86_64 */
-#if defined(PIPE_ARCH_ARM)
+#if defined(PIPE_ARCH_ARM) || defined(PIPE_ARCH_AARCH64)
static void
check_os_arm_support(void)
{
@@ -348,24 +348,36 @@ check_os_arm_support(void)
util_cpu_caps.has_neon = 1;
}
#elif defined(PIPE_OS_LINUX)
-Elf32_auxv_t aux;
+
+#if defined(PIPE_ARCH_ARM)
+#define Elf_auxv_t Elf32_auxv_t
+#elif defined(PIPE_ARCH_AARCH64)
+#define Elf_auxv_t Elf64_auxv_t
+#endif
+
+Elf_auxv_t aux;
int fd;
fd = open("/proc/self/auxv", O_RDONLY | O_CLOEXEC);
if (fd >= 0) {
- while (read(fd, &aux, sizeof(Elf32_auxv_t)) == sizeof(Elf32_auxv_t)) {
+ while (read(fd, &aux, sizeof(Elf_auxv_t)) == sizeof(Elf_auxv_t)) {
if (aux.a_type == AT_HWCAP) {
uint32_t hwcap = aux.a_un.a_val;
+#if defined(PIPE_ARCH_ARM)
util_cpu_caps.has_neon = (hwcap >> 12) & 1;
+#elif defined(PIPE_ARCH_AARCH64)
+ util_cpu_caps.has_neon = (hwcap >> 1) & 1;
+#endif
break;
}
}
close (fd);
}
+#undef Elf_auxv_t
#endif /* PIPE_OS_LINUX */
}
-#endif /* PIPE_ARCH_ARM */
+#endif /* PIPE_ARCH_ARM || PIPE_ARCH_AARCH64 */
static void
get_cpu_topology(void)
@@ -534,7 +546,7 @@ util_cpu_detect_once(void)
}
#endif /* PIPE_ARCH_X86 || PIPE_ARCH_X86_64 */
-#if defined(PIPE_ARCH_ARM)
+#if defined(PIPE_ARCH_ARM) || defined(PIPE_ARCH_AARCH64)
check_os_arm_support();
#endif
--
2.19.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] ac/nir_to_llvm: add bindless support for uniform handles
For the series:
Reviewed-by: Marek Olšák
Marek
On Mon, Jan 21, 2019 at 9:29 PM Timothy Arceri
wrote:
> ---
> src/amd/common/ac_nir_to_llvm.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index c558873bbe..161a8b2c34 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -3303,6 +3303,27 @@ static void visit_intrinsic(struct ac_nir_context
> *ctx,
> }
> }
>
> +static LLVMValueRef get_bindless_index_from_uniform(struct ac_nir_context
> *ctx,
> + unsigned base_index,
> + unsigned
> constant_index,
> + LLVMValueRef
> dynamic_index)
> +{
> + LLVMValueRef offset = LLVMConstInt(ctx->ac.i32, base_index * 4, 0);
> + LLVMValueRef index = LLVMBuildAdd(ctx->ac.builder, dynamic_index,
> + LLVMConstInt(ctx->ac.i32,
> constant_index, 0), "");
> +
> + /* Bindless uniforms are 64bit so multiple index by 8 */
> + index = LLVMBuildMul(ctx->ac.builder, index,
> LLVMConstInt(ctx->ac.i32, 8, 0), "");
> + offset = LLVMBuildAdd(ctx->ac.builder, offset, index, "");
> +
> + LLVMValueRef ubo_index = ctx->abi->load_ubo(ctx->abi,
> ctx->ac.i32_0);
> +
> + LLVMValueRef ret = ac_build_buffer_load(&ctx->ac, ubo_index, 1,
> NULL, offset,
> + NULL, 0, false, false,
> true, true);
> +
> + return LLVMBuildBitCast(ctx->ac.builder, ret, ctx->ac.i32, "");
> +}
> +
> static LLVMValueRef get_sampler_desc(struct ac_nir_context *ctx,
> nir_deref_instr *deref_instr,
> enum ac_descriptor_type desc_type,
> @@ -3353,8 +3374,15 @@ static LLVMValueRef get_sampler_desc(struct
> ac_nir_context *ctx,
> descriptor_set = deref_instr->var->data.descriptor_set;
>
> if (deref_instr->var->data.bindless) {
> + /* For now just assert on unhandled variable types
> */
> + assert(deref_instr->var->data.mode ==
> nir_var_uniform);
> +
> base_index =
> deref_instr->var->data.driver_location;
> bindless = true;
> +
> + index = index ? index : ctx->ac.i32_0;
> + index = get_bindless_index_from_uniform(ctx,
> base_index,
> +
> constant_index, index);
> } else
> base_index = deref_instr->var->data.binding;
> }
> --
> 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
Re: [Mesa-dev] [PATCH] ac/nir_to_llvm: fix interpolateAt* for structs
Acked-by: Marek Olšák
Marek
On Tue, Jan 22, 2019 at 12:35 AM Timothy Arceri
wrote:
> This fixes the arb_gpu_shader5 interpolateAt* tests that contain
> structs.
> ---
>
> Extra piglit tests for structs:
>
> https://patchwork.freedesktop.org/patch/279466/
>
> src/amd/common/ac_nir_to_llvm.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 161a8b2c34..ea0da850f2 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -2924,12 +2924,10 @@ static LLVMValueRef visit_interp(struct
> ac_nir_context *ctx,
>
> }
>
> - LLVMValueRef array_idx = ctx->ac.i32_0;
> + LLVMValueRef attrib_idx = ctx->ac.i32_0;
> while(deref_instr->deref_type != nir_deref_type_var) {
> if (deref_instr->deref_type == nir_deref_type_array) {
> - unsigned array_size =
> glsl_get_aoa_size(deref_instr->type);
> - if (!array_size)
> - array_size = 1;
> + unsigned array_size =
> glsl_count_attribute_slots(deref_instr->type, false);
>
> LLVMValueRef offset;
> nir_const_value *const_value =
> nir_src_as_const_value(deref_instr->arr.index);
> @@ -2942,23 +2940,26 @@ static LLVMValueRef visit_interp(struct
> ac_nir_context *ctx,
>
> LLVMConstInt(ctx->ac.i32, array_size, false), "");
> }
>
> - array_idx = LLVMBuildAdd(ctx->ac.builder,
> array_idx, offset, "");
> + attrib_idx = LLVMBuildAdd(ctx->ac.builder,
> attrib_idx, offset, "");
> deref_instr =
> nir_src_as_deref(deref_instr->parent);
> + } else if (deref_instr->deref_type ==
> nir_deref_type_struct) {
> + LLVMValueRef offset;
> + unsigned sidx = deref_instr->strct.index;
> + deref_instr =
> nir_src_as_deref(deref_instr->parent);
> + offset = LLVMConstInt(ctx->ac.i32,
> glsl_get_record_location_offset(deref_instr->type, sidx), false);
> + attrib_idx = LLVMBuildAdd(ctx->ac.builder,
> attrib_idx, offset, "");
> } else {
> unreachable("Unsupported deref type");
> }
>
> }
>
> - unsigned input_array_size = glsl_get_aoa_size(var->type);
> - if (!input_array_size)
> - input_array_size = 1;
> -
> + unsigned attrib_size = glsl_count_attribute_slots(var->type,
> false);
> for (chan = 0; chan < 4; chan++) {
> - LLVMValueRef gather =
> LLVMGetUndef(LLVMVectorType(ctx->ac.f32, input_array_size));
> + LLVMValueRef gather =
> LLVMGetUndef(LLVMVectorType(ctx->ac.f32, attrib_size));
> LLVMValueRef llvm_chan = LLVMConstInt(ctx->ac.i32, chan,
> false);
>
> - for (unsigned idx = 0; idx < input_array_size; ++idx) {
> + for (unsigned idx = 0; idx < attrib_size; ++idx) {
> LLVMValueRef v, attr_number;
>
> attr_number = LLVMConstInt(ctx->ac.i32, input_base
> + idx, false);
> @@ -2981,7 +2982,7 @@ static LLVMValueRef visit_interp(struct
> ac_nir_context *ctx,
>
> LLVMConstInt(ctx->ac.i32, idx, false), "");
> }
>
> - result[chan] = LLVMBuildExtractElement(ctx->ac.builder,
> gather, array_idx, "");
> + result[chan] = LLVMBuildExtractElement(ctx->ac.builder,
> gather, attrib_idx, "");
>
> }
> return ac_build_varying_gather_values(&ctx->ac, result,
> instr->num_components,
> --
> 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
Re: [Mesa-dev] [PATCH] intel/compiler: Reset default flag register in brw_find_live_channel()
Matt Turner writes:
> emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
> flag_subreg set, so that the IR knows which flag is accessed. However
> the flag is only used on Gen7 in Align1 mode.
>
> To avoid setting unnecessary bits in the instruction words, get the
> information we need and reset the default flag register. This allows
> round-tripping through the assembler/disassembler.
> ---
> src/intel/compiler/brw_eu_emit.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/compiler/brw_eu_emit.c
> b/src/intel/compiler/brw_eu_emit.c
> index 45e2552783b..d05ea506353 100644
> --- a/src/intel/compiler/brw_eu_emit.c
> +++ b/src/intel/compiler/brw_eu_emit.c
> @@ -3312,6 +3312,14 @@ brw_find_live_channel(struct brw_codegen *p, struct
> brw_reg dst,
>
> brw_push_insn_state(p);
>
> + /* The flag register is only used on Gen7 in align1 mode, so avoid setting
> +* unnecessary bits in the instruction words, get the information we need
> +* and reset the default flag register.
> +*/
> + int flag_reg = p->current->flag_subreg / 2;
> + int flag_subreg = p->current->flag_subreg % 2;
You can replace the two lines above with:
+ const unsigned flag_subreg = p->current->flag_subreg;
> + brw_set_default_flag_reg(p, 0, 0);
> +
> if (brw_get_default_access_mode(p) == BRW_ALIGN_1) {
>brw_set_default_mask_control(p, BRW_MASK_DISABLE);
>
> @@ -3345,12 +3353,14 @@ brw_find_live_channel(struct brw_codegen *p, struct
> brw_reg dst,
>*/
> inst = brw_FBL(p, vec1(dst), exec_mask);
>} else {
> - const struct brw_reg flag = brw_flag_reg(p->current->flag_subreg /
> 2,
> - p->current->flag_subreg %
> 2);
> + const struct brw_reg flag = brw_flag_reg(flag_reg, flag_subreg);
so this will just be "brw_flag_subreg(flag_subreg)".
>
> brw_set_default_exec_size(p, BRW_EXECUTE_1);
> brw_MOV(p, retype(flag, BRW_REGISTER_TYPE_UD), brw_imm_ud(0));
>
> + brw_push_insn_state(p);
> + brw_set_default_flag_reg(p, flag_reg, flag_subreg);
> +
No need to push and pop another entry into the default instruction state
stack, you can just "brw_inst_set_flag_*reg_nr()" on the MOV instruction.
> /* Run enough instructions returning zero with execution masking and
>* a conditional modifier enabled in order to get the full execution
>* mask in f1.0. We could use a single 32-wide move here if it
> @@ -3368,6 +3378,8 @@ brw_find_live_channel(struct brw_codegen *p, struct
> brw_reg dst,
> brw_inst_set_exec_size(devinfo, inst, cvt(lower_size) - 1);
> }
>
> + brw_pop_insn_state(p);
> +
> /* Find the first bit set in the exec_size-wide portion of the flag
>* register that was updated by the last sequence of MOV
>* instructions.
> --
> 2.19.2
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: purge framebuffers when unbinding a context
Acked-by: Timothy Arceri
On 23/1/19 3:16 am, Marek Olšák wrote:
From: Marek Olšák
This fixes pipe_surface "leaks".
Cc: 18.3
---
src/mesa/state_tracker/st_manager.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index 7a3d9777101..7064b99743c 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -1088,21 +1088,26 @@ st_api_make_current(struct st_api *stapi, struct
st_context_iface *stctxi,
st_framebuffer_reference(&stdraw, NULL);
st_framebuffer_reference(&stread, NULL);
/* Purge the context's winsys_buffers list in case any
* of the referenced drawables no longer exist.
*/
st_framebuffers_purge(st);
}
else {
+ GET_CURRENT_CONTEXT(ctx);
+
ret = _mesa_make_current(NULL, NULL, NULL);
+
+ if (ctx)
+ st_framebuffers_purge(ctx->st);
}
return ret;
}
static void
st_api_destroy(struct st_api *stapi)
{
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: propagate known constant values into the if-then branch
On 23/1/19 7:17 am, Caio Marcelo de Oliveira Filho wrote:
Hi,
I like this patch, did it get dropped for a specific reason or just
forgotten?
Did you look at any of the HURT? The problem I was seeing was this could
end up stopping copy propagation from working on some UBOs etc.
For example if you have something like:
load UBO at offset offset_a;
if (offset_a == 10) {
load UBO at offset offset_a;
...
}
Without this patch this will get optimised to a single UBO load outside
the loop.
However with this patch we end up with:
load UBO at offset offset_a;
if (offset_a == 10) {
load UBO at offset 10;
...
}
copy prop no longer recognizes that we are reusing the same UBO and
reloads it again.
shader-db results skl:
total instructions in shared programs: 15049273 -> 15049211 (<.01%)
instructions in affected programs: 75678 -> 75616 (-0.08%)
helped: 197
HURT: 8
total cycles in shared programs: 369994915 -> 370136090 (0.04%)
cycles in affected programs: 1750477 -> 1891652 (8.06%)
helped: 91
HURT: 91
total loops in shared programs: 4401 -> 4401 (0.00%)
loops in affected programs: 0 -> 0
helped: 0
HURT: 0
total spills in shared programs: 10159 -> 10159 (0.00%)
spills in affected programs: 0 -> 0
helped: 0
HURT: 0
total fills in shared programs: 22118 -> 22118 (0.00%)
fills in affected programs: 0 -> 0
helped: 0
HURT: 0
LOST: 0
GAINED: 0
+static bool
+opt_for_known_values(nir_builder *b, nir_if *nif)
+{
+ bool progress = false;
Remove because unused.
+ nir_ssa_def *src0 = alu->src[0].src.ssa;
+ nir_ssa_def *src1 = alu->src[1].src.ssa;
+ if (src0a->parent_instr->type == nir_instr_type_load_const) {
You fixed this already.
+
+ break;
+ }
+
+ default:
+ return false;
+ }
+
+ return false;
Optional: unless you plan to add more cases here, consider replacing
the switch with an if (alu->op == ... || alu->op == ...), so you don't
have this noise at the end.
With the 'progress' and the 'src0a' fixes, this patch is
Reviewed-by: Caio Marcelo de Oliveira Filho
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: improve gathering of load_push_constants with dynamic bindings
Reviewed-by: Bas Nieuwenhuizen
On Tue, Jan 22, 2019 at 7:27 PM Samuel Pitoiset
wrote:
>
> For example, if a pipeline has two stages VS and FS. And if only
> the fragment stage needs dynamic bindings, we shouldn't allocate
> an extra user SGPR for the vertex stage. Of course, if the vertex
> stage loads constants, it needs an user SGPR.
>
> This should reduce the number of SET_SH_REG packets that are emitted.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_descriptor_set.c | 3 +++
> src/amd/vulkan/radv_descriptor_set.h | 1 +
> src/amd/vulkan/radv_shader_info.c| 4 +++-
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_descriptor_set.c
> b/src/amd/vulkan/radv_descriptor_set.c
> index 526bb77a553..30f982252bb 100644
> --- a/src/amd/vulkan/radv_descriptor_set.c
> +++ b/src/amd/vulkan/radv_descriptor_set.c
> @@ -345,6 +345,7 @@ VkResult radv_CreatePipelineLayout(
> layout->num_sets = pCreateInfo->setLayoutCount;
>
> unsigned dynamic_offset_count = 0;
> + uint16_t dynamic_shader_stages = 0;
>
>
> _mesa_sha1_init(&ctx);
> @@ -356,6 +357,7 @@ VkResult radv_CreatePipelineLayout(
> layout->set[set].dynamic_offset_start = dynamic_offset_count;
> for (uint32_t b = 0; b < set_layout->binding_count; b++) {
> dynamic_offset_count +=
> set_layout->binding[b].array_size *
> set_layout->binding[b].dynamic_offset_count;
> + dynamic_shader_stages |=
> set_layout->dynamic_shader_stages;
> if (set_layout->binding[b].immutable_samplers_offset)
> _mesa_sha1_update(&ctx,
> radv_immutable_samplers(set_layout, set_layout->binding + b),
>
> set_layout->binding[b].array_size * 4 * sizeof(uint32_t));
> @@ -365,6 +367,7 @@ VkResult radv_CreatePipelineLayout(
> }
>
> layout->dynamic_offset_count = dynamic_offset_count;
> + layout->dynamic_shader_stages = dynamic_shader_stages;
> layout->push_constant_size = 0;
>
> for (unsigned i = 0; i < pCreateInfo->pushConstantRangeCount; ++i) {
> diff --git a/src/amd/vulkan/radv_descriptor_set.h
> b/src/amd/vulkan/radv_descriptor_set.h
> index d8431241fd9..7b13c6fb621 100644
> --- a/src/amd/vulkan/radv_descriptor_set.h
> +++ b/src/amd/vulkan/radv_descriptor_set.h
> @@ -85,6 +85,7 @@ struct radv_pipeline_layout {
> uint32_t num_sets;
> uint32_t push_constant_size;
> uint32_t dynamic_offset_count;
> + uint16_t dynamic_shader_stages;
>
> unsigned char sha1[20];
> };
> diff --git a/src/amd/vulkan/radv_shader_info.c
> b/src/amd/vulkan/radv_shader_info.c
> index c2e005e63dd..7e5a3789af2 100644
> --- a/src/amd/vulkan/radv_shader_info.c
> +++ b/src/amd/vulkan/radv_shader_info.c
> @@ -512,8 +512,10 @@ radv_nir_shader_info_pass(const struct nir_shader *nir,
> struct nir_function *func =
> (struct nir_function
> *)exec_list_get_head_const(&nir->functions);
>
> - if (options->layout && options->layout->dynamic_offset_count)
> + if (options->layout && options->layout->dynamic_offset_count &&
> + (options->layout->dynamic_shader_stages &
> mesa_to_vk_shader_stage(nir->info.stage))) {
> info->loads_push_constants = true;
> + }
>
> nir_foreach_variable(variable, &nir->inputs)
> gather_info_input_decl(nir, variable, info);
> --
> 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
Re: [Mesa-dev] [PATCH] radv: try to select better export formats for chips without Rb+
On Tue, Jan 22, 2019 at 4:32 PM Samuel Pitoiset
wrote:
>
> For some R8 formats, it's useless to export two channels
> when no alpha blending is used. I assume the CB should
> automatically clamps its inputs.
>
> 29077 shaders in 15096 tests
> Totals:
> SGPRS: 1321106 -> 1320970 (-0.01 %)
> VGPRS: 935936 -> 935948 (0.00 %)
> Spilled SGPRs: 25186 -> 25204 (0.07 %)
> Code Size: 49813556 -> 49796944 (-0.03 %) bytes
> Max Waves: 242091 -> 242088 (-0.00 %)
>
> Totals from affected shaders:
> SGPRS: 170608 -> 170472 (-0.08 %)
> VGPRS: 99752 -> 99764 (0.01 %)
> Spilled SGPRs: 10377 -> 10395 (0.17 %)
> Code Size: 6332492 -> 6315880 (-0.26 %) bytes
> Max Waves: 12317 -> 12314 (-0.02 %)
>
> This helps some Rise Of Tomb Raider shaders, especially
> when an expcnt instruction is added between two MRT exports.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 27 ++-
> 1 file changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 138e153f9a4..25281c3c6da 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -372,9 +372,10 @@ static bool is_dual_src(VkBlendFactor factor)
> }
> }
>
> -static unsigned si_choose_spi_color_format(VkFormat vk_format,
> - bool blend_enable,
> - bool blend_need_alpha)
> +static unsigned si_choose_spi_color_format(struct radv_device *device,
> + VkFormat vk_format,
> + bool blend_enable,
> + bool blend_need_alpha)
> {
> const struct vk_format_description *desc =
> vk_format_description(vk_format);
> unsigned format, ntype, swap;
> @@ -486,6 +487,20 @@ static unsigned si_choose_spi_color_format(VkFormat
> vk_format,
> unreachable("unhandled blend format");
> }
>
> + if (device && /* NULL for internal meta formats */
> + !device->physical_device->rbplus_allowed) {
> + /* Try to select better export formats for chips without Rb+.
> */
> + if (desc->nr_channels == 1 &&
> + desc->channel[0].size == 8 &&
Why do we only allow this for 8 bit components? Why not also for
16/32-bit components?
> + swap == V_028C70_SWAP_STD && /* R */
> + !vk_format_is_srgb(vk_format)) {
> + /* Do not need to export two channels for some R8
> +* formats when alpha blending isn't used.
> +*/
> + blend = normal = V_028714_SPI_SHADER_32_R;
> + }
> + }
> +
> if (blend_enable && blend_need_alpha)
> return blend_alpha;
> else if(blend_need_alpha)
> @@ -516,7 +531,8 @@ radv_pipeline_compute_spi_color_formats(struct
> radv_pipeline *pipeline,
> bool blend_enable =
> blend->blend_enable_4bit & (0xfu << (i * 4));
>
> - cf = si_choose_spi_color_format(attachment->format,
> + cf = si_choose_spi_color_format(pipeline->device,
> + attachment->format,
> blend_enable,
> blend->need_src_alpha
> & (1 << i));
> }
> @@ -586,7 +602,8 @@ const VkFormat
> radv_fs_key_format_exemplars[NUM_META_FS_KEYS] = {
>
> unsigned radv_format_meta_fs_key(VkFormat format)
> {
> - unsigned col_format = si_choose_spi_color_format(format, false,
> false);
> + unsigned col_format =
> + si_choose_spi_color_format(NULL, format, false, false);
I think we properly need to plumb through the device here?
>
> assert(col_format != V_028714_SPI_SHADER_32_AR);
> if (col_format >= V_028714_SPI_SHADER_32_AR)
> --
> 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
Re: [Mesa-dev] [PATCH 1/3] radeonsi: allow si_cp_dma_clear_buffer to clear GDS from any IB
On Thu, Nov 29, 2018 at 11:23 AM Koenig, Christian wrote: > Hi Marek, > > you stumbled over a pretty fundamental bug in the memory management here. > Essentially we where leaking BOs when we ran into an OOM situation. Patch > to fix this is on the mailing list. > > A second problem is that eviction doesn't seem to work when GDS BOs aren't > idle. In other words when two applications try to use GDS at the same time > they don't wait for each other, but rather one looses with an OOM message. > FYI, the OOM message is the last issue with GDS. Everything else is good. I have a workaround in Mesa that re-submits the CS ioctl if it has failed with -ENOMEM. I guess there is no downside to it other than the OOM spam in dmesg. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] loader: fix the no-modifiers case
Reviewed-by: Bas Nieuwenhuizen
On Tue, Jan 22, 2019 at 10:20 PM Kristian Høgsberg wrote:
>
> On Tue, Jan 22, 2019 at 11:45 AM Rob Clark wrote:
> >
> > Normally modifiers take precendence over use flags, as they are more
> > explicit. But if the driver supports modifiers, but the xserver does
> > not, then we should fallback to the old mechanism of allocating a buffer
> > using 'use' flags.
> >
> > Fixes: 069fdd5f9facbd72fb6a289696c7b74e3237e70f
> > Signed-off-by: Rob Clark
>
> Reviewed-by: Kristian H. Kristensen
>
> > ---
> > Backport note: This fixes an issue with enabling UBWC in freedreno/a6xx
> > (which is something I'd like to land soonish, but not something that
> > exists yet in release branches). Unless a similar issue is reported in
> > other drivers, this may not be worth backporting to release branches, at
> > least not until it has had some soak time in master.
> >
> > Backtrace to explain the issue:
> >
> > Breakpoint 1, fd_resource_create_with_modifiers (pscreen=0x574ae0,
> > tmpl=0x7fdbf0, modifiers=0x7fdb38, count=1)
> > at ../src/gallium/drivers/freedreno/freedreno_resource.c:838
> > 838 struct fd_screen *screen = fd_screen(pscreen);
> > 1: *tmpl = {reference = {count = 0}, width0 = 800, height0 = 600, depth0
> > = 1, array_size = 1, format = PIPE_FORMAT_B8G8R8A8_UNORM,
> > target = PIPE_TEXTURE_2D, last_level = 0, nr_samples = 0,
> > nr_storage_samples = 0, usage = 0, bind = 1572874, flags = 0, next = 0x0,
> > screen = 0x0}
> > (gdb) bt
> > #0 fd_resource_create_with_modifiers (pscreen=0x574ae0,
> > tmpl=0x7fdbf0, modifiers=0x7fdb38, count=1) at
> > ../src/gallium/drivers/freedreno/freedreno_resource.c:838
> > #1 0x007fbde0 in fd_resource_create (pscreen=0x574ae0,
> > tmpl=0x7fdbf0) at
> > ../src/gallium/drivers/freedreno/freedreno_resource.c:956
> > #2 0x007fbe54e2a4 in u_transfer_helper_resource_create
> > (pscreen=0x574ae0, templ=0x7fdbf0) at
> > ../src/gallium/auxiliary/util/u_transfer_helper.c:126
> > #3 0x007fbdcc8148 in dri2_create_image_common (_screen=0x570530,
> > width=800, height=600, format=4099, use=19, modifiers=0x0, count=0,
> > loaderPrivate=0x6c4160) at ../src/gallium/state_trackers/dri/dri2.c:1039
> > #4 0x007fbdcc8214 in dri2_create_image (_screen=0x570530, width=800,
> > height=600, format=4099, use=19, loaderPrivate=0x6c4160) at
> > ../src/gallium/state_trackers/dri/dri2.c:1061
> > #5 0x007fbec89a30 in dri3_alloc_render_buffer (draw=0x531418,
> > format=4099, width=800, height=600, depth=24) at
> > ../src/loader/loader_dri3_helper.c:1341
> > #6 0x007fbec8aab4 in dri3_get_buffer (driDrawable=0x5387b0,
> > format=4099, buffer_type=loader_dri3_buffer_back, draw=0x531418) at
> > ../src/loader/loader_dri3_helper.c:1822
> > #7 0x007fbec8b10c in loader_dri3_get_buffers (driDrawable=0x5387b0,
> > format=4099, stamp=0x64d480, loaderPrivate=0x531418, buffer_mask=1,
> > buffers=0x7fdf20) at ../src/loader/loader_dri3_helper.c:2021
> > #8 0x007fbdcc68c4 in dri_image_drawable_get_buffers
> > (drawable=0x64d480, images=0x7fdf20, statts=0x65ee90, statts_count=2)
> > at ../src/gallium/state_trackers/dri/dri2.c:339
> > #9 0x007fbdcc6c44 in dri2_allocate_textures (ctx=0x5a7540,
> > drawable=0x64d480, statts=0x65ee90, statts_count=2) at
> > ../src/gallium/state_trackers/dri/dri2.c:466
> > #10 0x007fbdccb580 in dri_st_framebuffer_validate (stctx=0x535cf0,
> > stfbi=0x64d480, statts=0x65ee90, count=2, out=0x7fe0c8) at
> > ../src/gallium/state_trackers/dri/dri_drawable.c:85
> > #11 0x007fbe048c84 in st_framebuffer_validate (stfb=0x65e9c0,
> > st=0x535cf0) at ../src/mesa/state_tracker/st_manager.c:222
> > #12 0x007fbe04a884 in st_api_make_current (stapi=0x7fbe8d90d8
> > , stctxi=0x535cf0, stdrawi=0x64d480, streadi=0x64d480) at
> > ../src/mesa/state_tracker/st_manager.c:1074
> > #13 0x007fbdccaf44 in dri_make_current (cPriv=0x67bdc0,
> > driDrawPriv=0x5387b0, driReadPriv=0x5387b0) at
> > ../src/gallium/state_trackers/dri/dri_context.c:301
> > #14 0x007fbdcc2910 in driBindContext (pcp=0x67bdc0, pdp=0x5387b0,
> > prp=0x5387b0) at ../src/mesa/drivers/dri/common/dri_util.c:579
> > #15 0x007fbec6b7e0 in dri3_bind_context (context=0x51ccd0,
> > old=0x7fbecd0798 , draw=2097154, read=2097154) at
> > ../src/glx/dri3_glx.c:210
> > #16 0x007fbec4b010 in MakeContextCurrent (dpy=0x503d00, draw=2097154,
> > read=2097154, gc_user=0x51ccd0) at ../src/glx/glxcurrent.c:220
> > #17 0x007fbec4b184 in glXMakeCurrent (dpy=0x503d00, draw=2097154,
> > gc=0x51ccd0) at ../src/glx/glxcurrent.c:267
> > #18 0x007fbee8deac in ?? () from /lib64/libGLX.so.0
> > #19 0x007fbee8f7d4 in ?? () from /lib64/libGLX.so.0
> > #20 0x0040b330 in GLStateGLX::valid() ()
> > #21 0x00409a28 in CanvasGeneric::do_make_current() ()
> > #22 0x0040a4f0 in CanvasGeneric::reset(
[Mesa-dev] [PATCH] intel/compiler: Reset default flag register in brw_find_live_channel()
emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
flag_subreg set, so that the IR knows which flag is accessed. However
the flag is only used on Gen7 in Align1 mode.
To avoid setting unnecessary bits in the instruction words, get the
information we need and reset the default flag register. This allows
round-tripping through the assembler/disassembler.
---
src/intel/compiler/brw_eu_emit.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 45e2552783b..d05ea506353 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -3312,6 +3312,14 @@ brw_find_live_channel(struct brw_codegen *p, struct
brw_reg dst,
brw_push_insn_state(p);
+ /* The flag register is only used on Gen7 in align1 mode, so avoid setting
+* unnecessary bits in the instruction words, get the information we need
+* and reset the default flag register.
+*/
+ int flag_reg = p->current->flag_subreg / 2;
+ int flag_subreg = p->current->flag_subreg % 2;
+ brw_set_default_flag_reg(p, 0, 0);
+
if (brw_get_default_access_mode(p) == BRW_ALIGN_1) {
brw_set_default_mask_control(p, BRW_MASK_DISABLE);
@@ -3345,12 +3353,14 @@ brw_find_live_channel(struct brw_codegen *p, struct
brw_reg dst,
*/
inst = brw_FBL(p, vec1(dst), exec_mask);
} else {
- const struct brw_reg flag = brw_flag_reg(p->current->flag_subreg / 2,
- p->current->flag_subreg % 2);
+ const struct brw_reg flag = brw_flag_reg(flag_reg, flag_subreg);
brw_set_default_exec_size(p, BRW_EXECUTE_1);
brw_MOV(p, retype(flag, BRW_REGISTER_TYPE_UD), brw_imm_ud(0));
+ brw_push_insn_state(p);
+ brw_set_default_flag_reg(p, flag_reg, flag_subreg);
+
/* Run enough instructions returning zero with execution masking and
* a conditional modifier enabled in order to get the full execution
* mask in f1.0. We could use a single 32-wide move here if it
@@ -3368,6 +3378,8 @@ brw_find_live_channel(struct brw_codegen *p, struct
brw_reg dst,
brw_inst_set_exec_size(devinfo, inst, cvt(lower_size) - 1);
}
+ brw_pop_insn_state(p);
+
/* Find the first bit set in the exec_size-wide portion of the flag
* register that was updated by the last sequence of MOV
* instructions.
--
2.19.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: Reset default flag register in brw_find_live_channel()
On Tue, Jan 22, 2019 at 11:53 AM Francisco Jerez wrote: > > Matt Turner writes: > > > emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its > > flag_subreg set, so that the IR knows which flag is accessed. However > > the flag is only used on Gen7 in Align1 mode, and it is used as an > > explicit source and destination. > > > > To avoid setting unnecessary bits in the instruction words, get the > > information we need and reset the default flag register. This allows > > round-tripping through the assembler/disassembler. > > --- > > src/intel/compiler/brw_eu_emit.c | 11 --- > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > diff --git a/src/intel/compiler/brw_eu_emit.c > > b/src/intel/compiler/brw_eu_emit.c > > index 45e2552783b..e6f6d6419d2 100644 > > --- a/src/intel/compiler/brw_eu_emit.c > > +++ b/src/intel/compiler/brw_eu_emit.c > > @@ -3312,6 +3312,14 @@ brw_find_live_channel(struct brw_codegen *p, struct > > brw_reg dst, > > > > brw_push_insn_state(p); > > > > + /* The flag register is only used on Gen7 in align1 mode, so avoid > > setting > > +* unnecessary bits in the instruction words, get the information we > > need > > +* and reset the default flag register. > > +*/ > > + const struct brw_reg flag = brw_flag_reg(p->current->flag_subreg / 2, > > +p->current->flag_subreg % 2); > > + brw_set_default_flag_reg(p, 0, 0); > > + > > I think this is going to break Gen7, because the MOV instructions > emitted in the loop below have conditional mod enabled and won't be > pointing at the right flag register anymore after this change. Crap, I missed that. I'll send an updated patch. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] loader: fix the no-modifiers case
On Tue, Jan 22, 2019 at 11:45 AM Rob Clark wrote:
>
> Normally modifiers take precendence over use flags, as they are more
> explicit. But if the driver supports modifiers, but the xserver does
> not, then we should fallback to the old mechanism of allocating a buffer
> using 'use' flags.
>
> Fixes: 069fdd5f9facbd72fb6a289696c7b74e3237e70f
> Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
> ---
> Backport note: This fixes an issue with enabling UBWC in freedreno/a6xx
> (which is something I'd like to land soonish, but not something that
> exists yet in release branches). Unless a similar issue is reported in
> other drivers, this may not be worth backporting to release branches, at
> least not until it has had some soak time in master.
>
> Backtrace to explain the issue:
>
> Breakpoint 1, fd_resource_create_with_modifiers (pscreen=0x574ae0,
> tmpl=0x7fdbf0, modifiers=0x7fdb38, count=1)
> at ../src/gallium/drivers/freedreno/freedreno_resource.c:838
> 838 struct fd_screen *screen = fd_screen(pscreen);
> 1: *tmpl = {reference = {count = 0}, width0 = 800, height0 = 600, depth0 =
> 1, array_size = 1, format = PIPE_FORMAT_B8G8R8A8_UNORM,
> target = PIPE_TEXTURE_2D, last_level = 0, nr_samples = 0,
> nr_storage_samples = 0, usage = 0, bind = 1572874, flags = 0, next = 0x0,
> screen = 0x0}
> (gdb) bt
> #0 fd_resource_create_with_modifiers (pscreen=0x574ae0, tmpl=0x7fdbf0,
> modifiers=0x7fdb38, count=1) at
> ../src/gallium/drivers/freedreno/freedreno_resource.c:838
> #1 0x007fbde0 in fd_resource_create (pscreen=0x574ae0,
> tmpl=0x7fdbf0) at
> ../src/gallium/drivers/freedreno/freedreno_resource.c:956
> #2 0x007fbe54e2a4 in u_transfer_helper_resource_create
> (pscreen=0x574ae0, templ=0x7fdbf0) at
> ../src/gallium/auxiliary/util/u_transfer_helper.c:126
> #3 0x007fbdcc8148 in dri2_create_image_common (_screen=0x570530,
> width=800, height=600, format=4099, use=19, modifiers=0x0, count=0,
> loaderPrivate=0x6c4160) at ../src/gallium/state_trackers/dri/dri2.c:1039
> #4 0x007fbdcc8214 in dri2_create_image (_screen=0x570530, width=800,
> height=600, format=4099, use=19, loaderPrivate=0x6c4160) at
> ../src/gallium/state_trackers/dri/dri2.c:1061
> #5 0x007fbec89a30 in dri3_alloc_render_buffer (draw=0x531418,
> format=4099, width=800, height=600, depth=24) at
> ../src/loader/loader_dri3_helper.c:1341
> #6 0x007fbec8aab4 in dri3_get_buffer (driDrawable=0x5387b0,
> format=4099, buffer_type=loader_dri3_buffer_back, draw=0x531418) at
> ../src/loader/loader_dri3_helper.c:1822
> #7 0x007fbec8b10c in loader_dri3_get_buffers (driDrawable=0x5387b0,
> format=4099, stamp=0x64d480, loaderPrivate=0x531418, buffer_mask=1,
> buffers=0x7fdf20) at ../src/loader/loader_dri3_helper.c:2021
> #8 0x007fbdcc68c4 in dri_image_drawable_get_buffers
> (drawable=0x64d480, images=0x7fdf20, statts=0x65ee90, statts_count=2) at
> ../src/gallium/state_trackers/dri/dri2.c:339
> #9 0x007fbdcc6c44 in dri2_allocate_textures (ctx=0x5a7540,
> drawable=0x64d480, statts=0x65ee90, statts_count=2) at
> ../src/gallium/state_trackers/dri/dri2.c:466
> #10 0x007fbdccb580 in dri_st_framebuffer_validate (stctx=0x535cf0,
> stfbi=0x64d480, statts=0x65ee90, count=2, out=0x7fe0c8) at
> ../src/gallium/state_trackers/dri/dri_drawable.c:85
> #11 0x007fbe048c84 in st_framebuffer_validate (stfb=0x65e9c0,
> st=0x535cf0) at ../src/mesa/state_tracker/st_manager.c:222
> #12 0x007fbe04a884 in st_api_make_current (stapi=0x7fbe8d90d8
> , stctxi=0x535cf0, stdrawi=0x64d480, streadi=0x64d480) at
> ../src/mesa/state_tracker/st_manager.c:1074
> #13 0x007fbdccaf44 in dri_make_current (cPriv=0x67bdc0,
> driDrawPriv=0x5387b0, driReadPriv=0x5387b0) at
> ../src/gallium/state_trackers/dri/dri_context.c:301
> #14 0x007fbdcc2910 in driBindContext (pcp=0x67bdc0, pdp=0x5387b0,
> prp=0x5387b0) at ../src/mesa/drivers/dri/common/dri_util.c:579
> #15 0x007fbec6b7e0 in dri3_bind_context (context=0x51ccd0,
> old=0x7fbecd0798 , draw=2097154, read=2097154) at
> ../src/glx/dri3_glx.c:210
> #16 0x007fbec4b010 in MakeContextCurrent (dpy=0x503d00, draw=2097154,
> read=2097154, gc_user=0x51ccd0) at ../src/glx/glxcurrent.c:220
> #17 0x007fbec4b184 in glXMakeCurrent (dpy=0x503d00, draw=2097154,
> gc=0x51ccd0) at ../src/glx/glxcurrent.c:267
> #18 0x007fbee8deac in ?? () from /lib64/libGLX.so.0
> #19 0x007fbee8f7d4 in ?? () from /lib64/libGLX.so.0
> #20 0x0040b330 in GLStateGLX::valid() ()
> #21 0x00409a28 in CanvasGeneric::do_make_current() ()
> #22 0x0040a4f0 in CanvasGeneric::reset() ()
> #23 0x00406714 in main ()
> (gdb)
>
> In dri3_alloc_render_buffer() the request gets turned into
> createImageWithModifiers() but in dri2_create_image_common() it gets
> turned back into pscreen->create_resource() (ie. without modifiers) so
> we
[Mesa-dev] [AppVeyor] mesa master #9821 completed
Build mesa 9821 completed Commit 956c219c8f by Brian Paul on 1/22/2019 7:29 PM: svga: add new gallium formats to the format conversion table\n\nFixes a static assertion which broke the build.\n\nFixes: 3ee240890 "gallium: add SINT formats to have exact counterparts to SNORM formats"\nReviewed-by: Marek Olšák \nReviewed-by: Neha Bhende Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: propagate known constant values into the if-then branch
Hi,
I like this patch, did it get dropped for a specific reason or just
forgotten?
shader-db results skl:
total instructions in shared programs: 15049273 -> 15049211 (<.01%)
instructions in affected programs: 75678 -> 75616 (-0.08%)
helped: 197
HURT: 8
total cycles in shared programs: 369994915 -> 370136090 (0.04%)
cycles in affected programs: 1750477 -> 1891652 (8.06%)
helped: 91
HURT: 91
total loops in shared programs: 4401 -> 4401 (0.00%)
loops in affected programs: 0 -> 0
helped: 0
HURT: 0
total spills in shared programs: 10159 -> 10159 (0.00%)
spills in affected programs: 0 -> 0
helped: 0
HURT: 0
total fills in shared programs: 22118 -> 22118 (0.00%)
fills in affected programs: 0 -> 0
helped: 0
HURT: 0
LOST: 0
GAINED: 0
> +static bool
> +opt_for_known_values(nir_builder *b, nir_if *nif)
> +{
> + bool progress = false;
Remove because unused.
> + nir_ssa_def *src0 = alu->src[0].src.ssa;
> + nir_ssa_def *src1 = alu->src[1].src.ssa;
> + if (src0a->parent_instr->type == nir_instr_type_load_const) {
You fixed this already.
> +
> + break;
> + }
> +
> + default:
> + return false;
> + }
> +
> + return false;
Optional: unless you plan to add more cases here, consider replacing
the switch with an if (alu->op == ... || alu->op == ...), so you don't
have this noise at the end.
With the 'progress' and the 'src0a' fixes, this patch is
Reviewed-by: Caio Marcelo de Oliveira Filho
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/nine: Immediately upload user provided textures
Fixes regression caused by
42d672fa6a766363e5703f119607f7c7975918aa
st/nine: Bind src not dst in nine_context_box_upload
Before that patch, for user provided textures,
when the texture was destroyed, the safety
check for pending uploads, which according to
the code "Following condition cannot happen currently",
was flushing the queue and thus triggering the upload.
After the patch, the texture destruction was delayed after
the upload. However the user frees the texture buffer,
as it thinks the texture released.
Instead of reverting the faulty patch,
this patch instead flushes the csmt queue right away
after queuing the upload for this type of textures.
This is more future-proof, as we may want to bind the
surface for other reasons in the future.
Signed-off-by: Axel Davy
Cc: 18.3
---
The regression affects Mesa 18.3.2. At least HL2 lost coast
is affected, has artifacts and crashes at the menu.
src/gallium/state_trackers/nine/surface9.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/gallium/state_trackers/nine/surface9.c
b/src/gallium/state_trackers/nine/surface9.c
index f94f7c62583..7f4ecf559e8 100644
--- a/src/gallium/state_trackers/nine/surface9.c
+++ b/src/gallium/state_trackers/nine/surface9.c
@@ -668,6 +668,19 @@ NineSurface9_CopyMemToDefault( struct NineSurface9 *This,
From->data, From->stride,
0, /* depth = 1 */
&src_box);
+if (From->texture == D3DRTYPE_TEXTURE) {
+struct NineTexture9 *tex =
+NineTexture9(From->base.base.container);
+/* D3DPOOL_SYSTEMMEM with buffer content passed
+ * from the user: execute the upload right now.
+ * It is possible it is enough to delay upload
+ * until the surface refcount is 0, but the
+ * bind refcount may not be 0, and thus the dtor
+ * is not executed (and doesn't trigger the
+ * pending_uploads_counter check). */
+if (!tex->managed_buffer)
+nine_csmt_process(This->base.base.device);
+}
if (This->data_conversion)
(void) util_format_translate(This->format_conversion,
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: Reset default flag register in brw_find_live_channel()
Matt Turner writes:
> emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
> flag_subreg set, so that the IR knows which flag is accessed. However
> the flag is only used on Gen7 in Align1 mode, and it is used as an
> explicit source and destination.
>
> To avoid setting unnecessary bits in the instruction words, get the
> information we need and reset the default flag register. This allows
> round-tripping through the assembler/disassembler.
> ---
> src/intel/compiler/brw_eu_emit.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/compiler/brw_eu_emit.c
> b/src/intel/compiler/brw_eu_emit.c
> index 45e2552783b..e6f6d6419d2 100644
> --- a/src/intel/compiler/brw_eu_emit.c
> +++ b/src/intel/compiler/brw_eu_emit.c
> @@ -3312,6 +3312,14 @@ brw_find_live_channel(struct brw_codegen *p, struct
> brw_reg dst,
>
> brw_push_insn_state(p);
>
> + /* The flag register is only used on Gen7 in align1 mode, so avoid setting
> +* unnecessary bits in the instruction words, get the information we need
> +* and reset the default flag register.
> +*/
> + const struct brw_reg flag = brw_flag_reg(p->current->flag_subreg / 2,
> +p->current->flag_subreg % 2);
> + brw_set_default_flag_reg(p, 0, 0);
> +
I think this is going to break Gen7, because the MOV instructions
emitted in the loop below have conditional mod enabled and won't be
pointing at the right flag register anymore after this change.
> if (brw_get_default_access_mode(p) == BRW_ALIGN_1) {
>brw_set_default_mask_control(p, BRW_MASK_DISABLE);
>
> @@ -3345,9 +3353,6 @@ brw_find_live_channel(struct brw_codegen *p, struct
> brw_reg dst,
>*/
> inst = brw_FBL(p, vec1(dst), exec_mask);
>} else {
> - const struct brw_reg flag = brw_flag_reg(p->current->flag_subreg /
> 2,
> - p->current->flag_subreg %
> 2);
> -
> brw_set_default_exec_size(p, BRW_EXECUTE_1);
> brw_MOV(p, retype(flag, BRW_REGISTER_TYPE_UD), brw_imm_ud(0));
>
> --
> 2.19.2
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] svga: add new gallium formats to the format conversion table
Reviewed-by: Marek Olšák
Sorry for breaking the build.
Marek
On Tue, Jan 22, 2019 at 2:31 PM Brian Paul wrote:
> Fixes a static assertion which broke the build.
>
> Fixes:3ee240890 "gallium: add SINT formats to have exact counterparts to
> SNORM formats"
> ---
> src/gallium/drivers/svga/svga_format.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/drivers/svga/svga_format.c
> b/src/gallium/drivers/svga/svga_format.c
> index cf88e33..d751eb0 100644
> --- a/src/gallium/drivers/svga/svga_format.c
> +++ b/src/gallium/drivers/svga/svga_format.c
> @@ -371,6 +371,10 @@ static const struct vgpu10_format_entry
> format_conversion_table[] =
> { PIPE_FORMAT_X1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
> { PIPE_FORMAT_A4B4G4R4_UNORM,SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
> { PIPE_FORMAT_R8_SRGB, SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
> + { PIPE_FORMAT_A8L8_SINT, SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
> + { PIPE_FORMAT_G8R8_SINT, SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
> + { PIPE_FORMAT_A8B8G8R8_SINT, SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
> + { PIPE_FORMAT_X8B8G8R8_SINT, SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
> };
>
>
> --
> 1.8.5.6
>
> ___
> 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] [PATCH] loader: fix the no-modifiers case
Normally modifiers take precendence over use flags, as they are more
explicit. But if the driver supports modifiers, but the xserver does
not, then we should fallback to the old mechanism of allocating a buffer
using 'use' flags.
Fixes: 069fdd5f9facbd72fb6a289696c7b74e3237e70f
Signed-off-by: Rob Clark
---
Backport note: This fixes an issue with enabling UBWC in freedreno/a6xx
(which is something I'd like to land soonish, but not something that
exists yet in release branches). Unless a similar issue is reported in
other drivers, this may not be worth backporting to release branches, at
least not until it has had some soak time in master.
Backtrace to explain the issue:
Breakpoint 1, fd_resource_create_with_modifiers (pscreen=0x574ae0,
tmpl=0x7fdbf0, modifiers=0x7fdb38, count=1)
at ../src/gallium/drivers/freedreno/freedreno_resource.c:838
838 struct fd_screen *screen = fd_screen(pscreen);
1: *tmpl = {reference = {count = 0}, width0 = 800, height0 = 600, depth0 = 1,
array_size = 1, format = PIPE_FORMAT_B8G8R8A8_UNORM,
target = PIPE_TEXTURE_2D, last_level = 0, nr_samples = 0,
nr_storage_samples = 0, usage = 0, bind = 1572874, flags = 0, next = 0x0,
screen = 0x0}
(gdb) bt
#0 fd_resource_create_with_modifiers (pscreen=0x574ae0, tmpl=0x7fdbf0,
modifiers=0x7fdb38, count=1) at
../src/gallium/drivers/freedreno/freedreno_resource.c:838
#1 0x007fbde0 in fd_resource_create (pscreen=0x574ae0,
tmpl=0x7fdbf0) at ../src/gallium/drivers/freedreno/freedreno_resource.c:956
#2 0x007fbe54e2a4 in u_transfer_helper_resource_create
(pscreen=0x574ae0, templ=0x7fdbf0) at
../src/gallium/auxiliary/util/u_transfer_helper.c:126
#3 0x007fbdcc8148 in dri2_create_image_common (_screen=0x570530,
width=800, height=600, format=4099, use=19, modifiers=0x0, count=0,
loaderPrivate=0x6c4160) at ../src/gallium/state_trackers/dri/dri2.c:1039
#4 0x007fbdcc8214 in dri2_create_image (_screen=0x570530, width=800,
height=600, format=4099, use=19, loaderPrivate=0x6c4160) at
../src/gallium/state_trackers/dri/dri2.c:1061
#5 0x007fbec89a30 in dri3_alloc_render_buffer (draw=0x531418,
format=4099, width=800, height=600, depth=24) at
../src/loader/loader_dri3_helper.c:1341
#6 0x007fbec8aab4 in dri3_get_buffer (driDrawable=0x5387b0, format=4099,
buffer_type=loader_dri3_buffer_back, draw=0x531418) at
../src/loader/loader_dri3_helper.c:1822
#7 0x007fbec8b10c in loader_dri3_get_buffers (driDrawable=0x5387b0,
format=4099, stamp=0x64d480, loaderPrivate=0x531418, buffer_mask=1,
buffers=0x7fdf20) at ../src/loader/loader_dri3_helper.c:2021
#8 0x007fbdcc68c4 in dri_image_drawable_get_buffers (drawable=0x64d480,
images=0x7fdf20, statts=0x65ee90, statts_count=2) at
../src/gallium/state_trackers/dri/dri2.c:339
#9 0x007fbdcc6c44 in dri2_allocate_textures (ctx=0x5a7540,
drawable=0x64d480, statts=0x65ee90, statts_count=2) at
../src/gallium/state_trackers/dri/dri2.c:466
#10 0x007fbdccb580 in dri_st_framebuffer_validate (stctx=0x535cf0,
stfbi=0x64d480, statts=0x65ee90, count=2, out=0x7fe0c8) at
../src/gallium/state_trackers/dri/dri_drawable.c:85
#11 0x007fbe048c84 in st_framebuffer_validate (stfb=0x65e9c0,
st=0x535cf0) at ../src/mesa/state_tracker/st_manager.c:222
#12 0x007fbe04a884 in st_api_make_current (stapi=0x7fbe8d90d8
, stctxi=0x535cf0, stdrawi=0x64d480, streadi=0x64d480) at
../src/mesa/state_tracker/st_manager.c:1074
#13 0x007fbdccaf44 in dri_make_current (cPriv=0x67bdc0,
driDrawPriv=0x5387b0, driReadPriv=0x5387b0) at
../src/gallium/state_trackers/dri/dri_context.c:301
#14 0x007fbdcc2910 in driBindContext (pcp=0x67bdc0, pdp=0x5387b0,
prp=0x5387b0) at ../src/mesa/drivers/dri/common/dri_util.c:579
#15 0x007fbec6b7e0 in dri3_bind_context (context=0x51ccd0,
old=0x7fbecd0798 , draw=2097154, read=2097154) at
../src/glx/dri3_glx.c:210
#16 0x007fbec4b010 in MakeContextCurrent (dpy=0x503d00, draw=2097154,
read=2097154, gc_user=0x51ccd0) at ../src/glx/glxcurrent.c:220
#17 0x007fbec4b184 in glXMakeCurrent (dpy=0x503d00, draw=2097154,
gc=0x51ccd0) at ../src/glx/glxcurrent.c:267
#18 0x007fbee8deac in ?? () from /lib64/libGLX.so.0
#19 0x007fbee8f7d4 in ?? () from /lib64/libGLX.so.0
#20 0x0040b330 in GLStateGLX::valid() ()
#21 0x00409a28 in CanvasGeneric::do_make_current() ()
#22 0x0040a4f0 in CanvasGeneric::reset() ()
#23 0x00406714 in main ()
(gdb)
In dri3_alloc_render_buffer() the request gets turned into
createImageWithModifiers() but in dri2_create_image_common() it gets
turned back into pscreen->create_resource() (ie. without modifiers) so
we've lost the information from the 'use' flags that the buffer is
shared and cannot differentiate the allocation from other internal
buffer allocations.
src/loader/loader_dri3_helper.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
Re: [Mesa-dev] [PATCH] svga: add new gallium formats to the format conversion table
Looks good
Reviewed-by: Neha Bhende
Regards,
Neha
From: Brian Paul
Sent: Tuesday, January 22, 2019 11:31:13 AM
To: mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca; Neha Bhende; Marek Olšák
Subject: [PATCH] svga: add new gallium formats to the format conversion table
Fixes a static assertion which broke the build.
Fixes:3ee240890 "gallium: add SINT formats to have exact counterparts to SNORM
formats"
---
src/gallium/drivers/svga/svga_format.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/svga/svga_format.c
b/src/gallium/drivers/svga/svga_format.c
index cf88e33..d751eb0 100644
--- a/src/gallium/drivers/svga/svga_format.c
+++ b/src/gallium/drivers/svga/svga_format.c
@@ -371,6 +371,10 @@ static const struct vgpu10_format_entry
format_conversion_table[] =
{ PIPE_FORMAT_X1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
{ PIPE_FORMAT_A4B4G4R4_UNORM,SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
{ PIPE_FORMAT_R8_SRGB, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
+ { PIPE_FORMAT_A8L8_SINT, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
+ { PIPE_FORMAT_G8R8_SINT, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
+ { PIPE_FORMAT_A8B8G8R8_SINT, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
+ { PIPE_FORMAT_X8B8G8R8_SINT, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
};
--
1.8.5.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/compiler: Reset default flag register in brw_find_live_channel()
emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
flag_subreg set, so that the IR knows which flag is accessed. However
the flag is only used on Gen7 in Align1 mode, and it is used as an
explicit source and destination.
To avoid setting unnecessary bits in the instruction words, get the
information we need and reset the default flag register. This allows
round-tripping through the assembler/disassembler.
---
src/intel/compiler/brw_eu_emit.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 45e2552783b..e6f6d6419d2 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -3312,6 +3312,14 @@ brw_find_live_channel(struct brw_codegen *p, struct
brw_reg dst,
brw_push_insn_state(p);
+ /* The flag register is only used on Gen7 in align1 mode, so avoid setting
+* unnecessary bits in the instruction words, get the information we need
+* and reset the default flag register.
+*/
+ const struct brw_reg flag = brw_flag_reg(p->current->flag_subreg / 2,
+p->current->flag_subreg % 2);
+ brw_set_default_flag_reg(p, 0, 0);
+
if (brw_get_default_access_mode(p) == BRW_ALIGN_1) {
brw_set_default_mask_control(p, BRW_MASK_DISABLE);
@@ -3345,9 +3353,6 @@ brw_find_live_channel(struct brw_codegen *p, struct
brw_reg dst,
*/
inst = brw_FBL(p, vec1(dst), exec_mask);
} else {
- const struct brw_reg flag = brw_flag_reg(p->current->flag_subreg / 2,
- p->current->flag_subreg % 2);
-
brw_set_default_exec_size(p, BRW_EXECUTE_1);
brw_MOV(p, retype(flag, BRW_REGISTER_TYPE_UD), brw_imm_ud(0));
--
2.19.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] svga: add new gallium formats to the format conversion table
Fixes a static assertion which broke the build.
Fixes:3ee240890 "gallium: add SINT formats to have exact counterparts to SNORM
formats"
---
src/gallium/drivers/svga/svga_format.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/svga/svga_format.c
b/src/gallium/drivers/svga/svga_format.c
index cf88e33..d751eb0 100644
--- a/src/gallium/drivers/svga/svga_format.c
+++ b/src/gallium/drivers/svga/svga_format.c
@@ -371,6 +371,10 @@ static const struct vgpu10_format_entry
format_conversion_table[] =
{ PIPE_FORMAT_X1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
{ PIPE_FORMAT_A4B4G4R4_UNORM,SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
{ PIPE_FORMAT_R8_SRGB, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
+ { PIPE_FORMAT_A8L8_SINT, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
+ { PIPE_FORMAT_G8R8_SINT, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
+ { PIPE_FORMAT_A8B8G8R8_SINT, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
+ { PIPE_FORMAT_X8B8G8R8_SINT, SVGA3D_FORMAT_INVALID,
SVGA3D_FORMAT_INVALID, SVGA3D_FORMAT_INVALID, 0 },
};
--
1.8.5.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 16/42] intel/compiler: add instruction setters for Src1Type and Src2Type.
Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/8] i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.
On Tue, Jan 22, 2019 at 01:15:25PM +0200, Eleni Maria Stea wrote: > On 1/22/19 12:46 PM, Eleni Maria Stea wrote: > >>> + /** > >>> +* \brief Indicates that we fake the ETC2 compression support > >>> +* > >>> +* GPUs Gen < 8 don't support sampling and rendering of ETC2 > >>> formats so > >>> +* we need to fake it. This variable is set to true when we > >>> fake it. > >>> +*/ > >>> + bool needs_fake_etc; > >>> + > >> > >> Let's make a function to detect needs_fake_etc instead of adding to > >> the data structure. That'd be easier to follow. > >> > >> -Nanley > > > > > > Hi Nanley, > > > > I'd like a small clarification here if you don't mind: I wasn't very > > sure about this last change you suggest. > > > > The reasons I preferred to extend the data structure instead of adding > > a function were: > > > > 1- that I need to check if we fake ETC in several different places in > > which I don't always have access to the information that helped me > > decide if we need to fake the ETC or not, so I found it much easier to > > keep this information in the miptree that can be accessed from > > everywhere. (That was the main reason). > > Actually, now I better thought of it, I only need the GPU version and if > the format is compressed, so I can probably get this information in all > places but we would still need to make many unnecessary calls... > Couldn't we avoid them by just checking this once at the beginning? > The performance difference should be negligible if the function is declared static inline in the intel_mipmap_tree.h header. The compiler should include the body of function (which should be small) and avoid the overhead of a function call. > Thanks again, > Eleni > > > The other reasons were that: > > 2- I thought that it would be faster to check the miptree than call a > > function. > > 3- I was hoping that from the name of the variable it won't be > > difficult to follow (but I could rename it to something better if you > > prefer it). > > > > Could you explain me why you'd like me to replace it? Is there an > > advantage I hadn't thought of? > > Firstly, it's not information that's generally useful for most intel_mipmap_tree objects. Having too much of such state makes debugging and reading the struct definition more difficult. Secondly, it adds to the amount of state-dependent variables I have to keep in mind when looking at the code. I have to start asking, when is needs_fake_etc initialized? Is needs_fake_etc ever modified later? I'm already familiar with the other variables needs_fake_etc can be computed by: the gen, the miptree format, and the shadow_mt. I hope that helps. -Nanley > > Thank you in advance, > > Eleni > > ___ > > 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 107822] Just Cause 3 Flickering Textures with AMD RADV
https://bugs.freedesktop.org/show_bug.cgi?id=107822 Alexander changed: What|Removed |Added Version|18.2|18.3 -- 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 107822] Just Cause 3 Flickering Textures with AMD RADV
https://bugs.freedesktop.org/show_bug.cgi?id=107822 Alexander changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #8 from Alexander --- I reopened this bug because someone reported this bug in wine-4.0-rc7-esync-staging-amd64 + dxvk 0.95, system kernel linux-5.0.0-rc3 + mesa 19.0 (git) +llvm 7.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] [AppVeyor] mesa master #9820 failed
Build mesa 9820 failed Commit d85917deaf by Marek Olšák on 1/19/2019 12:35 AM: radeonsi: rename rfence -> sfence\n\nReviewed-by: Bas Nieuwenhuizen Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts after hitting 100 merge requests?
On Thu, Jan 17, 2019 at 1:07 PM Daniel Stone wrote: > Hi, > > On Thu, 17 Jan 2019 at 16:35, Jason Ekstrand wrote: > > On January 17, 2019 08:58:03 Erik Faye-Lund < > erik.faye-l...@collabora.com> wrote: > > > Whoops! I meant to say something like "we'd need to be able to > > > distinguis between CI steps that are triggered due to new MRs versus > > > updated MRs, or pushes to existing branches". > > > > > >> Anyway, Jason did actually write that hook, and it's something I'm > > >> happy to host on existing fd.o machines. I just haven't got to doing > > >> it, since I ended up taking my sabbatical a lot more seriously than I > > >> expected, and now I'm back to work I've got a bit of a backlog. But > > >> we > > >> can definitely do it, and pretty soon. > > > > > > Cool, then I won't worry about it, and just assume it'll appear > > > magically soon :) > > > > My script was a total hack. It's probably massively insecure and doesn't > > include any code to provide a diffstat which has been requested by > several > > people. Someone taking it a bit more seriously would probably be good > > before we deploy anything. > > With the caveat that I can no longer see the script because it's been > expired out of the pastebin (why not make a GitLab repo or at least > upload it to a snippet?) ... > https://gitlab.freedesktop.org/jekstrand/gitlab-mailbot > I had the same assumption when you posted it, but came to the > conclusion it was actually OK, or at least would be with very minimal > work. We can configure Apache and GitLab pretty easily so it can only > be triggered with a secret token which is buried in the repo config > and/or accessible only to admins. It calls back into GitLab to get the > changes, so there's no danger of it sending completely arbitrary > content even if someone does figure out how to trigger it when they > shouldn't. It also has GitLab project -> email destination hardcoded > in the script, so there's no danger of it being used to spam arbitrary > addresses either. > That makes me feel a tiny bit better. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/8] i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.
On Tue, Jan 22, 2019 at 02:17:16PM +0200, Eleni Maria Stea wrote:
> On 1/19/19 1:32 AM, Nanley Chery wrote:
> >> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> >> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> >> index e214fae140..4d1eafac91 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> >> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> >> @@ -329,6 +329,17 @@ brw_get_texture_swizzle(const struct gl_context *ctx,
> >> {
> >> const struct gl_texture_image *img = t->Image[0][t->BaseLevel];
> >>
> >> + struct brw_context *brw = brw_context((struct gl_context *)ctx);
> >> + const struct gen_device_info *devinfo = &brw->screen->devinfo;
> >> + bool is_fake_etc = _mesa_is_format_etc2(img->TexFormat) &&
> >> + devinfo->gen < 8;
> >> +
> >> + mesa_format format;
> >> + if (is_fake_etc)
> >> + format = intel_lower_compressed_format(brw, img->TexFormat);
> >> + else
> >> + format = img->TexFormat;
> >> +
> >
> > Why is modifying this function necessary?
>
> Hi,
>
> I'll try to explain this modification:
>
> After the changes we made:
> - the image TexFormat remains ETC2 to match the main miptree's format
> - the main miptree stores the compressed data (ETC2) so that the
> GetCompressed* functions work
> - the shadow miptree stores the RGBA data and we map it for the drawing
>
> This texture swizzle function is called before the drawing and it can't
> access the miptrees. Instead it reads the format of the texture we are
> supposed to have in the memory from the gl_texture_image struct directly
> so in this case it reads the ETC2 format.
>
> At this time, the texture that we have in the memory and is about to be
> used in the drawing is RGBA (from the shadow miptree).
>
> As a result, we end up calculating the swizzle of the ETC2 format used
> in the original image (+the main miptree) for the RGBA texture that we
> have in the memory. As a result the texture is not rendered properly.
>
Oh okay, I was thinking that the swizzles of the ETC2 formats wouldn't
conflict with their decompressed RGBA texture, but I see that the SRGB
ones currently need to have the 1st and 3rd swizzles swapped.
To avoid having to modify this function, could you try the following?
* setting the bgra argument in the decoding function call to false
* updating the mapping in intel_lower_compressed_format() accordingly
-Nanley
> The solution was to use the corresponding RGBA format when we fake the
> ETC2, but as I couldn't read it from the shadow miptree inside this
> function, I took it by calling intel_lower_compressed_format for the
> original ETC2 format of the gl_texture_image.
>
> I hope that this change is more clear now, I will add a comment
> explaining this just in case,
>
> Thank you!
> Eleni
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/8] gallium/util: add a linear allocator for reducing malloc overhead
On Fri, Jan 18, 2019 at 8:22 PM Bas Nieuwenhuizen
wrote:
> On Sat, Jan 19, 2019 at 2:10 AM Marek Olšák wrote:
> >
> > On Fri, Jan 18, 2019 at 6:08 PM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >> On Fri, Jan 18, 2019 at 5:44 PM Marek Olšák wrote:
> >> >
> >> > From: Marek Olšák
> >> >
> >> > ---
> >> > src/gallium/auxiliary/Makefile.sources | 1 +
> >> > src/gallium/auxiliary/meson.build | 1 +
> >> > src/gallium/auxiliary/util/u_cpu_suballoc.h | 90
> +
> >> > 3 files changed, 92 insertions(+)
> >> > create mode 100644 src/gallium/auxiliary/util/u_cpu_suballoc.h
> >> >
> >> > diff --git a/src/gallium/auxiliary/Makefile.sources
> b/src/gallium/auxiliary/Makefile.sources
> >> > index 50e88088ff8..b26415858f6 100644
> >> > --- a/src/gallium/auxiliary/Makefile.sources
> >> > +++ b/src/gallium/auxiliary/Makefile.sources
> >> > @@ -211,20 +211,21 @@ C_SOURCES := \
> >> > util/u_bitmask.c \
> >> > util/u_bitmask.h \
> >> > util/u_blend.h \
> >> > util/u_blit.c \
> >> > util/u_blit.h \
> >> > util/u_blitter.c \
> >> > util/u_blitter.h \
> >> > util/u_box.h \
> >> > util/u_cache.c \
> >> > util/u_cache.h \
> >> > + util/u_cpu_suballoc.h \
> >> > util/u_debug_gallium.h \
> >> > util/u_debug_gallium.c \
> >> > util/u_debug_describe.c \
> >> > util/u_debug_describe.h \
> >> > util/u_debug_flush.c \
> >> > util/u_debug_flush.h \
> >> > util/u_debug_image.c \
> >> > util/u_debug_image.h \
> >> > util/u_debug_memory.c \
> >> > util/u_debug_refcnt.c \
> >> > diff --git a/src/gallium/auxiliary/meson.build
> b/src/gallium/auxiliary/meson.build
> >> > index 57f7e69050f..7e1e4732421 100644
> >> > --- a/src/gallium/auxiliary/meson.build
> >> > +++ b/src/gallium/auxiliary/meson.build
> >> > @@ -231,20 +231,21 @@ files_libgallium = files(
> >> >'util/u_bitmask.c',
> >> >'util/u_bitmask.h',
> >> >'util/u_blend.h',
> >> >'util/u_blit.c',
> >> >'util/u_blit.h',
> >> >'util/u_blitter.c',
> >> >'util/u_blitter.h',
> >> >'util/u_box.h',
> >> >'util/u_cache.c',
> >> >'util/u_cache.h',
> >> > + 'util/u_cpu_suballoc.h',
> >> >'util/u_debug_gallium.h',
> >> >'util/u_debug_gallium.c',
> >> >'util/u_debug_describe.c',
> >> >'util/u_debug_describe.h',
> >> >'util/u_debug_flush.c',
> >> >'util/u_debug_flush.h',
> >> >'util/u_debug_image.c',
> >> >'util/u_debug_image.h',
> >> >'util/u_debug_memory.c',
> >> >'util/u_debug_refcnt.c',
> >> > diff --git a/src/gallium/auxiliary/util/u_cpu_suballoc.h
> b/src/gallium/auxiliary/util/u_cpu_suballoc.h
> >> > new file mode 100644
> >> > index 000..2373c1f7c70
> >> > --- /dev/null
> >> > +++ b/src/gallium/auxiliary/util/u_cpu_suballoc.h
> >> > @@ -0,0 +1,90 @@
> >> >
> +/**
> >> > + *
> >> > + * Copyright 2019 Advanced Micro Devices, Inc.
> >> > + * All Rights Reserved.
> >> > + *
> >> > + * 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, sub license, and/or sell copies of the Software, and
> to
> >> > + * permit persons to whom the Software is furnished to do so,
> subject to
> >> > + * the following conditions:
> >> > + *
> >> > + * The above copyright notice and this permission notice (including
> the
> >> > + * next paragraph) shall be included in all copies or substantial
> portions
> >> > + * of the Software.
> >> > + *
> >> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS
> >> > + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> >> > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> NON-INFRINGEMENT.
> >> > + * IN NO EVENT SHALL AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR
> >> > + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
> CONTRACT,
> >> > + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> >> > + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> >> > + *
> >> > +
> **/
> >> > +
> >> > +/* A simple utility for suballocating out of malloc_aligned. */
> >> > +
> >> > +#ifndef U_CPU_SUBALLOC_H
> >> > +#define U_CPU_SUBALLOC_H
> >> > +
> >> > +#include
> >> > +#include "util/os_memory.h"
> >> > +
> >> > +struct u_cpu_suballoc {
> >> > + unsigned default_size; /* Default size of the buffer, in bytes.
> */
> >> > + unsigned current_size; /* Current size of the buffer, in bytes.
> */
> >> > + unsigned alignment; /* malloc alignment. */
> >> > + unsigned
[Mesa-dev] [AppVeyor] mesa master #9818 failed
Build mesa 9818 failed Commit a75b12ce66 by Lionel Landwerlin on 1/22/2019 5:36 PM: vulkan: make generated enum to strings helpers available from c++\n\nSigned-off-by: Lionel Landwerlin \nReviewed-by: Caio Marcelo de Oliveira Filho Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: improve gathering of load_push_constants with dynamic bindings
For example, if a pipeline has two stages VS and FS. And if only
the fragment stage needs dynamic bindings, we shouldn't allocate
an extra user SGPR for the vertex stage. Of course, if the vertex
stage loads constants, it needs an user SGPR.
This should reduce the number of SET_SH_REG packets that are emitted.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_descriptor_set.c | 3 +++
src/amd/vulkan/radv_descriptor_set.h | 1 +
src/amd/vulkan/radv_shader_info.c| 4 +++-
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_descriptor_set.c
b/src/amd/vulkan/radv_descriptor_set.c
index 526bb77a553..30f982252bb 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -345,6 +345,7 @@ VkResult radv_CreatePipelineLayout(
layout->num_sets = pCreateInfo->setLayoutCount;
unsigned dynamic_offset_count = 0;
+ uint16_t dynamic_shader_stages = 0;
_mesa_sha1_init(&ctx);
@@ -356,6 +357,7 @@ VkResult radv_CreatePipelineLayout(
layout->set[set].dynamic_offset_start = dynamic_offset_count;
for (uint32_t b = 0; b < set_layout->binding_count; b++) {
dynamic_offset_count +=
set_layout->binding[b].array_size * set_layout->binding[b].dynamic_offset_count;
+ dynamic_shader_stages |=
set_layout->dynamic_shader_stages;
if (set_layout->binding[b].immutable_samplers_offset)
_mesa_sha1_update(&ctx,
radv_immutable_samplers(set_layout, set_layout->binding + b),
set_layout->binding[b].array_size * 4 * sizeof(uint32_t));
@@ -365,6 +367,7 @@ VkResult radv_CreatePipelineLayout(
}
layout->dynamic_offset_count = dynamic_offset_count;
+ layout->dynamic_shader_stages = dynamic_shader_stages;
layout->push_constant_size = 0;
for (unsigned i = 0; i < pCreateInfo->pushConstantRangeCount; ++i) {
diff --git a/src/amd/vulkan/radv_descriptor_set.h
b/src/amd/vulkan/radv_descriptor_set.h
index d8431241fd9..7b13c6fb621 100644
--- a/src/amd/vulkan/radv_descriptor_set.h
+++ b/src/amd/vulkan/radv_descriptor_set.h
@@ -85,6 +85,7 @@ struct radv_pipeline_layout {
uint32_t num_sets;
uint32_t push_constant_size;
uint32_t dynamic_offset_count;
+ uint16_t dynamic_shader_stages;
unsigned char sha1[20];
};
diff --git a/src/amd/vulkan/radv_shader_info.c
b/src/amd/vulkan/radv_shader_info.c
index c2e005e63dd..7e5a3789af2 100644
--- a/src/amd/vulkan/radv_shader_info.c
+++ b/src/amd/vulkan/radv_shader_info.c
@@ -512,8 +512,10 @@ radv_nir_shader_info_pass(const struct nir_shader *nir,
struct nir_function *func =
(struct nir_function
*)exec_list_get_head_const(&nir->functions);
- if (options->layout && options->layout->dynamic_offset_count)
+ if (options->layout && options->layout->dynamic_offset_count &&
+ (options->layout->dynamic_shader_stages &
mesa_to_vk_shader_stage(nir->info.stage))) {
info->loads_push_constants = true;
+ }
nir_foreach_variable(variable, &nir->inputs)
gather_info_input_decl(nir, variable, info);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vulkan: make generated enum to strings helpers available from c++
Thanks Caio, pushed to master. On 22/01/2019 18:13, Caio Marcelo de Oliveira Filho wrote: Reviewed-by: Caio Marcelo de Oliveira Filho ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts after hitting 100 merge requests?
On Tue, 2019-01-15 at 07:21 -0500, Rob Clark wrote: > On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli wrote: > > > > > > On 1/14/19 2:36 PM, Daniel Stone wrote: > > > Hi, > > > > > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote: > > > > 5. There's no way with gitlab for Reviewed-by tags to get > > > > automatically applied as part of the merging process. This makes > > > > merging a bit more manual than it needs to be but is really no worse > > > > than it was before. > > > > > > I'm still on the side of not seeing the value in them. Most of the > > > time when I go to pursue someone who reviewed a commit, I'll go to see > > > what came up in review anyway. Maybe someone had the same comment > > > which was found to be not applicable or otherwise explained away. > > > Reviewed-by and Acked-by are also pretty lossy anyway, and freeform > > > text descriptors in a comment can much better capture the intent (e.g. > > > 'I'm strongly OK with the driver changes and weakly OK with the core > > > changes as it's not really my area of expertise'). > > > > > > In other projects, we looked for ways to apply the tags and ended up > > > concluding that they didn't bring enough value to make it worthwhile. > > > I don't know if that holds for Mesa, but it would be better to start > > > with an actual problem statement - what value does R-b bring and how? > > > - then look at ways to solve that problem, rather than just very > > > directly finding a way to insert that literal text string into every > > > commit message. > > > > IMO it brings some 'shared responsibility' for correctness of the patch > > and quickly accessible information on who were looking at the change. So > > ideally later when filing bug against commit/series there would be more > > people than just the committer that should take a look at the possible > > regressions. At least in my experience people filing bugs tend to often > > also CC the reviewer. > > +1 .. and also it is nice to see things like Reported-by/Reviewed-by > without having to go search somewhere else (ie. outside of git/tig) > Maybe something like this could be useful: https://github.com/smarkets/marge-bot > (ofc it would be pretty awesome incentive to switch to gitlab issues > if gitlab could automate adding Reported-by tags for MR's associated > with an issue.. but I guess checkbox to add Reviewed-by tag would > already make my day) > > BR, > -R > > > > FWIW, if you go to > > > https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a > > > hyperlink from the web UI which points you to the MR. The API to do > > > this is pretty straightforward and amenable to piping through jq: > > > https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit > > > > I guess if we would move issue tracking to gitlab then we could possibly > > automate the CC list generation based on commit? > > > > // Tapani > > ___ > > 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 mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vulkan: make generated enum to strings helpers available from c++
Reviewed-by: Caio Marcelo de Oliveira Filho
On Tue, Jan 22, 2019 at 05:36:56PM +, Lionel Landwerlin wrote:
> Signed-off-by: Lionel Landwerlin
> ---
> src/vulkan/util/gen_enum_to_str.py | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/vulkan/util/gen_enum_to_str.py
> b/src/vulkan/util/gen_enum_to_str.py
> index fb9ecd65c6d..06f74eb487c 100644
> --- a/src/vulkan/util/gen_enum_to_str.py
> +++ b/src/vulkan/util/gen_enum_to_str.py
> @@ -101,6 +101,10 @@ H_TEMPLATE = Template(textwrap.dedent(u"""\
> #include
> #include
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> % for ext in extensions:
> #define _${ext.name}_number (${ext.number})
> % endfor
> @@ -109,6 +113,10 @@ H_TEMPLATE = Template(textwrap.dedent(u"""\
> const char * vk_${enum.name[2:]}_to_str(${enum.name} input);
> % endfor
>
> +#ifdef __cplusplus
> +} /* extern "C" */
> +#endif
> +
> #endif"""),
> output_encoding='utf-8')
>
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] MR: WIP: vulkan overlay layer
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/139 The start of a Vulkan layer to display some basic swapchain/draws/submit information. Looks like this : https://i.imgur.com/4zyIiVb.png There is probably plenty of improvements that can be made to get closer to the gallium HUD. -Lionel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa review/arb_gl_spirv-xfb-improvement #9817 completed
Build mesa 9817 completed Commit b1293c8745 by Alejandro Piñeiro on 11/7/2018 9:11 AM: nir/linker: use nir_gather_xfb_info\n\nInstead of a custom ARB_gl_spirv xfb gather info pass.\n\nIn fact, this is not only about reusing code, but the current custom\ncode was not handling properly how many varyings are enumerated from\nsome complex types. So this change is also about fixing some corner\ncases. Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #9816 failed
Build mesa 9816 failed Commit 1cfbed7587 by Marek Olšák on 1/19/2019 12:39 AM: radeonsi: remove r600 from comments\n\nReviewed-by: Bas Nieuwenhuizen Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vulkan: make generated enum to strings helpers available from c++
Signed-off-by: Lionel Landwerlin
---
src/vulkan/util/gen_enum_to_str.py | 8
1 file changed, 8 insertions(+)
diff --git a/src/vulkan/util/gen_enum_to_str.py
b/src/vulkan/util/gen_enum_to_str.py
index fb9ecd65c6d..06f74eb487c 100644
--- a/src/vulkan/util/gen_enum_to_str.py
+++ b/src/vulkan/util/gen_enum_to_str.py
@@ -101,6 +101,10 @@ H_TEMPLATE = Template(textwrap.dedent(u"""\
#include
#include
+#ifdef __cplusplus
+extern "C" {
+#endif
+
% for ext in extensions:
#define _${ext.name}_number (${ext.number})
% endfor
@@ -109,6 +113,10 @@ H_TEMPLATE = Template(textwrap.dedent(u"""\
const char * vk_${enum.name[2:]}_to_str(${enum.name} input);
% endfor
+#ifdef __cplusplus
+} /* extern "C" */
+#endif
+
#endif"""),
output_encoding='utf-8')
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: add etnaviv support for armada drm
Similar configuration to the iMX platform, but interfaces with
the armada-drm driver.
Signed-off-by: Kyle Russell
---
configure.ac | 12 +-
meson.build | 6 -
meson_options.txt | 2 +-
src/gallium/Makefile.am | 4
.../auxiliary/pipe-loader/pipe_loader_drm.c | 5
.../auxiliary/target-helpers/drm_helper.h | 23 ++
.../target-helpers/drm_helper_public.h| 3 +++
src/gallium/drivers/armada/Automake.inc | 9 +++
src/gallium/drivers/armada/Makefile.am| 8 +++
src/gallium/meson.build | 5
src/gallium/targets/dri/Makefile.am | 1 +
src/gallium/targets/dri/meson.build | 3 ++-
src/gallium/targets/dri/target.c | 1 +
src/gallium/winsys/armada/drm/Makefile.am | 11 +
.../winsys/armada/drm/Makefile.sources| 3 +++
.../winsys/armada/drm/armada_drm_public.h | 8 +++
.../winsys/armada/drm/armada_drm_winsys.c | 24 +++
src/gallium/winsys/armada/drm/meson.build | 14 +++
18 files changed, 138 insertions(+), 4 deletions(-)
create mode 100644 src/gallium/drivers/armada/Automake.inc
create mode 100644 src/gallium/drivers/armada/Makefile.am
create mode 100644 src/gallium/winsys/armada/drm/Makefile.am
create mode 100644 src/gallium/winsys/armada/drm/Makefile.sources
create mode 100644 src/gallium/winsys/armada/drm/armada_drm_public.h
create mode 100644 src/gallium/winsys/armada/drm/armada_drm_winsys.c
create mode 100644 src/gallium/winsys/armada/drm/meson.build
diff --git a/configure.ac b/configure.ac
index c7473d77eff..a6c3fa19852 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1408,7 +1408,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast"
AC_ARG_WITH([gallium-drivers],
[AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@],
[comma delimited Gallium drivers list, e.g.
-
"i915,nouveau,r300,r600,radeonsi,freedreno,pl111,svga,swrast,swr,tegra,v3d,vc4,virgl,etnaviv,imx"
+
"i915,nouveau,r300,r600,radeonsi,freedreno,pl111,svga,swrast,swr,tegra,v3d,vc4,virgl,etnaviv,imx,armada"
@<:@default=r300,r600,svga,swrast@:>@])],
[with_gallium_drivers="$withval"],
[with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
@@ -2747,6 +2747,9 @@ if test -n "$with_gallium_drivers"; then
HAVE_GALLIUM_TEGRA=yes
require_libdrm "tegra"
;;
+xarmada)
+HAVE_GALLIUM_ARMADA=yes
+;;
xswrast)
HAVE_GALLIUM_SOFTPIPE=yes
if test "x$enable_llvm" = xyes; then
@@ -2867,6 +2870,10 @@ if test "x$HAVE_GALLIUM_ETNAVIV" != xyes -a
"x$HAVE_GALLIUM_IMX" = xyes ; then
AC_MSG_ERROR([Building with imx requires etnaviv])
fi
+if test "x$HAVE_GALLIUM_ETNAVIV" != xyes -a "x$HAVE_GALLIUM_ARMADA" = xyes ;
then
+ AC_MSG_ERROR([Building with armada requires etnaviv])
+fi
+
if test "x$HAVE_GALLIUM_VC4" != xyes -a "x$HAVE_GALLIUM_PL111" = xyes ; then
AC_MSG_ERROR([Building with pl111 requires vc4])
fi
@@ -2973,6 +2980,7 @@ AM_CONDITIONAL(HAVE_GALLIUM_NOUVEAU, test
"x$HAVE_GALLIUM_NOUVEAU" = xyes)
AM_CONDITIONAL(HAVE_GALLIUM_FREEDRENO, test "x$HAVE_GALLIUM_FREEDRENO" = xyes)
AM_CONDITIONAL(HAVE_GALLIUM_ETNAVIV, test "x$HAVE_GALLIUM_ETNAVIV" = xyes)
AM_CONDITIONAL(HAVE_GALLIUM_IMX, test "x$HAVE_GALLIUM_IMX" = xyes)
+AM_CONDITIONAL(HAVE_GALLIUM_ARMADA, test "x$HAVE_GALLIUM_ARMADA" = xyes)
AM_CONDITIONAL(HAVE_GALLIUM_TEGRA, test "x$HAVE_GALLIUM_TEGRA" = xyes)
AM_CONDITIONAL(HAVE_GALLIUM_SOFTPIPE, test "x$HAVE_GALLIUM_SOFTPIPE" = xyes)
AM_CONDITIONAL(HAVE_GALLIUM_LLVMPIPE, test "x$HAVE_GALLIUM_LLVMPIPE" = xyes)
@@ -3124,6 +3132,7 @@ AC_CONFIG_FILES([Makefile
src/gallium/drivers/swr/Makefile
src/gallium/drivers/tegra/Makefile
src/gallium/drivers/etnaviv/Makefile
+ src/gallium/drivers/armada/Makefile
src/gallium/drivers/imx/Makefile
src/gallium/drivers/v3d/Makefile
src/gallium/drivers/vc4/Makefile
@@ -3159,6 +3168,7 @@ AC_CONFIG_FILES([Makefile
src/gallium/tests/trivial/Makefile
src/gallium/tests/unit/Makefile
src/gallium/winsys/etnaviv/drm/Makefile
+ src/gallium/winsys/armada/drm/Makefile
src/gallium/winsys/imx/drm/Makefile
src/gallium/winsys/freedreno/drm/Makefile
src/gallium/winsys/i915/drm/Makefile
diff --git a/meson.build b/meson.build
index c5bc94720d6..6536a38e790 100644
--- a/meson.build
+++ b/meson.build
@@ -132,7 +132,7 @@ if _drivers.contains('auto')
elif ['arm', 'aarch64'].contains(host_machine.cpu_family())
_drivers = [
'pl111', 'v3d', 'vc4', 'freedreno', 'etnaviv', 'imx', 'nouveau',
-'tegra', 'virg
Re: [Mesa-dev] [PATCH] st/mesa: fix PRIMITIVES_GENERATED query after the "pipeline stat single" changes
ping
On Fri, Jan 18, 2019 at 11:27 AM Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_cb_queryobj.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
> b/src/mesa/state_tracker/st_cb_queryobj.c
> index abb126547c9..642b901d05a 100644
> --- a/src/mesa/state_tracker/st_cb_queryobj.c
> +++ b/src/mesa/state_tracker/st_cb_queryobj.c
> @@ -84,21 +84,22 @@ st_DeleteQuery(struct gl_context *ctx, struct
> gl_query_object *q)
> struct st_query_object *stq = st_query_object(q);
>
> free_queries(pipe, stq);
>
> free(stq);
> }
>
> static int
> target_to_index(const struct st_context *st, const struct gl_query_object
> *q)
> {
> - if (q->Target == GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN ||
> + if (q->Target == GL_PRIMITIVES_GENERATED ||
> + q->Target == GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN ||
> q->Target == GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB)
>return q->Stream;
>
> if (st->has_single_pipe_stat) {
>switch (q->Target) {
>case GL_VERTICES_SUBMITTED_ARB:
> return PIPE_STAT_QUERY_IA_VERTICES;
>case GL_PRIMITIVES_SUBMITTED_ARB:
> return PIPE_STAT_QUERY_IA_PRIMITIVES;
>case GL_VERTEX_SHADER_INVOCATIONS_ARB:
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105371] r600_shader_from_tgsi - GPR limit exceeded - shader requires 360 registers
https://bugs.freedesktop.org/show_bug.cgi?id=105371 --- Comment #21 from amonpaike --- (In reply to mirh from comment #20) > A couple of devs are working into reinventing the wheel so that you could > basically have r600 cards work and be supported almost like they had been > released in 2018 (well, sans vulkan) > > And you have been already provided with an explanation of why this is kinda > difficult to debug, and with a workaround. > So please, just wait. sorry if I asked for solicitation, it was because nobody answered, I did not know about this .. so is someone rewriting these drivers? Is there a new branch or something? -- 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] st/mesa: purge framebuffers when unbinding a context
From: Marek Olšák
This fixes pipe_surface "leaks".
Cc: 18.3
---
src/mesa/state_tracker/st_manager.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index 7a3d9777101..7064b99743c 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -1088,21 +1088,26 @@ st_api_make_current(struct st_api *stapi, struct
st_context_iface *stctxi,
st_framebuffer_reference(&stdraw, NULL);
st_framebuffer_reference(&stread, NULL);
/* Purge the context's winsys_buffers list in case any
* of the referenced drawables no longer exist.
*/
st_framebuffers_purge(st);
}
else {
+ GET_CURRENT_CONTEXT(ctx);
+
ret = _mesa_make_current(NULL, NULL, NULL);
+
+ if (ctx)
+ st_framebuffers_purge(ctx->st);
}
return ret;
}
static void
st_api_destroy(struct st_api *stapi)
{
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] configure: EGL requirements only apply if EGL is built
On Tuesday, 2019-01-22 13:32:15 +, Emil Velikov wrote:
> On Mon, 21 Jan 2019 at 19:53, Eric Engestrom wrote:
> >
> AFAICT this triggers when egl is explicitly disabled and drm is
> explicitly listed in the with-platforms list.
> Please add the triggering configure line to the commit message.
Yes sorry, that's exactly how I hit this error:
--disable-{egl,gbm,glx} --with-platform=drm
Added to the commit message.
>
>
> > Fixes: 2c4f6ceeb466cb15df34 "configure.ac: Fail if egl x11 platform
> > dependencies are not available"
> > Signed-off-by: Eric Engestrom
>
> The above fixes commit caters only for egl-platforms. So I think we'd
> want the one below instead.
>
> Fixes: 3208fd2e46b ("configure: move platform handling further up")
Fair, I may have gone too far back in time :]
> Reviewed-by: Emil Velikov
Thanks :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: try to select better export formats for chips without Rb+
For some R8 formats, it's useless to export two channels
when no alpha blending is used. I assume the CB should
automatically clamps its inputs.
29077 shaders in 15096 tests
Totals:
SGPRS: 1321106 -> 1320970 (-0.01 %)
VGPRS: 935936 -> 935948 (0.00 %)
Spilled SGPRs: 25186 -> 25204 (0.07 %)
Code Size: 49813556 -> 49796944 (-0.03 %) bytes
Max Waves: 242091 -> 242088 (-0.00 %)
Totals from affected shaders:
SGPRS: 170608 -> 170472 (-0.08 %)
VGPRS: 99752 -> 99764 (0.01 %)
Spilled SGPRs: 10377 -> 10395 (0.17 %)
Code Size: 6332492 -> 6315880 (-0.26 %) bytes
Max Waves: 12317 -> 12314 (-0.02 %)
This helps some Rise Of Tomb Raider shaders, especially
when an expcnt instruction is added between two MRT exports.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 138e153f9a4..25281c3c6da 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -372,9 +372,10 @@ static bool is_dual_src(VkBlendFactor factor)
}
}
-static unsigned si_choose_spi_color_format(VkFormat vk_format,
- bool blend_enable,
- bool blend_need_alpha)
+static unsigned si_choose_spi_color_format(struct radv_device *device,
+ VkFormat vk_format,
+ bool blend_enable,
+ bool blend_need_alpha)
{
const struct vk_format_description *desc =
vk_format_description(vk_format);
unsigned format, ntype, swap;
@@ -486,6 +487,20 @@ static unsigned si_choose_spi_color_format(VkFormat
vk_format,
unreachable("unhandled blend format");
}
+ if (device && /* NULL for internal meta formats */
+ !device->physical_device->rbplus_allowed) {
+ /* Try to select better export formats for chips without Rb+. */
+ if (desc->nr_channels == 1 &&
+ desc->channel[0].size == 8 &&
+ swap == V_028C70_SWAP_STD && /* R */
+ !vk_format_is_srgb(vk_format)) {
+ /* Do not need to export two channels for some R8
+* formats when alpha blending isn't used.
+*/
+ blend = normal = V_028714_SPI_SHADER_32_R;
+ }
+ }
+
if (blend_enable && blend_need_alpha)
return blend_alpha;
else if(blend_need_alpha)
@@ -516,7 +531,8 @@ radv_pipeline_compute_spi_color_formats(struct
radv_pipeline *pipeline,
bool blend_enable =
blend->blend_enable_4bit & (0xfu << (i * 4));
- cf = si_choose_spi_color_format(attachment->format,
+ cf = si_choose_spi_color_format(pipeline->device,
+ attachment->format,
blend_enable,
blend->need_src_alpha &
(1 << i));
}
@@ -586,7 +602,8 @@ const VkFormat
radv_fs_key_format_exemplars[NUM_META_FS_KEYS] = {
unsigned radv_format_meta_fs_key(VkFormat format)
{
- unsigned col_format = si_choose_spi_color_format(format, false, false);
+ unsigned col_format =
+ si_choose_spi_color_format(NULL, format, false, false);
assert(col_format != V_028714_SPI_SHADER_32_AR);
if (col_format >= V_028714_SPI_SHADER_32_AR)
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] configure: EGL requirements only apply if EGL is built
On Mon, 21 Jan 2019 at 19:53, Eric Engestrom wrote:
>
AFAICT this triggers when egl is explicitly disabled and drm is
explicitly listed in the with-platforms list.
Please add the triggering configure line to the commit message.
> Fixes: 2c4f6ceeb466cb15df34 "configure.ac: Fail if egl x11 platform
> dependencies are not available"
> Signed-off-by: Eric Engestrom
The above fixes commit caters only for egl-platforms. So I think we'd
want the one below instead.
Fixes: 3208fd2e46b ("configure: move platform handling further up")
Reviewed-by: Emil Velikov
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/8] i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.
On 1/19/19 1:32 AM, Nanley Chery wrote:
>> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
>> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
>> index e214fae140..4d1eafac91 100644
>> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
>> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
>> @@ -329,6 +329,17 @@ brw_get_texture_swizzle(const struct gl_context *ctx,
>> {
>> const struct gl_texture_image *img = t->Image[0][t->BaseLevel];
>>
>> + struct brw_context *brw = brw_context((struct gl_context *)ctx);
>> + const struct gen_device_info *devinfo = &brw->screen->devinfo;
>> + bool is_fake_etc = _mesa_is_format_etc2(img->TexFormat) &&
>> + devinfo->gen < 8;
>> +
>> + mesa_format format;
>> + if (is_fake_etc)
>> + format = intel_lower_compressed_format(brw, img->TexFormat);
>> + else
>> + format = img->TexFormat;
>> +
>
> Why is modifying this function necessary?
Hi,
I'll try to explain this modification:
After the changes we made:
- the image TexFormat remains ETC2 to match the main miptree's format
- the main miptree stores the compressed data (ETC2) so that the
GetCompressed* functions work
- the shadow miptree stores the RGBA data and we map it for the drawing
This texture swizzle function is called before the drawing and it can't
access the miptrees. Instead it reads the format of the texture we are
supposed to have in the memory from the gl_texture_image struct directly
so in this case it reads the ETC2 format.
At this time, the texture that we have in the memory and is about to be
used in the drawing is RGBA (from the shadow miptree).
As a result, we end up calculating the swizzle of the ETC2 format used
in the original image (+the main miptree) for the RGBA texture that we
have in the memory. As a result the texture is not rendered properly.
The solution was to use the corresponding RGBA format when we fake the
ETC2, but as I couldn't read it from the shadow miptree inside this
function, I took it by calling intel_lower_compressed_format for the
original ETC2 format of the gl_texture_image.
I hope that this change is more clear now, I will add a comment
explaining this just in case,
Thank you!
Eleni
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0
Hello, Could somebody help me with a push of the following patch? https://patchwork.freedesktop.org/patch/254397 This fix is needed to fix these fails: https://mesa-ci.01.org/global_logic/builds/56/group/ac3c5a0dc1f15492570367c6c8ec835c When this fix is pushed we will be able to remove the following test: tex-upside-down-miptree from Intel CI "[expected-crashes]" sections. Thanks, Andrii. On Mon, Jan 14, 2019 at 3:05 PM andrey simiklit wrote: > Hello, > > The test for this issue is pushed to the piglit. > It would be great to push the mesa fix too if it is still an acceptable > for all :) > > Thanks, > Andrii. > On Sat, Oct 20, 2018 at 12:29 PM andrey simiklit > wrote: > >> Hello, >> >> On Fri, Oct 19, 2018 at 15:14 Kenneth Graunke >> wrote: >> >>> On Thursday, October 11, 2018 12:12:38 PM PDT Kenneth Graunke wrote: >>> > On Thursday, October 11, 2018 11:58:40 AM PDT Kenneth Graunke wrote: >>> > > On Tuesday, October 2, 2018 9:16:01 AM PDT asimiklit.w...@gmail.com >>> wrote: >>> > > > From: Andrii Simiklit >>> > > > >>> > > > I guess that when we calculating the width0, height0, depth0 >>> > > > to use for function 'intel_miptree_create' we need to consider >>> > > > the 'base level' like it is done in the >>> 'intel_miptree_create_for_teximage' >>> > > > function. >>> > > > >>> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987 >>> > > > Signed-off-by: Andrii Simiklit >>> > > > --- >>> > > > .../drivers/dri/i965/intel_tex_validate.c | 26 >>> ++- >>> > > > 1 file changed, 25 insertions(+), 1 deletion(-) >>> > > >>> > > I believe this patch is correct - we're assembling things into a new >>> > > miptree, which we start at level 0 - so we need the sizes for level >>> 0. >>> > > >>> > > Alternatively, we might be able to pass validate_first_level instead >>> > > of 0 when calling intel_miptree_create, to make one that's only good >>> > > up until the new base...and have to re-assemble it the next time they >>> > > change the base. It would save memory potentially. But more copies. >>> > > I don't have a strong preference which is better. >>> > > >>> > > Please do make a Piglit or dEQP test for this. >>> > > >>> > > Reviewed-by: Kenneth Graunke >>> > >>> > Sorry, withdrawing my review. :( Chris Forbes pointed out on IRC that >>> > your reproducer case is backwards: >>> > >>> > miplevel 0 - 1x1 >>> > miplevel 1 - 2x2 >>> > miplevel 2 - 4x4 >>> > >>> > That's upside down. A proper miptree would have the base be largest: >>> > >>> > miplevel 0 - 4x4 >>> > miplevel 1 - 2x2 >>> > miplevel 2 - 1x1 >>> > >>> > So, yes, I could see this tripping an assert...but such a crazy texture >>> > will never be mipmap complete. If they're expecting mipmapping, then >>> > it seems like they should get a fallback black texture (which normally >>> > happens for incomplete textures). If not, maybe they should get a >>> > single miplevel? Either way, seems like we should detect insanity and >>> > bail, rather than change size calculations for the normal sane case. >>> > >>> >>> So...looked at this again. I'm not sure why upside-down matters. >>> >>> At DrawArrays time, we have a single miplevel (base = 2), and are trying >>> to put that single miplevel's image into a miptree. We do properly >>> ignore levels 0..1 as they're beyond the base. >>> >>> We appear to use level 0 as the actual base, and want to store our >>> single level at level 2. Other places (TexImage) seem to work that way >>> too. >>> >>> But, we're creating the miplevel with level 0 as the base, but where >>> level 0 has the dimensions of level 2. This doesn't work. And your >>> patch fixes that. >>> >>> I tried making the actual base of the unified tree be level 2, rather >>> than level 0...so that the BaseLevel is the actual base...but tons of >>> things broke. >>> >>> So, back to Reviewed-by. I think once we get a Piglit test, I'm happy >>> to land this patch. >> >> >> Thanks for reviewing :-) I will start to work on it as soon as come back >> from vacation (on Monday) >> >> >>> >>> --Ken >> >> >> Thanks, >> Andrii. >> > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/8] i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.
On 1/22/19 12:46 PM, Eleni Maria Stea wrote: >>> + /** >>> +* \brief Indicates that we fake the ETC2 compression support >>> +* >>> +* GPUs Gen < 8 don't support sampling and rendering of ETC2 >>> formats so >>> +* we need to fake it. This variable is set to true when we >>> fake it. >>> +*/ >>> + bool needs_fake_etc; >>> + >> >> Let's make a function to detect needs_fake_etc instead of adding to >> the data structure. That'd be easier to follow. >> >> -Nanley > > > Hi Nanley, > > I'd like a small clarification here if you don't mind: I wasn't very > sure about this last change you suggest. > > The reasons I preferred to extend the data structure instead of adding > a function were: > > 1- that I need to check if we fake ETC in several different places in > which I don't always have access to the information that helped me > decide if we need to fake the ETC or not, so I found it much easier to > keep this information in the miptree that can be accessed from > everywhere. (That was the main reason). Actually, now I better thought of it, I only need the GPU version and if the format is compressed, so I can probably get this information in all places but we would still need to make many unnecessary calls... Couldn't we avoid them by just checking this once at the beginning? Thanks again, Eleni > The other reasons were that: > 2- I thought that it would be faster to check the miptree than call a > function. > 3- I was hoping that from the name of the variable it won't be > difficult to follow (but I could rename it to something better if you > prefer it). > > Could you explain me why you'd like me to replace it? Is there an > advantage I hadn't thought of? > > Thank you in advance, > Eleni > ___ > 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
Re: [Mesa-dev] [PATCH] nv50,nvc0: mark textures dirty on fb update
Reviewed-by: Karol Herbst On Mon, Jan 21, 2019 at 4:27 AM Ilia Mirkin wrote: > > We may have to flush the cache if there are any textures presently bound > that refer to the outgoing framebuffer. This is only checked at > validation time. > > Fixes a number of dEQP-GLES3.functional.fbo.color.repeated_clear.sample.* > tests, which would bind a texture, then clear it while the binding was > in effect, and then render to a different texture. This seems legal > under the "no feedback loops" rule. > > Signed-off-by: Ilia Mirkin > --- > src/gallium/drivers/nouveau/nv50/nv50_state.c | 2 +- > src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 4 +++- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state.c > b/src/gallium/drivers/nouveau/nv50/nv50_state.c > index 629613bded8..292eab80b4f 100644 > --- a/src/gallium/drivers/nouveau/nv50/nv50_state.c > +++ b/src/gallium/drivers/nouveau/nv50/nv50_state.c > @@ -962,7 +962,7 @@ nv50_set_framebuffer_state(struct pipe_context *pipe, > > util_copy_framebuffer_state(&nv50->framebuffer, fb); > > - nv50->dirty_3d |= NV50_NEW_3D_FRAMEBUFFER; > + nv50->dirty_3d |= NV50_NEW_3D_FRAMEBUFFER | NV50_NEW_3D_TEXTURES; > } > > static void > diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c > b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c > index 9653de86fe9..53ad47c6ed4 100644 > --- a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c > +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c > @@ -852,7 +852,9 @@ nvc0_set_framebuffer_state(struct pipe_context *pipe, > > util_copy_framebuffer_state(&nvc0->framebuffer, fb); > > -nvc0->dirty_3d |= NVC0_NEW_3D_FRAMEBUFFER | NVC0_NEW_3D_SAMPLE_LOCATIONS; > +nvc0->dirty_3d |= NVC0_NEW_3D_FRAMEBUFFER | NVC0_NEW_3D_SAMPLE_LOCATIONS > | > + NVC0_NEW_3D_TEXTURES; > +nvc0->dirty_cp |= NVC0_NEW_CP_TEXTURES; > } > > static void > -- > 2.19.2 > > ___ > 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
Re: [Mesa-dev] [PATCH 3/8] i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.
> > + /** > > +* \brief Indicates that we fake the ETC2 compression support > > +* > > +* GPUs Gen < 8 don't support sampling and rendering of ETC2 > > formats so > > +* we need to fake it. This variable is set to true when we > > fake it. > > +*/ > > + bool needs_fake_etc; > > + > > Let's make a function to detect needs_fake_etc instead of adding to > the data structure. That'd be easier to follow. > > -Nanley Hi Nanley, I'd like a small clarification here if you don't mind: I wasn't very sure about this last change you suggest. The reasons I preferred to extend the data structure instead of adding a function were: 1- that I need to check if we fake ETC in several different places in which I don't always have access to the information that helped me decide if we need to fake the ETC or not, so I found it much easier to keep this information in the miptree that can be accessed from everywhere. (That was the main reason). The other reasons were that: 2- I thought that it would be faster to check the miptree than call a function. 3- I was hoping that from the name of the variable it won't be difficult to follow (but I could rename it to something better if you prefer it). Could you explain me why you'd like me to replace it? Is there an advantage I hadn't thought of? Thank you in advance, Eleni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109258] Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1
https://bugs.freedesktop.org/show_bug.cgi?id=109258 Eric Engestrom changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #6 from Eric Engestrom --- (In reply to n3rdopolis from comment #5) > Created attachment 143147 [details] [review] > Reverse 47273d7312cb5b5b6b0b9faa814d574bbbce1c01 > > Weston and Gnome shell work with LIBGL_ALWAYS_SOFTWARE with this patch, but > all I did was revert commit 47273d7312cb5b5b6b0b9faa814d574bbbce1c01 and > then changed up the conflicts. This revert makes Mesa ignore LIBGL_ALWAYS_SOFTWARE for the drm (and android) platforms. This is making it "work" by not doing what the user asked for, which is not what we want. DRM does not have a software path yet, hence the /* Not supported yet */ if (disp->Options.ForceSoftware) return EGL_FALSE; in dri2_initialize_drm() If a software DRM path is needed, then patches to implement it are welcome :) I have to admit for rendering I'm not sure what needs to be done there, but for display if you don't have a DRM driver you can use VKMS. I'm closing this as NOTABUG, as EGL is working as intended. If a wayland compositor want to discard the user's instructions and use the hardware when given LIBGL_ALWAYS_SOFTWARE, it needs to override the env var (set to `0` or simply unset) before calling eglInitialize(). -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/dri2: try to bind old context if bindContext failed
Hi Luigi,
Luigi Santivetti writes:
> Before this change, if bindContext() failed then dri2_make_current() would
> rebind the old EGL context and surfaces and return EGL_BAD_MATCH. However,
> it wouldn't rebind the DRI context and surfaces, thus leaving it in an
> inconsistent and unrecoverable state.
>
> After this change, dri2_make_current() tries to bind the old DRI context
> and surfaces when bindContext() failed. If unable to do so, it leaves EGL
> and the DRI driver in a consistent state, it reports an error and returns
> EGL_BAD_MATCH.
>
> Fixes: 4e8f95f64d004aa1 ("egl_dri2: Always unbind old contexts")
>
> Signed-off-by: Luigi Santivetti
> ---
> src/egl/drivers/dri2/egl_dri2.c | 54 ++---
> 1 file changed, 43 insertions(+), 11 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index dca22762047..016a3ced96d 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1648,8 +1648,9 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
> _EGLSurface *dsurf,
> _EGLSurface *old_dsurf, *old_rsurf;
> _EGLSurface *tmp_dsurf, *tmp_rsurf;
> __DRIdrawable *ddraw, *rdraw;
> - __DRIcontext *cctx;
> + __DRIcontext *cctx, *old_cctx;
> EGLBoolean unbind;
> + EGLint egl_error;
>
> if (!dri2_dpy)
>return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent");
> @@ -1674,7 +1675,7 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
> _EGLSurface *dsurf,
> cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
>
> if (old_ctx) {
> - __DRIcontext *old_cctx = dri2_egl_context(old_ctx)->dri_context;
> + old_cctx = dri2_egl_context(old_ctx)->dri_context;
>
>if (old_dsurf)
> dri2_surf_update_fence_fd(old_ctx, disp, old_dsurf);
> @@ -1691,17 +1692,24 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
> _EGLSurface *dsurf,
> unbind = (cctx == NULL && ddraw == NULL && rdraw == NULL);
>
> if (!unbind && !dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
> + __DRIdrawable *old_ddraw, *old_rdraw;
> +
> + /* dri2_dpy->core->bindContext failed. We cannot tell for sure why, but
> + * setting the error to EGL_BAD_MATCH is surely better than leaving it
> + * as EGL_SUCCESS.
> + */
> + egl_error = EGL_BAD_MATCH;
> +
> + old_ddraw = (old_dsurf) ? dri2_dpy->vtbl->get_dri_drawable(old_dsurf)
> : NULL;
> + old_rdraw = (old_rsurf) ? dri2_dpy->vtbl->get_dri_drawable(old_rsurf)
> : NULL;
> + old_cctx = (old_ctx) ? dri2_egl_context(old_ctx)->dri_context : NULL;
> +
>/* undo the previous _eglBindContext */
>_eglBindContext(old_ctx, old_dsurf, old_rsurf, &ctx, &tmp_dsurf,
> &tmp_rsurf);
>assert(&dri2_ctx->base == ctx &&
> tmp_dsurf == dsurf &&
> tmp_rsurf == rsurf);
>
> - if (old_dsurf && _eglSurfaceInSharedBufferMode(old_dsurf) &&
> - old_dri2_dpy->vtbl->set_shared_buffer_mode) {
> - old_dri2_dpy->vtbl->set_shared_buffer_mode(old_disp, old_dsurf,
> true);
> - }
> -
>_eglPutSurface(dsurf);
>_eglPutSurface(rsurf);
>_eglPutContext(ctx);
> @@ -1710,11 +1718,32 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
> _EGLSurface *dsurf,
>_eglPutSurface(old_rsurf);
>_eglPutContext(old_ctx);
>
> - /* dri2_dpy->core->bindContext failed. We cannot tell for sure why, but
> - * setting the error to EGL_BAD_MATCH is surely better than leaving it
> - * as EGL_SUCCESS.
> + /* undo the previous dri2_dpy->core->unbindContext */
> + if (dri2_dpy->core->bindContext(old_cctx, old_ddraw, old_rdraw)) {
> + if (old_dsurf && _eglSurfaceInSharedBufferMode(old_dsurf) &&
> + old_dri2_dpy->vtbl->set_shared_buffer_mode) {
> +old_dri2_dpy->vtbl->set_shared_buffer_mode(old_disp, old_dsurf,
> true);
> + }
> +
> + return _eglError(egl_error, "eglMakeCurrent");
> + }
> +
> + /* We cannot restore the same state as it was before calling
> + * eglMakeCurrent(), but we can keep EGL in a consistent state with
> + * the DRI driver by unbinding the old EGL context and surfaces.
> */
> - return _eglError(EGL_BAD_MATCH, "eglMakeCurrent");
> + ctx = dsurf = rsurf = NULL;
This line causes:
warning: assignment from incompatible pointer type
[-Wincompatible-pointer-types]
With that fixed this gets my:
Reviewed-by: Frank Binns
> + unbind = true;
> +
> + _eglBindContext(ctx, dsurf, rsurf, &old_ctx, &tmp_dsurf, &tmp_rsurf);
> + assert(&dri2_ctx->base == old_ctx &&
> + tmp_dsurf == old_dsurf &&
> + tmp_rsurf == old_rsurf);
> +
> + _eglLog(_EGL_FATAL, "DRI2: failed to rebind the previous context");
> + } else {
> + /* We can no longer fail at this point. */
> + egl_error = EGL_SUCCESS;
> }
>
> dri2_destroy_surface(drv, disp, old_ds
Re: [Mesa-dev] [PATCH v3 25/42] intel/compiler: workaround for SIMD8 half-float MAD in gen8
On Mon, 2019-01-21 at 18:48 -0600, Jason Ekstrand wrote:
> On Mon, Jan 21, 2019 at 4:55 AM Iago Toral wrote:
> > On Fri, 2019-01-18 at 11:51 -0600, Jason Ekstrand wrote:
> > > On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga <
> > > ito...@igalia.com> wrote:
> > > > Broadwell hardware has a bug that manifests in SIMD8 executions
> > > > of
> > > >
> > > > 16-bit MAD instructions when any of the sources is a Y or W
> > > > component.
> > > >
> > > > We pack these components in the same SIMD register as
> > > > components X and
> > > >
> > > > Z respectively, but starting at offset 16B (so they live in the
> > > > second
> > > >
> > > > half of the register). The problem does not exist in SKL or
> > > > later.
> > > >
> > > >
> > > >
> > > > We work around this issue by moving any such sources to a
> > > > temporary
> > > >
> > > > starting at offset 0B. We want to do this after the main
> > > > optimization loop
> > > >
> > > > to prevent copy-propagation and friends to undo the fix.
> > > >
> > > >
> > > >
> > > > Reviewed-by: Topi Pohjolainen
> > > >
> > > > ---
> > > >
> > > > src/intel/compiler/brw_fs.cpp | 48
> > > > +++
> > > >
> > > > src/intel/compiler/brw_fs.h | 1 +
> > > >
> > > > 2 files changed, 49 insertions(+)
> > > >
> > > >
> > > >
> > > > diff --git a/src/intel/compiler/brw_fs.cpp
> > > > b/src/intel/compiler/brw_fs.cpp
> > > >
> > > > index 0b3ec94e2d2..d6096cd667d 100644
> > > >
> > > > --- a/src/intel/compiler/brw_fs.cpp
> > > >
> > > > +++ b/src/intel/compiler/brw_fs.cpp
> > > >
> > > > @@ -6540,6 +6540,48 @@ fs_visitor::optimize()
> > > >
> > > > validate();
> > > >
> > > > }
> > > >
> > > >
> > > >
> > > > +/**
> > > >
> > > > + * Broadwell hardware has a bug that manifests in SIMD8
> > > > executions of 16-bit
> > > >
> > > > + * MAD instructions when any of the sources is a Y or W
> > > > component. We pack
> > > >
> > > > + * these components in the same SIMD register as components X
> > > > and Z
> > > >
> > > > + * respectively, but starting at offset 16B (so they live in
> > > > the second half
> > > >
> > > > + * of the register).
> > >
> > > What exactly do you mean by a Y or W component? Is this for the
> > > case where you have a scalar that happens to land at certain
> > > offsets? Or does it apply to regular stride == 1 MADs? If it
> > > applied in the stride == 1 case, then I really don't see what
> > > this is doing to fix it. It might help if you provided some
> > > before and after assembly example.
> >
> > This happens when a source to a half-float MAD instruction starts
> > at offset 16B, which at the time I wrote this patch, happened when
> > we were packing the Y component or the W component of a 16-bit
> > vec2/vec4 into the second half of a SIMD register. I have an old
> > version of that branch and the CTS tests and was able to reproduce
> > the problem. Here is a code trace which is not working as expected,
> > making some CTS tests fail:
> >
> > send(8) g16<1>UWg19<8,8,1>UD
> > data ( DC byte scattered read, 0, 4)
> > mlen 1 rlen 1 { align1 1Q };
> > mov(8) g14.8<1>HF g16<16,8,2>HF {
> > align1 1Q };
> > mad(8) g18<1>HF-
> > g17<4,4,1>HF g14.8<4,4,1>HF g11<4,4,1>HF { align16 1Q };
> > mov(8) g21<2>W g18<8,8,1>W {
> > align1 1Q };
> >
> > If we run this pass, we would produce the same code, only that we
> > would replace the MAD instruction with this:
> >
> > mov(8) g22<1>HFg14.8<8,8,1>HF {
> > align1 WE_all 1Q };
> > mad(8) g18<1>HF-
> > g17<4,4,1>HF g22<4,4,1>HFg11<4,4,1>HF { align16 1Q };
> >
> > Which makes the test pass.
> >
> > It seems our compiler produces different code now than when I found
> > this and these same tests now pass without this pass because we
> > simply don't hit that scenario any more. It seems as if our
> > shuffling code after a load is not attempting to pack 2 16-bit
> > vector components in each VGRF anymore as we used to do when we
> > implemented 16-bit storage and therefore we no longer hit this
> > scenario. Independently of whether this change was intended or a
> > bug, the hardware bug is there so I think we still want to have
> > code to dea with it.
>
> Thanks for the info! It makes a lot more sense now. Does this only
> apply to wide reads or does it also fail with a stride of 0? Also,
> is it only 16 or is it all non-zero values or everything >= 16? It'd
> be good if we could get more data.
Sure, I have hacked a bit the tests and the old branch/driver code that
triggered the problem and experimented with more scenarios. The
conclusions are:
1. All offsets but 0B fail (tested with 16B, 8B, 4B, 3B, 2B, 1B).2. A
stride of 0 seems to works fine with any offset.
When I port this to the regioning lowering pass I'll make it so we
leave sources wi
