Re: [Mesa-dev] [PATCH] vbo: remove MaxVertexAttribStride assert check.
Hi Dave, On Tuesday, 15 May 2018 07:44:44 CEST Dave Airlie wrote: > From: Dave Airlie > > Some drivers (virgl) don't support GL4.4 or GLES3.1 yet, > so never fill in this const. May be I should take care of all of these type of asserts, also the ones with MaxVertexAttribRelativeOffset and care for not checking them when the extension version is unavailable or checking against the OpenGL spec guaranteed minimum values for both constants instead of the actual ones. ... means, there are more asserts of this kind. Well, alternatively since you probably aim for supporting GL4.4 at one point, you could alternatively set the constant already? AFAICT the PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE is only used to set the constant and does not imply anything beyond. Anyhow, if it just bothers now ... Reviewed-by: Mathias Fröhlich best Mathias > > Signed-off-by: Dave Airlie > --- > src/mesa/vbo/vbo_exec_draw.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c > index 31d77002257..9f40e954224 100644 > --- a/src/mesa/vbo/vbo_exec_draw.c > +++ b/src/mesa/vbo/vbo_exec_draw.c > @@ -201,7 +201,6 @@ vbo_exec_bind_arrays(struct gl_context *ctx) > > /* Bind the buffer object */ > const GLuint stride = exec->vtx.vertex_size*sizeof(GLfloat); > - assert(stride <= ctx->Const.MaxVertexAttribStride); > _mesa_bind_vertex_buffer(ctx, vao, 0, exec->vtx.bufferobj, buffer_offset, > stride, false); > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vbo: remove MaxVertexAttribStride assert check.
From: Dave Airlie Some drivers (virgl) don't support GL4.4 or GLES3.1 yet, so never fill in this const. Signed-off-by: Dave Airlie --- src/mesa/vbo/vbo_exec_draw.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c index 31d77002257..9f40e954224 100644 --- a/src/mesa/vbo/vbo_exec_draw.c +++ b/src/mesa/vbo/vbo_exec_draw.c @@ -201,7 +201,6 @@ vbo_exec_bind_arrays(struct gl_context *ctx) /* Bind the buffer object */ const GLuint stride = exec->vtx.vertex_size*sizeof(GLfloat); - assert(stride <= ctx->Const.MaxVertexAttribStride); _mesa_bind_vertex_buffer(ctx, vao, 0, exec->vtx.bufferobj, buffer_offset, stride, false); -- 2.14.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106209] [opencl] [llvm-svn] build failure undefined reference to `clang::FrontendTimesIsEnabled'
https://bugs.freedesktop.org/show_bug.cgi?id=106209 Kai changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Kai --- This should be fixed by the following commit in Mesa master: commit b691d9192c436aba5a76577b7d772a791283a2e2 Author: Kai Wasserbäch Date: Tue May 1 14:14:46 2018 +0200 opencl: autotools: Fix linking order for OpenCL target Otherwise the build fails with an undefined reference to clang::FrontendTimesIsEnabled. Bugzilla: https://bugs.freedesktop.org/106209 Cc: Jan Vesely Cc: mesa-sta...@lists.freedesktop.org Signed-off-by: Kai Wasserbäch Acked-by: Jan Vesely Tested-by: Aaron Watry Tested-by: Dieter Nützel -- 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 7/9] radeonsi: avoid a crash in gallivm_dispose_target_library_info
On Mon, May 14, 2018 at 10:55 PM, Jan Vesely wrote: > On Thu, 2018-05-10 at 17:10 -0400, Marek Olšák wrote: > > On Thu, May 10, 2018 at 4:39 PM, Jan Vesely > wrote: > > > > > Is this still needed for llvm-6.0.1? > > > > > > > Probably. > > was it reproducible on non-ubuntu systems? There's still some time > until 6.0.1 is out, but I don't see any crashes on fedora (llvm-git). > I don't use non-ubuntu systems. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] radeonsi: avoid a crash in gallivm_dispose_target_library_info
On Thu, 2018-05-10 at 17:10 -0400, Marek Olšák wrote: > On Thu, May 10, 2018 at 4:39 PM, Jan Vesely wrote: > > > Is this still needed for llvm-6.0.1? > > > > Probably. was it reproducible on non-ubuntu systems? There's still some time until 6.0.1 is out, but I don't see any crashes on fedora (llvm-git). Jan > > Marek -- Jan Vesely signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallivm: Use alloca_undef with array type instead of alloca_array
From: Roland Scheidegger
Use a single allocation of array type instead of the old-style array
allocation for the temp and immediate arrays.
Probably only makes a difference if they aren't used indirectly (so,
if we used them solely because there's too many temps or immediates).
In this case the sroa and early-cse passes can sometimes do some
optimizations which they otherwise cannot.
(As a side note, for the temp reg array, we actually really should
use one allocation per array id, not just one for everything.)
Note that the instcombine pass would actually promote such
allocations to single alloc of array type as well, but it's too late
for some artificial shaders we've seen to help (we don't want to run
instcombine at the beginning due to its cost, hence would need
another sroa/cse pass after instcombine). sroa/early-cse help there
because they can actually eliminate all of the huge shader, reducing
it to a single const output (don't ask...).
(Interestingly, instcombine also removes all the bitcasts we do on that
allocation for single-value gathering, and in the end directly indexes
into the single vector elements, which according to spec is only
semi-valid, but this happens regardless. Another thing instcombine also
does is use inbound GEPs, which is probably something we should do
manually as well - for indirectly indexed reg files llvm may not be
able to figure it out on its own, but we should be able to guarantee
all pointers are always inbound. In any case, by the looks of it
using single allocation with array type seems to be the right thing
to do even for ordinary shaders.)
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 61 +
1 file changed, 33 insertions(+), 28 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index e411f90..83d7dbe 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -741,7 +741,8 @@ static void lp_exec_mask_store(struct lp_exec_mask *mask,
assert(lp_check_value(bld_store->type, val));
assert(LLVMGetTypeKind(LLVMTypeOf(dst_ptr)) == LLVMPointerTypeKind);
- assert(LLVMGetElementType(LLVMTypeOf(dst_ptr)) == LLVMTypeOf(val));
+ assert(LLVMGetElementType(LLVMTypeOf(dst_ptr)) == LLVMTypeOf(val) ||
+ LLVMGetTypeKind(LLVMGetElementType(LLVMTypeOf(dst_ptr))) ==
LLVMArrayTypeKind);
if (exec_mask) {
LLVMValueRef res, dst;
@@ -852,7 +853,14 @@ get_file_ptr(struct lp_build_tgsi_soa_context *bld,
if (bld->indirect_files & (1 << file)) {
LLVMValueRef lindex = lp_build_const_int32(bld->bld_base.base.gallivm,
index * 4 + chan);
- return LLVMBuildGEP(builder, var_of_array, &lindex, 1, "");
+ if (LLVMGetTypeKind(LLVMGetElementType(LLVMTypeOf(var_of_array))) ==
LLVMArrayTypeKind) {
+ LLVMValueRef gep[2];
+ gep[0] = lp_build_const_int32(bld->bld_base.base.gallivm, 0);
+ gep[1] = lindex;
+ return LLVMBuildGEP(builder, var_of_array, gep, 2, "");
+ } else {
+ return LLVMBuildGEP(builder, var_of_array, &lindex, 1, "");
+ }
}
else {
assert(index <= bld->bld_base.info->file_max[file]);
@@ -1352,21 +1360,20 @@ emit_fetch_immediate(
/* Gather values from the immediate register array */
res = build_gather(bld_base, imms_array, index_vec, NULL, index_vec2);
} else {
- LLVMValueRef lindex = lp_build_const_int32(gallivm,
-reg->Register.Index * 4 + swizzle);
- LLVMValueRef imms_ptr = LLVMBuildGEP(builder,
-bld->imms_array, &lindex, 1,
"");
+ LLVMValueRef gep[2];
+ gep[0] = lp_build_const_int32(gallivm, 0);
+ gep[1] = lp_build_const_int32(gallivm, reg->Register.Index * 4 +
swizzle);
+ LLVMValueRef imms_ptr = LLVMBuildGEP(builder,
+ bld->imms_array, gep, 2, "");
res = LLVMBuildLoad(builder, imms_ptr, "");
if (tgsi_type_is_64bit(stype)) {
-LLVMValueRef lindex1;
LLVMValueRef imms_ptr2;
LLVMValueRef res2;
-
-lindex1 = lp_build_const_int32(gallivm,
- reg->Register.Index * 4 + swizzle +
1);
+gep[1] = lp_build_const_int32(gallivm,
+ reg->Register.Index * 4 + swizzle +
1);
imms_ptr2 = LLVMBuildGEP(builder,
- bld->imms_array, &lindex1, 1, "");
+ bld->imms_array, gep, 2, "");
res2 = LLVMBuildLoad(builder, imms_ptr2, "");
res = emit_fetch_64bit(bld_base, stype, res, res2);
}
@@ -2957,13 +2964,14 @@ void lp_emit_immediate_soa(
unsigned index = bld->num_immediates;
struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target
Hi Kai, I've pushed the patch. I've also kept the stable tag although the policy is (afaik) to only support llvm versions available at the point of mesa release. Don't be surprised to see some pushback from stable maintainers. thanks, Jan On Sun, 2018-05-13 at 23:19 +0200, Dieter Nützel wrote: > Hello Jan and Kai, > > would be nice if this lands (have T-b from me). > > Dieter > > Am 13.05.2018 19:10, schrieb Jan Vesely: > > Hi, > > > > sorry for the delay. I thought maybe Emil is on holiday. I plan to > > push this on Monday evening (EDT) if there is no response by then. > > > > Jan > > > > On Sun, May 13, 2018 at 3:56 AM, Kai Wasserbäch > > wrote: > > > > > Ping! Can somebody *please* commit this patch? It fixes an FTBFS, > > > has two T-b > > > and one A-b. > > > > > > Kai Wasserbäch wrote on 07.05.2018 16:48: > > > > Jan Vesely wrote on 02.05.2018 22:38: > > > > > On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote: > > > > > > [...] > > > > > > > > > > Thank for looking into this. We probably need CLANG_LIBS handling > > > > > similar to LLVM_LIBS. I agree this is the best fix for now. > > > > > > > > > > Acked-by: Jan Vesely > > > > > > > > > > libclang.so might be a solkution, but I'm not sure how it > > > > > > interacts > > > > > with older or static build clang. It's also weird that we are > > > > > > linking > > > > > to clang here instead of clover which actually uses clang > > > > > > symbols. > > > > > > > > > > @Emil, are you OK with this patch? > > > > > > > > Gentle ping. > > > > > > > > > > > > > > -lclangDriver \ > > > > > > > > > > -lclangSerialization \ > > > > > > > > > > - -lclangCodeGen \ > > > > > > > > > > > > > > > > > > Is this change related? > > > > > > > > > > > > > > > > Not really, just a minor clean-up while I was busy a few lines > > > > > > above. > > > > > > > > "clangCodeGen" is already named on the first Clang library > > > > > > line. > > > > > > > > > > > > > > ah, all right, maybe mention it in the commit message? > > > > > > > > > > > > Do I need to resend the patch for that or can you just add a > > > > > > line like "This > > > > > > change also removes the duplicate clangCodeGen line (trivial > > > > > > change)." before > > > > > > pushing, considering, that there are two T-b tags to be added > > > > > > anyway? > > > > > > > > > > I'll add it on my side before pushing the patch. > > > > > > > > Thanks a lot! > > > > > > > > Cheers, > > > > Kai > > > > > > > > > > > > > > > > ___ > > > > mesa-dev mailing list > > > > mesa-dev@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev [1] > > > > > > > > > > -- > > > > > > Kai Wasserbäch (Kai Wasserbaech) > > > > > > E-Mail: k...@dev.carbon-project.org > > > > > > > > Links: > > -- > > [1] https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Jan Vesely signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] cso: check count == 0 in cso_set_vertex_buffers
From: Marek Olšák
The code didn't expect that.
Fixes: 86d63b53a20a747e "gallium: remove aux_vertex_buffer_slot code"
---
src/gallium/auxiliary/cso_cache/cso_context.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c
b/src/gallium/auxiliary/cso_cache/cso_context.c
index e3d46f3c8de..2543c5ff61f 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -1140,20 +1140,23 @@ cso_restore_vertex_elements(struct cso_context *ctx)
}
/* vertex buffers */
void cso_set_vertex_buffers(struct cso_context *ctx,
unsigned start_slot, unsigned count,
const struct pipe_vertex_buffer *buffers)
{
struct u_vbuf *vbuf = ctx->vbuf;
+ if (!count)
+ return;
+
if (vbuf) {
u_vbuf_set_vertex_buffers(vbuf, start_slot, count, buffers);
return;
}
/* Save what's in the auxiliary slot, so that we can save and restore it
* for meta ops. */
if (start_slot == 0) {
if (buffers) {
pipe_vertex_buffer_reference(&ctx->vertex_buffer0_current,
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC] glsl: bump default glsl version to 130 if EXT_gpu_shader4 used
EXT_gpu_shader4 is GL 3.0 plus some more bits and pieces. Currently
the extension is never enabled for any drivers. Bumping the glsl
version should allow shaders to compile.
Noticed when looking at the trace from:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102522
---
src/compiler/glsl/glsl_parser_extras.cpp | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
b/src/compiler/glsl/glsl_parser_extras.cpp
index c6ffdcc588c..9d22b53de56 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -422,7 +422,7 @@ _mesa_glsl_parse_state::process_version_directive(YYLTYPE
*locp, int version,
if (this->forced_language_version)
this->language_version = this->forced_language_version;
- else
+ else if ((unsigned)version > this->language_version)
this->language_version = version;
this->compat_shader = compat_token_present ||
@@ -814,6 +814,23 @@ _mesa_glsl_process_extension(const char *name, YYLTYPE
*name_locp,
}
} else {
const _mesa_glsl_extension *extension = find_extension(name);
+
+ /* The following is a hack while EXT_gpu_shader4 is unsupported.
+ */
+ assert(state->ctx->Extensions.EXT_gpu_shader4 == false);
+ if (state->language_version < 130 &&
+ state->ctx->Const.GLSLVersion >= 130 &&
+ strcmp(name, "GL_EXT_gpu_shader4") == 0 &&
+ (behavior == extension_enable || behavior == extension_require)) {
+
+ state->language_version = 130;
+ _mesa_glsl_warning(name_locp, state,
+"extension `%s' unsupported in %s shader."
+" Use GLSL 1.30 instead.",
+name, _mesa_shader_stage_to_string(state->stage));
+ return true;
+ }
+
if (extension && extension->compatible_with_state(state, api,
gl_version)) {
extension->set_flags(state, behavior);
if (extension->available_pred == has_ANDROID_extension_pack_es31a) {
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106522] QA Notice
https://bugs.freedesktop.org/show_bug.cgi?id=106522 Bug ID: 106522 Summary: QA Notice Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/X11 Assignee: mesa-dev@lists.freedesktop.org Reporter: pbril...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org * QA Notice: Package triggers severe warnings which indicate that it *may exhibit random runtime failures. * /var/tmp/portage/media-libs/mesa-18.1.0_rc2/work/mesa-18.1.0-rc2/src/amd/addrlib/gfx9/coord.cpp:203:39: warning: array subscript is above array bounds [-Warray-bounds] -- 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 102522] [radeonsi, bisected] commit 147d7fb772 causes full-window map to flash green in Crea
https://bugs.freedesktop.org/show_bug.cgi?id=102522 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Timothy Arceri --- I don't see any issue on my RX580 with a recent Mesa/llvm/kernel can you confirm this now works for you? As a side note the game seems to use GL_EXT_gpu_shader4 which Mesa doesn't support so some shaders fail to compile. They don't seem to use anything special and should just use GLSL 1.30 instead. -- 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] docs: Intel Mesa Drivers infographic
One more comment: NIR is *not* a stable API. On Mon, May 14, 2018 at 2:10 PM, Laura Ekstrand wrote: > I've made the edits. https://drive.google.com/file/d/1D0k3- > p88xEame5gepJQfIcCyZhG4CAsW/view?usp=sharing > > Thanks. > > Laura > > On Fri, May 11, 2018 at 5:07 PM, Jason Ekstrand > wrote: > >> Couple of edits: >> >> i915: I'd leave the bit about "embedded" out. I don't think it's used >> for any new deployments at this point. >> >> 1965: How about "Implements intel-specific parts of OpenGL entrypoints" >> >> ISL isn't really for converting between surface formats. A better >> one-sentence description would be "A library for computing image sizes and >> memory layouts" >> >> BLORP: How about "blit, clear, and resolve functionality" rather than >> "driver functionality" >> >> NIR: Not really a "front-end" more of an "optimizing middle compiler" >> >> Looks snazzy though. :-) >> >> On Thu, May 10, 2018 at 6:19 PM, Laura Ekstrand >> wrote: >> >>> Hi All, >>> >>> I developed the following infographic to inform readers about the >>> various parts that make up the Intel Mesa drivers. It is intended to help >>> groups inside Intel better understand the open source community, and at the >>> same time, it helps train newcomers to Mesa in driver architecture. >>> >>> I haven't put this in a tree yet since it is a combination of a >>> LibreOffice Draw document and a binary image file. >>> >>> Thanks. >>> >>> Laura >>> >>> https://drive.google.com/file/d/1D0k3-p88xEame5gepJQfIcCyZhG >>> 4CAsW/view?usp=sharing >>> >>> ___ >>> 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 00/19] AMD support for NIR deref instructions.
On Mon, May 14, 2018 at 8:07 PM, Dave Airlie wrote: > On 13 May 2018 at 10:19, Bas Nieuwenhuizen wrote: >> This implements support in radv and radeonsi for NIR deref >> instructions instead of deref chains. >> >> It contains 4 parts: >> - patch 1 is a fixup for the initial series by Jason >> - Add support everywhere for instruction based derefs >> - Stop lowering them to deref chains (may need to be synchronized >> with other drivers and core nir code to keep things bisectable) >> - Remove support for deref chains. > > Okay I've read over this and I'm pretty happy with it. > > I do wonder if we could lower the impact on some of the code by > adding the wrappers functions and getting var in a few places. > > i.e. instead of > + nir_variable *var = uses_deref_chain ? instr->variables[0]->var : > + > nir_deref_instr_get_variable(nir_instr_as_deref(instr->src[0].ssa->parent_instr); > - int idx = instr->variables[0]->var->data.driver_location; > + int idx = var->data.driver_location; I guess the uses_deref_chain part goes away, but I'd proposed some helper to get the var before.. it saves a bit of the churn, but not all.. (and iirc we ended up with a helper something along those lines anyways, I'd have to switch back to deref branch to check the name.. Anyways, I'm pretty happy with Jason's series.. I didn't really bother to try to review it patch by patch, but it is a lot of churn so looking at the end result seemed to be the more sensible way to approach it. I've played with it quite a bit since I've added pointer support for compute on top. I guess tomorrow I should rebase the gallium/ir3/vc4/vc5 parts, and start trying to merge this into a bisectable patchset. BR, -R > > We could do a first pass patch that adds the var = > instr->variables[0]; and removes > the instr->variables[0] references elsewhere. > > Up to you though, not sure how much extra work it would generate. > > Also for Jason, strct is less chars than struct_type, but I expect the > number of times you typo it might end up more keystrokes :-P > > For the series: > Reviewed-by: Dave Airlie > > Dave. > ___ > 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 00/19] AMD support for NIR deref instructions.
On 13 May 2018 at 10:19, Bas Nieuwenhuizen wrote: > This implements support in radv and radeonsi for NIR deref > instructions instead of deref chains. > > It contains 4 parts: > - patch 1 is a fixup for the initial series by Jason > - Add support everywhere for instruction based derefs > - Stop lowering them to deref chains (may need to be synchronized > with other drivers and core nir code to keep things bisectable) > - Remove support for deref chains. Okay I've read over this and I'm pretty happy with it. I do wonder if we could lower the impact on some of the code by adding the wrappers functions and getting var in a few places. i.e. instead of + nir_variable *var = uses_deref_chain ? instr->variables[0]->var : + nir_deref_instr_get_variable(nir_instr_as_deref(instr->src[0].ssa->parent_instr); - int idx = instr->variables[0]->var->data.driver_location; + int idx = var->data.driver_location; We could do a first pass patch that adds the var = instr->variables[0]; and removes the instr->variables[0] references elsewhere. Up to you though, not sure how much extra work it would generate. Also for Jason, strct is less chars than struct_type, but I expect the number of times you typo it might end up more keystrokes :-P For the series: Reviewed-by: Dave Airlie Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radv/resolve: pass number of components to resolve builder
From: Dave Airlie
This just adds the option to use more components
---
src/amd/vulkan/radv_meta.c| 9 +
src/amd/vulkan/radv_meta.h| 3 ++-
src/amd/vulkan/radv_meta_resolve_cs.c | 2 +-
src/amd/vulkan/radv_meta_resolve_fs.c | 2 +-
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/amd/vulkan/radv_meta.c b/src/amd/vulkan/radv_meta.c
index 56b72d1c99b..98dfccae9e3 100644
--- a/src/amd/vulkan/radv_meta.c
+++ b/src/amd/vulkan/radv_meta.c
@@ -509,7 +509,8 @@ void radv_meta_build_resolve_shader_core(nir_builder *b,
int samples,
nir_variable *input_img,
nir_variable *color,
-nir_ssa_def *img_coord)
+nir_ssa_def *img_coord,
+int coord_components)
{
/* do a txf_ms on each sample */
nir_ssa_def *tmp;
@@ -524,7 +525,7 @@ void radv_meta_build_resolve_shader_core(nir_builder *b,
tex->src[1].src = nir_src_for_ssa(nir_imm_int(b, 0));
tex->dest_type = nir_type_float;
tex->is_array = false;
- tex->coord_components = 2;
+ tex->coord_components = coord_components;
tex->texture = nir_deref_var_create(tex, input_img);
tex->sampler = NULL;
@@ -541,7 +542,7 @@ void radv_meta_build_resolve_shader_core(nir_builder *b,
tex_all_same->src[0].src = nir_src_for_ssa(img_coord);
tex_all_same->dest_type = nir_type_float;
tex_all_same->is_array = false;
- tex_all_same->coord_components = 2;
+ tex_all_same->coord_components = coord_components;
tex_all_same->texture = nir_deref_var_create(tex_all_same,
input_img);
tex_all_same->sampler = NULL;
@@ -564,7 +565,7 @@ void radv_meta_build_resolve_shader_core(nir_builder *b,
tex_add->src[1].src = nir_src_for_ssa(nir_imm_int(b,
i));
tex_add->dest_type = nir_type_float;
tex_add->is_array = false;
- tex_add->coord_components = 2;
+ tex_add->coord_components = coord_components;
tex_add->texture = nir_deref_var_create(tex_add,
input_img);
tex_add->sampler = NULL;
diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index 4a9abae30ac..326f2ce1438 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -221,7 +221,8 @@ void radv_meta_build_resolve_shader_core(nir_builder *b,
int samples,
nir_variable *input_img,
nir_variable *color,
-nir_ssa_def *img_coord);
+nir_ssa_def *img_coord,
+int coord_components);
#ifdef __cplusplus
}
#endif
diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c
b/src/amd/vulkan/radv_meta_resolve_cs.c
index 322e72e465e..3f28a766cec 100644
--- a/src/amd/vulkan/radv_meta_resolve_cs.c
+++ b/src/amd/vulkan/radv_meta_resolve_cs.c
@@ -128,7 +128,7 @@ build_resolve_compute_shader(struct radv_device *dev, bool
is_integer, bool is_s
nir_variable *color = nir_local_variable_create(b.impl,
glsl_vec4_type(), "color");
radv_meta_build_resolve_shader_core(&b, is_integer, samples, input_img,
- color, img_coord);
+ color, img_coord, 2);
nir_ssa_def *outval = nir_load_var(&b, color);
if (is_srgb)
diff --git a/src/amd/vulkan/radv_meta_resolve_fs.c
b/src/amd/vulkan/radv_meta_resolve_fs.c
index ef8c1d8b1da..3c42bbdd52d 100644
--- a/src/amd/vulkan/radv_meta_resolve_fs.c
+++ b/src/amd/vulkan/radv_meta_resolve_fs.c
@@ -93,7 +93,7 @@ build_resolve_fragment_shader(struct radv_device *dev, bool
is_integer, int samp
nir_variable *color = nir_local_variable_create(b.impl,
glsl_vec4_type(), "color");
radv_meta_build_resolve_shader_core(&b, is_integer, samples, input_img,
- color, img_coord);
+ color, img_coord, 2);
nir_ssa_def *outval = nir_load_var(&b, color);
nir_store_var(&b, color_out, outval, 0xf);
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radv: attempt to do multi-layer subpass resolve in single pass
From: Dave Airlie
This changes the cs resolve path to try and resolve all layers
using a single shader invocation.
We still have to create a dest iview to do the srgb format conversion.
---
src/amd/vulkan/radv_meta_resolve_cs.c | 107 ++
1 file changed, 45 insertions(+), 62 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c
b/src/amd/vulkan/radv_meta_resolve_cs.c
index 3f28a766cec..a3f81f5667a 100644
--- a/src/amd/vulkan/radv_meta_resolve_cs.c
+++ b/src/amd/vulkan/radv_meta_resolve_cs.c
@@ -77,11 +77,11 @@ build_resolve_compute_shader(struct radv_device *dev, bool
is_integer, bool is_s
char name[64];
const struct glsl_type *sampler_type =
glsl_sampler_type(GLSL_SAMPLER_DIM_MS,
false,
-false,
+true,
GLSL_TYPE_FLOAT);
const struct glsl_type *img_type =
glsl_sampler_type(GLSL_SAMPLER_DIM_2D,
false,
-false,
+true,
GLSL_TYPE_FLOAT);
snprintf(name, 64, "meta_resolve_cs-%d-%s", samples, is_integer ? "int"
: (is_srgb ? "srgb" : "float"));
nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_COMPUTE, NULL);
@@ -110,25 +110,25 @@ build_resolve_compute_shader(struct radv_device *dev,
bool is_integer, bool is_s
nir_intrinsic_instr *src_offset = nir_intrinsic_instr_create(b.shader,
nir_intrinsic_load_push_constant);
nir_intrinsic_set_base(src_offset, 0);
- nir_intrinsic_set_range(src_offset, 16);
+ nir_intrinsic_set_range(src_offset, 24);
src_offset->src[0] = nir_src_for_ssa(nir_imm_int(&b, 0));
- src_offset->num_components = 2;
- nir_ssa_dest_init(&src_offset->instr, &src_offset->dest, 2, 32,
"src_offset");
+ src_offset->num_components = 3;
+ nir_ssa_dest_init(&src_offset->instr, &src_offset->dest, 3, 32,
"src_offset");
nir_builder_instr_insert(&b, &src_offset->instr);
nir_intrinsic_instr *dst_offset = nir_intrinsic_instr_create(b.shader,
nir_intrinsic_load_push_constant);
nir_intrinsic_set_base(dst_offset, 0);
- nir_intrinsic_set_range(dst_offset, 16);
- dst_offset->src[0] = nir_src_for_ssa(nir_imm_int(&b, 8));
- dst_offset->num_components = 2;
- nir_ssa_dest_init(&dst_offset->instr, &dst_offset->dest, 2, 32,
"dst_offset");
+ nir_intrinsic_set_range(dst_offset, 24);
+ dst_offset->src[0] = nir_src_for_ssa(nir_imm_int(&b, 12));
+ dst_offset->num_components = 3;
+ nir_ssa_dest_init(&dst_offset->instr, &dst_offset->dest, 3, 32,
"dst_offset");
nir_builder_instr_insert(&b, &dst_offset->instr);
- nir_ssa_def *img_coord = nir_channels(&b, nir_iadd(&b, global_id,
&src_offset->dest.ssa), 0x3);
+ nir_ssa_def *img_coord = nir_channels(&b, nir_iadd(&b, global_id,
&src_offset->dest.ssa), 0x7);
nir_variable *color = nir_local_variable_create(b.impl,
glsl_vec4_type(), "color");
radv_meta_build_resolve_shader_core(&b, is_integer, samples, input_img,
- color, img_coord, 2);
+ color, img_coord, 3);
nir_ssa_def *outval = nir_load_var(&b, color);
if (is_srgb)
@@ -188,7 +188,7 @@ create_layout(struct radv_device *device)
.setLayoutCount = 1,
.pSetLayouts = &device->meta_state.resolve_compute.ds_layout,
.pushConstantRangeCount = 1,
- .pPushConstantRanges =
&(VkPushConstantRange){VK_SHADER_STAGE_COMPUTE_BIT, 0, 16},
+ .pPushConstantRanges =
&(VkPushConstantRange){VK_SHADER_STAGE_COMPUTE_BIT, 0, 24},
};
result = radv_CreatePipelineLayout(radv_device_to_handle(device),
@@ -311,9 +311,9 @@ static void
emit_resolve(struct radv_cmd_buffer *cmd_buffer,
struct radv_image_view *src_iview,
struct radv_image_view *dest_iview,
-const VkOffset2D *src_offset,
- const VkOffset2D *dest_offset,
- const VkExtent2D *resolve_extent)
+const VkOffset3D *src_offset,
+const VkOffset3D *dest_offset,
+const VkExtent3D *resolve_extent)
{
struct radv_device *device = cmd_buffer->device;
const uint32_t samples = src_iview->image->info.samples;
@@ -364,17 +364,19 @@ emit_resolve(struct radv_cmd_buffer *cmd_buffer,
radv_CmdBindPipeline(radv_cmd_buffer_to_handle(cmd_buffer),
VK_PIPELINE_BIND_POINT_COMPUTE, pipeline);
- unsigned push_constants[4] = {
+
Re: [Mesa-dev] [PATCH 3/4] i965: Handle non-zero texture buffer offsets in buffer object range calculation.
On Fri, May 11, 2018 at 05:09:57PM -0700, Francisco Jerez wrote: > Hey Nanley, > > Nanley Chery writes: > > > On Mon, Mar 19, 2018 at 11:26:58AM -0700, Francisco Jerez wrote: > >> Otherwise the specified surface state will allow the GPU to access > >> memory up to BufferOffset bytes past the end of the buffer. Found by > >> inspection. > >> > >> Cc: mesa-sta...@lists.freedesktop.org > >> --- > >> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> 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 ed4def9046e..2ab15af793a 100644 > >> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c > >> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c > >> @@ -654,7 +654,8 @@ buffer_texture_range_size(struct brw_context *brw, > >> * so that when ISL divides by stride to obtain the number of texels, > >> that > >> * texel count is clamped to MAX_TEXTURE_BUFFER_SIZE. > >> */ > >> - return MIN3((unsigned)obj->BufferSize, buffer_size, > >> + return MIN3((unsigned)obj->BufferSize, > >> + buffer_size - obj->BufferOffset, > >> brw->ctx.Const.MaxTextureBufferSize * texel_size); > > > > I don't understand this change. Previously we took the minimum between: > > 1) The TextureBuffer size specified by glTexBufferRange(). > > 2) The size of the buffer object specified by glTexBuffer(). > > 3) The maximum allowed texture buffer size. > > > > This patch modifies case 2 to be subtracted by the offset which will > > always be 0 for glTexBuffer(). > > > > The second argument of the MIN3 function is calculating the size of the > buffer object range accessible to the GPU. The correct offset interval > that is supposed to be mapped to the GPU is [obj->BufferOffset, > obj->BufferObject->Size[, from where the expression above follows. > We discussed this in the office. The scenario in question is if the user calls glTexBufferRange() with a non-zero offset, then shrinks the size of the backing buffer object with glBufferData(). Thinking about some scenarios aloud here: Scenario A: * Create a texbuf s.t. texbuf_offset == 0 && texbuf_size > 0 * Shrink the backing buf s.t. buf_size < texbuf_size * buffer_texture_range_size() returns buf_size pre and post patch (correct) Scenario B: * Create a texbuf s.t. texbuf_offset > 0 && texbuf_size > 0 * Shrink the backing buf s.t. buf_size < texbuf_offset && buf_size > texbuf_size * buffer_texture_range_size() returns texbuf_size pre-patch (incorrect) and buf_size - texbuf_offset post-patch (negative number -> incorrect). We should return 0. Scenario C: * Create a texbuf s.t. texbuf_offset > 0 && texbuf_size > 0 * Shrink the backing buf s.t. buf_size < texbuf_offset && buf_size < texbuf_size * buffer_texture_range_size() returns buf_size pre-patch (incorrect) and buf_size - texbuf_offset post-patch (negative number -> incorrect). We should return 0. Scenario D: * Create a texbuf s.t. texbuf_offset > 0 && texbuf_size > 0 * Shrink the backing buf s.t. buf_size > texbuf_offset && buf_size < texbuf_size * buffer_texture_range_size() returns buf_size pre-patch (incorrect) and buf_size - texbuf_offset post-patch (correct). Scenario E: * Create a texbuf s.t. texbuf_offset > 0 && texbuf_size > 0 * Shrink the backing buf s.t. buf_size > texbuf_offset && buf_size > texbuf_size && buf_size < texbuf_offset + texbuf_size * buffer_texture_range_size() returns texbuf_size pre-patch (incorrect) and buf_size - texbuf_offset post-patch (correct). This patch fixes scenarios D and E. I think it'd be helpful if you added an assert or at least a comment about the cases this function doesn't handle. With that, this patch is Reviewed-by: Nanley Chery > >> } > >> > >> -- > >> 2.16.1 > >> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] docs: Intel Mesa Drivers infographic
I've made the edits. https://drive.google.com/file/d/1D0k3-p88xEame5gepJQfIcCyZhG4CAsW/view?usp=sharing Thanks. Laura On Fri, May 11, 2018 at 5:07 PM, Jason Ekstrand wrote: > Couple of edits: > > i915: I'd leave the bit about "embedded" out. I don't think it's used > for any new deployments at this point. > > 1965: How about "Implements intel-specific parts of OpenGL entrypoints" > > ISL isn't really for converting between surface formats. A better > one-sentence description would be "A library for computing image sizes and > memory layouts" > > BLORP: How about "blit, clear, and resolve functionality" rather than > "driver functionality" > > NIR: Not really a "front-end" more of an "optimizing middle compiler" > > Looks snazzy though. :-) > > On Thu, May 10, 2018 at 6:19 PM, Laura Ekstrand > wrote: > >> Hi All, >> >> I developed the following infographic to inform readers about the various >> parts that make up the Intel Mesa drivers. It is intended to help groups >> inside Intel better understand the open source community, and at the same >> time, it helps train newcomers to Mesa in driver architecture. >> >> I haven't put this in a tree yet since it is a combination of a >> LibreOffice Draw document and a binary image file. >> >> Thanks. >> >> Laura >> >> https://drive.google.com/file/d/1D0k3-p88xEame5gepJQfIcCyZhG >> 4CAsW/view?usp=sharing >> >> ___ >> 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] ac/surface: Don't assert that bpp is power of two.
There are non-shared linear images too, and those don't
need the extra alignment at all.
So just keep track of whether the image can be exported.
Fixes: e361970ed73 "radv: Add support for IMG_DATA_FORMAT_32_32_32."
---
src/amd/common/ac_surface.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 9e742dc8a45..f6c4cd7db0f 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -281,7 +281,7 @@ static int surf_config_sanity(const struct ac_surf_config
*config,
static int gfx6_compute_level(ADDR_HANDLE addrlib,
const struct ac_surf_config *config,
struct radeon_surf *surf, bool is_stencil,
- unsigned level, bool compressed,
+ unsigned level, bool compressed, bool shareable,
ADDR_COMPUTE_SURFACE_INFO_INPUT *AddrSurfInfoIn,
ADDR_COMPUTE_SURFACE_INFO_OUTPUT *AddrSurfInfoOut,
ADDR_COMPUTE_DCCINFO_INPUT *AddrDccIn,
@@ -301,7 +301,7 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
*/
if (config->info.levels == 1 &&
AddrSurfInfoIn->tileMode == ADDR_TM_LINEAR_ALIGNED &&
- AddrSurfInfoIn->bpp) {
+ AddrSurfInfoIn->bpp && shareable) {
unsigned alignment = 256 / (AddrSurfInfoIn->bpp / 8);
assert(util_is_power_of_two_or_zero(AddrSurfInfoIn->bpp));
@@ -560,6 +560,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
{
unsigned level;
bool compressed;
+ bool shareable;
ADDR_COMPUTE_SURFACE_INFO_INPUT AddrSurfInfoIn = {0};
ADDR_COMPUTE_SURFACE_INFO_OUTPUT AddrSurfInfoOut = {0};
ADDR_COMPUTE_DCCINFO_INPUT AddrDccIn = {0};
@@ -579,6 +580,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
AddrSurfInfoOut.pTileInfo = &AddrTileInfoOut;
compressed = surf->blk_w == 4 && surf->blk_h == 4;
+ shareable = (surf->flags & RADEON_SURF_SHAREABLE);
/* MSAA requires 2D tiling. */
if (config->info.samples > 1)
@@ -773,7 +775,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
if (!only_stencil) {
for (level = 0; level < config->info.levels; level++) {
r = gfx6_compute_level(addrlib, config, surf, false,
level, compressed,
- &AddrSurfInfoIn,
&AddrSurfInfoOut,
+ shareable, &AddrSurfInfoIn,
&AddrSurfInfoOut,
&AddrDccIn, &AddrDccOut,
&AddrHtileIn, &AddrHtileOut);
if (r)
return r;
@@ -820,7 +822,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
for (level = 0; level < config->info.levels; level++) {
r = gfx6_compute_level(addrlib, config, surf, true,
level, compressed,
- &AddrSurfInfoIn,
&AddrSurfInfoOut,
+ shareable, &AddrSurfInfoIn,
&AddrSurfInfoOut,
&AddrDccIn, &AddrDccOut,
NULL, NULL);
if (r)
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: make eglWaitClient behave like glFinish
Tapani Pälli writes: > On 14.05.2018 10:03, Eric Anholt wrote: >> Tapani Pälli writes: >> >>> As defined by the spec: >>> "All rendering calls for the currently bound context, for >>> the current rendering API, made prior to eglWaitClient, are >>> guaranteed to be executed before native rendering calls made >>> after eglWaitClient which affect the read or draw surfaces >>> associated with that context. >>> >>> The same result can be achieved using client API-specific calls >>> such as glFinish or vgFinish." >>> >>> v2: call glFinish() to ensure identical behaviour >>> >>> Signed-off-by: Tapani Pälli >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106337 >> >> I don't think the operation they're doing there is "native rendering" as >> far as EGL is concerned. I think the backend flush is the right thing >> for us to be calling here, same as glXWaitGL(). If they want >> glFinish(), they should be calling glFinish(). >> > > Hmm ok .. the problem is that they do CPU read on the buffer which is > not "native rendering" but it seemed to me something that native API > could also attempt to do. I'm OK with 'just use glFinish' also. To pretend to be "native rendering", the CPU read on the other side should be participating in implicit synchronization. That's what a glamor fallback would be doing in X11, for example. 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] [Mesa-stable] [PATCH 1/2] radv: Fix up 2_10_10_10 alpha sign.
On Mon, May 14, 2018 at 9:28 PM, Mark Janes wrote:
> Bas Nieuwenhuizen writes:
>
>> Pre-Vega HW always interprets the alpha for this format as unsigned,
>> so we have to implement a fixup to do the sign correctly for signed
>> formats.
>>
>> CC: 18.0 18.1
>
> I couldn't apply this to 18.0. You will probably need to provide a
> backport for Juan.
Backport here:
https://patchwork.freedesktop.org/patch/222758/
>
>> ---
>> src/amd/vulkan/radv_nir_to_llvm.c | 61 ---
>> src/amd/vulkan/radv_pipeline.c| 30 +--
>> src/amd/vulkan/radv_private.h | 1 +
>> src/amd/vulkan/radv_shader.h | 12 ++
>> 4 files changed, 95 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
>> b/src/amd/vulkan/radv_nir_to_llvm.c
>> index f98940f0d8f..9d9ecda63cf 100644
>> --- a/src/amd/vulkan/radv_nir_to_llvm.c
>> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
>> @@ -1865,6 +1865,47 @@ static LLVMValueRef radv_get_sampler_desc(struct
>> ac_shader_abi *abi,
>> return ac_build_load_to_sgpr(&ctx->ac, list, index);
>> }
>>
>> +/* For 2_10_10_10 formats the alpha is handled as unsigned by pre-vega HW.
>> + * so we may need to fix it up. */
>> +static LLVMValueRef
>> +adjust_vertex_fetch_alpha(struct radv_shader_context *ctx,
>> + unsigned adjustment,
>> + LLVMValueRef alpha)
>> +{
>> + if (adjustment == RADV_ALPHA_ADJUST_NONE)
>> + return alpha;
>> +
>> + LLVMValueRef c30 = LLVMConstInt(ctx->ac.i32, 30, 0);
>> +
>> + if (adjustment == RADV_ALPHA_ADJUST_SSCALED)
>> + alpha = LLVMBuildFPToUI(ctx->ac.builder, alpha, ctx->ac.i32,
>> "");
>> + else
>> + alpha = LLVMBuildBitCast(ctx->ac.builder, alpha, ctx->ac.i32,
>> "");
>> +
>> + /* For the integer-like cases, do a natural sign extension.
>> + *
>> + * For the SNORM case, the values are 0.0, 0.333, 0.666, 1.0
>> + * and happen to contain 0, 1, 2, 3 as the two LSBs of the
>> + * exponent.
>> + */
>> + alpha = LLVMBuildShl(ctx->ac.builder, alpha,
>> + adjustment == RADV_ALPHA_ADJUST_SNORM ?
>> + LLVMConstInt(ctx->ac.i32, 7, 0) : c30, "");
>> + alpha = LLVMBuildAShr(ctx->ac.builder, alpha, c30, "");
>> +
>> + /* Convert back to the right type. */
>> + if (adjustment == RADV_ALPHA_ADJUST_SNORM) {
>> + LLVMValueRef clamp;
>> + LLVMValueRef neg_one = LLVMConstReal(ctx->ac.f32, -1.0);
>> + alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
>> "");
>> + clamp = LLVMBuildFCmp(ctx->ac.builder, LLVMRealULT, alpha,
>> neg_one, "");
>> + alpha = LLVMBuildSelect(ctx->ac.builder, clamp, neg_one,
>> alpha, "");
>> + } else if (adjustment == RADV_ALPHA_ADJUST_SSCALED) {
>> + alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
>> "");
>> + }
>> +
>> + return alpha;
>> +}
>>
>> static void
>> handle_vs_input_decl(struct radv_shader_context *ctx,
>> @@ -1884,9 +1925,11 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
>>
>> variable->data.driver_location = idx * 4;
>>
>> - for (unsigned i = 0; i < attrib_count; ++i, ++idx) {
>> - if (ctx->options->key.vs.instance_rate_inputs & (1u << (index
>> + i))) {
>> - uint32_t divisor =
>> ctx->options->key.vs.instance_rate_divisors[index + i];
>> + for (unsigned i = 0; i < attrib_count; ++i, ++idx, ++index) {
>> + LLVMValueRef output[4];
>> +
>> + if (ctx->options->key.vs.instance_rate_inputs & (1u << index))
>> {
>> + uint32_t divisor =
>> ctx->options->key.vs.instance_rate_divisors[index];
>>
>> if (divisor) {
>> buffer_index = LLVMBuildAdd(ctx->ac.builder,
>> ctx->abi.instance_id,
>> @@ -1910,7 +1953,7 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
>> } else
>> buffer_index = LLVMBuildAdd(ctx->ac.builder,
>> ctx->abi.vertex_id,
>> ctx->abi.base_vertex, "");
>> - t_offset = LLVMConstInt(ctx->ac.i32, index + i, false);
>> + t_offset = LLVMConstInt(ctx->ac.i32, index, false);
>>
>> t_list = ac_build_load_to_sgpr(&ctx->ac, t_list_ptr, t_offset);
>>
>> @@ -1923,9 +1966,15 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
>>
>> for (unsigned chan = 0; chan < 4; chan++) {
>> LLVMValueRef llvm_chan = LLVMConstInt(ctx->ac.i32,
>> chan, false);
>> + output[chan] =
>> LLVMBuildExtractElement(ctx->ac.builder, input, llvm_chan, "");
>> + }
>> +
>> + unsigned alpha_adjust = (ctx->options->key.vs.alpha_adjust >>
>> (index * 2)) & 3;
>> + output[3] = adjust_vertex_fetch_alpha(ctx, alpha_adjust,
>> output[3]);
>>
[Mesa-dev] [PATCH] radv: Fix up 2_10_10_10 alpha sign.
Pre-Vega HW always interprets the alpha for this format as unsigned,
so we have to implement a fixup to do the sign correctly for signed
formats.
v2: Improve indexing mess.
CC: 18.0
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106480
Reviewed-by: Samuel Pitoiset
(Backport of 3d4d388e392 "radv: Fix up 2_10_10_10 alpha sign.")
---
src/amd/common/ac_nir_to_llvm.c | 67 -
src/amd/common/ac_nir_to_llvm.h | 12 ++
src/amd/vulkan/radv_pipeline.c | 29 +-
src/amd/vulkan/radv_private.h | 1 +
4 files changed, 98 insertions(+), 11 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index d82a059df84..f3afb237038 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -5335,6 +5335,48 @@ static void visit_cf_list(struct ac_nir_context *ctx,
}
}
+/* For 2_10_10_10 formats the alpha is handled as unsigned by pre-vega HW.
+ * so we may need to fix it up. */
+static LLVMValueRef
+adjust_vertex_fetch_alpha(struct nir_to_llvm_context *ctx,
+ unsigned adjustment,
+ LLVMValueRef alpha)
+{
+ if (adjustment == RADV_ALPHA_ADJUST_NONE)
+ return alpha;
+
+ LLVMValueRef c30 = LLVMConstInt(ctx->ac.i32, 30, 0);
+
+ if (adjustment == RADV_ALPHA_ADJUST_SSCALED)
+ alpha = LLVMBuildFPToUI(ctx->ac.builder, alpha, ctx->ac.i32,
"");
+ else
+ alpha = ac_to_integer(&ctx->ac, alpha);
+
+ /* For the integer-like cases, do a natural sign extension.
+*
+* For the SNORM case, the values are 0.0, 0.333, 0.666, 1.0
+* and happen to contain 0, 1, 2, 3 as the two LSBs of the
+* exponent.
+*/
+ alpha = LLVMBuildShl(ctx->ac.builder, alpha,
+adjustment == RADV_ALPHA_ADJUST_SNORM ?
+LLVMConstInt(ctx->ac.i32, 7, 0) : c30, "");
+ alpha = LLVMBuildAShr(ctx->ac.builder, alpha, c30, "");
+
+ /* Convert back to the right type. */
+ if (adjustment == RADV_ALPHA_ADJUST_SNORM) {
+ LLVMValueRef clamp;
+ LLVMValueRef neg_one = LLVMConstReal(ctx->ac.f32, -1.0);
+ alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
"");
+ clamp = LLVMBuildFCmp(ctx->ac.builder, LLVMRealULT, alpha,
neg_one, "");
+ alpha = LLVMBuildSelect(ctx->ac.builder, clamp, neg_one, alpha,
"");
+ } else if (adjustment == RADV_ALPHA_ADJUST_SSCALED) {
+ alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
"");
+ }
+
+ return alpha;
+}
+
static void
handle_vs_input_decl(struct nir_to_llvm_context *ctx,
struct nir_variable *variable)
@@ -5344,14 +5386,15 @@ handle_vs_input_decl(struct nir_to_llvm_context *ctx,
LLVMValueRef t_list;
LLVMValueRef input;
LLVMValueRef buffer_index;
- int index = variable->data.location - VERT_ATTRIB_GENERIC0;
- int idx = variable->data.location;
unsigned attrib_count = glsl_count_attribute_slots(variable->type,
true);
- variable->data.driver_location = idx * 4;
+ variable->data.driver_location = variable->data.location * 4;
+
+ for (unsigned i = 0; i < attrib_count; ++i) {
+ LLVMValueRef output[4];
+ unsigned attrib_index = variable->data.location + i -
VERT_ATTRIB_GENERIC0;
- for (unsigned i = 0; i < attrib_count; ++i, ++idx) {
- if (ctx->options->key.vs.instance_rate_inputs & (1u << (index +
i))) {
+ if (ctx->options->key.vs.instance_rate_inputs & (1u <<
attrib_index)) {
buffer_index = LLVMBuildAdd(ctx->builder,
ctx->abi.instance_id,
ctx->abi.start_instance,
"");
if (ctx->options->key.vs.as_ls) {
@@ -5364,7 +5407,7 @@ handle_vs_input_decl(struct nir_to_llvm_context *ctx,
} else
buffer_index = LLVMBuildAdd(ctx->builder,
ctx->abi.vertex_id,
ctx->abi.base_vertex, "");
- t_offset = LLVMConstInt(ctx->ac.i32, index + i, false);
+ t_offset = LLVMConstInt(ctx->ac.i32, attrib_index, false);
t_list = ac_build_load_to_sgpr(&ctx->ac, t_list_ptr, t_offset);
@@ -5375,9 +5418,15 @@ handle_vs_input_decl(struct nir_to_llvm_context *ctx,
for (unsigned chan = 0; chan < 4; chan++) {
LLVMValueRef llvm_chan = LLVMConstInt(ctx->ac.i32,
chan, false);
- ctx->inputs[radeon_llvm_reg_index_soa(idx, chan)] =
- ac_to_integer(&ctx->ac,
LLVMBuildExtractElement(ctx->builder,
- input, llvm_chan, ""));
+ output[chan] = LLVMBuildExtractElement
Re: [Mesa-dev] [PATCH] spirv: fix visiting inner loops with same break/continue block
On Mon, May 14, 2018 at 1:22 PM, Jason Ekstrand wrote: > On Mon, May 14, 2018 at 1:05 PM, Samuel Pitoiset < > samuel.pitoi...@gmail.com> wrote: > >> We should stop walking through the CFG when the inner loop's >> break block ends up as the same block as the outer loop's >> continue block because we are already going to visit it. >> >> This fixes the following assertion which ends up by crashing >> in RADV or ANV: >> >> SPIR-V parsing FAILED: >> In file ../src/compiler/spirv/vtn_cfg.c:381 >> block->node.link.next == NULL >> 0 bytes into the SPIR-V binary >> >> This also fixes a crash with a camera shader from SteamVR. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106090 >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106504 >> CC: 18.0 18.1 >> Signed-off-by: Samuel Pitoiset >> --- >> src/compiler/spirv/vtn_cfg.c | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c >> index e7d2f9ea61..28554e8c72 100644 >> --- a/src/compiler/spirv/vtn_cfg.c >> +++ b/src/compiler/spirv/vtn_cfg.c >> @@ -374,6 +374,13 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct >> list_head *cf_list, >> vtn_cfg_walk_blocks(b, &loop->cont_body, new_loop_cont, NULL, >> NULL, >> new_loop_break, NULL, block); >> >> + /* Stop walking through the CFG when this inner loop's break >> block >> + * ends up as the same block as the outer loop's continue block >> + * because we are already going to visit it. >> + */ >> + if (new_loop_break == loop_cont) >> +return; >> > > I think this is mostly correct. However, I think what we really want is > to call vtn_get_branch_type() and bail if the returnd branch type is not > vtn_branch_type_none. Possibly with an assert like we have in switch case > handling. > In particular, I think loop continues and none are probably the only valid branch types. It's possible that a switch case fall-through would also be valid but I haven't thought about it long enough. That should be considered. --Jason > > >> + >> block = new_loop_break; >> continue; >>} >> -- >> 2.17.0 >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] spirv: fix visiting inner loops with same break/continue block
On Mon, May 14, 2018 at 1:05 PM, Samuel Pitoiset wrote: > We should stop walking through the CFG when the inner loop's > break block ends up as the same block as the outer loop's > continue block because we are already going to visit it. > > This fixes the following assertion which ends up by crashing > in RADV or ANV: > > SPIR-V parsing FAILED: > In file ../src/compiler/spirv/vtn_cfg.c:381 > block->node.link.next == NULL > 0 bytes into the SPIR-V binary > > This also fixes a crash with a camera shader from SteamVR. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106090 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106504 > CC: 18.0 18.1 > Signed-off-by: Samuel Pitoiset > --- > src/compiler/spirv/vtn_cfg.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c > index e7d2f9ea61..28554e8c72 100644 > --- a/src/compiler/spirv/vtn_cfg.c > +++ b/src/compiler/spirv/vtn_cfg.c > @@ -374,6 +374,13 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct > list_head *cf_list, > vtn_cfg_walk_blocks(b, &loop->cont_body, new_loop_cont, NULL, > NULL, > new_loop_break, NULL, block); > > + /* Stop walking through the CFG when this inner loop's break > block > + * ends up as the same block as the outer loop's continue block > + * because we are already going to visit it. > + */ > + if (new_loop_break == loop_cont) > +return; > I think this is mostly correct. However, I think what we really want is to call vtn_get_branch_type() and bail if the returnd branch type is not vtn_branch_type_none. Possibly with an assert like we have in switch case handling. --Jason > + > block = new_loop_break; > continue; >} > -- > 2.17.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] spirv: fix visiting inner loops with same break/continue block
We should stop walking through the CFG when the inner loop's break block ends up as the same block as the outer loop's continue block because we are already going to visit it. This fixes the following assertion which ends up by crashing in RADV or ANV: SPIR-V parsing FAILED: In file ../src/compiler/spirv/vtn_cfg.c:381 block->node.link.next == NULL 0 bytes into the SPIR-V binary This also fixes a crash with a camera shader from SteamVR. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106090 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106504 CC: 18.0 18.1 Signed-off-by: Samuel Pitoiset --- src/compiler/spirv/vtn_cfg.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c index e7d2f9ea61..28554e8c72 100644 --- a/src/compiler/spirv/vtn_cfg.c +++ b/src/compiler/spirv/vtn_cfg.c @@ -374,6 +374,13 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct list_head *cf_list, vtn_cfg_walk_blocks(b, &loop->cont_body, new_loop_cont, NULL, NULL, new_loop_break, NULL, block); + /* Stop walking through the CFG when this inner loop's break block + * ends up as the same block as the outer loop's continue block + * because we are already going to visit it. + */ + if (new_loop_break == loop_cont) +return; + block = new_loop_break; continue; } -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] radv: Fix up 2_10_10_10 alpha sign.
Bas Nieuwenhuizen writes:
> Pre-Vega HW always interprets the alpha for this format as unsigned,
> so we have to implement a fixup to do the sign correctly for signed
> formats.
>
> CC: 18.0 18.1
I couldn't apply this to 18.0. You will probably need to provide a
backport for Juan.
> ---
> src/amd/vulkan/radv_nir_to_llvm.c | 61 ---
> src/amd/vulkan/radv_pipeline.c| 30 +--
> src/amd/vulkan/radv_private.h | 1 +
> src/amd/vulkan/radv_shader.h | 12 ++
> 4 files changed, 95 insertions(+), 9 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index f98940f0d8f..9d9ecda63cf 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -1865,6 +1865,47 @@ static LLVMValueRef radv_get_sampler_desc(struct
> ac_shader_abi *abi,
> return ac_build_load_to_sgpr(&ctx->ac, list, index);
> }
>
> +/* For 2_10_10_10 formats the alpha is handled as unsigned by pre-vega HW.
> + * so we may need to fix it up. */
> +static LLVMValueRef
> +adjust_vertex_fetch_alpha(struct radv_shader_context *ctx,
> + unsigned adjustment,
> + LLVMValueRef alpha)
> +{
> + if (adjustment == RADV_ALPHA_ADJUST_NONE)
> + return alpha;
> +
> + LLVMValueRef c30 = LLVMConstInt(ctx->ac.i32, 30, 0);
> +
> + if (adjustment == RADV_ALPHA_ADJUST_SSCALED)
> + alpha = LLVMBuildFPToUI(ctx->ac.builder, alpha, ctx->ac.i32,
> "");
> + else
> + alpha = LLVMBuildBitCast(ctx->ac.builder, alpha, ctx->ac.i32,
> "");
> +
> + /* For the integer-like cases, do a natural sign extension.
> + *
> + * For the SNORM case, the values are 0.0, 0.333, 0.666, 1.0
> + * and happen to contain 0, 1, 2, 3 as the two LSBs of the
> + * exponent.
> + */
> + alpha = LLVMBuildShl(ctx->ac.builder, alpha,
> + adjustment == RADV_ALPHA_ADJUST_SNORM ?
> + LLVMConstInt(ctx->ac.i32, 7, 0) : c30, "");
> + alpha = LLVMBuildAShr(ctx->ac.builder, alpha, c30, "");
> +
> + /* Convert back to the right type. */
> + if (adjustment == RADV_ALPHA_ADJUST_SNORM) {
> + LLVMValueRef clamp;
> + LLVMValueRef neg_one = LLVMConstReal(ctx->ac.f32, -1.0);
> + alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
> "");
> + clamp = LLVMBuildFCmp(ctx->ac.builder, LLVMRealULT, alpha,
> neg_one, "");
> + alpha = LLVMBuildSelect(ctx->ac.builder, clamp, neg_one, alpha,
> "");
> + } else if (adjustment == RADV_ALPHA_ADJUST_SSCALED) {
> + alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
> "");
> + }
> +
> + return alpha;
> +}
>
> static void
> handle_vs_input_decl(struct radv_shader_context *ctx,
> @@ -1884,9 +1925,11 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
>
> variable->data.driver_location = idx * 4;
>
> - for (unsigned i = 0; i < attrib_count; ++i, ++idx) {
> - if (ctx->options->key.vs.instance_rate_inputs & (1u << (index +
> i))) {
> - uint32_t divisor =
> ctx->options->key.vs.instance_rate_divisors[index + i];
> + for (unsigned i = 0; i < attrib_count; ++i, ++idx, ++index) {
> + LLVMValueRef output[4];
> +
> + if (ctx->options->key.vs.instance_rate_inputs & (1u << index)) {
> + uint32_t divisor =
> ctx->options->key.vs.instance_rate_divisors[index];
>
> if (divisor) {
> buffer_index = LLVMBuildAdd(ctx->ac.builder,
> ctx->abi.instance_id,
> @@ -1910,7 +1953,7 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
> } else
> buffer_index = LLVMBuildAdd(ctx->ac.builder,
> ctx->abi.vertex_id,
> ctx->abi.base_vertex, "");
> - t_offset = LLVMConstInt(ctx->ac.i32, index + i, false);
> + t_offset = LLVMConstInt(ctx->ac.i32, index, false);
>
> t_list = ac_build_load_to_sgpr(&ctx->ac, t_list_ptr, t_offset);
>
> @@ -1923,9 +1966,15 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
>
> for (unsigned chan = 0; chan < 4; chan++) {
> LLVMValueRef llvm_chan = LLVMConstInt(ctx->ac.i32,
> chan, false);
> + output[chan] = LLVMBuildExtractElement(ctx->ac.builder,
> input, llvm_chan, "");
> + }
> +
> + unsigned alpha_adjust = (ctx->options->key.vs.alpha_adjust >>
> (index * 2)) & 3;
> + output[3] = adjust_vertex_fetch_alpha(ctx, alpha_adjust,
> output[3]);
> +
> + for (unsigned chan = 0; chan < 4; chan++) {
> ctx->inputs[ac_llvm_reg_index_soa(idx, chan)] =
> - ac_to_integer(&ctx->ac,
> LLVMBuildExtractElement(ctx->ac.bui
[Mesa-dev] [Bug 106502] Running game with wine fullscreen freezes the system when missing xf86-video-amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=106502 --- Comment #4 from Fabian Maurer --- Created attachment 139565 --> https://bugs.freedesktop.org/attachment.cgi?id=139565&action=edit Xorg log when it works -- 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 106502] Running game with wine fullscreen freezes the system when missing xf86-video-amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=106502 --- Comment #3 from Fabian Maurer --- Created attachment 139564 --> https://bugs.freedesktop.org/attachment.cgi?id=139564&action=edit Xorg log when freeze occurs > What does "corrupt installation of xf86-video-amdgpu" mean exactly? The package wasn't installed completely (missing files), probably due to a reboot during a freeze. I installed the package (but xorg was already running) and then ran into the freeze, so the package needed to be force-reinstalled- -- 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 100430] [radv] graphical glitches on dolphin emulator
https://bugs.freedesktop.org/show_bug.cgi?id=100430 --- Comment #19 from MIka R --- I had the same rectangle bug in Metroid Prime: Trilogy and that patch fixed it for me. Thanks a bunch! -- 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 mesa 2/5] meson: fix gallium-drivers=[]
Quoting Eric Engestrom (2018-05-14 07:08:07)
> On Friday, 2018-05-11 08:48:34 -0700, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-05-11 07:12:27)
> > > Fixes: 5608d0a2cee47c7d037f ("meson: use array type options")
> > > Signed-off-by: Eric Engestrom
> > > ---
> > > meson.build | 73 +++--
> > > 1 file changed, 32 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/meson.build b/meson.build
> > > index afebfd2c65fdb22dae29..6b069ae5dfc52adba1b7 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -123,23 +123,6 @@ with_dri = (with_dri_i915 or with_dri_i965 or
> > > with_dri_r100 or with_dri_r200 or
> > > with_dri_nouveau or with_dri_swrast)
> > >
> > > -with_gallium = false
> > > -with_gallium_pl111 = false
> > > -with_gallium_radeonsi = false
> > > -with_gallium_r300 = false
> > > -with_gallium_r600 = false
> > > -with_gallium_nouveau = false
> > > -with_gallium_freedreno = false
> > > -with_gallium_softpipe = false
> > > -with_gallium_vc4 = false
> > > -with_gallium_vc5 = false
> > > -with_gallium_etnaviv = false
> > > -with_gallium_imx = false
> > > -with_gallium_tegra = false
> > > -with_gallium_i915 = false
> > > -with_gallium_svga = false
> > > -with_gallium_virgl = false
> > > -with_gallium_swr = false
> > > _drivers = get_option('gallium-drivers')
> > > if _drivers.contains('auto')
> > >if system_has_kms_drm
> > > @@ -162,30 +145,38 @@ if _drivers.contains('auto')
> > > error('Unknown OS. Please pass -Dgallium-drivers to set driver
> > > options. Patches gladly accepted to fix this.')
> > >endif
> > > endif
> > > -if _drivers != ['']
> > > - with_gallium_pl111 = _drivers.contains('pl111')
> > > - with_gallium_radeonsi = _drivers.contains('radeonsi')
> > > - with_gallium_r300 = _drivers.contains('r300')
> > > - with_gallium_r600 = _drivers.contains('r600')
> > > - with_gallium_nouveau = _drivers.contains('nouveau')
> > > - with_gallium_freedreno = _drivers.contains('freedreno')
> > > - with_gallium_softpipe = _drivers.contains('swrast')
> > > - with_gallium_vc4 = _drivers.contains('vc4')
> > > - with_gallium_vc5 = _drivers.contains('vc5')
> > > - with_gallium_etnaviv = _drivers.contains('etnaviv')
> > > - with_gallium_imx = _drivers.contains('imx')
> > > - with_gallium_tegra = _drivers.contains('tegra')
> > > - with_gallium_i915 = _drivers.contains('i915')
> > > - with_gallium_svga = _drivers.contains('svga')
> > > - with_gallium_virgl = _drivers.contains('virgl')
> > > - with_gallium_swr = _drivers.contains('swr')
> > > - with_gallium = true
> > > - if system_has_kms_drm
> > > -_glx = get_option('glx')
> > > -_egl = get_option('egl')
> > > -if _glx == 'dri' or _egl == 'true' or (_glx == 'disabled' and _egl
> > > != 'false')
> > > - with_dri = true
> > > -endif
> > > +
> > > +with_gallium_pl111 = _drivers.contains('pl111')
> > > +with_gallium_radeonsi = _drivers.contains('radeonsi')
> > > +with_gallium_r300 = _drivers.contains('r300')
> > > +with_gallium_r600 = _drivers.contains('r600')
> > > +with_gallium_nouveau = _drivers.contains('nouveau')
> > > +with_gallium_freedreno = _drivers.contains('freedreno')
> > > +with_gallium_softpipe = _drivers.contains('swrast')
> > > +with_gallium_vc4 = _drivers.contains('vc4')
> > > +with_gallium_vc5 = _drivers.contains('vc5')
> > > +with_gallium_etnaviv = _drivers.contains('etnaviv')
> > > +with_gallium_imx = _drivers.contains('imx')
> > > +with_gallium_tegra = _drivers.contains('tegra')
> > > +with_gallium_i915 = _drivers.contains('i915')
> > > +with_gallium_svga = _drivers.contains('svga')
> > > +with_gallium_virgl = _drivers.contains('virgl')
> > > +with_gallium_swr = _drivers.contains('swr')
> > > +
> > > +with_gallium = (with_gallium_pl111 or with_gallium_radeonsi or
> > > +with_gallium_r300 or with_gallium_r600 or
> > > +with_gallium_nouveau or with_gallium_freedreno or
> > > +with_gallium_softpipe or with_gallium_vc4 or
> > > +with_gallium_vc5 or with_gallium_etnaviv or
> > > +with_gallium_imx or with_gallium_tegra or
> > > +with_gallium_i915 or with_gallium_svga or
> > > +with_gallium_virgl or with_gallium_swr)
> >
> > This could be simplified to this, right?
> > with_gallium = _drivers != ['']
>
> No, because `gallium-drivers=[]` would match as `with_gallium` :/
> I suppose I could just add both cases to the check though?
>
> What I don't like about it is that there could be unhandled cases there,
> but now that we're using array options, at least 'random/typo'd string'
> is no longer an issue; I guess we can assume that any name allowed in
> meson_options.txt is gonna be handled in meson.build as well.
I think since we're using an array option now the only cases that could be
unhandled are [''] and [].
I we thinking about writing a patch for meson so that -Darray= and -Darray=[]
Re: [Mesa-dev] Mesa (18.1): Bump version to rc4
Quoting Michel Dänzer (2018-05-14 08:04:38) > On 2018-05-11 07:19 PM, Dylan Baker wrote: > > Quoting Michel Dänzer (2018-05-11 09:55:23) > >> > >> Hi Dylan, > >> > >> > >> any reason for not picking 6f81e07ecb8c0793dc482307d5d96fd3df95b7d2 > >> "dri3: Only update number of back buffers in loader_dri3_get_buffers" > >> for rc4? > > > > Hi Michel, > > > > That patch is present in rc4 as 312c2f047e5ce7fe277d34d7d99b9945c60f4e60. > > Excellent, thanks! Not sure how I missed that, sorry for the noise. > No worries! I appreciate the follow up to make sure that everything is going into the tarballs that should be. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 1/4] docs/meson: fix various typos
For the series: Reviewed-by: Dylan Baker Quoting Eric Engestrom (2018-05-14 08:48:41) > Signed-off-by: Eric Engestrom > --- > docs/meson.html | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/docs/meson.html b/docs/meson.html > index c260b703902083045e27..841a0d5b9d8d65b71da5 100644 > --- a/docs/meson.html > +++ b/docs/meson.html > @@ -49,7 +49,7 @@ 1. Basic Usage > your meson global arguments and project arguments, along with their defaults > and your local settings. > > -Moes does not currently support listing options before configure a build > +Meson does not currently support listing options before configure a build > directory, but this feature is being discussed upstream. > > > @@ -96,7 +96,7 @@ 1. Basic Usage > > > Environment Variables > -Meson supports the standard CC and CXX envrionment variables for > +Meson supports the standard CC and CXX environment variables for > changing the default compiler, and CFLAGS, CXXFLAGS, and LDFLAGS for setting > options to the compiler and linker. > > @@ -107,9 +107,9 @@ 1. Basic Usage > These arguments are consumed and stored by meson when it is initialized or > re-initialized. Therefore passing them to meson configure will not do > anything, > and passing them to ninja will only do something if ninja decides to > -re-initialze meson, for example, if a meson.build file has been changed. > +re-initialize meson, for example, if a meson.build file has been changed. > Changing these variables will not cause all targets to be rebuilt, so running > -ninja clean is recomended when changing CFLAGS or CXXFLAGS. meson will never > +ninja clean is recommended when changing CFLAGS or CXXFLAGS. Meson will never > change compiler in a configured build directory. > > > @@ -128,7 +128,7 @@ 1. Basic Usage > > LLVM > Meson includes upstream logic to wrap llvm-config using it's standard > -dependncy interface. It will search $PATH (or %PATH% on windows) for > +dependency interface. It will search $PATH (or %PATH% on windows) for > llvm-config, so using an LLVM from a non-standard path is as easy as > PATH=/path/with/llvm-config:$PATH meson build. > > @@ -162,7 +162,7 @@ 1. Basic Usage > > Note that in meson this defaults to "debugoptimized", and not setting it > to > "release" will yield non-optimal performance and binary size. Not using > "debug" > -may interfer with debbugging as some code and validation will be optimized > +may interfere with debugging as some code and validation will be optimized > away. > > > -- > Cheers, > Eric > signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 1/2] meson: remove "empty array"/"array of an empty string" confusion
I don't have a problem with this, but it is changing user facing interfaces. You might want to solicit some other developers on this before you land it. We'll also need to make some changes to our CI. I'm wondering if the better solution is to change upstream meson to treat -Darray= and -Darray=[] as equivalent (ie, the first one is the second one). I've added a few people who might have interest in this to the CC already, though there may be more people interested. Dylan Quoting Eric Engestrom (2018-05-14 08:51:21) > Signed-off-by: Eric Engestrom > --- > meson_options.txt | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/meson_options.txt b/meson_options.txt > index ce7d87f1ebd74a4ecc2c..b851f086a2b756142d8d 100644 > --- a/meson_options.txt > +++ b/meson_options.txt > @@ -23,7 +23,7 @@ option( >type : 'array', >value : ['auto'], >choices : [ > -'', 'auto', 'x11', 'wayland', 'drm', 'surfaceless', 'haiku', 'android', > +'auto', 'x11', 'wayland', 'drm', 'surfaceless', 'haiku', 'android', >], >description : 'comma separated list of window systems to support. If this > is set to auto all platforms applicable to the OS will be enabled.' > ) > @@ -38,7 +38,7 @@ option( >'dri-drivers', >type : 'array', >value : ['auto'], > - choices : ['', 'auto', 'i915', 'i965', 'r100', 'r200', 'nouveau', > 'swrast'], > + choices : ['auto', 'i915', 'i965', 'r100', 'r200', 'nouveau', 'swrast'], >description : 'List of dri drivers to build. If this is set to auto all > drivers applicable to the target OS/architecture will be built' > ) > option( > @@ -58,7 +58,7 @@ option( >type : 'array', >value : ['auto'], >choices : [ > -'', 'auto', 'pl111', 'radeonsi', 'r300', 'r600', 'nouveau', 'freedreno', > +'auto', 'pl111', 'radeonsi', 'r300', 'r600', 'nouveau', 'freedreno', > 'swrast', 'vc4', 'vc5', 'etnaviv', 'imx', 'tegra', 'i915', 'svga', > 'virgl', > 'swr', >], > @@ -152,7 +152,7 @@ option( >'vulkan-drivers', >type : 'array', >value : ['auto'], > - choices : ['', 'auto', 'amd', 'intel'], > + choices : ['auto', 'amd', 'intel'], >description : 'List of vulkan drivers to build. If this is set to auto all > drivers applicable to the target OS/architecture will be built' > ) > option( > -- > Cheers, > Eric > signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] i965: Use meta for pixel ops on gen6+
On Fri, May 11, 2018 at 04:48:17PM -0700, Jason Ekstrand wrote:
> Using meta for anything is fairly aweful and definitely has more CPU
> overhead. However, it also uses the 3D pipe and is therefore likely
> faster in terms of GPU time than the blitter. Also, the blitter code
> has so many early returns that it's probably not buying us that much.
> We may as well just use meta all the time instead of working over-time
> to find the tiny case where we can use the blitter. We keep gen4-5
> using the old blit paths to avoid perturbing old hardware too much.
After the rest of your series, using blitter for the few isolated cases
would be the only thing preventing us from removing BLT ring support
altogether. So I think moving over to meta is well justified - it
doesn't sound smart to maintain blitter support just for optimizing
(unknown?) corner cases. And if significant enough case happens to
emerge, we most likely can implement that using blorp.
Reviewed-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/intel_pixel_bitmap.c | 6 --
> src/mesa/drivers/dri/i965/intel_pixel_copy.c | 5 -
> src/mesa/drivers/dri/i965/intel_pixel_draw.c | 3 ++-
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_pixel_bitmap.c
> b/src/mesa/drivers/dri/i965/intel_pixel_bitmap.c
> index 5bc341b..f9d4829 100644
> --- a/src/mesa/drivers/dri/i965/intel_pixel_bitmap.c
> +++ b/src/mesa/drivers/dri/i965/intel_pixel_bitmap.c
> @@ -348,11 +348,13 @@ intelBitmap(struct gl_context * ctx,
> const struct gl_pixelstore_attrib *unpack,
> const GLubyte * pixels)
> {
> + struct brw_context *brw = brw_context(ctx);
> +
> if (!_mesa_check_conditional_render(ctx))
>return;
>
> - if (do_blit_bitmap(ctx, x, y, width, height,
> - unpack, pixels))
> + if (brw->screen->devinfo.gen < 6 &&
> + do_blit_bitmap(ctx, x, y, width, height, unpack, pixels))
>return;
>
> _mesa_meta_Bitmap(ctx, x, y, width, height, unpack, pixels);
> diff --git a/src/mesa/drivers/dri/i965/intel_pixel_copy.c
> b/src/mesa/drivers/dri/i965/intel_pixel_copy.c
> index 8029ffb..31838cc 100644
> --- a/src/mesa/drivers/dri/i965/intel_pixel_copy.c
> +++ b/src/mesa/drivers/dri/i965/intel_pixel_copy.c
> @@ -196,12 +196,15 @@ intelCopyPixels(struct gl_context * ctx,
> GLsizei width, GLsizei height,
> GLint destx, GLint desty, GLenum type)
> {
> + struct brw_context *brw = brw_context(ctx);
> +
> DBG("%s\n", __func__);
>
> if (!_mesa_check_conditional_render(ctx))
>return;
>
> - if (do_blit_copypixels(ctx, srcx, srcy, width, height, destx, desty,
> type))
> + if (brw->screen->devinfo.gen < 6 &&
> + do_blit_copypixels(ctx, srcx, srcy, width, height, destx, desty,
> type))
>return;
>
> /* this will use swrast if needed */
> diff --git a/src/mesa/drivers/dri/i965/intel_pixel_draw.c
> b/src/mesa/drivers/dri/i965/intel_pixel_draw.c
> index 82dca4a..d5d1b99e69 100644
> --- a/src/mesa/drivers/dri/i965/intel_pixel_draw.c
> +++ b/src/mesa/drivers/dri/i965/intel_pixel_draw.c
> @@ -163,7 +163,8 @@ intelDrawPixels(struct gl_context * ctx,
>return;
> }
>
> - if (_mesa_is_bufferobj(unpack->BufferObj)) {
> + if (brw->screen->devinfo.gen < 6 &&
> + _mesa_is_bufferobj(unpack->BufferObj)) {
>if (do_blit_drawpixels(ctx, x, y, width, height, format, type, unpack,
>pixels)) {
>return;
> --
> 2.5.0.400.gff86faf
>
> ___
> 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 106480] A2B10G10R10_SNORM vertex attribute doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=106480 Bas Nieuwenhuizen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Bas Nieuwenhuizen --- The fixes are in master 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] [Bug 106331] radv doesnt support VK_FORMAT_R32G32B32_SFLOAT
https://bugs.freedesktop.org/show_bug.cgi?id=106331 Bas Nieuwenhuizen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Bas Nieuwenhuizen --- Should be implemented on latest master with https://cgit.freedesktop.org/mesa/mesa/commit/?id=e361970ed73d0f0a11d93a718dbfe2bf4f38b56d Please reopen if it still gives issues for you. -- 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 08/10] i965: Remove support for the BLT ring
On Mon, May 14, 2018 at 10:08:35AM -0700, Jason Ekstrand wrote:
> On Mon, May 14, 2018 at 10:07 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
> > On Fri, May 11, 2018 at 04:48:24PM -0700, Jason Ekstrand wrote:
> > > We still support the blitter on gen4-5 but it's on the same ring as 3D.
> > > ---
> > > src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 +++-
> > > 1 file changed, 3 insertions(+), 9 deletions(-)
> >
> > Nothing amiss in the patch itself, only the title lets one to believe that
> > all occurrences of BLT_RING are removed. I don't have anything better to
> > offer though...
> >
>
> I have another patch for that. :-)
Nice, this and the 11/10:
Reviewed-by: Topi Pohjolainen
>
> --Jason
>
>
>
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > > index 8c5fd50..b9ea922 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > > @@ -771,18 +771,12 @@ submit_batch(struct brw_context *brw, int
> > in_fence_fd, int *out_fence_fd)
> > > * To avoid stalling, execobject.offset should match the current
> > > * address of that object within the active context.
> > > */
> > > - int flags = I915_EXEC_NO_RELOC;
> > > + assert(devinfo->gen < 6 || batch->ring == RENDER_RING);
> > > + int flags = I915_EXEC_NO_RELOC | I915_EXEC_RENDER;
> > >
> > > - if (devinfo->gen >= 6 && batch->ring == BLT_RING) {
> > > - flags |= I915_EXEC_BLT;
> > > - } else {
> > > - flags |= I915_EXEC_RENDER;
> > > - }
> > >if (batch->needs_sol_reset)
> > > flags |= I915_EXEC_GEN7_SOL_RESET;
> > >
> > > - uint32_t hw_ctx = batch->ring == RENDER_RING ? brw->hw_ctx : 0;
> > > -
> > >/* Set statebuffer relocations */
> > >const unsigned state_index = batch->state.bo->index;
> > >if (state_index < batch->exec_count &&
> > > @@ -812,7 +806,7 @@ submit_batch(struct brw_context *brw, int
> > in_fence_fd, int *out_fence_fd)
> > > batch->validation_list[index] = tmp;
> > >}
> > >
> > > - ret = execbuffer(dri_screen->fd, batch, hw_ctx,
> > > + ret = execbuffer(dri_screen->fd, batch, brw->hw_ctx,
> > > 4 * USED_BATCH(*batch),
> > > in_fence_fd, out_fence_fd, flags);
> > >
> > > --
> > > 2.5.0.400.gff86faf
> > >
> > > ___
> > > 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 10/10] intel/blorp: Use linear formats for CCS_E clear colors in copies
On Fri, May 11, 2018 at 04:48:26PM -0700, Jason Ekstrand wrote: > It's clear that the original code meant to do this and there is even a > 10-line comment explaining why. Originally, we had a simple function > for packing the clear colors which was unaware of sRGB. However, in > a6b66a7b26ae1, when we started using ISL to do the packing, the wrong > format was used. > > Fixes: a6b66a7b26 "intel/blorp: Use ISL instead of bitcast_color..." Thanks for spotting this: Reviewed-by: Topi Pohjolainen > --- > src/intel/blorp/blorp_blit.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c > index e825862..26bf442 100644 > --- a/src/intel/blorp/blorp_blit.c > +++ b/src/intel/blorp/blorp_blit.c > @@ -2562,7 +2562,7 @@ blorp_copy(struct blorp_batch *batch, >params.src.view.format)); >uint32_t packed[4]; >isl_color_value_pack(¶ms.src.clear_color, > - params.src.surf.format, packed); > + linear_src_format, packed); >isl_color_value_unpack(¶ms.src.clear_color, > params.src.view.format, packed); > } > @@ -2576,7 +2576,7 @@ blorp_copy(struct blorp_batch *batch, >params.dst.view.format)); >uint32_t packed[4]; >isl_color_value_pack(¶ms.dst.clear_color, > - params.dst.surf.format, packed); > + linear_dst_format, packed); >isl_color_value_unpack(¶ms.dst.clear_color, > params.dst.view.format, packed); > } > -- > 2.5.0.400.gff86faf > > ___ > 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 09/10] i965/miptree: Move the access_raw call to the individual map functions
On Fri, May 11, 2018 at 04:48:25PM -0700, Jason Ekstrand wrote:
> The only function that doesn't need to call access_raw is map_blit. If
> it takes the blitter path, it will happen as part of intel_miptree_copy.
> If map_blit takes the blorp path, no brw_blorp_copy_miptrees will handle
The part starting with "no brw_blorp_copy_miptrees...", I think you just
meant "brw_blorp_copy_miptrees() handles whatever resolves are needed"?
Reviewed-by: Topi Pohjolainen
> doing whatever resolves are needed. This should save us resolves in
> quite a few cases and will probably help performance a bit.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 7c5e6f6..0bfc426 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -3109,6 +3109,9 @@ intel_miptree_map_gtt(struct brw_context *brw,
> y /= bh;
> x /= bw;
>
> + intel_miptree_access_raw(brw, mt, level, slice,
> +map->mode & GL_MAP_WRITE_BIT);
> +
> base = intel_miptree_map_raw(brw, mt, map->mode);
>
> if (base == NULL)
> @@ -3247,6 +3250,8 @@ intel_miptree_map_movntdqa(struct brw_context *brw,
> assert(map->mode & GL_MAP_READ_BIT);
> assert(!(map->mode & GL_MAP_WRITE_BIT));
>
> + intel_miptree_access_raw(brw, mt, level, slice, false);
> +
> DBG("%s: %d,%d %dx%d from mt %p (%s) %d,%d = %p/%d\n", __func__,
> map->x, map->y, map->w, map->h,
> mt, _mesa_get_format_name(mt->format),
> @@ -3341,6 +3346,9 @@ intel_miptree_map_s8(struct brw_context *brw,
> if (!map->buffer)
>return;
>
> + intel_miptree_access_raw(brw, mt, level, slice,
> +map->mode & GL_MAP_WRITE_BIT);
> +
> /* One of either READ_BIT or WRITE_BIT or both is set. READ_BIT implies
> no
> * INVALIDATE_RANGE_BIT. WRITE_BIT needs the original values read in
> unless
> * invalidate is set, since we'll be writing the whole rectangle from our
> @@ -3423,6 +3431,8 @@ intel_miptree_map_etc(struct brw_context *brw,
> assert(map->mode & GL_MAP_WRITE_BIT);
> assert(map->mode & GL_MAP_INVALIDATE_RANGE_BIT);
>
> + intel_miptree_access_raw(brw, mt, level, slice, true);
> +
> map->stride = _mesa_format_row_stride(mt->etc_format, map->w);
> map->buffer = malloc(_mesa_format_image_size(mt->etc_format,
> map->w, map->h, 1));
> @@ -3516,6 +3526,9 @@ intel_miptree_map_depthstencil(struct brw_context *brw,
> if (!map->buffer)
>return;
>
> + intel_miptree_access_raw(brw, mt, level, slice,
> +map->mode & GL_MAP_WRITE_BIT);
> +
> /* One of either READ_BIT or WRITE_BIT or both is set. READ_BIT implies
> no
> * INVALIDATE_RANGE_BIT. WRITE_BIT needs the original values read in
> unless
> * invalidate is set, since we'll be writing the whole rectangle from our
> @@ -3697,9 +3710,6 @@ intel_miptree_map(struct brw_context *brw,
>return;
> }
>
> - intel_miptree_access_raw(brw, mt, level, slice,
> -map->mode & GL_MAP_WRITE_BIT);
> -
> if (mt->format == MESA_FORMAT_S_UINT8) {
>intel_miptree_map_s8(brw, mt, map, level, slice);
> } else if (mt->etc_format != MESA_FORMAT_NONE &&
> --
> 2.5.0.400.gff86faf
>
> ___
> 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 11/10] i965: Remove ring switching entirely
---
src/mesa/drivers/dri/i965/brw_compute.c | 2 +-
src/mesa/drivers/dri/i965/brw_context.h | 7 --
src/mesa/drivers/dri/i965/brw_draw.c | 2 +-
src/mesa/drivers/dri/i965/brw_misc_state.c| 2 +-
src/mesa/drivers/dri/i965/brw_pipe_control.c | 32 +++---
src/mesa/drivers/dri/i965/brw_urb.c | 2 +-
src/mesa/drivers/dri/i965/genX_blorp_exec.c | 4 +-
src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 92 ++-
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 15 ++---
src/mesa/drivers/dri/i965/intel_blit.c| 6 +-
11 files changed, 61 insertions(+), 105 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
b/src/mesa/drivers/dri/i965/brw_compute.c
index 5ce899b..de08fc3 100644
--- a/src/mesa/drivers/dri/i965/brw_compute.c
+++ b/src/mesa/drivers/dri/i965/brw_compute.c
@@ -182,7 +182,7 @@ brw_dispatch_compute_common(struct gl_context *ctx)
/* Flush the batch if the batch/state buffers are nearly full. We can
* grow them if needed, but this is not free, so we'd like to avoid it.
*/
- intel_batchbuffer_require_space(brw, 600, RENDER_RING);
+ intel_batchbuffer_require_space(brw, 600);
brw_require_statebuffer_space(brw, 2500);
intel_batchbuffer_save_state(brw);
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 7dcbd04..ff631dc 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -461,12 +461,6 @@ struct brw_query_object {
bool flushed;
};
-enum brw_gpu_ring {
- UNKNOWN_RING,
- RENDER_RING,
- BLT_RING,
-};
-
struct brw_reloc_list {
struct drm_i915_gem_relocation_entry *relocs;
int reloc_count;
@@ -496,7 +490,6 @@ struct intel_batchbuffer {
uint32_t *map_next;
uint32_t state_used;
- enum brw_gpu_ring ring;
bool use_shadow_copy;
bool use_batch_first;
bool needs_sol_reset;
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index ae3b7be..18aa12f 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -798,7 +798,7 @@ brw_draw_single_prim(struct gl_context *ctx,
/* Flush the batch if the batch/state buffers are nearly full. We can
* grow them if needed, but this is not free, so we'd like to avoid it.
*/
- intel_batchbuffer_require_space(brw, 1500, RENDER_RING);
+ intel_batchbuffer_require_space(brw, 1500);
brw_require_statebuffer_space(brw, 2400);
intel_batchbuffer_save_state(brw);
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 6d7ab92..9a663b1 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -348,7 +348,7 @@ brw_emit_depthbuffer(struct brw_context *brw)
brw_emit_depth_stall_flushes(brw);
const unsigned ds_dwords = brw->isl_dev.ds.size / 4;
- intel_batchbuffer_begin(brw, ds_dwords, RENDER_RING);
+ intel_batchbuffer_begin(brw, ds_dwords);
uint32_t *ds_map = brw->batch.map_next;
const uint32_t ds_offset = (char *)ds_map - (char *)brw->batch.batch.map;
diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c
b/src/mesa/drivers/dri/i965/brw_pipe_control.c
index e31d625..45f8203 100644
--- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
+++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
@@ -544,29 +544,17 @@ brw_emit_mi_flush(struct brw_context *brw)
{
const struct gen_device_info *devinfo = &brw->screen->devinfo;
- if (brw->batch.ring == BLT_RING && devinfo->gen >= 6) {
- const unsigned n_dwords = devinfo->gen >= 8 ? 5 : 4;
- BEGIN_BATCH_BLT(n_dwords);
- OUT_BATCH(MI_FLUSH_DW | (n_dwords - 2));
- OUT_BATCH(0);
- OUT_BATCH(0);
- OUT_BATCH(0);
- if (n_dwords == 5)
- OUT_BATCH(0);
- ADVANCE_BATCH();
- } else {
- int flags = PIPE_CONTROL_RENDER_TARGET_FLUSH;
- if (devinfo->gen >= 6) {
- flags |= PIPE_CONTROL_INSTRUCTION_INVALIDATE |
- PIPE_CONTROL_CONST_CACHE_INVALIDATE |
- PIPE_CONTROL_DATA_CACHE_FLUSH |
- PIPE_CONTROL_DEPTH_CACHE_FLUSH |
- PIPE_CONTROL_VF_CACHE_INVALIDATE |
- PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE |
- PIPE_CONTROL_CS_STALL;
- }
- brw_emit_pipe_control_flush(brw, flags);
+ int flags = PIPE_CONTROL_RENDER_TARGET_FLUSH;
+ if (devinfo->gen >= 6) {
+ flags |= PIPE_CONTROL_INSTRUCTION_INVALIDATE |
+ PIPE_CONTROL_CONST_CACHE_INVALIDATE |
+ PIPE_CONTROL_DATA_CACHE_FLUSH |
+ PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+ PIPE_CONTROL_VF_CACHE_INVALIDATE |
+ PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE |
+ PIPE_CONTROL_CS_STALL;
}
+ brw_emit_pipe_control_flush(brw, flags);
}
int
diff --git a
Re: [Mesa-dev] [PATCH 08/10] i965: Remove support for the BLT ring
On Mon, May 14, 2018 at 10:07 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Fri, May 11, 2018 at 04:48:24PM -0700, Jason Ekstrand wrote:
> > We still support the blitter on gen4-5 but it's on the same ring as 3D.
> > ---
> > src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 +++-
> > 1 file changed, 3 insertions(+), 9 deletions(-)
>
> Nothing amiss in the patch itself, only the title lets one to believe that
> all occurrences of BLT_RING are removed. I don't have anything better to
> offer though...
>
I have another patch for that. :-)
--Jason
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > index 8c5fd50..b9ea922 100644
> > --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > @@ -771,18 +771,12 @@ submit_batch(struct brw_context *brw, int
> in_fence_fd, int *out_fence_fd)
> > * To avoid stalling, execobject.offset should match the current
> > * address of that object within the active context.
> > */
> > - int flags = I915_EXEC_NO_RELOC;
> > + assert(devinfo->gen < 6 || batch->ring == RENDER_RING);
> > + int flags = I915_EXEC_NO_RELOC | I915_EXEC_RENDER;
> >
> > - if (devinfo->gen >= 6 && batch->ring == BLT_RING) {
> > - flags |= I915_EXEC_BLT;
> > - } else {
> > - flags |= I915_EXEC_RENDER;
> > - }
> >if (batch->needs_sol_reset)
> > flags |= I915_EXEC_GEN7_SOL_RESET;
> >
> > - uint32_t hw_ctx = batch->ring == RENDER_RING ? brw->hw_ctx : 0;
> > -
> >/* Set statebuffer relocations */
> >const unsigned state_index = batch->state.bo->index;
> >if (state_index < batch->exec_count &&
> > @@ -812,7 +806,7 @@ submit_batch(struct brw_context *brw, int
> in_fence_fd, int *out_fence_fd)
> > batch->validation_list[index] = tmp;
> >}
> >
> > - ret = execbuffer(dri_screen->fd, batch, hw_ctx,
> > + ret = execbuffer(dri_screen->fd, batch, brw->hw_ctx,
> > 4 * USED_BATCH(*batch),
> > in_fence_fd, out_fence_fd, flags);
> >
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > 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 08/10] i965: Remove support for the BLT ring
On Fri, May 11, 2018 at 04:48:24PM -0700, Jason Ekstrand wrote:
> We still support the blitter on gen4-5 but it's on the same ring as 3D.
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
Nothing amiss in the patch itself, only the title lets one to believe that
all occurrences of BLT_RING are removed. I don't have anything better to
offer though...
>
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 8c5fd50..b9ea922 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -771,18 +771,12 @@ submit_batch(struct brw_context *brw, int in_fence_fd,
> int *out_fence_fd)
> * To avoid stalling, execobject.offset should match the current
> * address of that object within the active context.
> */
> - int flags = I915_EXEC_NO_RELOC;
> + assert(devinfo->gen < 6 || batch->ring == RENDER_RING);
> + int flags = I915_EXEC_NO_RELOC | I915_EXEC_RENDER;
>
> - if (devinfo->gen >= 6 && batch->ring == BLT_RING) {
> - flags |= I915_EXEC_BLT;
> - } else {
> - flags |= I915_EXEC_RENDER;
> - }
>if (batch->needs_sol_reset)
> flags |= I915_EXEC_GEN7_SOL_RESET;
>
> - uint32_t hw_ctx = batch->ring == RENDER_RING ? brw->hw_ctx : 0;
> -
>/* Set statebuffer relocations */
>const unsigned state_index = batch->state.bo->index;
>if (state_index < batch->exec_count &&
> @@ -812,7 +806,7 @@ submit_batch(struct brw_context *brw, int in_fence_fd,
> int *out_fence_fd)
> batch->validation_list[index] = tmp;
>}
>
> - ret = execbuffer(dri_screen->fd, batch, hw_ctx,
> + ret = execbuffer(dri_screen->fd, batch, brw->hw_ctx,
> 4 * USED_BATCH(*batch),
> in_fence_fd, out_fence_fd, flags);
>
> --
> 2.5.0.400.gff86faf
>
> ___
> 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 00/10] Die, blitter, die!
On Fri, May 11, 2018 at 04:48:16PM -0700, Jason Ekstrand wrote: > This patch series completely kills off our usage of the hardware blitter > for Sandy Bridge and later. On Sandy Bridge, the blitter was moved to > another ring and so using it incurs noticable synchronization overhead and, > at the same time, that synchronization is an endless source of GPU hangs on > SNB. Some time around the Ivy Bridge time frame, we suspect that the > blitter ended up with somewhat slower paths to memory than the 3D engine so > it's slower in general. > > To make matters worse, the blitter does not understand any sort of > compression at all and so using it frequently means having to do some sort > of resolve operation. This is especially bad on gen9 where we have CCS > compression enabled on almost everything. By using blorp for things like > miptree mapping, we can avoid decompressing and even get free compression > on unmap as-needed. > > Jason Ekstrand (10): > i965: Use meta for pixel ops on gen6+ > i965/blit: Delete intel_emit_linear_blit > i965: Remove some unused includes of intel_blit.h > i965: Don't fall back to the blitter in BlitFramebuffer > i965: Delete the blitter path for CopyTexSubImage > i965/miptree: Use blorp for validation tex copies on gen6+ > i965/miptree: Use blorp for blit maps on gen6+ Patches 2-7: Reviewed-by: Topi Pohjolainen > i965: Remove support for the BLT ring > i965/miptree: Move the access_raw call to the individual map functions > intel/blorp: Use linear formats for CCS_E clear colors in copies > > src/intel/blorp/blorp_blit.c | 4 +- > src/mesa/drivers/dri/i965/brw_clear.c | 1 - > src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 +--- > src/mesa/drivers/dri/i965/intel_blit.c | 56 > src/mesa/drivers/dri/i965/intel_blit.h | 6 -- > src/mesa/drivers/dri/i965/intel_fbo.c | 8 --- > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 92 > +++--- > src/mesa/drivers/dri/i965/intel_pixel_bitmap.c | 6 +- > src/mesa/drivers/dri/i965/intel_pixel_copy.c | 5 +- > src/mesa/drivers/dri/i965/intel_pixel_draw.c | 3 +- > src/mesa/drivers/dri/i965/intel_pixel_read.c | 1 - > src/mesa/drivers/dri/i965/intel_tex_copy.c | 58 > src/mesa/drivers/dri/i965/intel_tex_image.c| 1 - > src/mesa/drivers/dri/i965/intel_tex_validate.c | 1 - > 14 files changed, 82 insertions(+), 172 deletions(-) > > -- > 2.5.0.400.gff86faf > > ___ > 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 09/19] i965: Add brw_stage_cache_id to map gl stages to brw cache_ids
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_program_cache.c | 15 +++
src/mesa/drivers/dri/i965/brw_state.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_program_cache.c
b/src/mesa/drivers/dri/i965/brw_program_cache.c
index 78159288af0..40f1078ca98 100644
--- a/src/mesa/drivers/dri/i965/brw_program_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_program_cache.c
@@ -78,6 +78,21 @@ struct brw_cache_item {
struct brw_cache_item *next;
};
+enum brw_cache_id
+brw_stage_cache_id(gl_shader_stage stage)
+{
+ static const enum brw_cache_id stage_sizes[] = {
+ BRW_CACHE_VS_PROG,
+ BRW_CACHE_TCS_PROG,
+ BRW_CACHE_TES_PROG,
+ BRW_CACHE_GS_PROG,
+ BRW_CACHE_FS_PROG,
+ BRW_CACHE_CS_PROG,
+ };
+ assert((int)stage >= 0 && stage < ARRAY_SIZE(stage_sizes));
+ return stage_sizes[stage];
+}
+
static unsigned
get_program_string_id(enum brw_cache_id cache_id, const void *key)
{
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/brw_state.h
index 1b4745ef753..445f5e0b510 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -180,6 +180,8 @@ void brw_destroy_caches( struct brw_context *brw );
void brw_print_program_cache(struct brw_context *brw);
+enum brw_cache_id brw_stage_cache_id(gl_shader_stage stage);
+
/* intel_batchbuffer.c */
void brw_require_statebuffer_space(struct brw_context *brw, int size);
void *brw_state_batch(struct brw_context *brw,
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 16/19] i965: Add brw_populate_default_key
We will need to populate the default key for ARB_get_program_binary to
allow us to retrieve the default gen program to store save in the
program binary.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_cs.c | 15 ++---
src/mesa/drivers/dri/i965/brw_cs.h | 4 +++
src/mesa/drivers/dri/i965/brw_gs.c | 16 ++---
src/mesa/drivers/dri/i965/brw_gs.h | 4 +++
src/mesa/drivers/dri/i965/brw_program.c | 35
src/mesa/drivers/dri/i965/brw_program.h | 15 +
src/mesa/drivers/dri/i965/brw_tcs.c | 57 +++--
src/mesa/drivers/dri/i965/brw_tes.c | 40 ++-
src/mesa/drivers/dri/i965/brw_vs.c | 26 ++-
src/mesa/drivers/dri/i965/brw_vs.h | 4 +++
src/mesa/drivers/dri/i965/brw_wm.c | 48 ---
src/mesa/drivers/dri/i965/brw_wm.h | 4 +++
12 files changed, 195 insertions(+), 73 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cs.c
b/src/mesa/drivers/dri/i965/brw_cs.c
index 9b1b0832b5a..614eb64bca9 100644
--- a/src/mesa/drivers/dri/i965/brw_cs.c
+++ b/src/mesa/drivers/dri/i965/brw_cs.c
@@ -184,6 +184,16 @@ brw_upload_cs_prog(struct brw_context *brw)
assert(success);
}
+void
+brw_cs_populate_default_key(const struct gen_device_info *devinfo,
+struct brw_cs_prog_key *key,
+struct gl_program *prog)
+{
+ memset(key, 0, sizeof(*key));
+ key->program_string_id = brw_program(prog)->id;
+
+ brw_setup_tex_for_precompile(devinfo, &key->tex, prog);
+}
bool
brw_cs_precompile(struct gl_context *ctx, struct gl_program *prog)
@@ -193,10 +203,7 @@ brw_cs_precompile(struct gl_context *ctx, struct
gl_program *prog)
struct brw_program *bcp = brw_program(prog);
- memset(&key, 0, sizeof(key));
- key.program_string_id = bcp->id;
-
- brw_setup_tex_for_precompile(&brw->screen->devinfo, &key.tex, prog);
+ brw_cs_populate_default_key(&brw->screen->devinfo, &key, prog);
uint32_t old_prog_offset = brw->cs.base.prog_offset;
struct brw_stage_prog_data *old_prog_data = brw->cs.base.prog_data;
diff --git a/src/mesa/drivers/dri/i965/brw_cs.h
b/src/mesa/drivers/dri/i965/brw_cs.h
index 60eb19c3594..669d4b544eb 100644
--- a/src/mesa/drivers/dri/i965/brw_cs.h
+++ b/src/mesa/drivers/dri/i965/brw_cs.h
@@ -34,6 +34,10 @@ brw_upload_cs_prog(struct brw_context *brw);
void
brw_cs_populate_key(struct brw_context *brw, struct brw_cs_prog_key *key);
+void
+brw_cs_populate_default_key(const struct gen_device_info *devinfo,
+struct brw_cs_prog_key *key,
+struct gl_program *prog);
#ifdef __cplusplus
}
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
b/src/mesa/drivers/dri/i965/brw_gs.c
index f488fab009e..9d4dc942d34 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -208,6 +208,17 @@ brw_upload_gs_prog(struct brw_context *brw)
assert(success);
}
+void
+brw_gs_populate_default_key(const struct gen_device_info *devinfo,
+struct brw_gs_prog_key *key,
+struct gl_program *prog)
+{
+ memset(key, 0, sizeof(*key));
+
+ brw_setup_tex_for_precompile(devinfo, &key->tex, prog);
+ key->program_string_id = brw_program(prog)->id;
+}
+
bool
brw_gs_precompile(struct gl_context *ctx, struct gl_program *prog)
{
@@ -219,10 +230,7 @@ brw_gs_precompile(struct gl_context *ctx, struct
gl_program *prog)
struct brw_program *bgp = brw_program(prog);
- memset(&key, 0, sizeof(key));
-
- brw_setup_tex_for_precompile(&brw->screen->devinfo, &key.tex, prog);
- key.program_string_id = bgp->id;
+ brw_gs_populate_default_key(&brw->screen->devinfo, &key, prog);
success = brw_codegen_gs_prog(brw, bgp, &key);
diff --git a/src/mesa/drivers/dri/i965/brw_gs.h
b/src/mesa/drivers/dri/i965/brw_gs.h
index 537a41679df..cff994a9323 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.h
+++ b/src/mesa/drivers/dri/i965/brw_gs.h
@@ -40,6 +40,10 @@ brw_upload_gs_prog(struct brw_context *brw);
void
brw_gs_populate_key(struct brw_context *brw,
struct brw_gs_prog_key *key);
+void
+brw_gs_populate_default_key(const struct gen_device_info *devinfo,
+struct brw_gs_prog_key *key,
+struct gl_program *prog);
#ifdef __cplusplus
} /* extern "C" */
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index ca934b91c9a..a54d90e92a7 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -48,6 +48,11 @@
#include "brw_defines.h"
#include "intel_batchbuffer.h"
+#include "brw_cs.h"
+#include "brw_gs.h"
+#include "brw_vs.h"
+#include "brw_wm.h"
+
static bool
brw_nir_lower_uniforms(nir_shader *nir, bool is_scalar)
{
@@ -844,3 +849,33 @@ brw_prog_key_set_id(union brw_any_prog_key *key,
gl_sh
[Mesa-dev] [PATCH 07/19] i965: Add brw_program_deserialize_driver_blob
brw_program_deserialize_driver_blob will be a more generic form of
brw_program_deserialize_nir. In addition to nir, it will also be able
to extract gen binaries and upload them to the program cache.
In this commit, it continues to only support nir.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_context.h| 5 ++-
src/mesa/drivers/dri/i965/brw_disk_cache.c | 4 +-
src/mesa/drivers/dri/i965/brw_program_binary.c | 60 ++
3 files changed, 48 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index d8b0d94aaff..0db98d86d07 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1646,8 +1646,9 @@ brw_deserialize_program_binary(struct gl_context *ctx,
void
brw_program_serialize_nir(struct gl_context *ctx, struct gl_program *prog);
void
-brw_program_deserialize_nir(struct gl_context *ctx, struct gl_program *prog,
-gl_shader_stage stage);
+brw_program_deserialize_driver_blob(struct gl_context *ctx,
+struct gl_program *prog,
+gl_shader_stage stage);
/*==
* Inline conversion functions. These are better-typed than the
diff --git a/src/mesa/drivers/dri/i965/brw_disk_cache.c
b/src/mesa/drivers/dri/i965/brw_disk_cache.c
index ee6067ca51a..4aa304eb4a6 100644
--- a/src/mesa/drivers/dri/i965/brw_disk_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_disk_cache.c
@@ -246,7 +246,7 @@ read_and_upload(struct brw_context *brw, struct disk_cache
*cache,
if (unlikely(debug_enabled_for_stage(stage))) {
fprintf(stderr, "NIR for %s program %d loaded from disk shader cache:\n",
_mesa_shader_stage_to_abbrev(stage), brw_program(prog)->id);
- brw_program_deserialize_nir(&brw->ctx, prog, stage);
+ brw_program_deserialize_driver_blob(&brw->ctx, prog, stage);
nir_shader *nir = prog->nir;
nir_print_shader(nir, stderr);
fprintf(stderr, "Native code for %s %s shader %s from disk cache:\n",
@@ -299,7 +299,7 @@ fail:
_mesa_shader_stage_to_abbrev(prog->info.stage));
}
- brw_program_deserialize_nir(&brw->ctx, prog, stage);
+ brw_program_deserialize_driver_blob(&brw->ctx, prog, stage);
return false;
}
diff --git a/src/mesa/drivers/dri/i965/brw_program_binary.c
b/src/mesa/drivers/dri/i965/brw_program_binary.c
index 099279ef37e..cb1cfdb560a 100644
--- a/src/mesa/drivers/dri/i965/brw_program_binary.c
+++ b/src/mesa/drivers/dri/i965/brw_program_binary.c
@@ -61,6 +61,11 @@ brw_get_program_binary_driver_sha1(struct gl_context *ctx,
uint8_t *sha1)
memcpy(sha1, driver_sha1, sizeof(uint8_t) * 20);
}
+enum driver_cache_blob_part {
+ END_PART,
+ NIR_PART,
+};
+
void
brw_program_serialize_nir(struct gl_context *ctx, struct gl_program *prog)
{
@@ -69,7 +74,12 @@ brw_program_serialize_nir(struct gl_context *ctx, struct
gl_program *prog)
struct blob writer;
blob_init(&writer);
+ blob_write_uint32(&writer, NIR_PART);
+ intptr_t size_offset = blob_reserve_uint32(&writer);
+ size_t nir_start = writer.size;
nir_serialize(&writer, prog->nir);
+ blob_overwrite_uint32(&writer, size_offset, writer.size - nir_start);
+ blob_write_uint32(&writer, END_PART);
prog->driver_cache_blob = ralloc_size(NULL, writer.size);
memcpy(prog->driver_cache_blob, writer.data, writer.size);
prog->driver_cache_blob_size = writer.size;
@@ -77,24 +87,40 @@ brw_program_serialize_nir(struct gl_context *ctx, struct
gl_program *prog)
}
void
-brw_program_deserialize_nir(struct gl_context *ctx, struct gl_program *prog,
-gl_shader_stage stage)
+brw_program_deserialize_driver_blob(struct gl_context *ctx,
+struct gl_program *prog,
+gl_shader_stage stage)
{
- if (!prog->nir) {
- assert(prog->driver_cache_blob && prog->driver_cache_blob_size > 0);
- const struct nir_shader_compiler_options *options =
- ctx->Const.ShaderCompilerOptions[stage].NirOptions;
- struct blob_reader reader;
- blob_reader_init(&reader, prog->driver_cache_blob,
- prog->driver_cache_blob_size);
- prog->nir = nir_deserialize(NULL, options, &reader);
- }
+ if (!prog->driver_cache_blob)
+ return;
+
+ struct blob_reader reader;
+ blob_reader_init(&reader, prog->driver_cache_blob,
+prog->driver_cache_blob_size);
+
+ do {
+ uint32_t part_type = blob_read_uint32(&reader);
+ if ((enum driver_cache_blob_part)part_type == END_PART)
+ break;
+ switch ((enum driver_cache_blob_part)part_type) {
+ case NIR_PART: {
+ uint32_t nir_size = blob_read_uint32(&reader);
+ assert(!reader.overrun &&
+(uintptr_t)(reade
[Mesa-dev] [PATCH 08/19] i965: Add brw_(read|write)_blob_program_data functions
We will want to use these for both the disk shader cache, and for the
ARB_get_program_binary.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_disk_cache.c | 45 +++-
src/mesa/drivers/dri/i965/brw_program.h| 10 ++
src/mesa/drivers/dri/i965/brw_program_binary.c | 47 ++
3 files changed, 61 insertions(+), 41 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_disk_cache.c
b/src/mesa/drivers/dri/i965/brw_disk_cache.c
index 4aa304eb4a6..82a9c121c63 100644
--- a/src/mesa/drivers/dri/i965/brw_disk_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_disk_cache.c
@@ -73,51 +73,14 @@ gen_shader_sha1(struct brw_context *brw, struct gl_program
*prog,
_mesa_sha1_compute(manifest, strlen(manifest), out_sha1);
}
-static void
-write_blob_program_data(struct blob *binary, gl_shader_stage stage,
-const void *program,
-struct brw_stage_prog_data *prog_data)
-{
- /* Write prog_data to blob. */
- blob_write_bytes(binary, prog_data, brw_prog_data_size(stage));
-
- /* Write program to blob. */
- blob_write_bytes(binary, program, prog_data->program_size);
-
- /* Write push params */
- blob_write_bytes(binary, prog_data->param,
-sizeof(uint32_t) * prog_data->nr_params);
-
- /* Write pull params */
- blob_write_bytes(binary, prog_data->pull_param,
-sizeof(uint32_t) * prog_data->nr_pull_params);
-}
-
static bool
read_blob_program_data(struct blob_reader *binary, struct gl_program *prog,
gl_shader_stage stage, const uint8_t **program,
struct brw_stage_prog_data *prog_data)
{
- /* Read shader prog_data from blob. */
- blob_copy_bytes(binary, prog_data, brw_prog_data_size(stage));
- if (binary->overrun)
- return false;
-
- /* Read shader program from blob. */
- *program = blob_read_bytes(binary, prog_data->program_size);
-
- /* Read push params */
- prog_data->param = rzalloc_array(NULL, uint32_t, prog_data->nr_params);
- blob_copy_bytes(binary, prog_data->param,
- sizeof(uint32_t) * prog_data->nr_params);
-
- /* Read pull params */
- prog_data->pull_param = rzalloc_array(NULL, uint32_t,
- prog_data->nr_pull_params);
- blob_copy_bytes(binary, prog_data->pull_param,
- sizeof(uint32_t) * prog_data->nr_pull_params);
-
- return (binary->current == binary->end && !binary->overrun);
+ return
+ brw_read_blob_program_data(binary, prog, stage, program, prog_data) &&
+ (binary->current == binary->end);
}
static bool
@@ -318,7 +281,7 @@ write_program_data(struct brw_context *brw, struct
gl_program *prog,
* generation time when the program is in normal memory accessible with
* cache to the CPU. Another easier change would be to use
* _mesa_streaming_load_memcpy to read from the program mapped memory. */
- write_blob_program_data(&binary, stage, program_map, prog_data);
+ brw_write_blob_program_data(&binary, stage, program_map, prog_data);
unsigned char sha1[20];
char buf[41];
diff --git a/src/mesa/drivers/dri/i965/brw_program.h
b/src/mesa/drivers/dri/i965/brw_program.h
index 701b8da482e..a49bc81a2b4 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -32,6 +32,8 @@ extern "C" {
#endif
struct brw_context;
+struct blob;
+struct blob_reader;
enum brw_param_domain {
BRW_PARAM_DOMAIN_BUILTIN = 0,
@@ -107,6 +109,14 @@ void brw_upload_tes_prog(struct brw_context *brw);
void brw_tes_populate_key(struct brw_context *brw,
struct brw_tes_prog_key *key);
+void brw_write_blob_program_data(struct blob *binary, gl_shader_stage stage,
+ const void *program,
+ struct brw_stage_prog_data *prog_data);
+bool brw_read_blob_program_data(struct blob_reader *binary,
+struct gl_program *prog, gl_shader_stage stage,
+const uint8_t **program,
+struct brw_stage_prog_data *prog_data);
+
#ifdef __cplusplus
} /* extern "C" */
#endif
diff --git a/src/mesa/drivers/dri/i965/brw_program_binary.c
b/src/mesa/drivers/dri/i965/brw_program_binary.c
index cb1cfdb560a..b72dc04ecab 100644
--- a/src/mesa/drivers/dri/i965/brw_program_binary.c
+++ b/src/mesa/drivers/dri/i965/brw_program_binary.c
@@ -133,3 +133,50 @@ brw_deserialize_program_binary(struct gl_context *ctx,
{
brw_program_deserialize_driver_blob(ctx, prog, prog->info.stage);
}
+
+void
+brw_write_blob_program_data(struct blob *binary, gl_shader_stage stage,
+const void *program,
+struct brw_stage_prog_data *prog_data)
+{
+ /* Write prog_data to blob. */
+ blob_write_bytes(binary, prog_data, brw_prog_data_size(stage));
+
+ /* Write
[Mesa-dev] [PATCH 12/19] i965: Add support for driver cache blob containing the gen program
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_program_binary.c | 41 ++
1 file changed, 41 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_program_binary.c
b/src/mesa/drivers/dri/i965/brw_program_binary.c
index b72dc04ecab..3528847e155 100644
--- a/src/mesa/drivers/dri/i965/brw_program_binary.c
+++ b/src/mesa/drivers/dri/i965/brw_program_binary.c
@@ -29,6 +29,7 @@
#include "brw_context.h"
#include "brw_program.h"
+#include "brw_state.h"
static uint8_t driver_sha1[20];
@@ -63,6 +64,7 @@ brw_get_program_binary_driver_sha1(struct gl_context *ctx,
uint8_t *sha1)
enum driver_cache_blob_part {
END_PART,
+ GEN_PART,
NIR_PART,
};
@@ -86,6 +88,38 @@ brw_program_serialize_nir(struct gl_context *ctx, struct
gl_program *prog)
blob_finish(&writer);
}
+static bool
+deserialize_gen_program(struct blob_reader *reader, struct gl_context *ctx,
+struct gl_program *prog, gl_shader_stage stage)
+{
+ struct brw_context *brw = brw_context(ctx);
+
+ union brw_any_prog_key prog_key;
+ blob_copy_bytes(reader, &prog_key, brw_prog_key_size(stage));
+ brw_prog_key_set_id(&prog_key, stage, brw_program(prog)->id);
+
+ enum brw_cache_id cache_id = brw_stage_cache_id(stage);
+
+ const uint8_t *program;
+ struct brw_stage_prog_data *prog_data =
+ ralloc_size(NULL, sizeof(union brw_any_prog_data));
+
+ if (!brw_read_blob_program_data(reader, prog, stage, &program, prog_data)) {
+ ralloc_free(prog_data);
+ return false;
+ }
+
+ uint32_t offset;
+ void *out_prog_data;
+ brw_upload_cache(&brw->cache, cache_id, &prog_key, brw_prog_key_size(stage),
+program, prog_data->program_size, prog_data,
+brw_prog_data_size(stage), &offset, &out_prog_data);
+
+ ralloc_free(prog_data);
+
+ return true;
+}
+
void
brw_program_deserialize_driver_blob(struct gl_context *ctx,
struct gl_program *prog,
@@ -103,6 +137,13 @@ brw_program_deserialize_driver_blob(struct gl_context *ctx,
if ((enum driver_cache_blob_part)part_type == END_PART)
break;
switch ((enum driver_cache_blob_part)part_type) {
+ case GEN_PART: {
+ uint32_t gen_size = blob_read_uint32(&reader);
+ assert(!reader.overrun &&
+(uintptr_t)(reader.end - reader.current) > gen_size);
+ deserialize_gen_program(&reader, ctx, prog, stage);
+ break;
+ }
case NIR_PART: {
uint32_t nir_size = blob_read_uint32(&reader);
assert(!reader.overrun &&
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 17/19] mesa: Add gl_shader_program param to ProgramBinarySerializeDriverBlob
This might be required because some stages might generate different
programs depending on the other stages in the program. For example,
the i965 driver's tessellation control stage depends on the
tessellation evaluation shader.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_context.c| 2 +-
src/mesa/drivers/dri/i965/brw_context.h| 3 +++
src/mesa/drivers/dri/i965/brw_program_binary.c | 8
src/mesa/main/dd.h | 1 +
src/mesa/main/program_binary.c | 3 ++-
src/mesa/state_tracker/st_context.c| 6 --
src/mesa/state_tracker/st_shader_cache.c | 16
src/mesa/state_tracker/st_shader_cache.h | 10 ++
8 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 0a87cc83e35..258eccbc835 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -340,7 +340,7 @@ brw_init_driver_functions(struct brw_context *brw,
/* GL_ARB_get_program_binary */
brw_program_binary_init(brw->screen->deviceID);
functions->GetProgramBinaryDriverSHA1 = brw_get_program_binary_driver_sha1;
- functions->ProgramBinarySerializeDriverBlob = brw_program_serialize_nir;
+ functions->ProgramBinarySerializeDriverBlob = brw_serialize_program_binary;
functions->ProgramBinaryDeserializeDriverBlob =
brw_deserialize_program_binary;
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 0db98d86d07..c61532899c7 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1639,6 +1639,9 @@ extern void
brw_program_binary_init(unsigned device_id);
extern void
brw_get_program_binary_driver_sha1(struct gl_context *ctx, uint8_t *sha1);
+void brw_serialize_program_binary(struct gl_context *ctx,
+ struct gl_shader_program *sh_prog,
+ struct gl_program *prog);
extern void
brw_deserialize_program_binary(struct gl_context *ctx,
struct gl_shader_program *shProg,
diff --git a/src/mesa/drivers/dri/i965/brw_program_binary.c
b/src/mesa/drivers/dri/i965/brw_program_binary.c
index 20d3a3c8ba5..1fe3ffd5bf9 100644
--- a/src/mesa/drivers/dri/i965/brw_program_binary.c
+++ b/src/mesa/drivers/dri/i965/brw_program_binary.c
@@ -237,6 +237,14 @@ brw_deserialize_program_binary(struct gl_context *ctx,
brw_program_deserialize_driver_blob(ctx, prog, prog->info.stage);
}
+void
+brw_serialize_program_binary(struct gl_context *ctx,
+ struct gl_shader_program *sh_prog,
+ struct gl_program *prog)
+{
+ brw_program_serialize_nir(ctx, prog);
+}
+
void
brw_write_blob_program_data(struct blob *binary, gl_shader_stage stage,
const void *program,
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 7a1e6823ac5..0ab5c621b6b 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -1210,6 +1210,7 @@ struct dd_function_table {
void (*GetProgramBinaryDriverSHA1)(struct gl_context *ctx, uint8_t *sha1);
void (*ProgramBinarySerializeDriverBlob)(struct gl_context *ctx,
+struct gl_shader_program *shProg,
struct gl_program *prog);
void (*ProgramBinaryDeserializeDriverBlob)(struct gl_context *ctx,
diff --git a/src/mesa/main/program_binary.c b/src/mesa/main/program_binary.c
index 078d59d13f8..f1bc7bd2cd2 100644
--- a/src/mesa/main/program_binary.c
+++ b/src/mesa/main/program_binary.c
@@ -172,7 +172,8 @@ write_program_payload(struct gl_context *ctx, struct blob
*blob,
for (unsigned stage = 0; stage < MESA_SHADER_STAGES; stage++) {
struct gl_linked_shader *shader = sh_prog->_LinkedShaders[stage];
if (shader)
- ctx->Driver.ProgramBinarySerializeDriverBlob(ctx, shader->Program);
+ ctx->Driver.ProgramBinarySerializeDriverBlob(ctx, sh_prog,
+ shader->Program);
}
serialize_glsl_program(blob, ctx, sh_prog);
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
index 0d0cfc5c63c..18e9799e8b5 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -771,12 +771,14 @@ st_init_driver_functions(struct pipe_screen *screen,
PIPE_SHADER_CAP_PREFERRED_IR);
if (preferred_ir == PIPE_SHADER_IR_NIR) {
functions->ShaderCacheSerializeDriverBlob = st_serialise_nir_program;
- functions->ProgramBinarySerializeDriverBlob = st_serialise_nir_program;
+ functions->ProgramBinarySerializeDriverBlob =
+ st_serialise_nir_program_binary;
functions->ProgramBinaryDeserializeDriverBlob =
st_deserialise_nir
[Mesa-dev] [PATCH 10/19] i965: Add brw_prog_key_set_id helper to set the program id on any stage
For saving programs (shader cache; get program binary) it is useful to
set the id to 0, with the stage being a parameter.
For restoring programs it is useful to set the id to the id allocated
to the program at creation time.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_program.c | 16
src/mesa/drivers/dri/i965/brw_program.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index 50077bcd2da..d84c618da31 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -829,3 +829,19 @@ brw_assign_common_binding_table_offsets(const struct
gen_device_info *devinfo,
assert(next_binding_table_offset <= BRW_MAX_SURFACES);
return next_binding_table_offset;
}
+
+void
+brw_prog_key_set_id(union brw_any_prog_key *key, gl_shader_stage stage,
+unsigned id)
+{
+ static const unsigned stage_offsets[] = {
+ offsetof(struct brw_vs_prog_key, program_string_id),
+ offsetof(struct brw_tcs_prog_key, program_string_id),
+ offsetof(struct brw_tes_prog_key, program_string_id),
+ offsetof(struct brw_gs_prog_key, program_string_id),
+ offsetof(struct brw_wm_prog_key, program_string_id),
+ offsetof(struct brw_cs_prog_key, program_string_id),
+ };
+ assert((int)stage >= 0 && stage < ARRAY_SIZE(stage_offsets));
+ *(unsigned*)((uint8_t*)key + stage_offsets[stage]) = id;
+}
diff --git a/src/mesa/drivers/dri/i965/brw_program.h
b/src/mesa/drivers/dri/i965/brw_program.h
index a49bc81a2b4..3cdb90264ad 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -82,6 +82,9 @@ brw_assign_common_binding_table_offsets(const struct
gen_device_info *devinfo,
const struct gl_program *prog,
struct brw_stage_prog_data
*stage_prog_data,
uint32_t next_binding_table_offset);
+void
+brw_prog_key_set_id(union brw_any_prog_key *key, gl_shader_stage stage,
+unsigned id);
void
brw_stage_prog_data_free(const void *prog_data);
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/19] i965: Move brw_program_*serialize_nir to brw_program_binary.c
This will allow get_program_binary to add the gen program into its
serialization in addition to just the nir program.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_program.c| 37 --
src/mesa/drivers/dri/i965/brw_program_binary.c | 37 ++
2 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index 3f18a0f7d47..50077bcd2da 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -41,7 +41,6 @@
#include "util/ralloc.h"
#include "compiler/glsl/ir.h"
#include "compiler/glsl/glsl_to_nir.h"
-#include "compiler/nir/nir_serialize.h"
#include "brw_program.h"
#include "brw_context.h"
@@ -830,39 +829,3 @@ brw_assign_common_binding_table_offsets(const struct
gen_device_info *devinfo,
assert(next_binding_table_offset <= BRW_MAX_SURFACES);
return next_binding_table_offset;
}
-
-void
-brw_program_serialize_nir(struct gl_context *ctx, struct gl_program *prog)
-{
- if (prog->driver_cache_blob)
- return;
-
- struct blob writer;
- blob_init(&writer);
- nir_serialize(&writer, prog->nir);
- prog->driver_cache_blob = ralloc_size(NULL, writer.size);
- memcpy(prog->driver_cache_blob, writer.data, writer.size);
- prog->driver_cache_blob_size = writer.size;
- blob_finish(&writer);
-}
-
-void
-brw_program_deserialize_nir(struct gl_context *ctx, struct gl_program *prog,
-gl_shader_stage stage)
-{
- if (!prog->nir) {
- assert(prog->driver_cache_blob && prog->driver_cache_blob_size > 0);
- const struct nir_shader_compiler_options *options =
- ctx->Const.ShaderCompilerOptions[stage].NirOptions;
- struct blob_reader reader;
- blob_reader_init(&reader, prog->driver_cache_blob,
- prog->driver_cache_blob_size);
- prog->nir = nir_deserialize(NULL, options, &reader);
- }
-
- if (prog->driver_cache_blob) {
- ralloc_free(prog->driver_cache_blob);
- prog->driver_cache_blob = NULL;
- prog->driver_cache_blob_size = 0;
- }
-}
diff --git a/src/mesa/drivers/dri/i965/brw_program_binary.c
b/src/mesa/drivers/dri/i965/brw_program_binary.c
index f1b327de4b3..099279ef37e 100644
--- a/src/mesa/drivers/dri/i965/brw_program_binary.c
+++ b/src/mesa/drivers/dri/i965/brw_program_binary.c
@@ -23,6 +23,7 @@
#include
+#include "compiler/nir/nir_serialize.h"
#include "util/build_id.h"
#include "util/mesa-sha1.h"
@@ -60,6 +61,42 @@ brw_get_program_binary_driver_sha1(struct gl_context *ctx,
uint8_t *sha1)
memcpy(sha1, driver_sha1, sizeof(uint8_t) * 20);
}
+void
+brw_program_serialize_nir(struct gl_context *ctx, struct gl_program *prog)
+{
+ if (prog->driver_cache_blob)
+ return;
+
+ struct blob writer;
+ blob_init(&writer);
+ nir_serialize(&writer, prog->nir);
+ prog->driver_cache_blob = ralloc_size(NULL, writer.size);
+ memcpy(prog->driver_cache_blob, writer.data, writer.size);
+ prog->driver_cache_blob_size = writer.size;
+ blob_finish(&writer);
+}
+
+void
+brw_program_deserialize_nir(struct gl_context *ctx, struct gl_program *prog,
+gl_shader_stage stage)
+{
+ if (!prog->nir) {
+ assert(prog->driver_cache_blob && prog->driver_cache_blob_size > 0);
+ const struct nir_shader_compiler_options *options =
+ ctx->Const.ShaderCompilerOptions[stage].NirOptions;
+ struct blob_reader reader;
+ blob_reader_init(&reader, prog->driver_cache_blob,
+ prog->driver_cache_blob_size);
+ prog->nir = nir_deserialize(NULL, options, &reader);
+ }
+
+ if (prog->driver_cache_blob) {
+ ralloc_free(prog->driver_cache_blob);
+ prog->driver_cache_blob = NULL;
+ prog->driver_cache_blob_size = 0;
+ }
+}
+
/* This is just a wrapper around brw_program_deserialize_nir() as i965
* doesn't need gl_shader_program like other drivers do.
*/
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 18/19] i965: Add flag_state param to brw_search_cache
This allows brw_search_cache to be used to find programs without
causing extra state to be emitted in the case where the program isn't
being made active. (For example, to find the program to save out with
the ARB_get_program_binary interface.)
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_blorp.c | 4 ++--
src/mesa/drivers/dri/i965/brw_clip.c | 5 ++---
src/mesa/drivers/dri/i965/brw_cs.c| 7 +++
src/mesa/drivers/dri/i965/brw_ff_gs.c | 6 +++---
src/mesa/drivers/dri/i965/brw_gs.c| 7 +++
src/mesa/drivers/dri/i965/brw_program_cache.c | 11 +--
src/mesa/drivers/dri/i965/brw_sf.c| 5 ++---
src/mesa/drivers/dri/i965/brw_state.h | 8 +++-
src/mesa/drivers/dri/i965/brw_tcs.c | 7 +++
src/mesa/drivers/dri/i965/brw_tes.c | 7 +++
src/mesa/drivers/dri/i965/brw_vs.c| 6 +++---
src/mesa/drivers/dri/i965/brw_wm.c| 7 +++
12 files changed, 35 insertions(+), 45 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
b/src/mesa/drivers/dri/i965/brw_blorp.c
index ba14136edc6..53e96a955cb 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -48,8 +48,8 @@ brw_blorp_lookup_shader(struct blorp_context *blorp,
uint32_t *kernel_out, void *prog_data_out)
{
struct brw_context *brw = blorp->driver_ctx;
- return brw_search_cache(&brw->cache, BRW_CACHE_BLORP_PROG,
- key, key_size, kernel_out, prog_data_out);
+ return brw_search_cache(&brw->cache, BRW_CACHE_BLORP_PROG, key, key_size,
+ kernel_out, prog_data_out, true);
}
static bool
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index 3a7c4829ed7..49c41d8c2e4 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -203,9 +203,8 @@ brw_upload_clip_prog(struct brw_context *brw)
}
}
- if (!brw_search_cache(&brw->cache, BRW_CACHE_CLIP_PROG,
-&key, sizeof(key),
-&brw->clip.prog_offset, &brw->clip.prog_data)) {
+ if (!brw_search_cache(&brw->cache, BRW_CACHE_CLIP_PROG, &key, sizeof(key),
+ &brw->clip.prog_offset, &brw->clip.prog_data, true)) {
compile_clip_prog( brw, &key );
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_cs.c
b/src/mesa/drivers/dri/i965/brw_cs.c
index 614eb64bca9..498c80d46a5 100644
--- a/src/mesa/drivers/dri/i965/brw_cs.c
+++ b/src/mesa/drivers/dri/i965/brw_cs.c
@@ -168,10 +168,9 @@ brw_upload_cs_prog(struct brw_context *brw)
brw_cs_populate_key(brw, &key);
- if (brw_search_cache(&brw->cache, BRW_CACHE_CS_PROG,
-&key, sizeof(key),
-&brw->cs.base.prog_offset,
-&brw->cs.base.prog_data))
+ if (brw_search_cache(&brw->cache, BRW_CACHE_CS_PROG, &key, sizeof(key),
+&brw->cs.base.prog_offset, &brw->cs.base.prog_data,
+true))
return;
if (brw_disk_cache_upload_program(brw, MESA_SHADER_COMPUTE))
diff --git a/src/mesa/drivers/dri/i965/brw_ff_gs.c
b/src/mesa/drivers/dri/i965/brw_ff_gs.c
index 174418a4748..b2c4ee12f4d 100644
--- a/src/mesa/drivers/dri/i965/brw_ff_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_ff_gs.c
@@ -251,9 +251,9 @@ brw_upload_ff_gs_prog(struct brw_context *brw)
}
if (brw->ff_gs.prog_active) {
- if (!brw_search_cache(&brw->cache, BRW_CACHE_FF_GS_PROG,
- &key, sizeof(key),
- &brw->ff_gs.prog_offset, &brw->ff_gs.prog_data)) {
+ if (!brw_search_cache(&brw->cache, BRW_CACHE_FF_GS_PROG, &key,
+sizeof(key), &brw->ff_gs.prog_offset,
+&brw->ff_gs.prog_data, true)) {
brw_codegen_ff_gs_prog(brw, &key);
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
b/src/mesa/drivers/dri/i965/brw_gs.c
index 9d4dc942d34..9acb0337e20 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -192,10 +192,9 @@ brw_upload_gs_prog(struct brw_context *brw)
brw_gs_populate_key(brw, &key);
- if (brw_search_cache(&brw->cache, BRW_CACHE_GS_PROG,
-&key, sizeof(key),
-&stage_state->prog_offset,
-&brw->gs.base.prog_data))
+ if (brw_search_cache(&brw->cache, BRW_CACHE_GS_PROG, &key, sizeof(key),
+&stage_state->prog_offset, &brw->gs.base.prog_data,
+true))
return;
if (brw_disk_cache_upload_program(brw, MESA_SHADER_GEOMETRY))
diff --git a/src/mesa/drivers/dri/i965/brw_program_cache.c
b/src/mesa/drivers/dri/i965/brw_program_cache.c
index 40f1078ca98..71664d5ddad 100644
--- a/src/mesa/drivers/dri/i965/brw_program_cache.c
+++ b/src/mesa/drivers/dri/i
[Mesa-dev] [PATCH 19/19] i965: Support saving the gen program with glGetProgramBinary
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_program_binary.c | 72 +++---
1 file changed, 66 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_program_binary.c
b/src/mesa/drivers/dri/i965/brw_program_binary.c
index 1fe3ffd5bf9..db03332241e 100644
--- a/src/mesa/drivers/dri/i965/brw_program_binary.c
+++ b/src/mesa/drivers/dri/i965/brw_program_binary.c
@@ -126,6 +126,16 @@ driver_blob_is_ready(void *blob, uint32_t size, bool
with_gen_program)
}
}
+static void
+serialize_nir_part(struct blob *writer, struct gl_program *prog)
+{
+ blob_write_uint32(writer, NIR_PART);
+ intptr_t size_offset = blob_reserve_uint32(writer);
+ size_t nir_start = writer->size;
+ nir_serialize(writer, prog->nir);
+ blob_overwrite_uint32(writer, size_offset, writer->size - nir_start);
+}
+
void
brw_program_serialize_nir(struct gl_context *ctx, struct gl_program *prog)
{
@@ -138,11 +148,7 @@ brw_program_serialize_nir(struct gl_context *ctx, struct
gl_program *prog)
struct blob writer;
blob_init(&writer);
- blob_write_uint32(&writer, NIR_PART);
- intptr_t size_offset = blob_reserve_uint32(&writer);
- size_t nir_start = writer.size;
- nir_serialize(&writer, prog->nir);
- blob_overwrite_uint32(&writer, size_offset, writer.size - nir_start);
+ serialize_nir_part(&writer, prog);
blob_write_uint32(&writer, END_PART);
prog->driver_cache_blob = ralloc_size(NULL, writer.size);
memcpy(prog->driver_cache_blob, writer.data, writer.size);
@@ -237,12 +243,66 @@ brw_deserialize_program_binary(struct gl_context *ctx,
brw_program_deserialize_driver_blob(ctx, prog, prog->info.stage);
}
+static void
+serialize_gen_part(struct blob *writer, struct gl_context *ctx,
+ struct gl_shader_program *sh_prog,
+ struct gl_program *prog)
+{
+ struct brw_context *brw = brw_context(ctx);
+
+ union brw_any_prog_key key;
+ brw_populate_default_key(&brw->screen->devinfo, &key, sh_prog, prog);
+
+ const gl_shader_stage stage = prog->info.stage;
+ uint32_t offset = 0;
+ void *prog_data = NULL;
+ if (brw_search_cache(&brw->cache, brw_stage_cache_id(stage), &key,
+brw_prog_key_size(stage), &offset, &prog_data,
+false)) {
+ const void *program_map = brw->cache.map + offset;
+ /* TODO: Improve perf for non-LLC. It would be best to save it at
+ * program generation time when the program is in normal memory
+ * accessible with cache to the CPU. Another easier change would be to
+ * use _mesa_streaming_load_memcpy to read from the program mapped
+ * memory.
+ */
+ blob_write_uint32(writer, GEN_PART);
+ intptr_t size_offset = blob_reserve_uint32(writer);
+ size_t gen_start = writer->size;
+ blob_write_bytes(writer, &key, brw_prog_key_size(stage));
+ brw_write_blob_program_data(writer, stage, program_map, prog_data);
+ blob_overwrite_uint32(writer, size_offset, writer->size - gen_start);
+ }
+}
+
void
brw_serialize_program_binary(struct gl_context *ctx,
struct gl_shader_program *sh_prog,
struct gl_program *prog)
{
- brw_program_serialize_nir(ctx, prog);
+ if (driver_blob_is_ready(prog->driver_cache_blob,
+prog->driver_cache_blob_size, true))
+ return;
+
+ if (prog->driver_cache_blob) {
+ if (!prog->nir) {
+ /* If we loaded from the disk shader cache, then the nir might not
+ * have been deserialized yet.
+ */
+ brw_program_deserialize_driver_blob(ctx, prog, prog->info.stage);
+ }
+ ralloc_free(prog->driver_cache_blob);
+ }
+
+ struct blob writer;
+ blob_init(&writer);
+ serialize_nir_part(&writer, prog);
+ serialize_gen_part(&writer, ctx, sh_prog, prog);
+ blob_write_uint32(&writer, END_PART);
+ prog->driver_cache_blob = ralloc_size(NULL, writer.size);
+ memcpy(prog->driver_cache_blob, writer.data, writer.size);
+ prog->driver_cache_blob_size = writer.size;
+ blob_finish(&writer);
}
void
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/19] compiler/blob: Add blob_skip_bytes
Signed-off-by: Jordan Justen
---
src/compiler/blob.c | 7 +++
src/compiler/blob.h | 6 ++
2 files changed, 13 insertions(+)
diff --git a/src/compiler/blob.c b/src/compiler/blob.c
index 5e8671b7b44..c89092e1cf3 100644
--- a/src/compiler/blob.c
+++ b/src/compiler/blob.c
@@ -291,6 +291,13 @@ blob_copy_bytes(struct blob_reader *blob, void *dest,
size_t size)
memcpy(dest, bytes, size);
}
+void
+blob_skip_bytes(struct blob_reader *blob, size_t size)
+{
+ if (ensure_can_read (blob, size))
+ blob->current += size;
+}
+
/* These next three read functions have identical form. If we add any beyond
* these first three we should probably switch to generating these with a
* preprocessor macro.
diff --git a/src/compiler/blob.h b/src/compiler/blob.h
index 2b975d45dfe..b56fa4b2fe0 100644
--- a/src/compiler/blob.h
+++ b/src/compiler/blob.h
@@ -294,6 +294,12 @@ blob_read_bytes(struct blob_reader *blob, size_t size);
void
blob_copy_bytes(struct blob_reader *blob, void *dest, size_t size);
+/**
+ * Skip \size bytes within the blob.
+ */
+void
+blob_skip_bytes(struct blob_reader *blob, size_t size);
+
/**
* Read a uint32_t from the current location, (and update the current location
* to just past this uint32_t).
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/19] mesa: Add disk shader cache driver blob callback
Signed-off-by: Jordan Justen
---
src/compiler/glsl/shader_cache.cpp | 8
src/mesa/main/dd.h | 15 +++
2 files changed, 23 insertions(+)
diff --git a/src/compiler/glsl/shader_cache.cpp
b/src/compiler/glsl/shader_cache.cpp
index 042f3a60f5b..31d0aa62966 100644
--- a/src/compiler/glsl/shader_cache.cpp
+++ b/src/compiler/glsl/shader_cache.cpp
@@ -102,6 +102,14 @@ shader_cache_write_program_metadata(struct gl_context *ctx,
struct blob metadata;
blob_init(&metadata);
+ if (ctx->Driver.ShaderCacheSerializeDriverBlob) {
+ for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
+ struct gl_linked_shader *sh = prog->_LinkedShaders[i];
+ if (sh)
+ctx->Driver.ShaderCacheSerializeDriverBlob(ctx, sh->Program);
+ }
+ }
+
serialize_glsl_program(&metadata, ctx, prog);
struct cache_item_metadata cache_item_metadata;
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 9f9606ac6b5..7a1e6823ac5 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -1274,6 +1274,21 @@ struct dd_function_table {
struct gl_semaphore_object *semObj,
int fd);
/*@}*/
+
+ /**
+* \name Disk shader cache functions
+*/
+ /*@{*/
+ /**
+* Called to initialize gl_program::driver_cache_blob (and size) with a
+* ralloc allocated buffer.
+*
+* This buffer will be saved and restored as part of the gl_program
+* serialization and deserialization.
+*/
+ void (*ShaderCacheSerializeDriverBlob)(struct gl_context *ctx,
+ struct gl_program *prog);
+ /*@}*/
};
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/19] i965: Use ShaderCacheSerializeDriverBlob driver function
This function is called just before the gl_program::driver_cache_blob
is saved out as part of the gl_program serialization.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_context.c | 4
src/mesa/drivers/dri/i965/brw_link.cpp | 11 ---
src/mesa/drivers/dri/i965/brw_program.c | 3 +++
3 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index ec3fe3be40d..0a87cc83e35 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -343,6 +343,10 @@ brw_init_driver_functions(struct brw_context *brw,
functions->ProgramBinarySerializeDriverBlob = brw_program_serialize_nir;
functions->ProgramBinaryDeserializeDriverBlob =
brw_deserialize_program_binary;
+
+ if (brw->screen->disk_cache) {
+ functions->ShaderCacheSerializeDriverBlob = brw_program_serialize_nir;
+ }
}
static void
diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp
b/src/mesa/drivers/dri/i965/brw_link.cpp
index 39fa94c0f8d..6f748659982 100644
--- a/src/mesa/drivers/dri/i965/brw_link.cpp
+++ b/src/mesa/drivers/dri/i965/brw_link.cpp
@@ -350,17 +350,6 @@ brw_link_shader(struct gl_context *ctx, struct
gl_shader_program *shProg)
}
}
- if (brw->ctx.Cache) {
- for (stage = 0; stage < ARRAY_SIZE(shProg->_LinkedShaders); stage++) {
- struct gl_linked_shader *shader = shProg->_LinkedShaders[stage];
- if (!shader)
-continue;
-
- struct gl_program *prog = shader->Program;
- brw_program_serialize_nir(ctx, prog);
- }
- }
-
if (brw->precompile && !brw_shader_precompile(ctx, shProg))
return false;
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index fc77926d6e0..3f18a0f7d47 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -834,6 +834,9 @@ brw_assign_common_binding_table_offsets(const struct
gen_device_info *devinfo,
void
brw_program_serialize_nir(struct gl_context *ctx, struct gl_program *prog)
{
+ if (prog->driver_cache_blob)
+ return;
+
struct blob writer;
blob_init(&writer);
nir_serialize(&writer, prog->nir);
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/19] i965: Replace brw_setup_tex_for_precompile brw with devinfo
Trying to make sure the setup of the default program key is not
dependent on the GL state.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_cs.c | 2 +-
src/mesa/drivers/dri/i965/brw_gs.c | 2 +-
src/mesa/drivers/dri/i965/brw_program.c | 3 +--
src/mesa/drivers/dri/i965/brw_program.h | 2 +-
src/mesa/drivers/dri/i965/brw_tcs.c | 2 +-
src/mesa/drivers/dri/i965/brw_tes.c | 2 +-
src/mesa/drivers/dri/i965/brw_vs.c | 2 +-
src/mesa/drivers/dri/i965/brw_wm.c | 2 +-
8 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cs.c
b/src/mesa/drivers/dri/i965/brw_cs.c
index e3f8fc67a4b..9b1b0832b5a 100644
--- a/src/mesa/drivers/dri/i965/brw_cs.c
+++ b/src/mesa/drivers/dri/i965/brw_cs.c
@@ -196,7 +196,7 @@ brw_cs_precompile(struct gl_context *ctx, struct gl_program
*prog)
memset(&key, 0, sizeof(key));
key.program_string_id = bcp->id;
- brw_setup_tex_for_precompile(brw, &key.tex, prog);
+ brw_setup_tex_for_precompile(&brw->screen->devinfo, &key.tex, prog);
uint32_t old_prog_offset = brw->cs.base.prog_offset;
struct brw_stage_prog_data *old_prog_data = brw->cs.base.prog_data;
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
b/src/mesa/drivers/dri/i965/brw_gs.c
index f74ee178f25..f488fab009e 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -221,7 +221,7 @@ brw_gs_precompile(struct gl_context *ctx, struct gl_program
*prog)
memset(&key, 0, sizeof(key));
- brw_setup_tex_for_precompile(brw, &key.tex, prog);
+ brw_setup_tex_for_precompile(&brw->screen->devinfo, &key.tex, prog);
key.program_string_id = bgp->id;
success = brw_codegen_gs_prog(brw, bgp, &key);
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index d84c618da31..ca934b91c9a 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -730,11 +730,10 @@ brw_dump_arb_asm(const char *stage, struct gl_program
*prog)
}
void
-brw_setup_tex_for_precompile(struct brw_context *brw,
+brw_setup_tex_for_precompile(const struct gen_device_info *devinfo,
struct brw_sampler_prog_key_data *tex,
struct gl_program *prog)
{
- const struct gen_device_info *devinfo = &brw->screen->devinfo;
const bool has_shader_channel_select = devinfo->is_haswell || devinfo->gen
>= 8;
unsigned sampler_count = util_last_bit(prog->SamplersUsed);
for (unsigned i = 0; i < sampler_count; i++) {
diff --git a/src/mesa/drivers/dri/i965/brw_program.h
b/src/mesa/drivers/dri/i965/brw_program.h
index 3cdb90264ad..c8656fcff1f 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -66,7 +66,7 @@ struct nir_shader *brw_create_nir(struct brw_context *brw,
void brw_shader_gather_info(nir_shader *nir, struct gl_program *prog);
-void brw_setup_tex_for_precompile(struct brw_context *brw,
+void brw_setup_tex_for_precompile(const struct gen_device_info *devinfo,
struct brw_sampler_prog_key_data *tex,
struct gl_program *prog);
diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c
b/src/mesa/drivers/dri/i965/brw_tcs.c
index 931ef64166c..70313fee8ac 100644
--- a/src/mesa/drivers/dri/i965/brw_tcs.c
+++ b/src/mesa/drivers/dri/i965/brw_tcs.c
@@ -374,7 +374,7 @@ brw_tcs_precompile(struct gl_context *ctx,
memset(&key, 0, sizeof(key));
key.program_string_id = btcp->id;
- brw_setup_tex_for_precompile(brw, &key.tex, prog);
+ brw_setup_tex_for_precompile(&brw->screen->devinfo, &key.tex, prog);
/* Guess that the input and output patches have the same dimensionality. */
if (devinfo->gen < 8)
diff --git a/src/mesa/drivers/dri/i965/brw_tes.c
b/src/mesa/drivers/dri/i965/brw_tes.c
index 2f3697ce961..72b218ac14f 100644
--- a/src/mesa/drivers/dri/i965/brw_tes.c
+++ b/src/mesa/drivers/dri/i965/brw_tes.c
@@ -239,7 +239,7 @@ brw_tes_precompile(struct gl_context *ctx,
key.patch_inputs_read |= tcp->nir->info.patch_outputs_written;
}
- brw_setup_tex_for_precompile(brw, &key.tex, prog);
+ brw_setup_tex_for_precompile(&brw->screen->devinfo, &key.tex, prog);
success = brw_codegen_tes_prog(brw, btep, &key);
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drivers/dri/i965/brw_vs.c
index 5154dee3ca3..f024c33c02d 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -369,7 +369,7 @@ brw_vs_precompile(struct gl_context *ctx, struct gl_program
*prog)
memset(&key, 0, sizeof(key));
- brw_setup_tex_for_precompile(brw, &key.tex, prog);
+ brw_setup_tex_for_precompile(&brw->screen->devinfo, &key.tex, prog);
key.program_string_id = bvp->id;
key.clamp_vertex_color =
(prog->info.outputs_written &
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
ind
[Mesa-dev] [PATCH 11/19] i965: Use brw_prog_key_set_id in disk cache load/store code
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_disk_cache.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_disk_cache.c
b/src/mesa/drivers/dri/i965/brw_disk_cache.c
index 82a9c121c63..c478753d4ad 100644
--- a/src/mesa/drivers/dri/i965/brw_disk_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_disk_cache.c
@@ -94,36 +94,32 @@ read_and_upload(struct brw_context *brw, struct disk_cache
*cache,
switch (stage) {
case MESA_SHADER_VERTEX:
brw_vs_populate_key(brw, &prog_key.vs);
- /* We don't care what instance of the program it is for the disk cache
- * hash lookup, so set the id to 0 for the sha1 hashing.
- * program_string_id will be set below.
- */
- prog_key.vs.program_string_id = 0;
break;
case MESA_SHADER_TESS_CTRL:
brw_tcs_populate_key(brw, &prog_key.tcs);
- prog_key.tcs.program_string_id = 0;
break;
case MESA_SHADER_TESS_EVAL:
brw_tes_populate_key(brw, &prog_key.tes);
- prog_key.tes.program_string_id = 0;
break;
case MESA_SHADER_GEOMETRY:
brw_gs_populate_key(brw, &prog_key.gs);
- prog_key.gs.program_string_id = 0;
break;
case MESA_SHADER_FRAGMENT:
brw_wm_populate_key(brw, &prog_key.wm);
- prog_key.wm.program_string_id = 0;
break;
case MESA_SHADER_COMPUTE:
brw_cs_populate_key(brw, &prog_key.cs);
- prog_key.cs.program_string_id = 0;
break;
default:
unreachable("Unsupported stage!");
}
+ /* We don't care what instance of the program it is for the disk cache hash
+* lookup, so set the id to 0 for the sha1 hashing. program_string_id will
+* be set below.
+*/
+ brw_prog_key_set_id(&prog_key, stage, 0);
+
gen_shader_sha1(brw, prog, stage, &prog_key, binary_sha1);
size_t buffer_size;
@@ -171,32 +167,26 @@ read_and_upload(struct brw_context *brw, struct
disk_cache *cache,
switch (stage) {
case MESA_SHADER_VERTEX:
- prog_key.vs.program_string_id = brw_program(prog)->id;
cache_id = BRW_CACHE_VS_PROG;
stage_state = &brw->vs.base;
break;
case MESA_SHADER_TESS_CTRL:
- prog_key.tcs.program_string_id = brw_program(prog)->id;
cache_id = BRW_CACHE_TCS_PROG;
stage_state = &brw->tcs.base;
break;
case MESA_SHADER_TESS_EVAL:
- prog_key.tes.program_string_id = brw_program(prog)->id;
cache_id = BRW_CACHE_TES_PROG;
stage_state = &brw->tes.base;
break;
case MESA_SHADER_GEOMETRY:
- prog_key.gs.program_string_id = brw_program(prog)->id;
cache_id = BRW_CACHE_GS_PROG;
stage_state = &brw->gs.base;
break;
case MESA_SHADER_FRAGMENT:
- prog_key.wm.program_string_id = brw_program(prog)->id;
cache_id = BRW_CACHE_FS_PROG;
stage_state = &brw->wm.base;
break;
case MESA_SHADER_COMPUTE:
- prog_key.cs.program_string_id = brw_program(prog)->id;
cache_id = BRW_CACHE_CS_PROG;
stage_state = &brw->cs.base;
break;
@@ -204,6 +194,8 @@ read_and_upload(struct brw_context *brw, struct disk_cache
*cache,
unreachable("Unsupported stage!");
}
+ brw_prog_key_set_id(&prog_key, stage, brw_program(prog)->id);
+
brw_alloc_stage_scratch(brw, stage_state, prog_data->total_scratch);
if (unlikely(debug_enabled_for_stage(stage))) {
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/19] st/mesa: i965: Use ShaderCacheSerializeDriverBlob driver function
Signed-off-by: Jordan Justen
---
src/mesa/state_tracker/st_context.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
index ee76e07a7d1..0d0cfc5c63c 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -770,10 +770,12 @@ st_init_driver_functions(struct pipe_screen *screen,
screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
PIPE_SHADER_CAP_PREFERRED_IR);
if (preferred_ir == PIPE_SHADER_IR_NIR) {
+ functions->ShaderCacheSerializeDriverBlob = st_serialise_nir_program;
functions->ProgramBinarySerializeDriverBlob = st_serialise_nir_program;
functions->ProgramBinaryDeserializeDriverBlob =
st_deserialise_nir_program;
} else {
+ functions->ShaderCacheSerializeDriverBlob = st_serialise_tgsi_program;
functions->ProgramBinarySerializeDriverBlob = st_serialise_tgsi_program;
functions->ProgramBinaryDeserializeDriverBlob =
st_deserialise_tgsi_program;
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/19] mesa: Always call ProgramBinarySerializeDriverBlob
The driver may prefer to have a different blob for
ARB_get_program_binary compared to the version saved out for the disk
shader cache.
Since they both use the driver_cache_blob field, we need to always
give the driver the opportunity to fill in the driver_cache_blob when
saving the program binary.
Signed-off-by: Jordan Justen
---
src/mesa/main/program_binary.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/src/mesa/main/program_binary.c b/src/mesa/main/program_binary.c
index 021f6315e72..078d59d13f8 100644
--- a/src/mesa/main/program_binary.c
+++ b/src/mesa/main/program_binary.c
@@ -169,24 +169,22 @@ static void
write_program_payload(struct gl_context *ctx, struct blob *blob,
struct gl_shader_program *sh_prog)
{
- bool serialize[MESA_SHADER_STAGES];
for (unsigned stage = 0; stage < MESA_SHADER_STAGES; stage++) {
struct gl_linked_shader *shader = sh_prog->_LinkedShaders[stage];
- serialize[stage] = shader && shader->Program->driver_cache_blob == NULL;
- if (serialize[stage])
+ if (shader)
ctx->Driver.ProgramBinarySerializeDriverBlob(ctx, shader->Program);
}
serialize_glsl_program(blob, ctx, sh_prog);
for (unsigned stage = 0; stage < MESA_SHADER_STAGES; stage++) {
- if (!serialize[stage])
- continue;
-
- struct gl_program *prog = sh_prog->_LinkedShaders[stage]->Program;
- ralloc_free(prog->driver_cache_blob);
- prog->driver_cache_blob = NULL;
- prog->driver_cache_blob_size = 0;
+ struct gl_linked_shader *shader = sh_prog->_LinkedShaders[stage];
+ if (shader) {
+ struct gl_program *prog = sh_prog->_LinkedShaders[stage]->Program;
+ ralloc_free(prog->driver_cache_blob);
+ prog->driver_cache_blob = NULL;
+ prog->driver_cache_blob_size = 0;
+ }
}
}
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/19] i965 save default gen program with GetProgramBinary
git://people.freedesktop.org/~jljusten/mesa i965-get-program-binary-gen-v1 Currently we only save the nir program out when GetProgramBinary is called. It is likely that the program using ARB_get_program_binary will also use the default gen program after loading a program with ProgramBinary. Therefore, it is also likely to save significant time if we save and restore the default gen program with ARB_get_program_binary. Since we use driver_cache_blob in gl_program for both the shader cache and ARB_get_program_binary, I had to allow the shader cache and ARB_get_program_binary to have separate paths to fill in different binaries for driver_cache_blob. We could also consider just saving the default gen program out with the shader cache glsl serialized cache entry. Then the shader cache and ARB_get_program_binary would still use the same format for driver_cache_blob. I tested this with DOTA 2 which uses ARB_get_program_binary. I also tested in CI which runs the deqp/cts/piglit ARB_get_program_binary tests. Cc: Timothy Arceri Jordan Justen (19): mesa: Add disk shader cache driver blob callback st/mesa: Skip serializing driver_cache_blob if it exists st/mesa: i965: Use ShaderCacheSerializeDriverBlob driver function i965: Use ShaderCacheSerializeDriverBlob driver function mesa: Always call ProgramBinarySerializeDriverBlob i965: Move brw_program_*serialize_nir to brw_program_binary.c i965: Add brw_program_deserialize_driver_blob i965: Add brw_(read|write)_blob_program_data functions i965: Add brw_stage_cache_id to map gl stages to brw cache_ids i965: Add brw_prog_key_set_id helper to set the program id on any stage i965: Use brw_prog_key_set_id in disk cache load/store code i965: Add support for driver cache blob containing the gen program compiler/blob: Add blob_skip_bytes i965: Regenerate blob without gen program for shader cache i965: Replace brw_setup_tex_for_precompile brw with devinfo i965: Add brw_populate_default_key mesa: Add gl_shader_program param to ProgramBinarySerializeDriverBlob i965: Add flag_state param to brw_search_cache i965: Support saving the gen program with glGetProgramBinary src/compiler/blob.c| 7 + src/compiler/blob.h| 6 + src/compiler/glsl/shader_cache.cpp | 8 + src/mesa/drivers/dri/i965/brw_blorp.c | 4 +- src/mesa/drivers/dri/i965/brw_clip.c | 5 +- src/mesa/drivers/dri/i965/brw_context.c| 6 +- src/mesa/drivers/dri/i965/brw_context.h| 8 +- src/mesa/drivers/dri/i965/brw_cs.c | 22 +- src/mesa/drivers/dri/i965/brw_cs.h | 4 + src/mesa/drivers/dri/i965/brw_disk_cache.c | 73 ++- src/mesa/drivers/dri/i965/brw_ff_gs.c | 6 +- src/mesa/drivers/dri/i965/brw_gs.c | 23 +- src/mesa/drivers/dri/i965/brw_gs.h | 4 + src/mesa/drivers/dri/i965/brw_link.cpp | 11 - src/mesa/drivers/dri/i965/brw_program.c| 70 +++--- src/mesa/drivers/dri/i965/brw_program.h| 30 ++- src/mesa/drivers/dri/i965/brw_program_binary.c | 283 - src/mesa/drivers/dri/i965/brw_program_cache.c | 26 ++- src/mesa/drivers/dri/i965/brw_sf.c | 5 +- src/mesa/drivers/dri/i965/brw_state.h | 10 +- src/mesa/drivers/dri/i965/brw_tcs.c| 64 +++--- src/mesa/drivers/dri/i965/brw_tes.c| 47 ++-- src/mesa/drivers/dri/i965/brw_vs.c | 32 ++- src/mesa/drivers/dri/i965/brw_vs.h | 4 + src/mesa/drivers/dri/i965/brw_wm.c | 55 +++-- src/mesa/drivers/dri/i965/brw_wm.h | 4 + src/mesa/main/dd.h | 16 ++ src/mesa/main/program_binary.c | 21 +- src/mesa/state_tracker/st_context.c| 8 +- src/mesa/state_tracker/st_shader_cache.c | 19 ++ src/mesa/state_tracker/st_shader_cache.h | 10 + 31 files changed, 658 insertions(+), 233 deletions(-) -- 2.16.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/19] st/mesa: Skip serializing driver_cache_blob if it exists
Previously the mesa core code would not call to serialize the
driver_cache_blob if it existed. We will update it to always call to
serialize the driver_cache_blob meaning we should avoid re-serializing
it under mesa/state_tracker.
Signed-off-by: Jordan Justen
---
src/mesa/state_tracker/st_shader_cache.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/state_tracker/st_shader_cache.c
b/src/mesa/state_tracker/st_shader_cache.c
index 3ca3fef1df2..4801bb1c504 100644
--- a/src/mesa/state_tracker/st_shader_cache.c
+++ b/src/mesa/state_tracker/st_shader_cache.c
@@ -74,6 +74,9 @@ static void
st_serialise_ir_program(struct gl_context *ctx, struct gl_program *prog,
bool nir)
{
+ if (prog->driver_cache_blob)
+ return;
+
struct blob blob;
blob_init(&blob);
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/19] i965: Regenerate blob without gen program for shader cache
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_program_binary.c | 64 +-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_program_binary.c
b/src/mesa/drivers/dri/i965/brw_program_binary.c
index 3528847e155..20d3a3c8ba5 100644
--- a/src/mesa/drivers/dri/i965/brw_program_binary.c
+++ b/src/mesa/drivers/dri/i965/brw_program_binary.c
@@ -68,12 +68,74 @@ enum driver_cache_blob_part {
NIR_PART,
};
+static bool
+blob_parts_valid(void *blob, uint32_t size)
+{
+ struct blob_reader reader;
+ blob_reader_init(&reader, blob, size);
+
+ do {
+ uint32_t part_type = blob_read_uint32(&reader);
+ if (reader.overrun)
+ return false;
+ if (part_type == END_PART)
+ return reader.current == reader.end;
+ switch ((enum driver_cache_blob_part)part_type) {
+ case GEN_PART:
+ case NIR_PART:
+ /* Read the uint32_t part-size and skip over it */
+ blob_skip_bytes(&reader, blob_read_uint32(&reader));
+ if (reader.overrun)
+return false;
+ break;
+ default:
+ return false;
+ }
+ } while (true);
+}
+
+static bool
+blob_has_part(void *blob, uint32_t size, enum driver_cache_blob_part part)
+{
+ struct blob_reader reader;
+ blob_reader_init(&reader, blob, size);
+
+ assert(blob_parts_valid(blob, size));
+ do {
+ uint32_t part_type = blob_read_uint32(&reader);
+ if (part_type == END_PART)
+ return false;
+ if (part_type == part)
+ return true;
+ blob_skip_bytes(&reader, blob_read_uint32(&reader));
+ } while (true);
+}
+
+static bool
+driver_blob_is_ready(void *blob, uint32_t size, bool with_gen_program)
+{
+ if (!blob) {
+ return false;
+ } else if (!blob_parts_valid(blob, size)) {
+ unreachable("Driver blob format is bad!");
+ return false;
+ } else if (blob_has_part(blob, size, GEN_PART) == with_gen_program) {
+ return true;
+ } else {
+ return false;
+ }
+}
+
void
brw_program_serialize_nir(struct gl_context *ctx, struct gl_program *prog)
{
- if (prog->driver_cache_blob)
+ if (driver_blob_is_ready(prog->driver_cache_blob,
+prog->driver_cache_blob_size, false))
return;
+ if (prog->driver_cache_blob)
+ ralloc_free(prog->driver_cache_blob);
+
struct blob writer;
blob_init(&writer);
blob_write_uint32(&writer, NIR_PART);
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/2] radv: Fix up 2_10_10_10 alpha sign.
Slightly OT (not actually radv related), does someone know if this bug
affects pre-gcn gpus and if so which ones?
There's a bug filed against r600 (with Barts) which suspiciously looks
like it's the exact same issue:
https://bugs.freedesktop.org/show_bug.cgi?id=105095
But it works for me (Juniper).
Am 14.05.2018 um 17:47 schrieb Samuel Pitoiset:
>
>
> On 05/14/2018 05:25 PM, Bas Nieuwenhuizen wrote:
>> Pre-Vega HW always interprets the alpha for this format as unsigned,
>> so we have to implement a fixup to do the sign correctly for signed
>> formats.
>>
>> v2: Improve indexing mess.
>>
>
> Bugzilla:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D106480&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0&m=VRC4LtXeDiCAHyOVVUCPMeyB4QgGVayRUsFmgFWKg20&s=91D-0Wtd5R48b9JrfiK6BJsuj8XP6suDqktAi-sqj2s&e=
>
>
> Series is:
>
> Reviewed-by: Samuel Pitoiset
>
> You might need to send a backport for 18.0 since the divisor stuff
> because I'm not sure if this one will apply correctly.
>
>> CC: 18.0 18.1
>> ---
>> src/amd/vulkan/radv_nir_to_llvm.c | 68 ++-
>> src/amd/vulkan/radv_pipeline.c | 30 --
>> src/amd/vulkan/radv_private.h | 1 +
>> src/amd/vulkan/radv_shader.h | 12 ++
>> 4 files changed, 98 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
>> b/src/amd/vulkan/radv_nir_to_llvm.c
>> index f98940f0d8f..47c52dc437b 100644
>> --- a/src/amd/vulkan/radv_nir_to_llvm.c
>> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
>> @@ -1865,6 +1865,47 @@ static LLVMValueRef
>> radv_get_sampler_desc(struct ac_shader_abi *abi,
>> return ac_build_load_to_sgpr(&ctx->ac, list, index);
>> }
>> +/* For 2_10_10_10 formats the alpha is handled as unsigned by
>> pre-vega HW.
>> + * so we may need to fix it up. */
>> +static LLVMValueRef
>> +adjust_vertex_fetch_alpha(struct radv_shader_context *ctx,
>> + unsigned adjustment,
>> + LLVMValueRef alpha)
>> +{
>> + if (adjustment == RADV_ALPHA_ADJUST_NONE)
>> + return alpha;
>> +
>> + LLVMValueRef c30 = LLVMConstInt(ctx->ac.i32, 30, 0);
>> +
>> + if (adjustment == RADV_ALPHA_ADJUST_SSCALED)
>> + alpha = LLVMBuildFPToUI(ctx->ac.builder, alpha, ctx->ac.i32,
>> "");
>> + else
>> + alpha = ac_to_integer(&ctx->ac, alpha);
>> +
>> + /* For the integer-like cases, do a natural sign extension.
>> + *
>> + * For the SNORM case, the values are 0.0, 0.333, 0.666, 1.0
>> + * and happen to contain 0, 1, 2, 3 as the two LSBs of the
>> + * exponent.
>> + */
>> + alpha = LLVMBuildShl(ctx->ac.builder, alpha,
>> + adjustment == RADV_ALPHA_ADJUST_SNORM ?
>> + LLVMConstInt(ctx->ac.i32, 7, 0) : c30, "");
>> + alpha = LLVMBuildAShr(ctx->ac.builder, alpha, c30, "");
>> +
>> + /* Convert back to the right type. */
>> + if (adjustment == RADV_ALPHA_ADJUST_SNORM) {
>> + LLVMValueRef clamp;
>> + LLVMValueRef neg_one = LLVMConstReal(ctx->ac.f32, -1.0);
>> + alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
>> "");
>> + clamp = LLVMBuildFCmp(ctx->ac.builder, LLVMRealULT, alpha,
>> neg_one, "");
>> + alpha = LLVMBuildSelect(ctx->ac.builder, clamp, neg_one,
>> alpha, "");
>> + } else if (adjustment == RADV_ALPHA_ADJUST_SSCALED) {
>> + alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
>> "");
>> + }
>> +
>> + return alpha;
>> +}
>> static void
>> handle_vs_input_decl(struct radv_shader_context *ctx,
>> @@ -1875,18 +1916,19 @@ handle_vs_input_decl(struct
>> radv_shader_context *ctx,
>> LLVMValueRef t_list;
>> LLVMValueRef input;
>> LLVMValueRef buffer_index;
>> - int index = variable->data.location - VERT_ATTRIB_GENERIC0;
>> - int idx = variable->data.location;
>> unsigned attrib_count =
>> glsl_count_attribute_slots(variable->type, true);
>> uint8_t input_usage_mask =
>>
>> ctx->shader_info->info.vs.input_usage_mask[variable->data.location];
>> unsigned num_channels = util_last_bit(input_usage_mask);
>> - variable->data.driver_location = idx * 4;
>> + variable->data.driver_location = variable->data.location * 4;
>> +
>> + for (unsigned i = 0; i < attrib_count; ++i) {
>> + LLVMValueRef output[4];
>> + unsigned attrib_index = variable->data.location + i -
>> VERT_ATTRIB_GENERIC0;
>> - for (unsigned i = 0; i < attrib_count; ++i, ++idx) {
>> - if (ctx->options->key.vs.instance_rate_inputs & (1u << (index
>> + i))) {
>> - uint32_t divisor =
>> ctx->options->key.vs.instance_rate_divisors[index + i];
>> + if (ctx->options->key.vs.instance_rate_inputs & (1u <<
>> attrib_index)) {
>> + uint32_t divisor =
>> ctx->options->key.vs.instance_rate_divisors[attrib_index];
>> if (div
[Mesa-dev] [PATCH mesa 2/2] docs/meson: mention how to use array options
Signed-off-by: Eric Engestrom --- docs/meson.html | 8 1 file changed, 8 insertions(+) diff --git a/docs/meson.html b/docs/meson.html index d05b5fe347b67bad9f8d..c260b703902083045e27 100644 --- a/docs/meson.html +++ b/docs/meson.html @@ -67,6 +67,14 @@ 1. Basic Usage meson configure build/ -Dprefix=/tmp/install -Dglx=true + +Note that options taking lists (such as platforms) are +http://mesonbuild.com/Build-options.html#using-build-options";>a bit +more complicated, but the simplest form compatible with Mesa options +is to use a comma to separate values (-D platforms=drm,wayland) +and brackets to represent an empty list (-D platforms=[]). + + Once you've run the initial meson command successfully you can use your configured backend to build the project. With ninja, the -C option can be -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 1/2] meson: remove "empty array"/"array of an empty string" confusion
Signed-off-by: Eric Engestrom --- meson_options.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meson_options.txt b/meson_options.txt index ce7d87f1ebd74a4ecc2c..b851f086a2b756142d8d 100644 --- a/meson_options.txt +++ b/meson_options.txt @@ -23,7 +23,7 @@ option( type : 'array', value : ['auto'], choices : [ -'', 'auto', 'x11', 'wayland', 'drm', 'surfaceless', 'haiku', 'android', +'auto', 'x11', 'wayland', 'drm', 'surfaceless', 'haiku', 'android', ], description : 'comma separated list of window systems to support. If this is set to auto all platforms applicable to the OS will be enabled.' ) @@ -38,7 +38,7 @@ option( 'dri-drivers', type : 'array', value : ['auto'], - choices : ['', 'auto', 'i915', 'i965', 'r100', 'r200', 'nouveau', 'swrast'], + choices : ['auto', 'i915', 'i965', 'r100', 'r200', 'nouveau', 'swrast'], description : 'List of dri drivers to build. If this is set to auto all drivers applicable to the target OS/architecture will be built' ) option( @@ -58,7 +58,7 @@ option( type : 'array', value : ['auto'], choices : [ -'', 'auto', 'pl111', 'radeonsi', 'r300', 'r600', 'nouveau', 'freedreno', +'auto', 'pl111', 'radeonsi', 'r300', 'r600', 'nouveau', 'freedreno', 'swrast', 'vc4', 'vc5', 'etnaviv', 'imx', 'tegra', 'i915', 'svga', 'virgl', 'swr', ], @@ -152,7 +152,7 @@ option( 'vulkan-drivers', type : 'array', value : ['auto'], - choices : ['', 'auto', 'amd', 'intel'], + choices : ['auto', 'amd', 'intel'], description : 'List of vulkan drivers to build. If this is set to auto all drivers applicable to the target OS/architecture will be built' ) option( -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 4/4] docs/meson: mark code/commands as
Signed-off-by: Eric Engestrom --- docs/meson.html | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/meson.html b/docs/meson.html index 009aebd817057f3e73da..29907a60a9cb02975065 100644 --- a/docs/meson.html +++ b/docs/meson.html @@ -33,7 +33,7 @@ 1. Basic Usage The meson program is used to configure the source directory and generates either a ninja build file or Visual Studio® build files. The latter must -be enabled via the --backend switch, as ninja is the default backend on all +be enabled via the --backend switch, as ninja is the default backend on all operating systems. Meson only supports out-of-tree builds, and must be passed a directory to put built and generated sources into. We'll call that directory "build" for examples. @@ -60,7 +60,7 @@ 1. Basic Usage With additional arguments meson configure is used to change options on already configured build directory. All options passed to this -command are in the form -D "command"="value". +command are in the form -D "command"="value". @@ -122,13 +122,13 @@ 1. Basic Usage CFLAGS=-Wno-typedef-redefinition ninja -C build-clang -Meson also honors DESTDIR for installs +Meson also honors DESTDIR for installs LLVM Meson includes upstream logic to wrap llvm-config using it's standard -dependency interface. It will search $PATH (or %PATH% on windows) for +dependency interface. It will search $PATH (or %PATH% on windows) for llvm-config, so using an LLVM from a non-standard path is as easy as PATH=/path/with/llvm-config:$PATH meson build. @@ -160,13 +160,13 @@ 1. Basic Usage This option will set the compiler debug/optimisation levels to aid debugging the Mesa libraries. -Note that in meson this defaults to "debugoptimized", and not setting it to -"release" will yield non-optimal performance and binary size. Not using "debug" -may interfere with debugging as some code and validation will be optimized -away. +Note that in meson this defaults to debugoptimized, and +not setting it to release will yield non-optimal +performance and binary size. Not using debug may interfere +with debugging as some code and validation will be optimized away. - For those wishing to pass their own optimization flags, use the "plain" + For those wishing to pass their own optimization flags, use the plain buildtype, which causes meson to inject no additional compiler arguments, only those in the C/CXXFLAGS and those that mesa itself defines. @@ -174,7 +174,7 @@ 1. Basic Usage -Db_ndebug -This option controls assertions in meson projects. When set to false +This option controls assertions in meson projects. When set to false (the default) assertions are enabled, when set to true they are disabled. This is unrelated to the buildtype; setting the latter to release will not turn off assertions. -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 3/4] docs/meson: replace plaintext url with a link
Signed-off-by: Eric Engestrom --- docs/meson.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/meson.html b/docs/meson.html index 3c0e3a168b1a706a99be..009aebd817057f3e73da 100644 --- a/docs/meson.html +++ b/docs/meson.html @@ -90,9 +90,9 @@ 1. Basic Usage depending on the options you have chosen. Later, if you want to rebuild for a different configuration, you should run ninja clean before changing the configuration, or create a new out of tree build directory for -each configuration you want to build. - -http://mesonbuild.com/Using-multiple-build-directories.html +each configuration you want to build +http://mesonbuild.com/Using-multiple-build-directories.html";>as +recommended in the documentation -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 2/4] docs/meson: fix various html issues
Signed-off-by: Eric Engestrom --- docs/meson.html | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/meson.html b/docs/meson.html index 841a0d5b9d8d65b71da5..3c0e3a168b1a706a99be 100644 --- a/docs/meson.html +++ b/docs/meson.html @@ -95,6 +95,7 @@ 1. Basic Usage http://mesonbuild.com/Using-multiple-build-directories.html + Environment Variables Meson supports the standard CC and CXX environment variables for changing the default compiler, and CFLAGS, CXXFLAGS, and LDFLAGS for setting @@ -125,7 +126,6 @@ 1. Basic Usage - LLVM Meson includes upstream logic to wrap llvm-config using it's standard dependency interface. It will search $PATH (or %PATH% on windows) for @@ -151,7 +151,7 @@ 1. Basic Usage the meson than to meson configure. These options are passed as --option=foo to meson, but -Doption=foo to meson configure. Mesa defined options are always passed as -Doption=foo. - + For those coming from autotools be aware of the following: @@ -181,3 +181,7 @@ 1. Basic Usage + + + + -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 1/4] docs/meson: fix various typos
Signed-off-by: Eric Engestrom --- docs/meson.html | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/meson.html b/docs/meson.html index c260b703902083045e27..841a0d5b9d8d65b71da5 100644 --- a/docs/meson.html +++ b/docs/meson.html @@ -49,7 +49,7 @@ 1. Basic Usage your meson global arguments and project arguments, along with their defaults and your local settings. -Moes does not currently support listing options before configure a build +Meson does not currently support listing options before configure a build directory, but this feature is being discussed upstream. @@ -96,7 +96,7 @@ 1. Basic Usage Environment Variables -Meson supports the standard CC and CXX envrionment variables for +Meson supports the standard CC and CXX environment variables for changing the default compiler, and CFLAGS, CXXFLAGS, and LDFLAGS for setting options to the compiler and linker. @@ -107,9 +107,9 @@ 1. Basic Usage These arguments are consumed and stored by meson when it is initialized or re-initialized. Therefore passing them to meson configure will not do anything, and passing them to ninja will only do something if ninja decides to -re-initialze meson, for example, if a meson.build file has been changed. +re-initialize meson, for example, if a meson.build file has been changed. Changing these variables will not cause all targets to be rebuilt, so running -ninja clean is recomended when changing CFLAGS or CXXFLAGS. meson will never +ninja clean is recommended when changing CFLAGS or CXXFLAGS. Meson will never change compiler in a configured build directory. @@ -128,7 +128,7 @@ 1. Basic Usage LLVM Meson includes upstream logic to wrap llvm-config using it's standard -dependncy interface. It will search $PATH (or %PATH% on windows) for +dependency interface. It will search $PATH (or %PATH% on windows) for llvm-config, so using an LLVM from a non-standard path is as easy as PATH=/path/with/llvm-config:$PATH meson build. @@ -162,7 +162,7 @@ 1. Basic Usage Note that in meson this defaults to "debugoptimized", and not setting it to "release" will yield non-optimal performance and binary size. Not using "debug" -may interfer with debbugging as some code and validation will be optimized +may interfere with debugging as some code and validation will be optimized away. -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] amd/addrlib: Use defines in autotools build.
Otherwise stuff like NDEBUG would not be passed through. CC: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106479 --- src/amd/Makefile.addrlib.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am index 322a5c86973..75ff7fbcf75 100644 --- a/src/amd/Makefile.addrlib.am +++ b/src/amd/Makefile.addrlib.am @@ -22,6 +22,7 @@ ADDRLIB_LIBS = addrlib/libamdgpu_addrlib.la addrlib_libamdgpu_addrlib_la_CPPFLAGS = \ + $(DEFINES) \ -I$(top_srcdir)/src/ \ -I$(srcdir)/common \ -I$(srcdir)/addrlib \ -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/2] radv: Fix up 2_10_10_10 alpha sign.
On 05/14/2018 05:25 PM, Bas Nieuwenhuizen wrote:
Pre-Vega HW always interprets the alpha for this format as unsigned,
so we have to implement a fixup to do the sign correctly for signed
formats.
v2: Improve indexing mess.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106480
Series is:
Reviewed-by: Samuel Pitoiset
You might need to send a backport for 18.0 since the divisor stuff
because I'm not sure if this one will apply correctly.
CC: 18.0 18.1
---
src/amd/vulkan/radv_nir_to_llvm.c | 68 ++-
src/amd/vulkan/radv_pipeline.c| 30 --
src/amd/vulkan/radv_private.h | 1 +
src/amd/vulkan/radv_shader.h | 12 ++
4 files changed, 98 insertions(+), 13 deletions(-)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index f98940f0d8f..47c52dc437b 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -1865,6 +1865,47 @@ static LLVMValueRef radv_get_sampler_desc(struct
ac_shader_abi *abi,
return ac_build_load_to_sgpr(&ctx->ac, list, index);
}
+/* For 2_10_10_10 formats the alpha is handled as unsigned by pre-vega HW.
+ * so we may need to fix it up. */
+static LLVMValueRef
+adjust_vertex_fetch_alpha(struct radv_shader_context *ctx,
+ unsigned adjustment,
+ LLVMValueRef alpha)
+{
+ if (adjustment == RADV_ALPHA_ADJUST_NONE)
+ return alpha;
+
+ LLVMValueRef c30 = LLVMConstInt(ctx->ac.i32, 30, 0);
+
+ if (adjustment == RADV_ALPHA_ADJUST_SSCALED)
+ alpha = LLVMBuildFPToUI(ctx->ac.builder, alpha, ctx->ac.i32,
"");
+ else
+ alpha = ac_to_integer(&ctx->ac, alpha);
+
+ /* For the integer-like cases, do a natural sign extension.
+*
+* For the SNORM case, the values are 0.0, 0.333, 0.666, 1.0
+* and happen to contain 0, 1, 2, 3 as the two LSBs of the
+* exponent.
+*/
+ alpha = LLVMBuildShl(ctx->ac.builder, alpha,
+adjustment == RADV_ALPHA_ADJUST_SNORM ?
+LLVMConstInt(ctx->ac.i32, 7, 0) : c30, "");
+ alpha = LLVMBuildAShr(ctx->ac.builder, alpha, c30, "");
+
+ /* Convert back to the right type. */
+ if (adjustment == RADV_ALPHA_ADJUST_SNORM) {
+ LLVMValueRef clamp;
+ LLVMValueRef neg_one = LLVMConstReal(ctx->ac.f32, -1.0);
+ alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
"");
+ clamp = LLVMBuildFCmp(ctx->ac.builder, LLVMRealULT, alpha, neg_one,
"");
+ alpha = LLVMBuildSelect(ctx->ac.builder, clamp, neg_one, alpha,
"");
+ } else if (adjustment == RADV_ALPHA_ADJUST_SSCALED) {
+ alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
"");
+ }
+
+ return alpha;
+}
static void
handle_vs_input_decl(struct radv_shader_context *ctx,
@@ -1875,18 +1916,19 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
LLVMValueRef t_list;
LLVMValueRef input;
LLVMValueRef buffer_index;
- int index = variable->data.location - VERT_ATTRIB_GENERIC0;
- int idx = variable->data.location;
unsigned attrib_count = glsl_count_attribute_slots(variable->type,
true);
uint8_t input_usage_mask =
ctx->shader_info->info.vs.input_usage_mask[variable->data.location];
unsigned num_channels = util_last_bit(input_usage_mask);
- variable->data.driver_location = idx * 4;
+ variable->data.driver_location = variable->data.location * 4;
+
+ for (unsigned i = 0; i < attrib_count; ++i) {
+ LLVMValueRef output[4];
+ unsigned attrib_index = variable->data.location + i -
VERT_ATTRIB_GENERIC0;
- for (unsigned i = 0; i < attrib_count; ++i, ++idx) {
- if (ctx->options->key.vs.instance_rate_inputs & (1u << (index +
i))) {
- uint32_t divisor =
ctx->options->key.vs.instance_rate_divisors[index + i];
+ if (ctx->options->key.vs.instance_rate_inputs & (1u <<
attrib_index)) {
+ uint32_t divisor =
ctx->options->key.vs.instance_rate_divisors[attrib_index];
if (divisor) {
buffer_index = LLVMBuildAdd(ctx->ac.builder,
ctx->abi.instance_id,
@@ -1910,7 +1952,7 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
} else
buffer_index = LLVMBuildAdd(ctx->ac.builder,
ctx->abi.vertex_id,
ctx->abi.base_vertex, "");
- t_offset = LLVMConstInt(ctx->ac.i32, index + i, false);
+ t_offset = LLVMConstInt(ctx->ac.i32, attrib_index, false);
t_list = ac_build_load_to_sgpr(&ctx->ac, t_list_ptr, t_offset);
@@ -1923,9 +1965,15 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
for (unsigne
[Mesa-dev] [PATCH v2 1/2] radv: Fix up 2_10_10_10 alpha sign.
Pre-Vega HW always interprets the alpha for this format as unsigned,
so we have to implement a fixup to do the sign correctly for signed
formats.
v2: Improve indexing mess.
CC: 18.0 18.1
---
src/amd/vulkan/radv_nir_to_llvm.c | 68 ++-
src/amd/vulkan/radv_pipeline.c| 30 --
src/amd/vulkan/radv_private.h | 1 +
src/amd/vulkan/radv_shader.h | 12 ++
4 files changed, 98 insertions(+), 13 deletions(-)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index f98940f0d8f..47c52dc437b 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -1865,6 +1865,47 @@ static LLVMValueRef radv_get_sampler_desc(struct
ac_shader_abi *abi,
return ac_build_load_to_sgpr(&ctx->ac, list, index);
}
+/* For 2_10_10_10 formats the alpha is handled as unsigned by pre-vega HW.
+ * so we may need to fix it up. */
+static LLVMValueRef
+adjust_vertex_fetch_alpha(struct radv_shader_context *ctx,
+ unsigned adjustment,
+ LLVMValueRef alpha)
+{
+ if (adjustment == RADV_ALPHA_ADJUST_NONE)
+ return alpha;
+
+ LLVMValueRef c30 = LLVMConstInt(ctx->ac.i32, 30, 0);
+
+ if (adjustment == RADV_ALPHA_ADJUST_SSCALED)
+ alpha = LLVMBuildFPToUI(ctx->ac.builder, alpha, ctx->ac.i32,
"");
+ else
+ alpha = ac_to_integer(&ctx->ac, alpha);
+
+ /* For the integer-like cases, do a natural sign extension.
+*
+* For the SNORM case, the values are 0.0, 0.333, 0.666, 1.0
+* and happen to contain 0, 1, 2, 3 as the two LSBs of the
+* exponent.
+*/
+ alpha = LLVMBuildShl(ctx->ac.builder, alpha,
+adjustment == RADV_ALPHA_ADJUST_SNORM ?
+LLVMConstInt(ctx->ac.i32, 7, 0) : c30, "");
+ alpha = LLVMBuildAShr(ctx->ac.builder, alpha, c30, "");
+
+ /* Convert back to the right type. */
+ if (adjustment == RADV_ALPHA_ADJUST_SNORM) {
+ LLVMValueRef clamp;
+ LLVMValueRef neg_one = LLVMConstReal(ctx->ac.f32, -1.0);
+ alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
"");
+ clamp = LLVMBuildFCmp(ctx->ac.builder, LLVMRealULT, alpha,
neg_one, "");
+ alpha = LLVMBuildSelect(ctx->ac.builder, clamp, neg_one, alpha,
"");
+ } else if (adjustment == RADV_ALPHA_ADJUST_SSCALED) {
+ alpha = LLVMBuildSIToFP(ctx->ac.builder, alpha, ctx->ac.f32,
"");
+ }
+
+ return alpha;
+}
static void
handle_vs_input_decl(struct radv_shader_context *ctx,
@@ -1875,18 +1916,19 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
LLVMValueRef t_list;
LLVMValueRef input;
LLVMValueRef buffer_index;
- int index = variable->data.location - VERT_ATTRIB_GENERIC0;
- int idx = variable->data.location;
unsigned attrib_count = glsl_count_attribute_slots(variable->type,
true);
uint8_t input_usage_mask =
ctx->shader_info->info.vs.input_usage_mask[variable->data.location];
unsigned num_channels = util_last_bit(input_usage_mask);
- variable->data.driver_location = idx * 4;
+ variable->data.driver_location = variable->data.location * 4;
+
+ for (unsigned i = 0; i < attrib_count; ++i) {
+ LLVMValueRef output[4];
+ unsigned attrib_index = variable->data.location + i -
VERT_ATTRIB_GENERIC0;
- for (unsigned i = 0; i < attrib_count; ++i, ++idx) {
- if (ctx->options->key.vs.instance_rate_inputs & (1u << (index +
i))) {
- uint32_t divisor =
ctx->options->key.vs.instance_rate_divisors[index + i];
+ if (ctx->options->key.vs.instance_rate_inputs & (1u <<
attrib_index)) {
+ uint32_t divisor =
ctx->options->key.vs.instance_rate_divisors[attrib_index];
if (divisor) {
buffer_index = LLVMBuildAdd(ctx->ac.builder,
ctx->abi.instance_id,
@@ -1910,7 +1952,7 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
} else
buffer_index = LLVMBuildAdd(ctx->ac.builder,
ctx->abi.vertex_id,
ctx->abi.base_vertex, "");
- t_offset = LLVMConstInt(ctx->ac.i32, index + i, false);
+ t_offset = LLVMConstInt(ctx->ac.i32, attrib_index, false);
t_list = ac_build_load_to_sgpr(&ctx->ac, t_list_ptr, t_offset);
@@ -1923,9 +1965,15 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
for (unsigned chan = 0; chan < 4; chan++) {
LLVMValueRef llvm_chan = LLVMConstInt(ctx->ac.i32,
chan, false);
- ctx->inputs[ac_llvm_reg_index_soa(idx, chan)] =
- ac_to_integer(&ctx->ac,
LL
[Mesa-dev] [PATCH v2 2/2] radv: Disable texel buffers with A2 SNORM/SSCALED/SINT for pre-vega.
The hardware always interprets the alpha as unsigned and fixing it
in the shader is going to add unacceptable overheads.
CC: 18.0 18.1
---
src/amd/vulkan/radv_formats.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index f8438f43b85..1ac07b41a61 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -657,6 +657,25 @@ radv_physical_device_get_format_properties(struct
radv_physical_device *physical
tiled |= VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT;
}
+ switch(format) {
+ case VK_FORMAT_A2R10G10B10_SNORM_PACK32:
+ case VK_FORMAT_A2B10G10R10_SNORM_PACK32:
+ case VK_FORMAT_A2R10G10B10_SSCALED_PACK32:
+ case VK_FORMAT_A2B10G10R10_SSCALED_PACK32:
+ case VK_FORMAT_A2R10G10B10_SINT_PACK32:
+ case VK_FORMAT_A2B10G10R10_SINT_PACK32:
+ if (physical_device->rad_info.chip_class <= VI &&
+ physical_device->rad_info.family != CHIP_STONEY) {
+ buffer &= ~(VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT |
+ VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT);
+ linear = 0;
+ tiled = 0;
+ }
+ break;
+ default:
+ break;
+ }
+
out_properties->linearTilingFeatures = linear;
out_properties->optimalTilingFeatures = tiled;
out_properties->bufferFeatures = buffer;
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] vc4: use util_copy_framebuffer_state
Rob Clark writes: > On Mon, May 14, 2018 at 9:16 AM, Rob Clark wrote: >> Signed-off-by: Rob Clark >> --- >> Just happened to notice that vc4/vc5 was open-coding >> util_copy_framebuffer_state() > > and ofc if I actually managed to test-compile what I *thought* I was > compiling, I would have noticed the missing #include and unused > variable warning, both of which fixed up locally Assuming it compiles, Reviewed-by: Eric Anholt Thanks! 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] autotools, meson: add tileset.h
On Mon, 2018-05-14 at 15:37 +0100, Eric Engestrom wrote:
> On Monday, 2018-05-14 16:02:02 +0200, Juan A. Suarez Romero wrote:
> > On Mon, 2018-05-14 at 14:09 +0100, Eric Engestrom wrote:
> > > On Monday, 2018-05-14 13:53:37 +0200, Juan A. Suarez Romero wrote:
> > > > Fixes: 4e52cb51b5 ("swr/rast: Thread locked tiles improvement")
> > > > ---
> > > > src/gallium/drivers/swr/Makefile.sources | 1 +
> > > > src/gallium/drivers/swr/meson.build | 3 ++-
> > > > 2 files changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/gallium/drivers/swr/Makefile.sources
> > > > b/src/gallium/drivers/swr/Makefile.sources
> > > > index a06d1d7b929..6753d501a0d 100644
> > > > --- a/src/gallium/drivers/swr/Makefile.sources
> > > > +++ b/src/gallium/drivers/swr/Makefile.sources
> > > > @@ -132,6 +132,7 @@ CORE_CXX_SOURCES := \
> > > > rasterizer/core/threads.h \
> > > > rasterizer/core/tilemgr.cpp \
> > > > rasterizer/core/tilemgr.h \
> > > > + rasterizer/core/tileset.h \
> > > > rasterizer/core/utils.h
> > > >
> > > > JITTER_CXX_SOURCES := \
> > > > diff --git a/src/gallium/drivers/swr/meson.build
> > > > b/src/gallium/drivers/swr/meson.build
> > > > index 575133def56..5b3b53d0acf 100644
> > > > --- a/src/gallium/drivers/swr/meson.build
> > > > +++ b/src/gallium/drivers/swr/meson.build
> > > > @@ -1,4 +1,4 @@
> > > > -# Copyright © 2017-2018 Intel Corporation
> > > > +# Copyright © 2017-2018 Intel Corporation
> > >
> > > You should probably revert that before pushing your commit :)
> > >
> > > >
> > > > # Permission is hereby granted, free of charge, to any person
> > > > obtaining a copy
> > > > # of this software and associated documentation files (the
> > > > "Software"), to deal
> > > > @@ -131,6 +131,7 @@ files_swr_arch = files(
> > > >'rasterizer/core/threads.h',
> > > >'rasterizer/core/tilemgr.cpp',
> > > >'rasterizer/core/tilemgr.h',
> > > > + 'rasterizer/core/tileset.h',
> > >
> > > Meson tracks #includes, so adding this is actually a noop, but for
> > > consistency let's add it in for now.
> > >
> >
> > Ah, nice! That explains why it wasn't failing with Meson.
> >
> >
> > > Reviewed-by: Eric Engestrom
> > >
> > > Dylan, what do you think? Do we want to remove all the unnecessary
> > > files() from meson, or keep them to mirror what was needed by autotools?
> > > I'd vote 'remove', but the "let's do the same thing everywhere" argument
> > > is valid; what do people think?
> >
> > I would also remove them. I don't see any reason to mirror what autotools
> > do.
> > The simpler it is, the better. After all, IIUC scons doesn't mirror
> > autotools
> > neither.
>
> I think scons imports the file lists from autotools' Makefile.sources ?
>
Ah, you're right. In any case, my vote would be 'remove', as yours.
J.A.
> >
> >
> > J.A.
> >
> > >
> > > >'rasterizer/core/utils.h',
> > > >'rasterizer/memory/ClearTile.cpp',
> > > >'rasterizer/memory/Convert.h',
> > > > --
> > > > 2.17.0
> > > >
> > >
> > >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 16/21] nir/linker: Add nir_build_program_resource_list()
On 14/05/18 01:26, Timothy Arceri wrote:
> On 12/05/18 19:40, Alejandro Piñeiro wrote:
>> From: Eduardo Lima Mitev
>>
>> This function is equivalent to the linker.cpp
>> build_program_resource_list() but will extract the resources from NIR
>> shaders instead.
>>
>> For now, only uniforms and program inputs are implemented.
>>
>> v2: move from compiler/nir to compiler/glsl (Timothy Arceri)
>>
>> Signed-off-by: Eduardo Lima
>> Signed-off-by: Alejandro Piñeiro
>> ---
>> src/compiler/Makefile.sources | 1 +
>> src/compiler/glsl/gl_nir_linker.c | 93
>> +++
>> src/compiler/glsl/gl_nir_linker.h | 3 ++
>> src/compiler/glsl/meson.build | 1 +
>> 4 files changed, 98 insertions(+)
>> create mode 100644 src/compiler/glsl/gl_nir_linker.c
>>
>> diff --git a/src/compiler/Makefile.sources
>> b/src/compiler/Makefile.sources
>> index 8104dd32002..409252ee587 100644
>> --- a/src/compiler/Makefile.sources
>> +++ b/src/compiler/Makefile.sources
>> @@ -30,6 +30,7 @@ LIBGLSL_FILES = \
>> glsl/gl_nir_lower_samplers_as_deref.c \
>> glsl/gl_nir_link_uniform_initializers.c \
>> glsl/gl_nir_link_uniforms.c \
>> + glsl/gl_nir_linker.c \
>> glsl/gl_nir_linker.h \
>> glsl/gl_nir.h \
>> glsl/glsl_parser_extras.cpp \
>> diff --git a/src/compiler/glsl/gl_nir_linker.c
>> b/src/compiler/glsl/gl_nir_linker.c
>> new file mode 100644
>> index 000..155d94ef966
>> --- /dev/null
>> +++ b/src/compiler/glsl/gl_nir_linker.c
>> @@ -0,0 +1,93 @@
>> +/*
>> + * Copyright © 2018 Intel Corporation
>> + *
>> + * Permission is hereby granted, free of charge, to any person
>> obtaining a
>> + * copy of this software and associated documentation files (the
>> "Software"),
>> + * to deal in the Software without restriction, including without
>> limitation
>> + * the rights to use, copy, modify, merge, publish, distribute,
>> sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom
>> the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including
>> the next
>> + * paragraph) shall be included in all copies or substantial
>> portions of the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
>> EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
>> OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> OTHER DEALINGS
>> + * IN THE SOFTWARE.
>> + */
>> +
>> +#include "nir.h"
>> +#include "gl_nir_linker.h"
>> +#include "linker_util.h"
>> +#include "main/mtypes.h"
>> +#include "ir_uniform.h" /* for gl_uniform_storage */
>> +
>> +/* This file included general link methods, using NIR, instead of IR as
>> + * the counter-part glsl/linker.cpp
>> + *
>> + * Also note that this is tailored for ARB_gl_spirv needs and
>> particularities
>> + */
>> +
>> +void
>> +nir_build_program_resource_list(struct gl_context *ctx,
>> + struct gl_shader_program *prog)
>> +{
>> + /* Rebuild resource list. */
>> + if (prog->data->ProgramResourceList) {
>> + ralloc_free(prog->data->ProgramResourceList);
>> + prog->data->ProgramResourceList = NULL;
>> + prog->data->NumProgramResourceList = 0;
>> + }
>> +
>> + struct set *resource_set = _mesa_set_create(NULL,
>> + _mesa_hash_pointer,
>> +
>> _mesa_key_pointer_equal);
>> +
>> + /* Add uniforms
>> + *
>> + * Here, it is expected that nir_link_uniforms() has already been
>> + * called, so that UniformStorage table is already available.
>> + */
>> + for (unsigned i = 0; i < prog->data->NumUniformStorage; i++) {
>> + struct gl_uniform_storage *uniform =
>> &prog->data->UniformStorage[i];
>> +
>> + if (!link_util_add_program_resource(prog, resource_set,
>> GL_UNIFORM, uniform,
>> +
>> uniform->active_shader_mask)) {
>> + return;
>> + }
>> + }
>> +
>> + /* Add inputs */
>> + struct gl_linked_shader *sh =
>> prog->_LinkedShaders[MESA_SHADER_VERTEX];
>> + if (sh) {
>> + nir_shader *nir = sh->Program->nir;
>> + assert(nir);
>> +
>> + nir_foreach_variable(var, &nir->inputs) {
>> + struct gl_shader_variable *sh_var =
>> + rzalloc(prog, struct gl_shader_variable);
>> +
>> + /* ARB_gl_spirv: names are considered optional debug info,
>> so the linker
>> + * needs to work without them, and returning them is
>> optional. For
>> + * simplicity we ignore names.
>> + */
>> + sh_var->name
Re: [Mesa-dev] Mesa (18.1): Bump version to rc4
On 2018-05-11 07:19 PM, Dylan Baker wrote: > Quoting Michel Dänzer (2018-05-11 09:55:23) >> >> Hi Dylan, >> >> >> any reason for not picking 6f81e07ecb8c0793dc482307d5d96fd3df95b7d2 >> "dri3: Only update number of back buffers in loader_dri3_get_buffers" >> for rc4? > > Hi Michel, > > That patch is present in rc4 as 312c2f047e5ce7fe277d34d7d99b9945c60f4e60. Excellent, thanks! Not sure how I missed that, sorry for the noise. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radv: check that layout isn't NULL in radv_nir_shader_info_pass()
Reviewed-by: Bas Nieuwenhuizen for the series. On Mon, May 14, 2018 at 4:04 PM, Samuel Pitoiset wrote: > An upcoming patch will run the shader info pass on the > geometry shader just before emitting the GS copy shader. > > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_shader_info.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/amd/vulkan/radv_shader_info.c > b/src/amd/vulkan/radv_shader_info.c > index aa06efc9dc7..a436bd75343 100644 > --- a/src/amd/vulkan/radv_shader_info.c > +++ b/src/amd/vulkan/radv_shader_info.c > @@ -424,7 +424,7 @@ 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->dynamic_offset_count) > + if (options->layout && options->layout->dynamic_offset_count) > info->loads_push_constants = true; > > nir_foreach_variable(variable, &nir->inputs) > -- > 2.17.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: remove aux_vertex_buffer_slot code
Hi Marek, On 2018-05-10 06:21 PM, Marek Olšák wrote: > From: Marek Olšák > > The slot index is always 0, and is pretty unlikely to change in the future. This change caused dozens of piglit tests to crash for me, see an example below from tests/spec/gl-3.1/attributeless-vertexid.shader_test. Happens both with radeonsi and llvmpipe. Thread 1 "shader_runner" received signal SIGSEGV, Segmentation fault. pipe_reference_described (get_desc=, reference=0x1e, ptr=0x0) at ../../../../src/gallium/auxiliary/util/u_inlines.h:82 82 assert(pipe_is_referenced(reference)); (gdb) bt #0 pipe_reference_described (get_desc=, reference=0x1e, ptr=0x0) at ../../../../src/gallium/auxiliary/util/u_inlines.h:82 #1 pipe_resource_reference (tex=0x1e, ptr=0x559d76c0) at ../../../../src/gallium/auxiliary/util/u_inlines.h:138 #2 pipe_vertex_buffer_reference (src=0x7fffd870, dst=0x559d76b8) at ../../../../src/gallium/auxiliary/util/u_inlines.h:215 #3 cso_set_vertex_buffers (ctx=0x559d6080, start_slot=0, count=0, buffers=0x7fffd870) at ../../../../src/gallium/auxiliary/cso_cache/cso_context.c:1159 #4 0x703833f2 in set_vertex_attribs (st=0x559bfe30, st=0x559bfe30, num_velements=0, velements=0x7fffd770, num_vbuffers=0, vbuffers=0x7fffd870) at ../../../src/mesa/state_tracker/st_atom_array.c:375 #5 st_update_array (st=) at ../../../src/mesa/state_tracker/st_atom_array.c:507 #6 0x703845e2 in st_validate_state (st=st@entry=0x559bfe30, pipeline=pipeline@entry=ST_PIPELINE_RENDER) at ../../../src/mesa/state_tracker/st_atom.c:261 #7 0x703a9d29 in prepare_draw (ctx=0x559a2e20, ctx=0x559a2e20, st=) at ../../../src/mesa/state_tracker/st_draw.c:123 #8 st_draw_vbo (ctx=0x559a2e20, prims=0x7fffdff0, nr_prims=1, ib=0x0, index_bounds_valid=, min_index=, max_index=, tfb_vertcount=0x0, stream=0, indirect=0x0) at ../../../src/mesa/state_tracker/st_draw.c:149 #9 0x70361d80 in vbo_draw_arrays (ctx=0x559a2e20, mode=6, start=0, count=4, numInstances=1, baseInstance=0, drawID=0) at ../../../src/mesa/vbo/vbo_exec_array.c:391 #10 0x703627a4 in vbo_exec_DrawArrays (mode=6, start=0, count=4) at ../../../src/mesa/vbo/vbo_exec_array.c:550 #11 0x77a9e13b in stub_glDrawArrays (mode=6, first=0, count=4) at tests/util/piglit-dispatch-gen.c:12150 #12 0x55563367 in piglit_display () at tests/shaders/shader_runner.c:3137 #13 0x77b3142d in run_test (gl_fw=0x55783070, argc=2, argv=0x7fffe658) at tests/util/piglit-framework-gl/piglit_fbo_framework.c:52 #14 0x77b17511 in piglit_gl_test_run (argc=2, argv=0x7fffe658, config=0x7fffe510) at tests/util/piglit-framework-gl.c:229 #15 0xb59b in main (argc=2, argv=0x7fffe658) at tests/shaders/shader_runner.c:63 -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 4/5] meson: fix platforms=[]
On Friday, 2018-05-11 08:54:13 -0700, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-05-11 07:12:29)
> > Fixes: 5608d0a2cee47c7d037f ("meson: use array type options")
> > Signed-off-by: Eric Engestrom
> > ---
> > meson.build | 26 +++---
> > 1 file changed, 11 insertions(+), 15 deletions(-)
> >
> > diff --git a/meson.build b/meson.build
> > index a8999f37bd06a84cf7c0..5dd5168eb95dc823bbbe 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -231,12 +231,6 @@ else
> >with_dri_platform = 'none'
> > endif
> >
> > -with_platform_android = false
> > -with_platform_wayland = false
> > -with_platform_x11 = false
> > -with_platform_drm = false
> > -with_platform_surfaceless = false
> > -egl_native_platform = ''
> > _platforms = get_option('platforms')
> > if _platforms.contains('auto')
> >if system_has_kms_drm
> > @@ -249,13 +243,15 @@ if _platforms.contains('auto')
> > error('Unknown OS. Please pass -Dplatforms to set platforms. Patches
> > gladly accepted to fix this.')
> >endif
> > endif
> > -if _platforms != ['']
> > - with_platform_android = _platforms.contains('android')
> > - with_platform_x11 = _platforms.contains('x11')
> > - with_platform_wayland = _platforms.contains('wayland')
> > - with_platform_drm = _platforms.contains('drm')
> > - with_platform_haiku = _platforms.contains('haiku')
> > - with_platform_surfaceless = _platforms.contains('surfaceless')
> > +
> > +with_platform_android = _platforms.contains('android')
> > +with_platform_x11 = _platforms.contains('x11')
> > +with_platform_wayland = _platforms.contains('wayland')
> > +with_platform_drm = _platforms.contains('drm')
> > +with_platform_haiku = _platforms.contains('haiku')
> > +with_platform_surfaceless = _platforms.contains('surfaceless')
> > +
>
> > +if _platforms.length() != 0
> >egl_native_platform = _platforms[0]
> > endif
>
> This isn't going to work, since if you set -Dplatforms=, then _platforms will
> ==
> ['']
Ah, good catch :/
That said, I just realised that the core of the issue is that
meson_options.txt allows empty strings for the array options; would you
be ok with this patch, to avoid having to keep trying to make both
concepts behave the same?
---8<---
diff --git a/meson_options.txt b/meson_options.txt
index ce7d87f1ebd74a4ecc2c..b851f086a2b756142d8d 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -23,7 +23,7 @@ option(
type : 'array',
value : ['auto'],
choices : [
-'', 'auto', 'x11', 'wayland', 'drm', 'surfaceless', 'haiku', 'android',
+'auto', 'x11', 'wayland', 'drm', 'surfaceless', 'haiku', 'android',
],
description : 'comma separated list of window systems to support. If this is
set to auto all platforms applicable to the OS will be enabled.'
)
@@ -38,7 +38,7 @@ option(
'dri-drivers',
type : 'array',
value : ['auto'],
- choices : ['', 'auto', 'i915', 'i965', 'r100', 'r200', 'nouveau', 'swrast'],
+ choices : ['auto', 'i915', 'i965', 'r100', 'r200', 'nouveau', 'swrast'],
description : 'List of dri drivers to build. If this is set to auto all
drivers applicable to the target OS/architecture will be built'
)
option(
@@ -58,7 +58,7 @@ option(
type : 'array',
value : ['auto'],
choices : [
-'', 'auto', 'pl111', 'radeonsi', 'r300', 'r600', 'nouveau', 'freedreno',
+'auto', 'pl111', 'radeonsi', 'r300', 'r600', 'nouveau', 'freedreno',
'swrast', 'vc4', 'vc5', 'etnaviv', 'imx', 'tegra', 'i915', 'svga', 'virgl',
'swr',
],
@@ -152,7 +152,7 @@ option(
'vulkan-drivers',
type : 'array',
value : ['auto'],
- choices : ['', 'auto', 'amd', 'intel'],
+ choices : ['auto', 'amd', 'intel'],
description : 'List of vulkan drivers to build. If this is set to auto all
drivers applicable to the target OS/architecture will be built'
)
option(
--->8---
>
> >
> > @@ -298,13 +294,13 @@ endif
> >
> > _egl = get_option('egl')
> > if _egl == 'auto'
> > - with_egl = with_dri and with_shared_glapi and egl_native_platform != ''
> > + with_egl = with_dri and with_shared_glapi and _platforms.length() != 0
> > elif _egl == 'true'
> >if not with_dri
> > error('EGL requires dri')
> >elif not with_shared_glapi
> > error('EGL requires shared-glapi')
> > - elif egl_native_platform == ''
> > + elif _platforms.length() == 0
> > error('No platforms specified, consider -Dplatforms=drm,x11 at least')
> >elif not ['disabled', 'dri'].contains(with_glx)
> > error('EGL requires dri, but a GLX is being built without dri')
>
> Same for all of these.
>
> Dylan
>
> > --
> > Cheers,
> > Eric
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools, meson: add tileset.h
On Monday, 2018-05-14 16:02:02 +0200, Juan A. Suarez Romero wrote:
> On Mon, 2018-05-14 at 14:09 +0100, Eric Engestrom wrote:
> > On Monday, 2018-05-14 13:53:37 +0200, Juan A. Suarez Romero wrote:
> > > Fixes: 4e52cb51b5 ("swr/rast: Thread locked tiles improvement")
> > > ---
> > > src/gallium/drivers/swr/Makefile.sources | 1 +
> > > src/gallium/drivers/swr/meson.build | 3 ++-
> > > 2 files changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/gallium/drivers/swr/Makefile.sources
> > > b/src/gallium/drivers/swr/Makefile.sources
> > > index a06d1d7b929..6753d501a0d 100644
> > > --- a/src/gallium/drivers/swr/Makefile.sources
> > > +++ b/src/gallium/drivers/swr/Makefile.sources
> > > @@ -132,6 +132,7 @@ CORE_CXX_SOURCES := \
> > > rasterizer/core/threads.h \
> > > rasterizer/core/tilemgr.cpp \
> > > rasterizer/core/tilemgr.h \
> > > + rasterizer/core/tileset.h \
> > > rasterizer/core/utils.h
> > >
> > > JITTER_CXX_SOURCES := \
> > > diff --git a/src/gallium/drivers/swr/meson.build
> > > b/src/gallium/drivers/swr/meson.build
> > > index 575133def56..5b3b53d0acf 100644
> > > --- a/src/gallium/drivers/swr/meson.build
> > > +++ b/src/gallium/drivers/swr/meson.build
> > > @@ -1,4 +1,4 @@
> > > -# Copyright © 2017-2018 Intel Corporation
> > > +# Copyright © 2017-2018 Intel Corporation
> >
> > You should probably revert that before pushing your commit :)
> >
> > >
> > > # Permission is hereby granted, free of charge, to any person obtaining
> > > a copy
> > > # of this software and associated documentation files (the "Software"),
> > > to deal
> > > @@ -131,6 +131,7 @@ files_swr_arch = files(
> > >'rasterizer/core/threads.h',
> > >'rasterizer/core/tilemgr.cpp',
> > >'rasterizer/core/tilemgr.h',
> > > + 'rasterizer/core/tileset.h',
> >
> > Meson tracks #includes, so adding this is actually a noop, but for
> > consistency let's add it in for now.
> >
>
> Ah, nice! That explains why it wasn't failing with Meson.
>
>
> > Reviewed-by: Eric Engestrom
> >
> > Dylan, what do you think? Do we want to remove all the unnecessary
> > files() from meson, or keep them to mirror what was needed by autotools?
> > I'd vote 'remove', but the "let's do the same thing everywhere" argument
> > is valid; what do people think?
>
> I would also remove them. I don't see any reason to mirror what autotools do.
> The simpler it is, the better. After all, IIUC scons doesn't mirror autotools
> neither.
I think scons imports the file lists from autotools' Makefile.sources ?
>
>
> J.A.
>
> >
> > >'rasterizer/core/utils.h',
> > >'rasterizer/memory/ClearTile.cpp',
> > >'rasterizer/memory/Convert.h',
> > > --
> > > 2.17.0
> > >
> >
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] docs: add 18.0.5 in the release calendar
Mesa 18.1 series has not been released yet, so let's extend 18.0 lifetime. v2: Add missing closing TR tags (Eric Engestrom) CC: Andres Gomez CC: Emil Velikov --- docs/release-calendar.html | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/release-calendar.html b/docs/release-calendar.html index e4e1a1e61ff..49f4300d381 100644 --- a/docs/release-calendar.html +++ b/docs/release-calendar.html @@ -37,11 +37,18 @@ if you'd like to nominate a patch in the next stable release. Release Release manager Notes + -18.0 +18.0 2018-05-18 18.0.4 Juan A. Suarez Romero + + + +2018-06-01 +18.0.5 +Juan A. Suarez Romero Last planned 18.0.x release -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] threading in OSMesa and gallium swr driver
Hello, Sorry for the inconvenience if this message is not appropriate for this mailing list. The following is a question for developers of the swr driver of gallium. I am the main developer of a motion graphics application. Our application internally has a dependency graph where each node may run concurrently. We use OpenGL extensively in the implementation of the nodes (for example with Shadertoy). Our application has 2 main requirements: - A GPU backend, mainly for user interaction and fast results - A CPU backend for batch rendering Internally we use OSMesa for CPU backend so that our code is mostly identical for both GPU and CPU paths. However when it comes to CPU, our application is heavily multi-threaded: each processing node can potentially run in parallel of others as a dependency graph. We use Intel TBB to schedule the CPU threads. For each actual hardware thread (not task) we allocate a new OSMesa context so that we can freely multi-thread operators rendering. It works fine with llvmpipe and also SWR so far (with a patch to fix some static variables inside state_trackers/osmesa.c). However with SWR using its own thread pool, I’m afraid of over-threading, introducing a bottleneck in threads scheduling e.g: on a 32 cores processor, we already have lets say 24 threads busy on a TBB task on each core with 1 OSMesa context. I looked at the code and all those concurrent OSMesa contexts will create a SWR context and each will try to initialise its own thread pool in CreateThreadPool in swr/rasterizer/core/api.cpp Is there a way to have a single “static” thread-pool shared across all contexts ? Thank you Alexandre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 2/5] meson: fix gallium-drivers=[]
On Friday, 2018-05-11 08:48:34 -0700, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-05-11 07:12:27)
> > Fixes: 5608d0a2cee47c7d037f ("meson: use array type options")
> > Signed-off-by: Eric Engestrom
> > ---
> > meson.build | 73 +++--
> > 1 file changed, 32 insertions(+), 41 deletions(-)
> >
> > diff --git a/meson.build b/meson.build
> > index afebfd2c65fdb22dae29..6b069ae5dfc52adba1b7 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -123,23 +123,6 @@ with_dri = (with_dri_i915 or with_dri_i965 or
> > with_dri_r100 or with_dri_r200 or
> > with_dri_nouveau or with_dri_swrast)
> >
> > -with_gallium = false
> > -with_gallium_pl111 = false
> > -with_gallium_radeonsi = false
> > -with_gallium_r300 = false
> > -with_gallium_r600 = false
> > -with_gallium_nouveau = false
> > -with_gallium_freedreno = false
> > -with_gallium_softpipe = false
> > -with_gallium_vc4 = false
> > -with_gallium_vc5 = false
> > -with_gallium_etnaviv = false
> > -with_gallium_imx = false
> > -with_gallium_tegra = false
> > -with_gallium_i915 = false
> > -with_gallium_svga = false
> > -with_gallium_virgl = false
> > -with_gallium_swr = false
> > _drivers = get_option('gallium-drivers')
> > if _drivers.contains('auto')
> >if system_has_kms_drm
> > @@ -162,30 +145,38 @@ if _drivers.contains('auto')
> > error('Unknown OS. Please pass -Dgallium-drivers to set driver
> > options. Patches gladly accepted to fix this.')
> >endif
> > endif
> > -if _drivers != ['']
> > - with_gallium_pl111 = _drivers.contains('pl111')
> > - with_gallium_radeonsi = _drivers.contains('radeonsi')
> > - with_gallium_r300 = _drivers.contains('r300')
> > - with_gallium_r600 = _drivers.contains('r600')
> > - with_gallium_nouveau = _drivers.contains('nouveau')
> > - with_gallium_freedreno = _drivers.contains('freedreno')
> > - with_gallium_softpipe = _drivers.contains('swrast')
> > - with_gallium_vc4 = _drivers.contains('vc4')
> > - with_gallium_vc5 = _drivers.contains('vc5')
> > - with_gallium_etnaviv = _drivers.contains('etnaviv')
> > - with_gallium_imx = _drivers.contains('imx')
> > - with_gallium_tegra = _drivers.contains('tegra')
> > - with_gallium_i915 = _drivers.contains('i915')
> > - with_gallium_svga = _drivers.contains('svga')
> > - with_gallium_virgl = _drivers.contains('virgl')
> > - with_gallium_swr = _drivers.contains('swr')
> > - with_gallium = true
> > - if system_has_kms_drm
> > -_glx = get_option('glx')
> > -_egl = get_option('egl')
> > -if _glx == 'dri' or _egl == 'true' or (_glx == 'disabled' and _egl !=
> > 'false')
> > - with_dri = true
> > -endif
> > +
> > +with_gallium_pl111 = _drivers.contains('pl111')
> > +with_gallium_radeonsi = _drivers.contains('radeonsi')
> > +with_gallium_r300 = _drivers.contains('r300')
> > +with_gallium_r600 = _drivers.contains('r600')
> > +with_gallium_nouveau = _drivers.contains('nouveau')
> > +with_gallium_freedreno = _drivers.contains('freedreno')
> > +with_gallium_softpipe = _drivers.contains('swrast')
> > +with_gallium_vc4 = _drivers.contains('vc4')
> > +with_gallium_vc5 = _drivers.contains('vc5')
> > +with_gallium_etnaviv = _drivers.contains('etnaviv')
> > +with_gallium_imx = _drivers.contains('imx')
> > +with_gallium_tegra = _drivers.contains('tegra')
> > +with_gallium_i915 = _drivers.contains('i915')
> > +with_gallium_svga = _drivers.contains('svga')
> > +with_gallium_virgl = _drivers.contains('virgl')
> > +with_gallium_swr = _drivers.contains('swr')
> > +
> > +with_gallium = (with_gallium_pl111 or with_gallium_radeonsi or
> > +with_gallium_r300 or with_gallium_r600 or
> > +with_gallium_nouveau or with_gallium_freedreno or
> > +with_gallium_softpipe or with_gallium_vc4 or
> > +with_gallium_vc5 or with_gallium_etnaviv or
> > +with_gallium_imx or with_gallium_tegra or
> > +with_gallium_i915 or with_gallium_svga or
> > +with_gallium_virgl or with_gallium_swr)
>
> This could be simplified to this, right?
> with_gallium = _drivers != ['']
No, because `gallium-drivers=[]` would match as `with_gallium` :/
I suppose I could just add both cases to the check though?
What I don't like about it is that there could be unhandled cases there,
but now that we're using array options, at least 'random/typo'd string'
is no longer an issue; I guess we can assume that any name allowed in
meson_options.txt is gonna be handled in meson.build as well.
Should I do that in v2? `!=[] && !=['']` ?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Bump minor
Bump xa minor to signal that the underlying mesa version is suitable for dri3.
This is a bit ugly since it doesn't relate to a specific xa interface change.
Recently there has been a number of fixes in mesa that helps enabling dri3
without any significant regressions in automated testing and common desktop
usage latency. However, the xf86-video-vmware driver has no other way to tell
but inspecting the xa version.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
configure.ac | 2 +-
src/gallium/state_trackers/xa/meson.build | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 35ade98..a9babec 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2969,7 +2969,7 @@ AC_SUBST([XVMC_MAJOR], 1)
AC_SUBST([XVMC_MINOR], 0)
AC_SUBST([XA_MAJOR], 2)
-AC_SUBST([XA_MINOR], 3)
+AC_SUBST([XA_MINOR], 4)
AC_SUBST([XA_PATCH], 0)
AC_SUBST([XA_VERSION], "$XA_MAJOR.$XA_MINOR.$XA_PATCH")
diff --git a/src/gallium/state_trackers/xa/meson.build
b/src/gallium/state_trackers/xa/meson.build
index 109abc1..aff3963 100644
--- a/src/gallium/state_trackers/xa/meson.build
+++ b/src/gallium/state_trackers/xa/meson.build
@@ -18,7 +18,7 @@
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
-xa_version = ['2', '3', '0']
+xa_version = ['2', '4', '0']
xa_conf = configuration_data()
xa_conf.set('XA_MAJOR', xa_version[0])
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] radv: check that layout isn't NULL in radv_nir_shader_info_pass()
An upcoming patch will run the shader info pass on the geometry shader just before emitting the GS copy shader. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_shader_info.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_shader_info.c b/src/amd/vulkan/radv_shader_info.c index aa06efc9dc7..a436bd75343 100644 --- a/src/amd/vulkan/radv_shader_info.c +++ b/src/amd/vulkan/radv_shader_info.c @@ -424,7 +424,7 @@ 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->dynamic_offset_count) + if (options->layout && options->layout->dynamic_offset_count) info->loads_push_constants = true; nir_foreach_variable(variable, &nir->inputs) -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] radv: run the shader info pass before emitting the GS copy shader
For further optimizations. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_nir_to_llvm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/amd/vulkan/radv_nir_to_llvm.c b/src/amd/vulkan/radv_nir_to_llvm.c index f98940f0d8f..a8af32b58f3 100644 --- a/src/amd/vulkan/radv_nir_to_llvm.c +++ b/src/amd/vulkan/radv_nir_to_llvm.c @@ -3501,6 +3501,8 @@ radv_compile_gs_copy_shader(LLVMTargetMachineRef tm, ctx.ac.builder = ac_create_builder(ctx.context, float_mode); ctx.stage = MESA_SHADER_VERTEX; + radv_nir_shader_info_pass(geom_shader, options, &shader_info->info); + create_function(&ctx, MESA_SHADER_VERTEX, false, MESA_SHADER_VERTEX); ctx.gs_max_out_vertices = geom_shader->info.gs.vertices_out; -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] radv: scan the geometry shader output usage mask
For reducing the number of parameters that are exported by
the GS copy shader.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.h | 3 +++
src/amd/vulkan/radv_shader_info.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/src/amd/vulkan/radv_shader.h b/src/amd/vulkan/radv_shader.h
index 12878307ecd..c5d5694dca5 100644
--- a/src/amd/vulkan/radv_shader.h
+++ b/src/amd/vulkan/radv_shader.h
@@ -145,6 +145,9 @@ struct radv_shader_info {
bool needs_draw_id;
bool needs_instance_id;
} vs;
+ struct {
+ uint8_t output_usage_mask[VARYING_SLOT_VAR31 + 1];
+ } gs;
struct {
uint8_t output_usage_mask[VARYING_SLOT_VAR31 + 1];
} tes;
diff --git a/src/amd/vulkan/radv_shader_info.c
b/src/amd/vulkan/radv_shader_info.c
index a436bd75343..b45b4c0c95b 100644
--- a/src/amd/vulkan/radv_shader_info.c
+++ b/src/amd/vulkan/radv_shader_info.c
@@ -134,6 +134,12 @@ gather_intrinsic_store_var_info(const nir_shader *nir,
instr->const_index[0] << comp;
}
break;
+ case MESA_SHADER_GEOMETRY:
+ for (unsigned i = 0; i < attrib_count; i++) {
+ info->gs.output_usage_mask[idx + i +
const_offset] |=
+ instr->const_index[0] << comp;
+ }
+ break;
case MESA_SHADER_TESS_EVAL:
for (unsigned i = 0; i < attrib_count; i++) {
info->tes.output_usage_mask[idx + i +
const_offset] |=
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] radv: reduce the number of parameters export by the GS copy shader
By using the geometry shader output usage mask.
This improves all Vulkan demos that use a geometry shader
(ie. geometryshader, deferredshadows, viewportarray).
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_nir_to_llvm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index a8af32b58f3..51de94dd468 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -2445,10 +2445,9 @@ handle_vs_outputs_post(struct radv_shader_context *ctx,
output_usage_mask =
ctx->shader_info->info.tes.output_usage_mask[i];
} else {
- /* Enable all channels for the GS copy shader because
-* we don't know the output usage mask currently.
-*/
- output_usage_mask = 0xf;
+ assert(ctx->is_gs_copy_shader);
+ output_usage_mask =
+ ctx->shader_info->info.gs.output_usage_mask[i];
}
radv_export_param(ctx, param_count, values, output_usage_mask);
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] vc4: use util_copy_framebuffer_state
On Mon, May 14, 2018 at 9:16 AM, Rob Clark wrote: > Signed-off-by: Rob Clark > --- > Just happened to notice that vc4/vc5 was open-coding > util_copy_framebuffer_state() and ofc if I actually managed to test-compile what I *thought* I was compiling, I would have noticed the missing #include and unused variable warning, both of which fixed up locally BR, -R > > src/gallium/drivers/vc4/vc4_state.c | 12 +--- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git a/src/gallium/drivers/vc4/vc4_state.c > b/src/gallium/drivers/vc4/vc4_state.c > index f8c37818499..abce68916b0 100644 > --- a/src/gallium/drivers/vc4/vc4_state.c > +++ b/src/gallium/drivers/vc4/vc4_state.c > @@ -418,17 +418,7 @@ vc4_set_framebuffer_state(struct pipe_context *pctx, > > vc4->job = NULL; > > -for (i = 0; i < framebuffer->nr_cbufs; i++) > -pipe_surface_reference(&cso->cbufs[i], > framebuffer->cbufs[i]); > -for (; i < vc4->framebuffer.nr_cbufs; i++) > -pipe_surface_reference(&cso->cbufs[i], NULL); > - > -cso->nr_cbufs = framebuffer->nr_cbufs; > - > -pipe_surface_reference(&cso->zsbuf, framebuffer->zsbuf); > - > -cso->width = framebuffer->width; > -cso->height = framebuffer->height; > +util_copy_framebuffer_state(cso, framebuffer); > > /* Nonzero texture mipmap levels are laid out as if they were in > * power-of-two-sized spaces. The renderbuffer config infers its > -- > 2.17.0 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools, meson: add tileset.h
On Mon, 2018-05-14 at 14:09 +0100, Eric Engestrom wrote:
> On Monday, 2018-05-14 13:53:37 +0200, Juan A. Suarez Romero wrote:
> > Fixes: 4e52cb51b5 ("swr/rast: Thread locked tiles improvement")
> > ---
> > src/gallium/drivers/swr/Makefile.sources | 1 +
> > src/gallium/drivers/swr/meson.build | 3 ++-
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/swr/Makefile.sources
> > b/src/gallium/drivers/swr/Makefile.sources
> > index a06d1d7b929..6753d501a0d 100644
> > --- a/src/gallium/drivers/swr/Makefile.sources
> > +++ b/src/gallium/drivers/swr/Makefile.sources
> > @@ -132,6 +132,7 @@ CORE_CXX_SOURCES := \
> > rasterizer/core/threads.h \
> > rasterizer/core/tilemgr.cpp \
> > rasterizer/core/tilemgr.h \
> > + rasterizer/core/tileset.h \
> > rasterizer/core/utils.h
> >
> > JITTER_CXX_SOURCES := \
> > diff --git a/src/gallium/drivers/swr/meson.build
> > b/src/gallium/drivers/swr/meson.build
> > index 575133def56..5b3b53d0acf 100644
> > --- a/src/gallium/drivers/swr/meson.build
> > +++ b/src/gallium/drivers/swr/meson.build
> > @@ -1,4 +1,4 @@
> > -# Copyright © 2017-2018 Intel Corporation
> > +# Copyright © 2017-2018 Intel Corporation
>
> You should probably revert that before pushing your commit :)
>
> >
> > # Permission is hereby granted, free of charge, to any person obtaining a
> > copy
> > # of this software and associated documentation files (the "Software"), to
> > deal
> > @@ -131,6 +131,7 @@ files_swr_arch = files(
> >'rasterizer/core/threads.h',
> >'rasterizer/core/tilemgr.cpp',
> >'rasterizer/core/tilemgr.h',
> > + 'rasterizer/core/tileset.h',
>
> Meson tracks #includes, so adding this is actually a noop, but for
> consistency let's add it in for now.
>
Ah, nice! That explains why it wasn't failing with Meson.
> Reviewed-by: Eric Engestrom
>
> Dylan, what do you think? Do we want to remove all the unnecessary
> files() from meson, or keep them to mirror what was needed by autotools?
> I'd vote 'remove', but the "let's do the same thing everywhere" argument
> is valid; what do people think?
I would also remove them. I don't see any reason to mirror what autotools do.
The simpler it is, the better. After all, IIUC scons doesn't mirror autotools
neither.
J.A.
>
> >'rasterizer/core/utils.h',
> >'rasterizer/memory/ClearTile.cpp',
> >'rasterizer/memory/Convert.h',
> > --
> > 2.17.0
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: add 18.0.5 in the release calendar
On Monday, 2018-05-14 11:34:43 +0200, Juan A. Suarez Romero wrote: > Mesa 18.1 series has not been released yet, so let's extend 18.0 lifetime. > > CC: Andres Gomez > CC: Emil Velikov > --- > docs/release-calendar.html | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/docs/release-calendar.html b/docs/release-calendar.html > index e4e1a1e61ff..b0df36a8954 100644 > --- a/docs/release-calendar.html > +++ b/docs/release-calendar.html > @@ -38,10 +38,15 @@ if you'd like to nominate a patch in the next stable > release. > Release manager > Notes > > -18.0 > +18.0 > 2018-05-18 > 18.0.4 > Juan A. Suarez Romero > + You're missing a here... and I just realised it's also missing from the row above (just under `Notes`) > + > +2018-06-01 > +18.0.5 > +Juan A. Suarez Romero > Last planned 18.0.x release > > > -- > 2.17.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] vc5: use util_copy_framebuffer_state
Signed-off-by: Rob Clark --- src/gallium/drivers/vc5/vc5_state.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/src/gallium/drivers/vc5/vc5_state.c b/src/gallium/drivers/vc5/vc5_state.c index 42ae64157c4..27c9f78a0e9 100644 --- a/src/gallium/drivers/vc5/vc5_state.c +++ b/src/gallium/drivers/vc5/vc5_state.c @@ -445,17 +445,7 @@ vc5_set_framebuffer_state(struct pipe_context *pctx, vc5->job = NULL; -for (i = 0; i < framebuffer->nr_cbufs; i++) -pipe_surface_reference(&cso->cbufs[i], framebuffer->cbufs[i]); -for (; i < vc5->framebuffer.nr_cbufs; i++) -pipe_surface_reference(&cso->cbufs[i], NULL); - -cso->nr_cbufs = framebuffer->nr_cbufs; - -pipe_surface_reference(&cso->zsbuf, framebuffer->zsbuf); - -cso->width = framebuffer->width; -cso->height = framebuffer->height; +util_copy_framebuffer_state(cso, framebuffer); vc5->swap_color_rb = 0; vc5->blend_dst_alpha_one = 0; -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] vc4: use util_copy_framebuffer_state
Signed-off-by: Rob Clark --- Just happened to notice that vc4/vc5 was open-coding util_copy_framebuffer_state() src/gallium/drivers/vc4/vc4_state.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/src/gallium/drivers/vc4/vc4_state.c b/src/gallium/drivers/vc4/vc4_state.c index f8c37818499..abce68916b0 100644 --- a/src/gallium/drivers/vc4/vc4_state.c +++ b/src/gallium/drivers/vc4/vc4_state.c @@ -418,17 +418,7 @@ vc4_set_framebuffer_state(struct pipe_context *pctx, vc4->job = NULL; -for (i = 0; i < framebuffer->nr_cbufs; i++) -pipe_surface_reference(&cso->cbufs[i], framebuffer->cbufs[i]); -for (; i < vc4->framebuffer.nr_cbufs; i++) -pipe_surface_reference(&cso->cbufs[i], NULL); - -cso->nr_cbufs = framebuffer->nr_cbufs; - -pipe_surface_reference(&cso->zsbuf, framebuffer->zsbuf); - -cso->width = framebuffer->width; -cso->height = framebuffer->height; +util_copy_framebuffer_state(cso, framebuffer); /* Nonzero texture mipmap levels are laid out as if they were in * power-of-two-sized spaces. The renderbuffer config infers its -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: handle a bunch of formats in IMPLEMENTATION_COLOR_READ_*
Virgl could save a lot of work converting buffers in the host side
between formats if Mesa supported a bunch of other formats when reading
pixels.
This commit adds cases to handle specific formats so that the values
reported by the two calls match more closely the underlying native
formats.
In GLES is important that IMPLEMENTATION_COLOR_READ_* return the native
format and data type because the spec only allows reading with those,
besides GL_RGBA or GL_RGBA_INTEGER.
Additionally, because virgl currently doesn't implement such conversions,
this commit fixes several tests in
dEQP-GLES3.functional.fbo.color.clear.*, when using virgl in the guest
side.
Signed-off-by: Tomeu Vizoso
---
src/mesa/main/framebuffer.c | 73 -
1 file changed, 64 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 8e751b453b75..a22c66b349f2 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -836,15 +836,43 @@ _mesa_get_color_read_format(struct gl_context *ctx,
const mesa_format format = fb->_ColorReadBuffer->Format;
const GLenum data_type = _mesa_get_format_datatype(format);
- if (format == MESA_FORMAT_B8G8R8A8_UNORM)
+ switch(format) {
+ case MESA_FORMAT_B8G8R8A8_UNORM:
return GL_BGRA;
- else if (format == MESA_FORMAT_B5G6R5_UNORM)
+ case MESA_FORMAT_R10G10B10A2_UINT:
+ return GL_BGRA_INTEGER;
+ case MESA_FORMAT_B5G6R5_UNORM:
+ case MESA_FORMAT_R11G11B10_FLOAT:
return GL_RGB;
- else if (format == MESA_FORMAT_R_UNORM8)
+ case MESA_FORMAT_RG_FLOAT32:
+ case MESA_FORMAT_RG_FLOAT16:
+ case MESA_FORMAT_R8G8_UNORM:
+ return GL_RG;
+ case MESA_FORMAT_RG_SINT32:
+ case MESA_FORMAT_RG_UINT32:
+ case MESA_FORMAT_RG_SINT16:
+ case MESA_FORMAT_RG_UINT16:
+ case MESA_FORMAT_RG_SINT8:
+ case MESA_FORMAT_RG_UINT8:
+ return GL_RG_INTEGER;
+ case MESA_FORMAT_R_FLOAT32:
+ case MESA_FORMAT_R_FLOAT16:
+ case MESA_FORMAT_R_UNORM8:
return GL_RED;
+ case MESA_FORMAT_R_SINT32:
+ case MESA_FORMAT_R_UINT32:
+ case MESA_FORMAT_R_SINT16:
+ case MESA_FORMAT_R_UINT16:
+ case MESA_FORMAT_R_SINT8:
+ case MESA_FORMAT_R_UINT8:
+ return GL_RED_INTEGER;
+ default:
+ break;
+ }
switch (data_type) {
case GL_UNSIGNED_INT:
+ case GL_UNSIGNED_BYTE:
case GL_INT:
return GL_RGBA_INTEGER;
default:
@@ -885,14 +913,41 @@ _mesa_get_color_read_type(struct gl_context *ctx,
const GLenum format = fb->_ColorReadBuffer->Format;
const GLenum data_type = _mesa_get_format_datatype(format);
- if (format == MESA_FORMAT_B5G6R5_UNORM)
+ switch(format) {
+ case MESA_FORMAT_B5G6R5_UNORM:
return GL_UNSIGNED_SHORT_5_6_5;
-
- if (format == MESA_FORMAT_B10G10R10A2_UNORM ||
- format == MESA_FORMAT_B10G10R10X2_UNORM ||
- format == MESA_FORMAT_R10G10B10A2_UNORM ||
- format == MESA_FORMAT_R10G10B10X2_UNORM)
+ case MESA_FORMAT_B10G10R10A2_UNORM:
+ case MESA_FORMAT_B10G10R10X2_UNORM:
+ case MESA_FORMAT_R10G10B10A2_UNORM:
+ case MESA_FORMAT_R10G10B10X2_UNORM:
+ case MESA_FORMAT_B10G10R10A2_UINT:
+ case MESA_FORMAT_R10G10B10A2_UINT:
return GL_UNSIGNED_INT_2_10_10_10_REV;
+ case MESA_FORMAT_R11G11B10_FLOAT:
+ return GL_UNSIGNED_INT_10F_11F_11F_REV;
+ case MESA_FORMAT_RGBA_FLOAT16:
+ case MESA_FORMAT_RG_FLOAT16:
+ case MESA_FORMAT_R_FLOAT16:
+ return GL_HALF_FLOAT;
+ case MESA_FORMAT_RGBA_SINT16:
+ case MESA_FORMAT_RG_SINT16:
+ case MESA_FORMAT_R_SINT16:
+ return GL_SHORT;
+ case MESA_FORMAT_RGBA_UINT16:
+ case MESA_FORMAT_RG_UINT16:
+ case MESA_FORMAT_R_UINT16:
+ return GL_UNSIGNED_SHORT;
+ case MESA_FORMAT_RGBA_SINT8:
+ case MESA_FORMAT_RG_SINT8:
+ case MESA_FORMAT_R_SINT8:
+ return GL_BYTE;
+ case MESA_FORMAT_RG_UINT8:
+ case MESA_FORMAT_RGBA_UINT8:
+ case MESA_FORMAT_R_UINT8:
+ return GL_UNSIGNED_BYTE;
+ default:
+ break;
+ }
switch (data_type) {
case GL_SIGNED_NORMALIZED:
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools, meson: add tileset.h
On Monday, 2018-05-14 13:53:37 +0200, Juan A. Suarez Romero wrote:
> Fixes: 4e52cb51b5 ("swr/rast: Thread locked tiles improvement")
> ---
> src/gallium/drivers/swr/Makefile.sources | 1 +
> src/gallium/drivers/swr/meson.build | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/swr/Makefile.sources
> b/src/gallium/drivers/swr/Makefile.sources
> index a06d1d7b929..6753d501a0d 100644
> --- a/src/gallium/drivers/swr/Makefile.sources
> +++ b/src/gallium/drivers/swr/Makefile.sources
> @@ -132,6 +132,7 @@ CORE_CXX_SOURCES := \
> rasterizer/core/threads.h \
> rasterizer/core/tilemgr.cpp \
> rasterizer/core/tilemgr.h \
> + rasterizer/core/tileset.h \
> rasterizer/core/utils.h
>
> JITTER_CXX_SOURCES := \
> diff --git a/src/gallium/drivers/swr/meson.build
> b/src/gallium/drivers/swr/meson.build
> index 575133def56..5b3b53d0acf 100644
> --- a/src/gallium/drivers/swr/meson.build
> +++ b/src/gallium/drivers/swr/meson.build
> @@ -1,4 +1,4 @@
> -# Copyright © 2017-2018 Intel Corporation
> +# Copyright © 2017-2018 Intel Corporation
You should probably revert that before pushing your commit :)
>
> # Permission is hereby granted, free of charge, to any person obtaining a
> copy
> # of this software and associated documentation files (the "Software"), to
> deal
> @@ -131,6 +131,7 @@ files_swr_arch = files(
>'rasterizer/core/threads.h',
>'rasterizer/core/tilemgr.cpp',
>'rasterizer/core/tilemgr.h',
> + 'rasterizer/core/tileset.h',
Meson tracks #includes, so adding this is actually a noop, but for
consistency let's add it in for now.
Reviewed-by: Eric Engestrom
Dylan, what do you think? Do we want to remove all the unnecessary
files() from meson, or keep them to mirror what was needed by autotools?
I'd vote 'remove', but the "let's do the same thing everywhere" argument
is valid; what do people think?
>'rasterizer/core/utils.h',
>'rasterizer/memory/ClearTile.cpp',
>'rasterizer/memory/Convert.h',
> --
> 2.17.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] autotools, meson: add tileset.h
Fixes: 4e52cb51b5 ("swr/rast: Thread locked tiles improvement")
---
src/gallium/drivers/swr/Makefile.sources | 1 +
src/gallium/drivers/swr/meson.build | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/Makefile.sources
b/src/gallium/drivers/swr/Makefile.sources
index a06d1d7b929..6753d501a0d 100644
--- a/src/gallium/drivers/swr/Makefile.sources
+++ b/src/gallium/drivers/swr/Makefile.sources
@@ -132,6 +132,7 @@ CORE_CXX_SOURCES := \
rasterizer/core/threads.h \
rasterizer/core/tilemgr.cpp \
rasterizer/core/tilemgr.h \
+ rasterizer/core/tileset.h \
rasterizer/core/utils.h
JITTER_CXX_SOURCES := \
diff --git a/src/gallium/drivers/swr/meson.build
b/src/gallium/drivers/swr/meson.build
index 575133def56..5b3b53d0acf 100644
--- a/src/gallium/drivers/swr/meson.build
+++ b/src/gallium/drivers/swr/meson.build
@@ -1,4 +1,4 @@
-# Copyright © 2017-2018 Intel Corporation
+# Copyright © 2017-2018 Intel Corporation
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
@@ -131,6 +131,7 @@ files_swr_arch = files(
'rasterizer/core/threads.h',
'rasterizer/core/tilemgr.cpp',
'rasterizer/core/tilemgr.h',
+ 'rasterizer/core/tileset.h',
'rasterizer/core/utils.h',
'rasterizer/memory/ClearTile.cpp',
'rasterizer/memory/Convert.h',
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: make eglWaitClient behave like glFinish
On 14.05.2018 10:03, Eric Anholt wrote: Tapani Pälli writes: As defined by the spec: "All rendering calls for the currently bound context, for the current rendering API, made prior to eglWaitClient, are guaranteed to be executed before native rendering calls made after eglWaitClient which affect the read or draw surfaces associated with that context. The same result can be achieved using client API-specific calls such as glFinish or vgFinish." v2: call glFinish() to ensure identical behaviour Signed-off-by: Tapani Pälli Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106337 I don't think the operation they're doing there is "native rendering" as far as EGL is concerned. I think the backend flush is the right thing for us to be calling here, same as glXWaitGL(). If they want glFinish(), they should be calling glFinish(). Hmm ok .. the problem is that they do CPU read on the buffer which is not "native rendering" but it seemed to me something that native API could also attempt to do. I'm OK with 'just use glFinish' also. // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: Fix random number generation for unit tests
Hi Roland,
It's indeed been long time since I wrote this and I'm no longer certain
of what I intended to do, but the change looks overall.
Reviewed-by: Jose Fonseca
But is it really true rand returns 63 bits? I think it return RAND_MAX,
which was actually often 31 bits. Perhaps we should add some static
asserts in there.
BTW, it would be nice to replace `(unsigned long long)1` with 1ULL in
this code while we're at it. I'm not sure if this was due to some MSVC
limitation or thinko, but 1ULL should work everywhere and is much
shorter and readable.
Jose
On 08/05/18 00:21, srol...@vmware.com wrote:
From: Roland Scheidegger
We were never producing negative numbers for signed types.
Also fix only producing half the valid range for uint32, and
properly clamp signed values.
Because this now also properly tests snorm with actually negative
values, need to increase eps for such conversions. I believe these
cannot actually be hit in ordinary operation (e.g. if a snorm texture
is sampled and output to snorm RT, it will still go through snorm->float
and float->snorm conversion), so don't bother to do anything to fix
the bad accuracy (might be quite complex).
Basically, the issue is for something like snorm16->snorm8 that in the
end this will just use a 8 bit arithmetic right shift.
But the math behind it says we should actually do a division by 32767 / 127,
which
is ~258, not 256. So the result can be one bit off (values have too large
magnitude), and furthermore, the shift has incorrect rounding (always rounds
down). For positive numbers, these errors have different direction, but
for negative ones they have the same, hence for some values the error will
be 2 bit in the end.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106232
---
src/gallium/drivers/llvmpipe/lp_test_conv.c | 8
src/gallium/drivers/llvmpipe/lp_test_main.c | 13 +++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_test_conv.c
b/src/gallium/drivers/llvmpipe/lp_test_conv.c
index 6e58a03..a4f313a 100644
--- a/src/gallium/drivers/llvmpipe/lp_test_conv.c
+++ b/src/gallium/drivers/llvmpipe/lp_test_conv.c
@@ -211,6 +211,14 @@ test_one(unsigned verbose,
assert(src_type.length * num_srcs == dst_type.length * num_dsts);
eps = MAX2(lp_const_eps(src_type), lp_const_eps(dst_type));
+ if (dst_type.norm && dst_type.sign && src_type.sign && !src_type.floating) {
+ /*
+ * This is quite inaccurate due to shift being used.
+ * I don't think it's possible to hit such conversions with
+ * llvmpipe though.
+ */
+ eps *= 2;
+ }
context = LLVMContextCreate();
gallivm = gallivm_create("test_module", context);
diff --git a/src/gallium/drivers/llvmpipe/lp_test_main.c
b/src/gallium/drivers/llvmpipe/lp_test_main.c
index 518ca27..5ec0dd3 100644
--- a/src/gallium/drivers/llvmpipe/lp_test_main.c
+++ b/src/gallium/drivers/llvmpipe/lp_test_main.c
@@ -147,6 +147,7 @@ write_elem(struct lp_type type, void *dst, unsigned index,
double value)
if(type.sign) {
long long lvalue = (long long)value;
lvalue = MIN2(lvalue, ((long long)1 << (type.width - 1)) - 1);
+ lvalue = MAX2(lvalue, -((long long)1 << (type.width - 1)));
switch(type.width) {
case 8:
*((int8_t *)dst + index) = (int8_t)lvalue;
@@ -200,16 +201,24 @@ random_elem(struct lp_type type, void *dst, unsigned
index)
}
else {
unsigned long long mask;
-if (type.fixed)
+ if (type.fixed)
mask = ((unsigned long long)1 << (type.width / 2)) - 1;
else if (type.sign)
mask = ((unsigned long long)1 << (type.width - 1)) - 1;
else
mask = ((unsigned long long)1 << type.width) - 1;
value += (double)(mask & rand());
+ if (!type.fixed && !type.sign && type.width == 32) {
+/*
+ * rand only returns half the possible range
+ * XXX 64bit values...
+ */
+if(rand() & 1)
+ value += (double)0x8000;
+ }
}
}
- if(!type.sign)
+ if(type.sign)
if(rand() & 1)
value = -value;
write_elem(type, dst, index, value);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
