Re: [Mesa-dev] [PATCH 2/3] iris: Create a composite context for both compute and render pipelines
Quoting Kenneth Graunke (2019-03-26 05:52:10) > On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote: > > iris currently uses two distinct GEM contexts to have distinct logical > > HW contexts for the compute and render pipelines. However, using two > > distinct GEM contexts implies that they are distinct timelines, yet as > > they are a single GL context that implies they belong to a single > > timeline from the client perspective. Currently, fences are occasionally > > inserted to order the two timelines. Using 2 GEM contexts, also implies > > that we keep 2 ppGTT for identical buffer state. If we can create a > > single GEM context, with the right capabilities, we can have a single > > VM, a single timeline, but 2 logical HW contexts for the 2 pipelines. > > > > This is allowed through the new context interface that allows VM to be > > shared, timelines to be specified, and for the logical contexts to be > > constructed as the user desires. > > > > Cc: Joonas Lahtinen > > Cc: Kenneth Graunke > > --- > > src/gallium/drivers/iris/iris_batch.c | 16 ++- > > src/gallium/drivers/iris/iris_batch.h | 5 +-- > > src/gallium/drivers/iris/iris_context.c | 56 - > > 3 files changed, 60 insertions(+), 17 deletions(-) > > Hi Chris, > > I don't think that I want the single timeline option. It seems like > we've been moving away from implicit sync for a long time, and the > explicit sync code we have is pretty straightforward and seems to do > the trick. Jason and I also chatted briefly, and we don't necessarily > want to a strict submission-order between render/compute. I disagree if you think this means more implicit sync. It is setting up the GEM context to an exact match of the GL context, by _explicit_ control of the timeline. Then the fences you do export from inside the GL context do not need to be faked to be a composite of the pair of contexts. You still have explicit fences, and you have explicit control over the definition of their timeline. > Separating the VMA from the context state image seems like absolutely > the right thing to do - as you said, they're separate in hardware, > and no real reason to tie it together. I would be in favor of new > uABI for that. > > I don't think there will be much overhead reduction from sharing the > VMA here though. It's very plausible that the compositor might want > to run between render and compute batches, at which point we end up > doing page directory loads anyway. I have also heard rumors about bit > 47 becoming magical at some point which may prohibit us from sharing... Yeah, but that doesn't actually affect the context setup, just how you decide to use it in end. And by that point, you'll be forced into using this new uABI anyway or something entirely different :-p > Context cloning seems OK, but I'm always pretty hesitant to add new > uABI unless it's strictly necessary. In this case, we can do the same > thing with a little bit of userspace code, so I'm not sure it's worth > adding that... Actually you cannot do the same without some of the new uABI either, since previously you did not have all the parameters exposed. > I would love to see an iris patch to use the new > I915_CONTEXT_PARAM_RECOVERABLE option without the other dependencies. https://gitlab.freedesktop.org/ickle/mesa/commit/84d9cb1d8d98a50dcceea19ccbc3836b15cf73ae -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 102639] BadLength (poly request too large or internal Xlib length erro
https://bugs.freedesktop.org/show_bug.cgi?id=102639 --- Comment #3 from peterpen --- This is my first time to visit here using the url and play this http://robloxfreerobuxgenerator.com/ online roblox game its really interesting game here you get the better process for found the roblox game. -- 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 v2] ac: allow to use vec3 for typed/untyped buffer stores/loads with LLVM 9+
27670 shaders in 14347 tests
Totals:
SGPRS: 1231173 -> 1236757 (0.45 %)
VGPRS: 866056 -> 867488 (0.17 %)
Spilled SGPRs: 24201 -> 24169 (-0.13 %)
Code Size: 46134836 -> 46115944 (-0.04 %) bytes
Max Waves: 232287 -> 232070 (-0.09 %)
Totals from affected shaders:
SGPRS: 247624 -> 253208 (2.26 %)
VGPRS: 214952 -> 216384 (0.67 %)
Spilled SGPRs: 63 -> 31 (-50.79 %)
Code Size: 7633772 -> 7614880 (-0.25 %) bytes
Max Waves: 62065 -> 61848 (-0.35 %)
This changes requires LLVM r356755.
v2: - fix llvm 8
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 33 +++--
src/amd/common/ac_llvm_build.h | 1 +
2 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 1123dce2cc8..a816327ce95 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -83,6 +83,7 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
ctx->v2i32 = LLVMVectorType(ctx->i32, 2);
ctx->v3i32 = LLVMVectorType(ctx->i32, 3);
ctx->v4i32 = LLVMVectorType(ctx->i32, 4);
+ ctx->v3f32 = LLVMVectorType(ctx->f32, 3);
ctx->v2f32 = LLVMVectorType(ctx->f32, 2);
ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
ctx->v8i32 = LLVMVectorType(ctx->i32, 8);
@@ -1150,9 +1151,12 @@ ac_build_llvm8_buffer_store_common(struct
ac_llvm_context *ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, 4) - 1;
- const char *type_names[] = {"f32", "v2f32", "v4f32"};
+ if (HAVE_LLVM == 0x800 && func == 2)
+ func = 3; /* Only LLVM 9+ supports vec3 */
+
+ const char *type_names[] = {"f32", "v2f32", "v3f32", "v4f32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
@@ -1334,10 +1338,13 @@ ac_build_llvm8_buffer_load_common(struct
ac_llvm_context *ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, 4) - 1;
- LLVMTypeRef types[] = {ctx->f32, ctx->v2f32, ctx->v4f32};
- const char *type_names[] = {"f32", "v2f32", "v4f32"};
+ if (HAVE_LLVM == 0x800 && func == 2)
+ func = 3; /* Only LLVM 9+ supports vec3 */
+
+ LLVMTypeRef types[] = {ctx->f32, ctx->v2f32, ctx->v3f32, ctx->v4f32};
+ const char *type_names[] = {"f32", "v2f32", "v3f32", "v4f32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
@@ -1490,10 +1497,13 @@ ac_build_llvm8_tbuffer_load(struct ac_llvm_context *ctx,
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, dfmt | (nfmt << 4), 0);
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, 4) - 1;
- LLVMTypeRef types[] = {ctx->i32, ctx->v2i32, ctx->v4i32};
- const char *type_names[] = {"i32", "v2i32", "v4i32"};
+ if (HAVE_LLVM == 0x800 && func == 2)
+ func = 3; /* Only LLVM 9+ supports vec3 */
+
+ LLVMTypeRef types[] = {ctx->i32, ctx->v2i32, ctx->v3i32, ctx->v4i32};
+ const char *type_names[] = {"i32", "v2i32", "v3i32", "v4i32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
@@ -1651,9 +1661,12 @@ ac_build_llvm8_tbuffer_store(struct ac_llvm_context *ctx,
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, dfmt | (nfmt << 4), 0);
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, 4) - 1;
- const char *type_names[] = {"i32", "v2i32", "v4i32"};
+ if (HAVE_LLVM == 0x800 && func == 2)
+ func = 3; /* Only LLVM 9+ supports vec3 */
+
+ const char *type_names[] = {"i32", "v2i32", "v3i32", "v4i32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 9151c743bed..d2f8cd5e08b 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -71,6 +71,7 @@ struct ac_llvm_context {
LLVMTypeRef v3i32;
LLVMTypeRef v4i32;
LLVMTypeRef v2f32;
+ LLVMTypeRef v3f32;
LLVMTypeRef v4f32;
LLVMTypeRef v8i32;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedes
[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 Alex Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #23 from Alex Smith --- Thanks Dylan! I'll close this as not a Mesa bug now. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] ac: fix ac_build_umsb() for 16-bit integer type
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index bf4fe3d8c64..54d91649614 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1982,7 +1982,12 @@ ac_build_umsb(struct ac_llvm_context *ctx,
/* The HW returns the last bit index from MSB, but TGSI/NIR wants
* the index from LSB. Invert it by doing "31 - msb". */
msb = LLVMBuildSub(ctx->builder, highest_bit, msb, "");
- msb = LLVMBuildTruncOrBitCast(ctx->builder, msb, ctx->i32, "");
+
+ if (bitsize == 64) {
+ msb = LLVMBuildTrunc(ctx->builder, msb, ctx->i32, "");
+ } else if (bitsize == 16) {
+ msb = LLVMBuildSExt(ctx->builder, msb, ctx->i32, "");
+ }
/* check for zero */
return LLVMBuildSelect(ctx->builder,
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] ac: fix ac_build_bit_count() for 16-bit integer type
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 7f6b9df080c..8046d08d300 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -2559,6 +2559,8 @@ LLVMValueRef ac_build_bit_count(struct ac_llvm_context
*ctx, LLVMValueRef src0)
result = ac_build_intrinsic(ctx, "llvm.ctpop.i16", ctx->i16,
(LLVMValueRef []) { src0 }, 1,
AC_FUNC_ATTR_READNONE);
+
+ result = LLVMBuildZExt(ctx->builder, result, ctx->i32, "");
break;
default:
unreachable(!"invalid bitsize");
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] ac: fix ac_build_bitfield_reverse() for 16-bit integer type
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 8046d08d300..b0ce7fc98bd 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -2588,6 +2588,8 @@ LLVMValueRef ac_build_bitfield_reverse(struct
ac_llvm_context *ctx,
result = ac_build_intrinsic(ctx, "llvm.bitreverse.i16",
ctx->i16,
(LLVMValueRef []) { src0 }, 1,
AC_FUNC_ATTR_READNONE);
+
+ result = LLVMBuildZExt(ctx->builder, result, ctx->i32, "");
break;
default:
unreachable(!"invalid bitsize");
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] ac: fix ac_find_lsb() for 16-bit integer type
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index b0ce7fc98bd..bf4fe3d8c64 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -2956,6 +2956,8 @@ LLVMValueRef ac_find_lsb(struct ac_llvm_context *ctx,
if (src0_bitsize == 64) {
lsb = LLVMBuildTrunc(ctx->builder, lsb, ctx->i32, "");
+ } else if (src0_bitsize == 16) {
+ lsb = LLVMBuildSExt(ctx->builder, lsb, ctx->i32, "");
}
/* TODO: We need an intrinsic to skip this conditional. */
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] ac/nir: fix nir_op_b2i16
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 2321fed69f3..d74693ddd68 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -344,10 +344,16 @@ static LLVMValueRef emit_b2i(struct ac_llvm_context *ctx,
{
LLVMValueRef result = LLVMBuildAnd(ctx->builder, src0, ctx->i32_1, "");
- if (bitsize == 32)
+ switch (bitsize) {
+ case 16:
+ return LLVMBuildTrunc(ctx->builder, result, ctx->i16, "");
+ case 32:
return result;
-
- return LLVMBuildZExt(ctx->builder, result, ctx->i64, "");
+ case 64:
+ return LLVMBuildZExt(ctx->builder, result, ctx->i64, "");
+ default:
+ unreachable("Unsupported bit size.");
+ }
}
static LLVMValueRef emit_i2b(struct ac_llvm_context *ctx,
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] ac: add support for more types with struct/raw LLVM intrinsics
LLVM 9+ now supports 8-bit and 16-bit types.
This changes requires LLVM r356465.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 51 +++---
1 file changed, 28 insertions(+), 23 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index a816327ce95..88df82dcc54 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1136,6 +1136,7 @@ ac_build_llvm8_buffer_store_common(struct ac_llvm_context
*ctx,
LLVMValueRef voffset,
LLVMValueRef soffset,
unsigned num_channels,
+ LLVMTypeRef base_type,
bool glc,
bool slc,
bool writeonly_memory,
@@ -1151,21 +1152,22 @@ ac_build_llvm8_buffer_store_common(struct
ac_llvm_context *ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 4) - 1;
+ unsigned func = CLAMP(num_channels, 1, 4);
+ const char *indexing_kind = structurized ? "struct" : "raw";
+ char name[256], type_name[8];
- if (HAVE_LLVM == 0x800 && func == 2)
- func = 3; /* Only LLVM 9+ supports vec3 */
+ if (HAVE_LLVM == 0x800 && func == 3)
+ func = 4; /* Only LLVM 9+ supports vec3 */
- const char *type_names[] = {"f32", "v2f32", "v3f32", "v4f32"};
- const char *indexing_kind = structurized ? "struct" : "raw";
- char name[256];
+ LLVMTypeRef type = func > 1 ? LLVMVectorType(base_type, func) :
base_type;
+ ac_build_type_name_for_intr(type, type_name, sizeof(type_name));
if (use_format) {
snprintf(name, sizeof(name),
"llvm.amdgcn.%s.buffer.store.format.%s",
-indexing_kind, type_names[func]);
+indexing_kind, type_name);
} else {
snprintf(name, sizeof(name), "llvm.amdgcn.%s.buffer.store.%s",
-indexing_kind, type_names[func]);
+indexing_kind, type_name);
}
ac_build_intrinsic(ctx, name, ctx->voidt, args, idx,
@@ -1185,8 +1187,8 @@ ac_build_buffer_store_format(struct ac_llvm_context *ctx,
if (HAVE_LLVM >= 0x800) {
ac_build_llvm8_buffer_store_common(ctx, rsrc, data, vindex,
voffset, NULL, num_channels,
- glc, false, writeonly_memory,
- true, true);
+ ctx->f32, glc, false,
+ writeonly_memory, true,
true);
} else {
ac_build_buffer_store_common(ctx, rsrc, data, vindex, voffset,
num_channels, glc, false,
@@ -1249,6 +1251,7 @@ ac_build_buffer_store_dword(struct ac_llvm_context *ctx,
ctx->i32_0,
voffset, offset,
num_channels,
+ ctx->f32,
glc, slc,
writeonly_memory,
false, false);
@@ -1324,6 +1327,7 @@ ac_build_llvm8_buffer_load_common(struct ac_llvm_context
*ctx,
LLVMValueRef voffset,
LLVMValueRef soffset,
unsigned num_channels,
+ LLVMTypeRef base_type,
bool glc,
bool slc,
bool can_speculate,
@@ -1338,26 +1342,26 @@ ac_build_llvm8_buffer_load_common(struct
ac_llvm_context *ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 4) - 1;
+ unsigned func = CLAMP(num_channels, 1, 4);
- if (HAVE_LLVM == 0x800 && func == 2)
- func = 3; /* Only LLVM 9+ supports vec3 */
+ if (HAVE_LLVM == 0x800 && func == 3)
+ func = 4; /* Only LLVM 9+ supports vec3 */
- LLVMTypeRef types[] = {ctx->f32, ctx->v2f32, ctx->v3f32, ctx->v4f32};
- const char *type_names[] = {"f32", "v2f32", "v3f32", "v4f32"};
+ LLVMTypeRef type = func > 1 ? LLVMVectorTy
[Mesa-dev] [PATCH 2/3] ac: use struct/raw load intrinsics for 8-bit/16-bit int with LLVM 9+
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 51 ++
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 88df82dcc54..b35e5659c42 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1612,15 +1612,29 @@ ac_build_tbuffer_load_short(struct ac_llvm_context *ctx,
LLVMValueRef immoffset,
bool glc)
{
- unsigned dfmt = V_008F0C_BUF_DATA_FORMAT_16;
- unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
LLVMValueRef res;
- res = ac_build_raw_tbuffer_load(ctx, rsrc, voffset, soffset,
- immoffset, 1, dfmt, nfmt, glc, false,
- false);
+ if (HAVE_LLVM >= 0x900) {
+ voffset = LLVMBuildAdd(ctx->builder, voffset, immoffset, "");
+
+ /* LLVM 9+ supports i8/i16 with struct/raw intrinsics. */
+ res = ac_build_llvm8_buffer_load_common(ctx, rsrc, NULL,
+ voffset, soffset,
+ 1, ctx->i16, glc, false,
+ false, false, false);
+ LLVMDumpValue(res);
+ } else {
+ unsigned dfmt = V_008F0C_BUF_DATA_FORMAT_16;
+ unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
- return LLVMBuildTrunc(ctx->builder, res, ctx->i16, "");
+ res = ac_build_raw_tbuffer_load(ctx, rsrc, voffset, soffset,
+ immoffset, 1, dfmt, nfmt, glc,
false,
+ false);
+
+ res = LLVMBuildTrunc(ctx->builder, res, ctx->i16, "");
+ }
+
+ return res;
}
LLVMValueRef
@@ -1631,15 +1645,28 @@ ac_build_tbuffer_load_byte(struct ac_llvm_context *ctx,
LLVMValueRef immoffset,
bool glc)
{
- unsigned dfmt = V_008F0C_BUF_DATA_FORMAT_8;
- unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
LLVMValueRef res;
- res = ac_build_raw_tbuffer_load(ctx, rsrc, voffset, soffset,
- immoffset, 1, dfmt, nfmt, glc, false,
- false);
+ if (HAVE_LLVM >= 0x900) {
+ voffset = LLVMBuildAdd(ctx->builder, voffset, immoffset, "");
+
+ /* LLVM 9+ supports i8/i16 with struct/raw intrinsics. */
+ res = ac_build_llvm8_buffer_load_common(ctx, rsrc, NULL,
+ voffset, soffset,
+ 1, ctx->i8, glc, false,
+ false, false, false);
+ } else {
+ unsigned dfmt = V_008F0C_BUF_DATA_FORMAT_8;
+ unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
- return LLVMBuildTrunc(ctx->builder, res, ctx->i8, "");
+ res = ac_build_raw_tbuffer_load(ctx, rsrc, voffset, soffset,
+ immoffset, 1, dfmt, nfmt, glc,
false,
+ false);
+
+ res = LLVMBuildTrunc(ctx->builder, res, ctx->i8, "");
+ }
+
+ return res;
}
static void
ac_build_llvm8_tbuffer_store(struct ac_llvm_context *ctx,
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] ac: use struct/raw store intrinsics for 8-bit/16-bit int with LLVM 9+
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 48 --
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index b35e5659c42..508e0da7158 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1807,15 +1807,25 @@ ac_build_tbuffer_store_short(struct ac_llvm_context
*ctx,
bool glc,
bool writeonly_memory)
{
- unsigned dfmt = V_008F0C_BUF_DATA_FORMAT_16;
- unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
-
vdata = LLVMBuildBitCast(ctx->builder, vdata, ctx->i16, "");
- vdata = LLVMBuildZExt(ctx->builder, vdata, ctx->i32, "");
- ac_build_raw_tbuffer_store(ctx, rsrc, vdata, voffset, soffset,
- ctx->i32_0, 1, dfmt, nfmt, glc, false,
- writeonly_memory);
+ if (HAVE_LLVM >= 0x900) {
+ /* LLVM 9+ supports i8/i16 with struct/raw intrinsics. */
+ ac_build_llvm8_buffer_store_common(ctx, rsrc, vdata, NULL,
+ voffset, soffset, 1,
+ ctx->i16, glc, false,
+ writeonly_memory, false,
+ false);
+ } else {
+ unsigned dfmt = V_008F0C_BUF_DATA_FORMAT_16;
+ unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
+
+ vdata = LLVMBuildZExt(ctx->builder, vdata, ctx->i32, "");
+
+ ac_build_raw_tbuffer_store(ctx, rsrc, vdata, voffset, soffset,
+ ctx->i32_0, 1, dfmt, nfmt, glc,
false,
+ writeonly_memory);
+ }
}
void
@@ -1827,15 +1837,25 @@ ac_build_tbuffer_store_byte(struct ac_llvm_context *ctx,
bool glc,
bool writeonly_memory)
{
- unsigned dfmt = V_008F0C_BUF_DATA_FORMAT_8;
- unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
-
vdata = LLVMBuildBitCast(ctx->builder, vdata, ctx->i8, "");
- vdata = LLVMBuildZExt(ctx->builder, vdata, ctx->i32, "");
- ac_build_raw_tbuffer_store(ctx, rsrc, vdata, voffset, soffset,
- ctx->i32_0, 1, dfmt, nfmt, glc, false,
- writeonly_memory);
+ if (HAVE_LLVM >= 0x900) {
+ /* LLVM 9+ supports i8/i16 with struct/raw intrinsics. */
+ ac_build_llvm8_buffer_store_common(ctx, rsrc, vdata, NULL,
+ voffset, soffset, 1,
+ ctx->i8, glc, false,
+ writeonly_memory, false,
+ false);
+ } else {
+ unsigned dfmt = V_008F0C_BUF_DATA_FORMAT_8;
+ unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
+
+ vdata = LLVMBuildZExt(ctx->builder, vdata, ctx->i32, "");
+
+ ac_build_raw_tbuffer_store(ctx, rsrc, vdata, voffset, soffset,
+ ctx->i32_0, 1, dfmt, nfmt, glc,
false,
+ writeonly_memory);
+ }
}
/**
* Set range metadata on an instruction. This can only be used on load and
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] panfrost/midgard: Handle i2b constant
Just an observation...
f2b(0x8000) == false
i2b(0x8000) == true
I haven't read surrounding code, but if the handling of f2b and i2b is
entirely identical, you'll run into trouble.
Cheers,
-ilia
On Tue, Mar 26, 2019 at 12:59 AM Alyssa Rosenzweig wrote:
>
> Fixes
> dEQP-GLES2.functional.shaders.conversions.scalar_to_scalar.int_to_bool_fragment
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gallium/drivers/panfrost/midgard/midgard_compile.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
> b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
> index d6ed0008596..3dd21d0390d 100644
> --- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
> +++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
> @@ -1174,7 +1174,7 @@ emit_alu(compiler_context *ctx, nir_alu_instr *instr)
> }
>
> ins.alu.src2 = vector_alu_srco_unsigned(blank_alu_src_);
> -} else if (instr->op == nir_op_f2b32) {
> +} else if (instr->op == nir_op_f2b32 || instr->op == nir_op_i2b32) {
> ins.ssa_args.inline_constant = false;
> ins.ssa_args.src1 = SSA_FIXED_REGISTER(REGISTER_CONSTANT);
> ins.has_constants = true;
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] softpipe: fix clears to only clear specified color buffers.
On 03/26/2019 12:44 AM, Dave Airlie wrote:
From: Dave Airlie
This fixes piglit clearbuffer-mixed-format
---
src/gallium/drivers/softpipe/sp_clear.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/softpipe/sp_clear.c
b/src/gallium/drivers/softpipe/sp_clear.c
index ba04fd0aa87..d2626a24333 100644
--- a/src/gallium/drivers/softpipe/sp_clear.c
+++ b/src/gallium/drivers/softpipe/sp_clear.c
@@ -68,7 +68,8 @@ softpipe_clear(struct pipe_context *pipe, unsigned buffers,
if (buffers & PIPE_CLEAR_COLOR) {
for (i = 0; i < softpipe->framebuffer.nr_cbufs; i++) {
- sp_tile_cache_clear(softpipe->cbuf_cache[i], color, 0);
+ if (buffers & (PIPE_CLEAR_COLOR0 << i))
+sp_tile_cache_clear(softpipe->cbuf_cache[i], color, 0);
}
}
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] X.Org GSoC 2019 - Student Application Period
I'm happy to announce that the X.Org Foundation has been chosen to participate in this year's GSoC program! Students have from now until April 9th to submit their proposals. Students will be looking at https://www.x.org/wiki/SummerOfCodeIdeas/ and https://www.x.org/wiki/ToDo/ for ideas. Please take a moment to review those lists to see: - are these valid ideas? - should items be removed? - are there items that can be added? Also, please consider signing up to mentor. All the student enthusiasm in the world can't be put to any use if there are no mentors. A mentor only needs to provide technical direction and grading, all other aspects of the program will be handled by myself. If you have any updates to the ideas pages or are interested in mentoring, please get in touch! Students: Application requirements: * Applicants meet Google's requirements for participation in Summer of Code. * Applicants are in regular and close contact with their X.Org mentors and the community (IRC, email) * Applicants know their target programming language. * Applicants must successfully upstream a simple patch to demonstrate they know the process. * Applicants are willing to blog weekly and interact with the community (failure to do so will result in a fail at the next review) Check out https://www.x.org/wiki/GSoCApplication/ for information about how to apply. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] panfrost/midgard: Handle i2b constant
> Just an observation... > > f2b(0x8000) == false > i2b(0x8000) == true > > I haven't read surrounding code, but if the handling of f2b and i2b is > entirely identical, you'll run into trouble. Both are being lowered to fne/ine instructions; this hunk is just to force the second argument to "0" for each. [Actually, wait, am I using fne for both? That *is* a bug.] ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03
https://bugs.freedesktop.org/show_bug.cgi?id=110141 Eric Engestrom changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Eric Engestrom --- I'm really tempted to close this as NOTOURBUG, as it's the provider of a library that should claim to provide it (ie. GLVND in this case), but if I understand correctly, glesv2.pc isn't actually used for its contents but rather just as a "does this file exist" check. The thing I don't understand though is: why? What does mutter or wlroots do with this information? In a non-GLVND environment, you compile Mesa with things enabled or not, and you get .so and .pc files that tell you what you have and can use, but in a GLVND environment this information would have to be per-vendor, which a generic `gles2.pc` file cannot give. Say, for instance, that you have the proprietary NVIDIA driver and Mesa on your system. NVIDIA provides GLES 1 & 2, and Mesa is compiled with only GLES 1. You won't have gles2.pc, but GLVND provides libGLESv2.so, and it would be able to provide an actual context thanks to the NVIDIA driver. And what about gles1.pc, should NVIDIA or Mesa provide this file? They wouldn't be able to both provide it, so how would you decide who does? So again, I really don't understand the meaning that's given to "does gles2.pc exists?". Am I missing something? -- 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 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03
https://bugs.freedesktop.org/show_bug.cgi?id=110141 --- Comment #3 from Daniel Stone --- Mutter, wlroots, Weston, and quite a few others, use egl.pc and glesv2.pc to get the cflags/libs/etc for those libraries. It would be great if GLVND actually shipped them. -- 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 2/3] iris: Create a composite context for both compute and render pipelines
On Tuesday, March 26, 2019 12:16:20 AM PDT Chris Wilson wrote: > Quoting Kenneth Graunke (2019-03-26 05:52:10) > > On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote: > > > iris currently uses two distinct GEM contexts to have distinct logical > > > HW contexts for the compute and render pipelines. However, using two > > > distinct GEM contexts implies that they are distinct timelines, yet as > > > they are a single GL context that implies they belong to a single > > > timeline from the client perspective. Currently, fences are occasionally > > > inserted to order the two timelines. Using 2 GEM contexts, also implies > > > that we keep 2 ppGTT for identical buffer state. If we can create a > > > single GEM context, with the right capabilities, we can have a single > > > VM, a single timeline, but 2 logical HW contexts for the 2 pipelines. > > > > > > This is allowed through the new context interface that allows VM to be > > > shared, timelines to be specified, and for the logical contexts to be > > > constructed as the user desires. > > > > > > Cc: Joonas Lahtinen > > > Cc: Kenneth Graunke > > > --- > > > src/gallium/drivers/iris/iris_batch.c | 16 ++- > > > src/gallium/drivers/iris/iris_batch.h | 5 +-- > > > src/gallium/drivers/iris/iris_context.c | 56 - > > > 3 files changed, 60 insertions(+), 17 deletions(-) > > > > Hi Chris, > > > > I don't think that I want the single timeline option. It seems like > > we've been moving away from implicit sync for a long time, and the > > explicit sync code we have is pretty straightforward and seems to do > > the trick. Jason and I also chatted briefly, and we don't necessarily > > want to a strict submission-order between render/compute. > > I disagree if you think this means more implicit sync. It is setting up > the GEM context to an exact match of the GL context, by _explicit_ > control of the timeline. Then the fences you do export from inside the > GL context do not need to be faked to be a composite of the pair of > contexts. You still have explicit fences, and you have explicit control > over the definition of their timeline. With regard to multiple GL contexts, yes, everything remains explicit. But having 2-3 separate timelines within a GL context allows us to reorder work behind GL's back, which is all the rage these days for performance. Tilers do it all the time. Position-only bucketing may require it. I'd really like to start treating render and compute as distinct asynchronous queues. At the very least, experimenting with that and not tying my hands to a particular behavior. There may be some use for single timeline, though. Attaching images as compute shader inputs may require CCS/HiZ resolves, which have to happen on the RCS. Right now, I do those on IRIS_BATCH_RENDER, which mean that it backs up behind any queued render work. Ideally, I'd do those on a third context, which could be tied to the compute timeline, so the resolves and the compute job can both execute ahead of queued rendering, but still back to back. > > Separating the VMA from the context state image seems like absolutely > > the right thing to do - as you said, they're separate in hardware, > > and no real reason to tie it together. I would be in favor of new > > uABI for that. > > > > I don't think there will be much overhead reduction from sharing the > > VMA here though. It's very plausible that the compositor might want > > to run between render and compute batches, at which point we end up > > doing page directory loads anyway. I have also heard rumors about bit > > 47 becoming magical at some point which may prohibit us from sharing... > > Yeah, but that doesn't actually affect the context setup, just how you > decide to use it in end. And by that point, you'll be forced into using > this new uABI anyway or something entirely different :-p Looking into this a bit more, I think we're actually OK. I thought I might need to have distinct addresses for render and compute - at which point nearly every address would differ in terms of bit 47 - but it looks like the correct answer is "just never use that bit". *shrug* > > Context cloning seems OK, but I'm always pretty hesitant to add new > > uABI unless it's strictly necessary. In this case, we can do the same > > thing with a little bit of userspace code, so I'm not sure it's worth > > adding that... > > Actually you cannot do the same without some of the new uABI either, > since previously you did not have all the parameters exposed. What isn't exposed? We set up everything the first time, why can't we do it again? > > I would love to see an iris patch to use the new > > I915_CONTEXT_PARAM_RECOVERABLE option without the other dependencies. > > https://gitlab.freedesktop.org/ickle/mesa/commit/84d9cb1d8d98a50dcceea19ccbc3836b15cf73ae > -Chris signature.asc Description: This is a digitally signed message part. ___
Re: [Mesa-dev] [PATCH 2/3] iris: Create a composite context for both compute and render pipelines
Quoting Kenneth Graunke (2019-03-26 17:01:57) > On Tuesday, March 26, 2019 12:16:20 AM PDT Chris Wilson wrote: > > Quoting Kenneth Graunke (2019-03-26 05:52:10) > > > On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote: > > > > iris currently uses two distinct GEM contexts to have distinct logical > > > > HW contexts for the compute and render pipelines. However, using two > > > > distinct GEM contexts implies that they are distinct timelines, yet as > > > > they are a single GL context that implies they belong to a single > > > > timeline from the client perspective. Currently, fences are occasionally > > > > inserted to order the two timelines. Using 2 GEM contexts, also implies > > > > that we keep 2 ppGTT for identical buffer state. If we can create a > > > > single GEM context, with the right capabilities, we can have a single > > > > VM, a single timeline, but 2 logical HW contexts for the 2 pipelines. > > > > > > > > This is allowed through the new context interface that allows VM to be > > > > shared, timelines to be specified, and for the logical contexts to be > > > > constructed as the user desires. > > > > > > > > Cc: Joonas Lahtinen > > > > Cc: Kenneth Graunke > > > > --- > > > > src/gallium/drivers/iris/iris_batch.c | 16 ++- > > > > src/gallium/drivers/iris/iris_batch.h | 5 +-- > > > > src/gallium/drivers/iris/iris_context.c | 56 - > > > > 3 files changed, 60 insertions(+), 17 deletions(-) > > > > > > Hi Chris, > > > > > > I don't think that I want the single timeline option. It seems like > > > we've been moving away from implicit sync for a long time, and the > > > explicit sync code we have is pretty straightforward and seems to do > > > the trick. Jason and I also chatted briefly, and we don't necessarily > > > want to a strict submission-order between render/compute. > > > > I disagree if you think this means more implicit sync. It is setting up > > the GEM context to an exact match of the GL context, by _explicit_ > > control of the timeline. Then the fences you do export from inside the > > GL context do not need to be faked to be a composite of the pair of > > contexts. You still have explicit fences, and you have explicit control > > over the definition of their timeline. > > With regard to multiple GL contexts, yes, everything remains explicit. > But having 2-3 separate timelines within a GL context allows us to > reorder work behind GL's back, which is all the rage these days for > performance. Tilers do it all the time. Position-only bucketing may > require it. I'd really like to start treating render and compute as > distinct asynchronous queues. At the very least, experimenting with > that and not tying my hands to a particular behavior. That's a reasonable argument. If you want to try and keep the GL semantics intact while playing with ordering underneath, have fun! The only problem I forsee if there is any observable through which the pipelines can determine their ordering / concurrency (sampling a common buffer or clock) that might construe a violation. > There may be some use for single timeline, though. Attaching images as > compute shader inputs may require CCS/HiZ resolves, which have to happen > on the RCS. Right now, I do those on IRIS_BATCH_RENDER, which mean that > it backs up behind any queued render work. Ideally, I'd do those on a > third context, which could be tied to the compute timeline, so the > resolves and the compute job can both execute ahead of queued rendering, > but still back to back. I have an inkling that timelines should be first class for userspace to control exactly. But I have not seen anything close to a use case to justify that (yet). And by the time a usecase should arise, we will probably be onto the next shiny. That's the problem with cloudy crystal balls. > > > Separating the VMA from the context state image seems like absolutely > > > the right thing to do - as you said, they're separate in hardware, > > > and no real reason to tie it together. I would be in favor of new > > > uABI for that. > > > > > > I don't think there will be much overhead reduction from sharing the > > > VMA here though. It's very plausible that the compositor might want > > > to run between render and compute batches, at which point we end up > > > doing page directory loads anyway. I have also heard rumors about bit > > > 47 becoming magical at some point which may prohibit us from sharing... > > > > Yeah, but that doesn't actually affect the context setup, just how you > > decide to use it in end. And by that point, you'll be forced into using > > this new uABI anyway or something entirely different :-p > > Looking into this a bit more, I think we're actually OK. I thought I > might need to have distinct addresses for render and compute - at which > point nearly every address would differ in terms of bit 47 - but it > looks like the correct answer is "just never use that bit". *shrug* Yup
[Mesa-dev] [Bug 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03
https://bugs.freedesktop.org/show_bug.cgi?id=110141 --- Comment #4 from Eric Engestrom --- (In reply to Daniel Stone from comment #3) > Mutter, wlroots, Weston, and quite a few others, use egl.pc and glesv2.pc to > get the cflags/libs/etc for those libraries. It would be great if GLVND > actually shipped them. If that's the information that's being used, than yeah that's a definite NOTOURBUG :] -- 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 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03
https://bugs.freedesktop.org/show_bug.cgi?id=110141 --- Comment #5 from Adam Jackson --- (In reply to Eric Engestrom from comment #2) > So again, I really don't understand the meaning that's given to "does > gles2.pc exists?". Am I missing something? It means "can I link against GLES2's library, and if so, how". This really is something glvnd ought to provide. See also https://github.com/NVIDIA/libglvnd/pull/86 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeon/vcn: add H.264 constrained baseline support
VCN supports this profile as well as UVD, so add it
Signed-off-by: Leo Liu
CC:
---
src/gallium/drivers/radeon/radeon_vcn_dec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index a4e6d9dc6b5..d165c55f835 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -64,6 +64,7 @@ static rvcn_dec_message_avc_t get_h264_msg(struct
radeon_decoder *dec,
memset(&result, 0, sizeof(result));
switch (pic->base.profile) {
case PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE:
+ case PIPE_VIDEO_PROFILE_MPEG4_AVC_CONSTRAINED_BASELINE:
result.profile = RDECODE_H264_PROFILE_BASELINE;
break;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/glsl_to_nir: fix incorrect arrary access
On Mon, 25 Mar 2019 at 21:47, Timothy Arceri wrote: > > On 26/3/19 3:43 am, Emil Velikov wrote: > > Hi Timothy, > > > > On Fri, 1 Mar 2019 at 10:36, Timothy Arceri wrote: > >> > >> This fixes a segfault when we try to access the array using a > >> -1 when the array wasn't allocated in the first place. > >> > >> Before 7536af670b75 we would just access a pre-allocated array > >> that was also load/stored to/from the shader cache. But now the > >> cache will no longer allocate these arrays if they are empty. > >> The change resulted in tests such as the following segfaulting > >> when run with a warm shader cache. > >> > > I was going through some extra checks for 18.3 and noticed this commit. > > > > Admittedly it does not fix 7536af670b75 although it does address a > > preexisting issue exposed by it. > > That said I suspect we'd want this for stable? > > This fixes an issue that is not part of the default path of any drivers > so I'm happy to skip back porting to stable. Fair enough, thanks for the confirmation. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/vcn: add H.264 constrained baseline support
On Tue, Mar 26, 2019 at 2:44 PM Liu, Leo wrote:
>
> VCN supports this profile as well as UVD, so add it
>
> Signed-off-by: Leo Liu
> CC:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/radeon_vcn_dec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c
> b/src/gallium/drivers/radeon/radeon_vcn_dec.c
> index a4e6d9dc6b5..d165c55f835 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
> @@ -64,6 +64,7 @@ static rvcn_dec_message_avc_t get_h264_msg(struct
> radeon_decoder *dec,
> memset(&result, 0, sizeof(result));
> switch (pic->base.profile) {
> case PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE:
> + case PIPE_VIDEO_PROFILE_MPEG4_AVC_CONSTRAINED_BASELINE:
> result.profile = RDECODE_H264_PROFILE_BASELINE;
> break;
>
> --
> 2.17.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] panfrost: Cache index buffer bounds
Alyssa Rosenzweig writes: >> Can you reuse u_vbuf_get_minmax_index()? > > From a preliminary read, it didn't look like that did caching? It doesn't, but the inside of your caching function should probably be using it. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03
https://bugs.freedesktop.org/show_bug.cgi?id=110141 --- Comment #6 from LoneVVolf --- Before https://cgit.freedesktop.org/mesa/mesa/commit/?id=b01524fff05eef66e8cd24f1c5aacefed4209f03 mesa built with glvnd support did provide the gles pkgconfig files. After that commit mesa built with glvnd support doesn't provide them anymore. IF mesa developers feel that these files should be provided by glvnd, then it seems logical that mesa devs inform glvnd devs of that position. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Cache index buffer bounds
> It doesn't, but the inside of your caching function should probably be > using it. Ah, I see, fair point :) Will we want this caching to be moved up to shared Gallium or no? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03
https://bugs.freedesktop.org/show_bug.cgi?id=110141 --- Comment #7 from Adam Jackson --- (In reply to LoneVVolf from comment #6) > IF mesa developers feel that these files should be provided by glvnd, then > it seems logical that mesa devs inform glvnd devs of that position. My "see also" link in comment #5 was exactly me telling glvnd of that position, yes. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] nir: add nir_{load, store}_deref_with_access() helpers
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_builder.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index bcf03957bc7..9f9a05cbd09 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
@@ -1070,6 +1070,36 @@ nir_store_deref(nir_builder *build, nir_deref_instr
*deref,
nir_builder_instr_insert(build, &store->instr);
}
+static inline nir_ssa_def *
+nir_load_deref_with_access(nir_builder *build, nir_deref_instr *deref,
+ enum gl_access_qualifier access)
+{
+ nir_intrinsic_instr *load =
+ nir_intrinsic_instr_create(build->shader, nir_intrinsic_load_deref);
+ load->num_components = glsl_get_vector_elements(deref->type);
+ load->src[0] = nir_src_for_ssa(&deref->dest.ssa);
+ nir_ssa_dest_init(&load->instr, &load->dest, load->num_components,
+ glsl_get_bit_size(deref->type), NULL);
+ nir_intrinsic_set_access(load, access);
+ nir_builder_instr_insert(build, &load->instr);
+ return &load->dest.ssa;
+}
+
+static inline void
+nir_store_deref_with_access(nir_builder *build, nir_deref_instr *deref,
+nir_ssa_def *value, unsigned writemask,
+enum gl_access_qualifier access)
+{
+ nir_intrinsic_instr *store =
+ nir_intrinsic_instr_create(build->shader, nir_intrinsic_store_deref);
+ store->num_components = glsl_get_vector_elements(deref->type);
+ store->src[0] = nir_src_for_ssa(&deref->dest.ssa);
+ store->src[1] = nir_src_for_ssa(value);
+ nir_intrinsic_set_write_mask(store,
+writemask & ((1 << store->num_components) -
1));
+ nir_intrinsic_set_access(store, access);
+ nir_builder_instr_insert(build, &store->instr);
+}
static inline void
nir_copy_deref(nir_builder *build, nir_deref_instr *dest, nir_deref_instr *src)
{
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] spirv: propagate the access flag for store and load derefs
It was only propagated when UBO/SSBO access are lowered to offsets.
Signed-off-by: Samuel Pitoiset
---
src/compiler/spirv/vtn_cfg.c | 8 +++---
src/compiler/spirv/vtn_private.h | 6 +++--
src/compiler/spirv/vtn_variables.c | 42 +-
3 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 7868eeb60bc..af8ef52e2e8 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -232,7 +232,7 @@ vtn_handle_function_call(struct vtn_builder *b, SpvOp
opcode,
if (ret_type->base_type == vtn_base_type_void) {
vtn_push_value(b, w[2], vtn_value_type_undef);
} else {
- vtn_push_ssa(b, w[2], res_type, vtn_local_load(b, ret_deref));
+ vtn_push_ssa(b, w[2], res_type, vtn_local_load(b, ret_deref, 0));
}
}
@@ -792,7 +792,7 @@ vtn_handle_phis_first_pass(struct vtn_builder *b, SpvOp
opcode,
_mesa_hash_table_insert(b->phi_table, w, phi_var);
vtn_push_ssa(b, w[2], type,
-vtn_local_load(b, nir_build_deref_var(&b->nb, phi_var)));
+vtn_local_load(b, nir_build_deref_var(&b->nb, phi_var), 0));
return true;
}
@@ -816,7 +816,7 @@ vtn_handle_phi_second_pass(struct vtn_builder *b, SpvOp
opcode,
struct vtn_ssa_value *src = vtn_ssa_value(b, w[i]);
- vtn_local_store(b, src, nir_build_deref_var(&b->nb, phi_var));
+ vtn_local_store(b, src, nir_build_deref_var(&b->nb, phi_var), 0);
}
return true;
@@ -910,7 +910,7 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head
*cf_list,
nir_deref_instr *ret_deref =
nir_build_deref_cast(&b->nb, nir_load_param(&b->nb, 0),
nir_var_function_temp, ret_type, 0);
-vtn_local_store(b, src, ret_deref);
+vtn_local_store(b, src, ret_deref, 0);
}
if (block->branch_type != vtn_branch_type_none) {
diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h
index 463d6173640..395250984c5 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -730,10 +730,12 @@ vtn_pointer_to_offset(struct vtn_builder *b, struct
vtn_pointer *ptr,
nir_ssa_def **index_out);
struct vtn_ssa_value *
-vtn_local_load(struct vtn_builder *b, nir_deref_instr *src);
+vtn_local_load(struct vtn_builder *b, nir_deref_instr *src,
+ enum gl_access_qualifier access);
void vtn_local_store(struct vtn_builder *b, struct vtn_ssa_value *src,
- nir_deref_instr *dest);
+ nir_deref_instr *dest,
+ enum gl_access_qualifier access);
struct vtn_ssa_value *
vtn_variable_load(struct vtn_builder *b, struct vtn_pointer *src);
diff --git a/src/compiler/spirv/vtn_variables.c
b/src/compiler/spirv/vtn_variables.c
index 43c32930cff..91329567335 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -590,13 +590,14 @@ vtn_pointer_to_deref(struct vtn_builder *b, struct
vtn_pointer *ptr)
static void
_vtn_local_load_store(struct vtn_builder *b, bool load, nir_deref_instr *deref,
- struct vtn_ssa_value *inout)
+ struct vtn_ssa_value *inout,
+ enum gl_access_qualifier access)
{
if (glsl_type_is_vector_or_scalar(deref->type)) {
if (load) {
- inout->def = nir_load_deref(&b->nb, deref);
+ inout->def = nir_load_deref_with_access(&b->nb, deref, access);
} else {
- nir_store_deref(&b->nb, deref, inout->def, ~0);
+ nir_store_deref_with_access(&b->nb, deref, inout->def, ~0, access);
}
} else if (glsl_type_is_array(deref->type) ||
glsl_type_is_matrix(deref->type)) {
@@ -604,14 +605,14 @@ _vtn_local_load_store(struct vtn_builder *b, bool load,
nir_deref_instr *deref,
for (unsigned i = 0; i < elems; i++) {
nir_deref_instr *child =
nir_build_deref_array_imm(&b->nb, deref, i);
- _vtn_local_load_store(b, load, child, inout->elems[i]);
+ _vtn_local_load_store(b, load, child, inout->elems[i], access);
}
} else {
vtn_assert(glsl_type_is_struct_or_ifc(deref->type));
unsigned elems = glsl_get_length(deref->type);
for (unsigned i = 0; i < elems; i++) {
nir_deref_instr *child = nir_build_deref_struct(&b->nb, deref, i);
- _vtn_local_load_store(b, load, child, inout->elems[i]);
+ _vtn_local_load_store(b, load, child, inout->elems[i], access);
}
}
}
@@ -644,11 +645,12 @@ get_deref_tail(nir_deref_instr *deref)
}
struct vtn_ssa_value *
-vtn_local_load(struct vtn_builder *b, nir_deref_instr *src)
+vtn_local_load(struct vtn_builder *b, nir_deref_instr *src,
+ enum gl_access_qualifier access)
{
nir_deref_instr *src_tail = get_deref_tail(src);
struct vtn_ssa_value *val =
[Mesa-dev] [PATCH] intel/compiler: Replicate 16 bit immediate value correctly
For the W or UW (signed or unsigned word) source types, the 16-bit value
must be replicated in both the low and high words of the 32-bit
immediate value.
Signed-off-by: Sagar Ghuge
---
src/intel/compiler/brw_fs.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 0c2439d9daf..f8cb91fcf21 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -4069,6 +4069,9 @@ fs_visitor::lower_integer_multiplication()
mul->src[1].type = BRW_REGISTER_TYPE_UW;
mul->src[1].stride *= 2;
+if (mul->src[1].file == IMM)
+ mul->src[1].ud = ((mul->src[1].ud & 0x) |
+ mul->src[1].ud << 16);
} else if (devinfo->gen == 7 && !devinfo->is_haswell &&
inst->group > 0) {
/* Among other things the quarter control bits influence which
--
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: Replicate 16 bit immediate value correctly
On Tue, Mar 26, 2019 at 3:35 PM Sagar Ghuge wrote: > > For the W or UW (signed or unsigned word) source types, the 16-bit value > must be replicated in both the low and high words of the 32-bit > immediate value. > > Signed-off-by: Sagar Ghuge > --- > src/intel/compiler/brw_fs.cpp | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp > index 0c2439d9daf..f8cb91fcf21 100644 > --- a/src/intel/compiler/brw_fs.cpp > +++ b/src/intel/compiler/brw_fs.cpp > @@ -4069,6 +4069,9 @@ fs_visitor::lower_integer_multiplication() > mul->src[1].type = BRW_REGISTER_TYPE_UW; > mul->src[1].stride *= 2; > > +if (mul->src[1].file == IMM) > + mul->src[1].ud = ((mul->src[1].ud & 0x) | > + mul->src[1].ud << 16); Please put braces around the statement, since it's in nested control flow. 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] intel/compiler: Replicate 16 bit immediate value correctly
Thank you for reviewing the patch. On 3/26/19 4:46 PM, Matt Turner wrote: > On Tue, Mar 26, 2019 at 3:35 PM Sagar Ghuge wrote: >> >> For the W or UW (signed or unsigned word) source types, the 16-bit value >> must be replicated in both the low and high words of the 32-bit >> immediate value. >> >> Signed-off-by: Sagar Ghuge >> --- >> src/intel/compiler/brw_fs.cpp | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp >> index 0c2439d9daf..f8cb91fcf21 100644 >> --- a/src/intel/compiler/brw_fs.cpp >> +++ b/src/intel/compiler/brw_fs.cpp >> @@ -4069,6 +4069,9 @@ fs_visitor::lower_integer_multiplication() >> mul->src[1].type = BRW_REGISTER_TYPE_UW; >> mul->src[1].stride *= 2; >> >> +if (mul->src[1].file == IMM) >> + mul->src[1].ud = ((mul->src[1].ud & 0x) | >> + mul->src[1].ud << 16); > > Please put braces around the statement, since it's in nested control flow. > I will fix this :) > Reviewed-by: Matt Turner > ___ > 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/2] nir: add nir_{load, store}_deref_with_access() helpers
You could make the old ones call these. It'd make for a smaller diff and
less code to maintain.
On March 26, 2019 17:10:52 Samuel Pitoiset wrote:
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_builder.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index bcf03957bc7..9f9a05cbd09 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
@@ -1070,6 +1070,36 @@ nir_store_deref(nir_builder *build, nir_deref_instr
*deref,
nir_builder_instr_insert(build, &store->instr);
}
+static inline nir_ssa_def *
+nir_load_deref_with_access(nir_builder *build, nir_deref_instr *deref,
+ enum gl_access_qualifier access)
+{
+ nir_intrinsic_instr *load =
+ nir_intrinsic_instr_create(build->shader, nir_intrinsic_load_deref);
+ load->num_components = glsl_get_vector_elements(deref->type);
+ load->src[0] = nir_src_for_ssa(&deref->dest.ssa);
+ nir_ssa_dest_init(&load->instr, &load->dest, load->num_components,
+ glsl_get_bit_size(deref->type), NULL);
+ nir_intrinsic_set_access(load, access);
+ nir_builder_instr_insert(build, &load->instr);
+ return &load->dest.ssa;
+}
+
+static inline void
+nir_store_deref_with_access(nir_builder *build, nir_deref_instr *deref,
+nir_ssa_def *value, unsigned writemask,
+enum gl_access_qualifier access)
+{
+ nir_intrinsic_instr *store =
+ nir_intrinsic_instr_create(build->shader, nir_intrinsic_store_deref);
+ store->num_components = glsl_get_vector_elements(deref->type);
+ store->src[0] = nir_src_for_ssa(&deref->dest.ssa);
+ store->src[1] = nir_src_for_ssa(value);
+ nir_intrinsic_set_write_mask(store,
+writemask & ((1 << store->num_components)
- 1));
+ nir_intrinsic_set_access(store, access);
+ nir_builder_instr_insert(build, &store->instr);
+}
static inline void
nir_copy_deref(nir_builder *build, nir_deref_instr *dest, nir_deref_instr *src)
{
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] spirv: propagate the access flag for store and load derefs
Reviewed-by:
Also applies to the other patch with or without the suggested change.
On March 26, 2019 17:10:53 Samuel Pitoiset wrote:
It was only propagated when UBO/SSBO access are lowered to offsets.
Signed-off-by: Samuel Pitoiset
---
src/compiler/spirv/vtn_cfg.c | 8 +++---
src/compiler/spirv/vtn_private.h | 6 +++--
src/compiler/spirv/vtn_variables.c | 42 +-
3 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 7868eeb60bc..af8ef52e2e8 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -232,7 +232,7 @@ vtn_handle_function_call(struct vtn_builder *b, SpvOp
opcode,
if (ret_type->base_type == vtn_base_type_void) {
vtn_push_value(b, w[2], vtn_value_type_undef);
} else {
- vtn_push_ssa(b, w[2], res_type, vtn_local_load(b, ret_deref));
+ vtn_push_ssa(b, w[2], res_type, vtn_local_load(b, ret_deref, 0));
}
}
@@ -792,7 +792,7 @@ vtn_handle_phis_first_pass(struct vtn_builder *b, SpvOp
opcode,
_mesa_hash_table_insert(b->phi_table, w, phi_var);
vtn_push_ssa(b, w[2], type,
-vtn_local_load(b, nir_build_deref_var(&b->nb, phi_var)));
+vtn_local_load(b, nir_build_deref_var(&b->nb, phi_var), 0));
return true;
}
@@ -816,7 +816,7 @@ vtn_handle_phi_second_pass(struct vtn_builder *b, SpvOp
opcode,
struct vtn_ssa_value *src = vtn_ssa_value(b, w[i]);
- vtn_local_store(b, src, nir_build_deref_var(&b->nb, phi_var));
+ vtn_local_store(b, src, nir_build_deref_var(&b->nb, phi_var), 0);
}
return true;
@@ -910,7 +910,7 @@ vtn_emit_cf_list(struct vtn_builder *b, struct
list_head *cf_list,
nir_deref_instr *ret_deref =
nir_build_deref_cast(&b->nb, nir_load_param(&b->nb, 0),
nir_var_function_temp, ret_type, 0);
-vtn_local_store(b, src, ret_deref);
+vtn_local_store(b, src, ret_deref, 0);
}
if (block->branch_type != vtn_branch_type_none) {
diff --git a/src/compiler/spirv/vtn_private.h
b/src/compiler/spirv/vtn_private.h
index 463d6173640..395250984c5 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -730,10 +730,12 @@ vtn_pointer_to_offset(struct vtn_builder *b, struct
vtn_pointer *ptr,
nir_ssa_def **index_out);
struct vtn_ssa_value *
-vtn_local_load(struct vtn_builder *b, nir_deref_instr *src);
+vtn_local_load(struct vtn_builder *b, nir_deref_instr *src,
+ enum gl_access_qualifier access);
void vtn_local_store(struct vtn_builder *b, struct vtn_ssa_value *src,
- nir_deref_instr *dest);
+ nir_deref_instr *dest,
+ enum gl_access_qualifier access);
struct vtn_ssa_value *
vtn_variable_load(struct vtn_builder *b, struct vtn_pointer *src);
diff --git a/src/compiler/spirv/vtn_variables.c
b/src/compiler/spirv/vtn_variables.c
index 43c32930cff..91329567335 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -590,13 +590,14 @@ vtn_pointer_to_deref(struct vtn_builder *b, struct
vtn_pointer *ptr)
static void
_vtn_local_load_store(struct vtn_builder *b, bool load, nir_deref_instr *deref,
- struct vtn_ssa_value *inout)
+ struct vtn_ssa_value *inout,
+ enum gl_access_qualifier access)
{
if (glsl_type_is_vector_or_scalar(deref->type)) {
if (load) {
- inout->def = nir_load_deref(&b->nb, deref);
+ inout->def = nir_load_deref_with_access(&b->nb, deref, access);
} else {
- nir_store_deref(&b->nb, deref, inout->def, ~0);
+ nir_store_deref_with_access(&b->nb, deref, inout->def, ~0, access);
}
} else if (glsl_type_is_array(deref->type) ||
glsl_type_is_matrix(deref->type)) {
@@ -604,14 +605,14 @@ _vtn_local_load_store(struct vtn_builder *b, bool
load, nir_deref_instr *deref,
for (unsigned i = 0; i < elems; i++) {
nir_deref_instr *child =
nir_build_deref_array_imm(&b->nb, deref, i);
- _vtn_local_load_store(b, load, child, inout->elems[i]);
+ _vtn_local_load_store(b, load, child, inout->elems[i], access);
}
} else {
vtn_assert(glsl_type_is_struct_or_ifc(deref->type));
unsigned elems = glsl_get_length(deref->type);
for (unsigned i = 0; i < elems; i++) {
nir_deref_instr *child = nir_build_deref_struct(&b->nb, deref, i);
- _vtn_local_load_store(b, load, child, inout->elems[i]);
+ _vtn_local_load_store(b, load, child, inout->elems[i], access);
}
}
}
@@ -644,11 +645,12 @@ get_deref_tail(nir_deref_instr *deref)
}
struct vtn_ssa_value *
-vtn_local_load(struct vtn_builder *b, nir_deref_instr *src)
+vtn_local_load(struct vtn_builder *b, nir_deref_instr *src,
+ enum gl_access_qualifier access
[Mesa-dev] 2019 Election and By-laws approval voting OPEN
To all X.Org Foundation Members: The X.Org Foundation's annual election is now open and will remain open until 02:00 UTC on 11 April 2019. Four of the eight director seats are open during this election, with the four nominees receiving the highest vote totals serving as directors for two year terms. There were six candidates nominated. For a complete list of the candidates and their personal statements, please visit the 2019 X.Org Elections page at https://www.x.org/wiki/BoardOfDirectors/Elections/2019/ In addition to the board election, we are also voting on whether or not to approve of the new By-laws. Here are some instructions on how to cast your vote: Login to the membership system at: https://members.x.org/ If you do not remember your password, you can click on the "lost password" button and enter your user name. An e-mail will be sent to you with your password. If you have problems with the membership system, please e-mail members...@x.org. When you login you will see an "Active Ballots" section with the "X.Org 2019 Elections v2" ballot. When you click on that you will be presented with a page describing the ballot. At the bottom you will find a number of dropdowns that let you rank your candidates by order of preference, as well as a question on whether to accept the proposed By-laws changes. For the election: There is a pull-down selection box for 1st choice, 2nd, choice, and so on. Pick your candidates top to bottom in order of preference, avoiding duplicates. For the By-laws: If you approve of the new By-laws, select "yes" from the dropdown. If you do not approve of the new By-laws, select "no" from the dropdown. If you wish to abstain from this question, select "Abstain". There is a link to the new By-laws in the ballot description, as well as a link to the patch introducing the change. Note that answering this question is required for your vote to be validated. After you have completed your ballot, click the "Cast vote" button. Note that once you click this button, your votes will be cast and you will not be able to make further changes, so please make sure you are satisfied with your votes before clicking the "Cast vote" button. After you click the "Vote" button, the system will verify that you have completed a valid ballot. If your ballot is invalid (e.g., you duplicated a selection or did not answer the By-laws approval question), it will return you to the previous voting page. If your ballot is valid, your votes will be recorded and the system will show you a notice that your votes were cast. Note that the election will close at 02:00 UTC on 11 April 2019. At that time, the election committee will count the votes and present the results to the current board for validation. After the current board validates the results, the election committee will present the results to the Members. Harry, on behalf of the X.Org elections committee ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108841] [RADV] SPIRV's control flow attributes do not propagate to LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=108841 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Timothy Arceri --- I've pushed some patches that enable loop and selection control support for spriv. I you want the GL_EXT_control_flow_attributes extension supported also then I would suggest opening a separate bug against the glsl-compiler. Closing. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] Add nir_lower_viewport_transform
This is needed by Mali Utgard/Midgard GPU which don't have viewport transform HW, and Lima/Panfrost driver can share same implementation in a common place. I send out this patch series seperatly because Lima is under review in https://gitlab.freedesktop.org/mesa/mesa/merge_requests/465 and Panfrost driver need additinal changes in special uniform handling which I'm not familiar with. I expect Panfrost guys will send out patch to use this and Lima will be another user of it when upstreamed. Qiang Yu (4): mesa: seperate scale and translate in viewport calculation mesa: add STATE_VIEWPORT_SCALE/TRANSLATE nir: add nir_lower_viewport_transform mesa/st: do nir_lower_viewport_transform src/compiler/Makefile.sources | 1 + src/compiler/nir/meson.build | 1 + src/compiler/nir/nir.h| 8 + .../nir/nir_lower_viewport_transform.c| 142 ++ src/gallium/auxiliary/util/u_screen.c | 3 + src/gallium/include/pipe/p_defines.h | 1 + src/mesa/main/viewport.c | 26 ++-- src/mesa/program/prog_statevars.c | 35 + src/mesa/program/prog_statevars.h | 2 + src/mesa/state_tracker/st_glsl_to_nir.cpp | 23 +++ src/mesa/state_tracker/st_nir.h | 4 + src/mesa/state_tracker/st_program.c | 1 + 12 files changed, 233 insertions(+), 14 deletions(-) create mode 100644 src/compiler/nir/nir_lower_viewport_transform.c -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] mesa: seperate scale and translate in viewport calculation
This is needed in _mesa_fetch_state where scale and translate
are get one by one.
Signed-off-by: Qiang Yu
---
src/mesa/main/viewport.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index 97d328541b2..c9b1c27f120 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -585,21 +585,19 @@ _mesa_get_viewport_xform(struct gl_context *ctx, unsigned
i,
double n = ctx->ViewportArray[i].Near;
double f = ctx->ViewportArray[i].Far;
- scale[0] = half_width;
- translate[0] = half_width + x;
- if (ctx->Transform.ClipOrigin == GL_UPPER_LEFT) {
- scale[1] = -half_height;
- } else {
- scale[1] = half_height;
+ if (scale) {
+ scale[0] = half_width;
+ scale[1] = ctx->Transform.ClipOrigin == GL_UPPER_LEFT ?
+ -half_height : half_height;
+ scale[2] = ctx->Transform.ClipDepthMode == GL_NEGATIVE_ONE_TO_ONE ?
+ 0.5 * (f - n) : f - n;
}
- translate[1] = half_height + y;
-
- if (ctx->Transform.ClipDepthMode == GL_NEGATIVE_ONE_TO_ONE) {
- scale[2] = 0.5 * (f - n);
- translate[2] = 0.5 * (n + f);
- } else {
- scale[2] = f - n;
- translate[2] = n;
+
+ if (translate) {
+ translate[0] = half_width + x;
+ translate[1] = half_height + y;
+ translate[2] = ctx->Transform.ClipDepthMode == GL_NEGATIVE_ONE_TO_ONE ?
+ 0.5 * (n + f) : n;
}
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 --- Comment #3 from Jason Ekstrand --- I can reproduce locally and I think I know what the culpret is. Try reverting 3b3653c4cfbedf55a00cbddd0f341ebd1de81665 on master and see if it fixes it. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] mesa: add STATE_VIEWPORT_SCALE/TRANSLATE
Signed-off-by: Qiang Yu
---
src/mesa/program/prog_statevars.c | 35 +++
src/mesa/program/prog_statevars.h | 2 ++
2 files changed, 37 insertions(+)
diff --git a/src/mesa/program/prog_statevars.c
b/src/mesa/program/prog_statevars.c
index 3bbe451399f..ce74dbe317d 100644
--- a/src/mesa/program/prog_statevars.c
+++ b/src/mesa/program/prog_statevars.c
@@ -41,6 +41,7 @@
#include "prog_parameter.h"
#include "main/samplerobj.h"
#include "main/framebuffer.h"
+#include "main/viewport.h"
#define ONE_DIV_SQRT_LN2 (1.201122408786449815)
@@ -602,6 +603,30 @@ _mesa_fetch_state(struct gl_context *ctx, const
gl_state_index16 state[],
ctx->Color.BlendEnabled, ctx->Color._AdvancedBlendMode);
return;
+ case STATE_VIEWPORT_SCALE:
+ {
+float scale[3];
+_mesa_get_viewport_xform(ctx, 0, scale, NULL);
+if (_mesa_is_winsys_fbo(ctx->DrawBuffer))
+ scale[1] = -scale[1];
+value[0] = scale[0];
+value[1] = scale[1];
+value[2] = scale[2];
+return;
+ }
+
+ case STATE_VIEWPORT_TRANSLATE:
+ {
+float translate[3];
+_mesa_get_viewport_xform(ctx, 0, NULL, translate);
+if (_mesa_is_winsys_fbo(ctx->DrawBuffer))
+ translate[1] = (GLfloat)ctx->DrawBuffer->Height - translate[1];
+value[0] = translate[0];
+value[1] = translate[1];
+value[2] = translate[2];
+return;
+ }
+
/* XXX: make sure new tokens added here are also handled in the
* _mesa_program_state_flags() switch, below.
*/
@@ -713,6 +738,10 @@ _mesa_program_state_flags(const gl_state_index16
state[STATE_LENGTH])
case STATE_ADVANCED_BLENDING_MODE:
return _NEW_COLOR;
+ case STATE_VIEWPORT_SCALE:
+ case STATE_VIEWPORT_TRANSLATE:
+ return _NEW_BUFFERS | _NEW_VIEWPORT | _NEW_TRANSFORM;
+
default:
/* unknown state indexes are silently ignored and
* no flag set, since it is handled by the driver.
@@ -919,6 +948,12 @@ append_token(char *dst, gl_state_index k)
case STATE_ADVANCED_BLENDING_MODE:
append(dst, "AdvancedBlendingMode");
break;
+ case STATE_VIEWPORT_SCALE:
+ append(dst, "viewportScale");
+ break;
+ case STATE_VIEWPORT_TRANSLATE:
+ append(dst, "viewportTranslate");
+ break;
default:
/* probably STATE_INTERNAL_DRIVER+i (driver private state) */
append(dst, "driverState");
diff --git a/src/mesa/program/prog_statevars.h
b/src/mesa/program/prog_statevars.h
index f28d2bb4a37..0d7a255b8ee 100644
--- a/src/mesa/program/prog_statevars.h
+++ b/src/mesa/program/prog_statevars.h
@@ -129,6 +129,8 @@ typedef enum gl_state_index_ {
* currently active advanced blending equation, or zero if disabled.
*/
STATE_ADVANCED_BLENDING_MODE,
+ STATE_VIEWPORT_SCALE,
+ STATE_VIEWPORT_TRANSLATE,
STATE_INTERNAL_DRIVER /* first available state index for drivers
(must be last) */
} gl_state_index;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] nir: add nir_lower_viewport_transform
Signed-off-by: Qiang Yu
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/meson.build | 1 +
src/compiler/nir/nir.h| 8 +
.../nir/nir_lower_viewport_transform.c| 142 ++
4 files changed, 152 insertions(+)
create mode 100644 src/compiler/nir/nir_lower_viewport_transform.c
diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 722cfbb25a8..589a4f92602 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -269,6 +269,7 @@ NIR_FILES = \
nir/nir_lower_vars_to_ssa.c \
nir/nir_lower_var_copies.c \
nir/nir_lower_vec_to_movs.c \
+ nir/nir_lower_viewport_transform.c \
nir/nir_lower_wpos_center.c \
nir/nir_lower_wpos_ytransform.c \
nir/nir_metadata.c \
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index 4f1efb5c6d3..fd6678beb4d 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -149,6 +149,7 @@ files_libnir = files(
'nir_lower_vars_to_ssa.c',
'nir_lower_var_copies.c',
'nir_lower_vec_to_movs.c',
+ 'nir_lower_viewport_transform.c',
'nir_lower_wpos_center.c',
'nir_lower_wpos_ytransform.c',
'nir_lower_bit_size.c',
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 1da9874060b..688d006b646 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -3273,6 +3273,14 @@ bool nir_lower_wpos_ytransform(nir_shader *shader,
const nir_lower_wpos_ytransform_options
*options);
bool nir_lower_wpos_center(nir_shader *shader, const bool for_sample_shading);
+typedef struct nir_lower_viewport_transform_options {
+ gl_state_index16 scale[STATE_LENGTH];
+ gl_state_index16 translate[STATE_LENGTH];
+} nir_lower_viewport_transform_options;
+
+void nir_lower_viewport_transform(nir_shader *shader,
+ const nir_lower_viewport_transform_options
*options);
+
typedef struct nir_lower_drawpixels_options {
gl_state_index16 texcoord_state_tokens[STATE_LENGTH];
gl_state_index16 scale_state_tokens[STATE_LENGTH];
diff --git a/src/compiler/nir/nir_lower_viewport_transform.c
b/src/compiler/nir/nir_lower_viewport_transform.c
new file mode 100644
index 000..4a8102be1e0
--- /dev/null
+++ b/src/compiler/nir/nir_lower_viewport_transform.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (c) 2017-2019 Qiang Yu
+ *
+ * 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
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include "program/prog_statevars.h"
+#include "nir_builder.h"
+
+/* lower viewport transform into vertex shader
+ *
+ * This is needed for GPU like Mali Utgard and Midgard which has no viewport
+ * transform hw. Declare viewport transform parameters in uniform and use them
+ * to apply on the gl_Position varying output.
+ */
+
+typedef struct {
+ const nir_lower_viewport_transform_options *options;
+ nir_shader *shader;
+ nir_builder b;
+ nir_variable *scale, *translate;
+} lower_viewport_transform_state;
+
+static nir_variable *
+create_uniform(nir_shader *shader, const char *name, const gl_state_index16
*tokens)
+{
+ nir_variable *var = nir_variable_create(
+ shader, nir_var_uniform, glsl_vec_type(3), name);
+
+ var->num_state_slots = 1;
+ var->state_slots = ralloc_array(var, nir_state_slot, 1);
+ memcpy(var->state_slots[0].tokens, tokens,
+ sizeof(var->state_slots[0].tokens));
+ return var;
+}
+
+static nir_ssa_def *
+get_scale(lower_viewport_transform_state *state)
+{
+ if (!state->scale)
+ state->scale = create_uniform(state->shader, "gl_viewportScale",
+state->options->scale);
+
+ return nir_load_var(&state->b, state->scale);
+}
+
+static nir_ssa_def *
+get_translate(lower_viewport_transform_state *state)
+{
+ if (!state->translate)
+ state->translate = create_un
[Mesa-dev] [PATCH 4/4] mesa/st: do nir_lower_viewport_transform
Do nir_lower_viewport_transform when driver set
PIPE_CAP_NIR_VS_LOWER_VIEWPORT_TRANSFORM in vertex
shader.
Signed-off-by: Qiang Yu
---
src/gallium/auxiliary/util/u_screen.c | 3 +++
src/gallium/include/pipe/p_defines.h | 1 +
src/mesa/state_tracker/st_glsl_to_nir.cpp | 23 +++
src/mesa/state_tracker/st_nir.h | 4
src/mesa/state_tracker/st_program.c | 1 +
5 files changed, 32 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_screen.c
b/src/gallium/auxiliary/util/u_screen.c
index b902c083ad4..c3b8252197f 100644
--- a/src/gallium/auxiliary/util/u_screen.c
+++ b/src/gallium/auxiliary/util/u_screen.c
@@ -344,6 +344,9 @@ u_pipe_screen_get_param_defaults(struct pipe_screen
*pscreen,
case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
return 0;
+ case PIPE_CAP_NIR_VS_LOWER_VIEWPORT_TRANSFORM:
+ return 0;
+
default:
unreachable("bad PIPE_CAP_*");
}
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index ebc44d7a75e..1d6b69453e8 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -864,6 +864,7 @@ enum pipe_cap
PIPE_CAP_NIR_COMPACT_ARRAYS,
PIPE_CAP_MAX_VARYINGS,
PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK,
+ PIPE_CAP_NIR_VS_LOWER_VIEWPORT_TRANSFORM,
};
/**
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index e5d5fe21e27..87e457dccbf 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -738,6 +738,26 @@ st_nir_lower_wpos_ytransform(struct nir_shader *nir,
}
}
+void
+st_nir_lower_viewport_transform(struct nir_shader *nir,
+struct gl_program *prog,
+struct pipe_screen *pscreen)
+{
+ if (nir->info.stage != MESA_SHADER_VERTEX ||
+ !pscreen->get_param(pscreen, PIPE_CAP_NIR_VS_LOWER_VIEWPORT_TRANSFORM))
+ return;
+
+ static const nir_lower_viewport_transform_options viewport_options = {
+ .scale = { STATE_INTERNAL, STATE_VIEWPORT_SCALE },
+ .translate = { STATE_INTERNAL, STATE_VIEWPORT_TRANSLATE },
+ };
+
+ NIR_PASS_V(nir, nir_lower_viewport_transform, &viewport_options);
+
+ _mesa_add_state_reference(prog->Parameters, viewport_options.scale);
+ _mesa_add_state_reference(prog->Parameters, viewport_options.translate);
+}
+
bool
st_link_nir(struct gl_context *ctx,
struct gl_shader_program *shader_program)
@@ -793,6 +813,9 @@ st_link_nir(struct gl_context *ctx,
NIR_PASS_V(nir, st_nir_lower_wpos_ytransform, shader->Program,
st->pipe->screen);
+ NIR_PASS_V(nir, st_nir_lower_viewport_transform, shader->Program,
+ st->pipe->screen);
+
NIR_PASS_V(nir, nir_lower_system_values);
NIR_PASS_V(nir, nir_lower_clip_cull_distance_arrays);
diff --git a/src/mesa/state_tracker/st_nir.h b/src/mesa/state_tracker/st_nir.h
index 94eae84402e..100ab0f7125 100644
--- a/src/mesa/state_tracker/st_nir.h
+++ b/src/mesa/state_tracker/st_nir.h
@@ -41,6 +41,10 @@ void st_nir_lower_wpos_ytransform(struct nir_shader *nir,
struct gl_program *prog,
struct pipe_screen *pscreen);
+void st_nir_lower_viewport_transform(struct nir_shader *nir,
+ struct gl_program *prog,
+ struct pipe_screen *pscreen);
+
void st_finalize_nir(struct st_context *st, struct gl_program *prog,
struct gl_shader_program *shader_program,
struct nir_shader *nir);
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index 9f6e492d6fb..cf1ae6e65a8 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -442,6 +442,7 @@ st_translate_prog_to_nir(struct st_context *st, struct
gl_program *prog,
nir_validate_shader(nir, "after st/ptn lower_regs_to_ssa");
NIR_PASS_V(nir, st_nir_lower_wpos_ytransform, prog, st->pipe->screen);
+ NIR_PASS_V(nir, st_nir_lower_viewport_transform, prog, st->pipe->screen);
NIR_PASS_V(nir, nir_lower_system_values);
/* Optimise NIR */
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110252] swr software rasterizer fall back to OpenGL 2.1
https://bugs.freedesktop.org/show_bug.cgi?id=110252
Bug ID: 110252
Summary: swr software rasterizer fall back to OpenGL 2.1
Product: Mesa
Version: 19.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/swr
Assignee: mesa-dev@lists.freedesktop.org
Reporter: wanghaipen...@baidu.com
QA Contact: mesa-dev@lists.freedesktop.org
glGetString(GL_EXTENSIONS) returns no GL_EXT_framebuffer_sRGB, which is
required by OpenGL 3.0 (src/mesa/main/version.c compute_version)。so
glGetString(GL_VERSION) fall back to OpenGL 2.1。
#include
#include
#define GL_GLEXT_PROTOTYPES
#include
//#include
// settings
const unsigned int SCR_WIDTH = 960;
const unsigned int SCR_HEIGHT = 562;
int main(void) {
OSMesaContext ctx;
ctx = OSMesaCreateContextExt(OSMESA_RGBA, 16, 0, 0, NULL);
GLubyte *buffer = malloc(SCR_WIDTH * SCR_HEIGHT * 4 * sizeof(GLubyte));
OSMesaMakeCurrent(ctx, buffer, GL_UNSIGNED_BYTE, SCR_WIDTH, SCR_HEIGHT);
printf("GL_RENDERER = %s\n", (char*)glGetString(GL_RENDERER));
printf("GL_VERSION = %s\n", (char*)glGetString(GL_VERSION));
printf("GL_VENDOR = %s\n", (char*)glGetString(GL_VENDOR));
printf("GL_SHADING_LANGUAGE_VERSION = %s\n",
(char*)glGetString(GL_SHADING_LANGUAGE_VERSION));
printf("GL_EXTESIONS = %s\n", (char*)glGetString(GL_EXTENSIONS));
return 0;
}
--
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 110253] glBlitFramebuffer fails on MSAA fbo source.
https://bugs.freedesktop.org/show_bug.cgi?id=110253 Bug ID: 110253 Summary: glBlitFramebuffer fails on MSAA fbo source. Product: Mesa Version: 19.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/swr Assignee: mesa-dev@lists.freedesktop.org Reporter: wanghaipen...@baidu.com QA Contact: mesa-dev@lists.freedesktop.org https://github.com/mesa3d/mesa/blob/master/src/gallium/drivers/swr/swr_screen.cpp#L908 https://github.com/mesa3d/mesa/blob/master/src/gallium/drivers/swr/swr_screen.cpp#L105 when using MSAA fbo as read source, and OSMesa framebuffer as target, glBlitFramebuffer fails。 swr_blit: color resolve : 8 -> 0 swr: blit unsupported r8g8b8a8_unorm -> r8g8b8a8_unorm I think it may be solved by setting nr_storage_samples to 0 in src/gallium/drivers/swr/swr_screen.cpp swr_create_resolve_resource /* Create a single-sample copy of the resource. Copy the original * resource parameters and set flag to prevent recursion when re-calling * resource_create */ struct pipe_resource alt_template = msaa_res->base; alt_template.nr_samples = 0; alt_template.nr_storage_samples = 0; alt_template.flags |= SWR_RESOURCE_FLAG_ALT_SURFACE; -- 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
