[Mesa-dev] [Bug 105098] [RADV] GPU freeze with simple Vulkan App
https://bugs.freedesktop.org/show_bug.cgi?id=105098 --- Comment #7 from Adrià Cereto i Massagué --- The same behaviour can be observed on my Vega 56 when trying to run some games through DXVK. I'll try the patch to see whether it fixes it in that case too. -- 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] Adding a SPIR-V target to libclc
Jan Vesely writes: > On Thu, 2018-02-15 at 20:36 -0800, Francisco Jerez wrote: >> Jan Vesely writes: >> >> > On Thu, 2018-02-08 at 15:56 -0800, Francisco Jerez wrote: >> > > Jan Vesely writes: >> > > >> > > > On Thu, 2018-02-08 at 23:16 +0100, Pierre Moreau wrote: >> > > > > (Moving the conversation to its own thread.) >> > > > > >> > > > > > target agnostic libclc is rather difficult to do. CLC includes 3 >> > > > > > levels >> > > > > > of precision on float (fp32) operands; full, half, native. The >> > > > > > implementation of each depends on capabilites of specific device >> > > > > > (e.g. >> > > > > > vega(VI+?) can do 1 ULP log2/exp2 in hw, other targets need sw >> > > > > > implementation to meet CLC requirement of 3ulp). Any conversion >> > > > > > backend >> > > > > > would thus need to implement sw versions of math builtins for >> > > > > > targets >> > > > > > that can't perform the op in HW. >> > > > > >> > > > > My initial thought for the target agnostic libclc, was to just >> > > > > provide some >> > > > > (fake?) implementations of OpenCL built-in functions to make clang >> > > > > happy and >> > > > > let me compile kernels using “get_global_id()”, as well as include >> > > > > headers >> > > > > defining OpenCL specific types like “float4” or others. If there is >> > > > > another >> > > > > (better?) way to achieve this, I am all ears. (There is probably >> > > > > one, as I had >> > > > > no issues when using the Khronos LLVM/clang fork rather than Tomeu’s >> > > > > out-of-tree module, the former having also some bits and pieces in >> > > > > clang.) >> > > > >> > > > I don't think you need libclc for this. workitem IDs are >> > > > platform/device specific, and iiuc SPIR-V builtins should handle it in >> > > > an abstract way [0]. any conversion consuming SPIR-V needs to replace >> > > > those with device/platform specific way of obtaining the information. >> > > > you can also use clang's clc header to provide data types [1]. >> > > > >> > > > >> > > > [0] https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#B >> > > > uiltIn >> > > > [1] https://github.com/llvm-mirror/clang/blob/master/lib/Headers/opencl >> > > > -c.h >> > > > >> > > > > >> > > > > > Extending the current libclc to provide target specific SPIR-V >> > > > > > binaries >> > > > > > in addition to/in place of LLVM IR is rather straightforward. >> > > > > > Adding >> > > > > > additional targets it's more work since it relies on clang to >> > > > > > support >> > > > > > those targets. >> > > > > >> > > > > I’m curious how those target specific SPIR-V binaries would look >> > > > > like. I can >> > > > > imagine how some functions like “OpSign” could be implemented using >> > > > > other >> > > > > SPIR-V functions, but how would you handle something like >> > > > > “get_local_id()”? If >> > > > > you define it as the built-in “LocalInvocationId” and don’t supply an >> > > > > implementation of it, then you lose the target specificness. On the >> > > > > other hand, >> > > > > if you want to keep it device-specific, how would you express that >> > > > > in SPIR-V? >> > > > >> > > > getting IDs is not a problem. SPIR-V should provide builtins for that. >> > > > >> > > > The problem I had in mind is when SPIR-V binary calls e.g. exp2(). You >> > > > can either assume that the op needs CLC precision (3 ulp), or device >> > > > native precision. >> > > >> > > That's up to the SPIR-V extended instruction set specification to define >> > > what precision the exp2 built-in is supposed to have. >> > > >> > > > SPIR-V binary can also call exp2(fp64), which does not have an >> > > > equivalent GPU instruction. >> > > >> > > Then it should probably be lowered by the SPIR-V front-end, right? >> > >> > I'm not sure what you mean by "spir-v frontend". If it's the tool that >> > generates SPIR-V, then no, not really. >> >> No, I meant the SPIR-V front-end of the driver (or whatever translation >> pass in control of the driver is translating machine-agnostic SPIR-V >> into some other more hardware-specific representation of the program). > > OK. my question still stands. How does generic SPIR-V based libclc > help the process? > That I can think of now, it would remove the need for maintaining any target-specific knowledge in libclc, for plumbing target-specific information in order to select the right libclc flavour at link time, and it would allow solving common problems in a place where there is a chance that the solution could be shared among different drivers and APIs (e.g. the exp2(fp64) lowering example you mentioned earlier is not exclusively useful to CL). > Jan > >> >> > My understanding is that those are run prior to application >> > distribution, and therefore have no information about the target HW. >> > >> > So if a program imports "CLC.std.11" extended instruction set to get >> > access CLC builtin functions. What would a generic SPIR-V libclc >> > provide? >>
Re: [Mesa-dev] Adding a SPIR-V target to libclc
On Thu, 2018-02-15 at 20:36 -0800, Francisco Jerez wrote: > Jan Vesely writes: > > > On Thu, 2018-02-08 at 15:56 -0800, Francisco Jerez wrote: > > > Jan Vesely writes: > > > > > > > On Thu, 2018-02-08 at 23:16 +0100, Pierre Moreau wrote: > > > > > (Moving the conversation to its own thread.) > > > > > > > > > > > target agnostic libclc is rather difficult to do. CLC includes 3 > > > > > > levels > > > > > > of precision on float (fp32) operands; full, half, native. The > > > > > > implementation of each depends on capabilites of specific device > > > > > > (e.g. > > > > > > vega(VI+?) can do 1 ULP log2/exp2 in hw, other targets need sw > > > > > > implementation to meet CLC requirement of 3ulp). Any conversion > > > > > > backend > > > > > > would thus need to implement sw versions of math builtins for > > > > > > targets > > > > > > that can't perform the op in HW. > > > > > > > > > > My initial thought for the target agnostic libclc, was to just > > > > > provide some > > > > > (fake?) implementations of OpenCL built-in functions to make clang > > > > > happy and > > > > > let me compile kernels using “get_global_id()”, as well as include > > > > > headers > > > > > defining OpenCL specific types like “float4” or others. If there is > > > > > another > > > > > (better?) way to achieve this, I am all ears. (There is probably one, > > > > > as I had > > > > > no issues when using the Khronos LLVM/clang fork rather than Tomeu’s > > > > > out-of-tree module, the former having also some bits and pieces in > > > > > clang.) > > > > > > > > I don't think you need libclc for this. workitem IDs are > > > > platform/device specific, and iiuc SPIR-V builtins should handle it in > > > > an abstract way [0]. any conversion consuming SPIR-V needs to replace > > > > those with device/platform specific way of obtaining the information. > > > > you can also use clang's clc header to provide data types [1]. > > > > > > > > > > > > [0] https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#B > > > > uiltIn > > > > [1] https://github.com/llvm-mirror/clang/blob/master/lib/Headers/opencl > > > > -c.h > > > > > > > > > > > > > > > Extending the current libclc to provide target specific SPIR-V > > > > > > binaries > > > > > > in addition to/in place of LLVM IR is rather straightforward. Adding > > > > > > additional targets it's more work since it relies on clang to > > > > > > support > > > > > > those targets. > > > > > > > > > > I’m curious how those target specific SPIR-V binaries would look > > > > > like. I can > > > > > imagine how some functions like “OpSign” could be implemented using > > > > > other > > > > > SPIR-V functions, but how would you handle something like > > > > > “get_local_id()”? If > > > > > you define it as the built-in “LocalInvocationId” and don’t supply an > > > > > implementation of it, then you lose the target specificness. On the > > > > > other hand, > > > > > if you want to keep it device-specific, how would you express that in > > > > > SPIR-V? > > > > > > > > getting IDs is not a problem. SPIR-V should provide builtins for that. > > > > > > > > The problem I had in mind is when SPIR-V binary calls e.g. exp2(). You > > > > can either assume that the op needs CLC precision (3 ulp), or device > > > > native precision. > > > > > > That's up to the SPIR-V extended instruction set specification to define > > > what precision the exp2 built-in is supposed to have. > > > > > > > SPIR-V binary can also call exp2(fp64), which does not have an > > > > equivalent GPU instruction. > > > > > > Then it should probably be lowered by the SPIR-V front-end, right? > > > > I'm not sure what you mean by "spir-v frontend". If it's the tool that > > generates SPIR-V, then no, not really. > > No, I meant the SPIR-V front-end of the driver (or whatever translation > pass in control of the driver is translating machine-agnostic SPIR-V > into some other more hardware-specific representation of the program). OK. my question still stands. How does generic SPIR-V based libclc help the process? Jan > > > My understanding is that those are run prior to application > > distribution, and therefore have no information about the target HW. > > > > So if a program imports "CLC.std.11" extended instruction set to get > > access CLC builtin functions. What would a generic SPIR-V libclc > > provide? > > > > > > > > > It's easier to translate these to libclc function calls (combined with > > > > the right library implementation of the exp2 builtin), than try to > > > > generate exp2 algorithm when converting to NIR (or anything else > > > > really). > > > > > > > > > > But the SPIR-V front-end will need to lower that in terms of > > > instructions supported by the back-end anyway in order to be able to > > > handle general SPIR-V shaders as input, right? So why re-implement the > > > lowering for those operations in libclc in a way that's only going to be > > > useful for t
Re: [Mesa-dev] [PATCH 05/13] vbo: Implement method to track the inputs array.
Hi Brian, Thanks for the review so far! Two comments/questions below: On Friday, 16 February 2018 00:27:16 CET Brian Paul wrote: > > +/** > > + * Initialize inputs. > > + */ > > +void > > +_vbo_array_init(struct vbo_inputs *inputs); > > + > > + > > +/** > > + * Update the gl_vertex_array array inside the vbo_inputs structure > > + * provided the current _VPMode, the provided vao and > > + * the vao's enabled arrays filtered by the filter bitmask. > > + */ > > +void > > +_vbo_update_inputs(struct gl_context *ctx, struct vbo_inputs *inputs); > > If that struct and the two prototypes aren't going to be used outside > the VBO module, they should go into vbo_private.h Well, currently yes. But in a later step I plan to push the gl_vertex_array[] thing into the backend drivers, switch over the individual drivers to direct _DrawVAO use and fade out that vbo_inputs struct for most drivers. Remember the binding information present in the VAO struct shall be reused without rescanning the inputs where they stem from. Consequently, the tool functions here will be called from those individual driver that will still use the gl_vertex_array struct and those drivers need a public entry function. That is also the reason why there is a seperate init function for this almost trivial currently vbo module internal task. The init function would also be of public use in that later step. Finally that is even the reason for the seperate 'struct vbo_inputs' that could be as well open coded in the vbo module. But pushing that into driver backends is much more easy when this is a seperate tool struct with methods on it. So if you really require me to make them private now I can move them now, but a later patch will move them back here or somewhere similar. > > + /* The rest must be current inputs. */ > > + update_current_inputs(ctx, inputs, ~enable & VERT_BIT_ALL); > > The & VERT_BIT_ALL isn't really needed, is it? I guess there's no harm > though. Currently this is a logical noop and I think the compiler detects that. Originally the code stems from the time where the mask was 33 bits and there it was required. In the case we do further play with the VERT_ATTRIB_* list and VERT_BITs it may again be required an I like to be prepared for that, especially if its that easy. I will take care of the rest of the comments! best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start
https://bugs.freedesktop.org/show_bug.cgi?id=93551 --- Comment #48 from Alex --- Yes, the shim seems to no longer work -- I assume newer Mesa versions are no longer declaring compatibility with whatever version Divinity was hardcoded to? It's probably possible to create another workaround, but I don't have the knowledge to do so, and this is obviously quite brittle. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/2] radeonsi/nir: fix gl_FragCoord for pixel_center_integer
Fixes piglit test glsl-arb-fragment-coord-conventions
---
src/gallium/drivers/radeonsi/si_shader_nir.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 5ea1b4f033..ea9f2076da 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -290,6 +290,11 @@ void si_nir_scan_shader(const struct nir_shader *nir,
nir->info.fs.early_fragment_tests |
nir->info.fs.post_depth_coverage;
info->properties[TGSI_PROPERTY_FS_POST_DEPTH_COVERAGE] =
nir->info.fs.post_depth_coverage;
+ if (nir->info.fs.pixel_center_integer) {
+ info->properties[TGSI_PROPERTY_FS_COORD_PIXEL_CENTER] =
+ TGSI_FS_COORD_PIXEL_CENTER_INTEGER;
+ }
+
if (nir->info.fs.depth_layout != FRAG_DEPTH_LAYOUT_NONE) {
switch (nir->info.fs.depth_layout) {
case FRAG_DEPTH_LAYOUT_ANY:
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/2] glsl/nir: add pixel_center_integer to shader info
---
src/compiler/glsl/glsl_to_nir.cpp | 5 +
src/compiler/shader_info.h| 2 ++
2 files changed, 7 insertions(+)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index 1a579f41cd..7a9d15015e 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -406,6 +406,11 @@ nir_visitor::visit(ir_variable *ir)
var->data.pixel_center_integer = ir->data.pixel_center_integer;
var->data.location_frac = ir->data.location_frac;
+ if (var->data.pixel_center_integer) {
+ assert(shader->info.stage == MESA_SHADER_FRAGMENT);
+ shader->info.fs.pixel_center_integer = true;
+ }
+
switch (ir->data.depth_layout) {
case ir_depth_layout_none:
var->data.depth_layout = nir_depth_layout_none;
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 45ef4b5039..11a59ff6ac 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -164,6 +164,8 @@ typedef struct shader_info {
bool post_depth_coverage;
+ bool pixel_center_integer;
+
/** gl_FragDepth layout for ARB_conservative_depth. */
enum gl_frag_depth_layout depth_layout;
} fs;
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Adding a SPIR-V target to libclc
Jan Vesely writes: > On Thu, 2018-02-08 at 15:56 -0800, Francisco Jerez wrote: >> Jan Vesely writes: >> >> > On Thu, 2018-02-08 at 23:16 +0100, Pierre Moreau wrote: >> > > (Moving the conversation to its own thread.) >> > > >> > > > target agnostic libclc is rather difficult to do. CLC includes 3 levels >> > > > of precision on float (fp32) operands; full, half, native. The >> > > > implementation of each depends on capabilites of specific device (e.g. >> > > > vega(VI+?) can do 1 ULP log2/exp2 in hw, other targets need sw >> > > > implementation to meet CLC requirement of 3ulp). Any conversion backend >> > > > would thus need to implement sw versions of math builtins for targets >> > > > that can't perform the op in HW. >> > > >> > > My initial thought for the target agnostic libclc, was to just provide >> > > some >> > > (fake?) implementations of OpenCL built-in functions to make clang happy >> > > and >> > > let me compile kernels using “get_global_id()”, as well as include >> > > headers >> > > defining OpenCL specific types like “float4” or others. If there is >> > > another >> > > (better?) way to achieve this, I am all ears. (There is probably one, as >> > > I had >> > > no issues when using the Khronos LLVM/clang fork rather than Tomeu’s >> > > out-of-tree module, the former having also some bits and pieces in >> > > clang.) >> > >> > I don't think you need libclc for this. workitem IDs are >> > platform/device specific, and iiuc SPIR-V builtins should handle it in >> > an abstract way [0]. any conversion consuming SPIR-V needs to replace >> > those with device/platform specific way of obtaining the information. >> > you can also use clang's clc header to provide data types [1]. >> > >> > >> > [0] https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#B >> > uiltIn >> > [1] https://github.com/llvm-mirror/clang/blob/master/lib/Headers/opencl >> > -c.h >> > >> > > >> > > > Extending the current libclc to provide target specific SPIR-V binaries >> > > > in addition to/in place of LLVM IR is rather straightforward. Adding >> > > > additional targets it's more work since it relies on clang to support >> > > > those targets. >> > > >> > > I’m curious how those target specific SPIR-V binaries would look like. I >> > > can >> > > imagine how some functions like “OpSign” could be implemented using other >> > > SPIR-V functions, but how would you handle something like >> > > “get_local_id()”? If >> > > you define it as the built-in “LocalInvocationId” and don’t supply an >> > > implementation of it, then you lose the target specificness. On the >> > > other hand, >> > > if you want to keep it device-specific, how would you express that in >> > > SPIR-V? >> > >> > getting IDs is not a problem. SPIR-V should provide builtins for that. >> > >> > The problem I had in mind is when SPIR-V binary calls e.g. exp2(). You >> > can either assume that the op needs CLC precision (3 ulp), or device >> > native precision. >> >> That's up to the SPIR-V extended instruction set specification to define >> what precision the exp2 built-in is supposed to have. >> >> > SPIR-V binary can also call exp2(fp64), which does not have an >> > equivalent GPU instruction. >> >> Then it should probably be lowered by the SPIR-V front-end, right? > > I'm not sure what you mean by "spir-v frontend". If it's the tool that > generates SPIR-V, then no, not really. No, I meant the SPIR-V front-end of the driver (or whatever translation pass in control of the driver is translating machine-agnostic SPIR-V into some other more hardware-specific representation of the program). > My understanding is that those are run prior to application > distribution, and therefore have no information about the target HW. > > So if a program imports "CLC.std.11" extended instruction set to get > access CLC builtin functions. What would a generic SPIR-V libclc > provide? > >> >> > It's easier to translate these to libclc function calls (combined with >> > the right library implementation of the exp2 builtin), than try to >> > generate exp2 algorithm when converting to NIR (or anything else >> > really). >> > >> >> But the SPIR-V front-end will need to lower that in terms of >> instructions supported by the back-end anyway in order to be able to >> handle general SPIR-V shaders as input, right? So why re-implement the >> lowering for those operations in libclc in a way that's only going to be >> useful for the OpenCL C language but not for other APIs? >> >> > The current libclc mostly assumes that LLVM ops are done in device >> > native precision, and provides sw implementation of operations that >> > don't have conformant device instruction. >> >> But I don't think there is any disadvantage from having a libclc >> implementation that doesn't make any precision assumptions beyond what >> is stated in the SPIR-V spec. In fact that would have the IMO more >> desirable advantage that you could re-use one and the same l
Re: [Mesa-dev] clover: Fix build after llvm r325155 and r325160
Hello Jan, something semilar is needed fro libclc, too. LLVM-CC nvptx64--nvidiacl/lib/geometric/dot.cl.bc ./utils/prepare-builtins.cpp:108:3: error: no matching function for call to 'WriteBitcodeToFile' WriteBitcodeToFile(M, Out->os()); ^~ /usr/local/include/llvm/Bitcode/BitcodeWriter.h:129:8: note: candidate function not viable: no known conversion from 'llvm::Module *' to 'const llvm::Module' for 1st argument; dereference the argument with * void WriteBitcodeToFile(const Module &M, raw_ostream &Out, ^ Greetings, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] ac: use correct LLVM opcodes for ordered comparisons
On 15/02/18 20:06, Bas Nieuwenhuizen wrote: On Thu, Feb 15, 2018 at 8:54 AM, Connor Abbott wrote: On Wed, Feb 14, 2018 at 11:53 PM, Timothy Arceri wrote: On 15/02/18 04:39, Marek Olšák wrote: Reviewed-by: Marek Olšák Marek On Wed, Feb 14, 2018 at 7:29 AM, Timothy Arceri wrote: Fixes glsl-1.30/execution/isinf-and-isnan* piglit tests for radeonsi and should fix SPIRV errors when LLVM optimises away the workarounds in vtn_handle_alu() for handling ordered comparisons. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104905 --- src/amd/common/ac_nir_to_llvm.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c index a0c5680205..e81f86bb08 100644 --- a/src/amd/common/ac_nir_to_llvm.c +++ b/src/amd/common/ac_nir_to_llvm.c @@ -1792,16 +1792,16 @@ static void visit_alu(struct ac_nir_context *ctx, const nir_alu_instr *instr) result = emit_int_cmp(&ctx->ac, LLVMIntUGE, src[0], src[1]); break; case nir_op_feq: - result = emit_float_cmp(&ctx->ac, LLVMRealUEQ, src[0], src[1]); + result = emit_float_cmp(&ctx->ac, LLVMRealOEQ, src[0], src[1]); break; case nir_op_fne: - result = emit_float_cmp(&ctx->ac, LLVMRealUNE, src[0], src[1]); + result = emit_float_cmp(&ctx->ac, LLVMRealONE, src[0], src[1]); It seems we need to leave this one as is to avoid regressions. This is also what radeonsi does. So, the thing you have to understand is that in LLVM unordered comparisons are precisely the inverse of the ordered comparisons. That is, (a <=(ordered) b) == !(a >(unordered b), (a ==(ordered) b) == !(a !=(unordered) b), and so on. C defines that all comparsions are ordered except !=, so that (a == b) == !(a != b) always holds true. Most hardware follows this convention -- offhand, x86 SSE is the only ISA I know of with separate ordered and unordered comparisons, and LLVM appears to have copied the distinction from them, but no one else has both. I'm not even sure if it's in the IEEE spec. GLSL follows the C convention, so glsl_to_nir just uses nir_op_fne to mean unordered not-equal. spirv_to_nir generates some extra instructions, which then get stripped away later... sigh. I think the right way to untangle this mess is to define that the NIR opcodes should always match the C convention. The separate ordered and unordered opcodes are unnecesary, since one is just the logical negation of the other, and LLVM was a little overzealous -- I'm sure they would get rid of the distinction if they had the chance -- and then they were blindly copied to SPIR-V. spirv_to_nir should just negate the result if necessary rather than emitting the extra code to handle NaN, and ac should use ordered except for not-equals. GCN hardware actually has both ordered and unordered instructions, though I think it could be fair to only introduce them during instruction selection (or conversion to LLVM) and keep a canonical ordered comparison + not in nir. I think the most important part would be to firmly define which one the nir instructions are and then make nir_opt_algebraic not break that. Well you guys seem to understand the issue and solutions better then I do so I think I'll step back from this for the time being. So feel free to tackle the issue. I've also noticed what seems to be mishandling of nans elsewhere. For example on radeonsi the following test produces "vec1 32 ssa_5 = load_const (0x /* -nan */)" which seems to incorrectly handled and optimised out at some point along the way. ./glcts --deqp-case=KHR-GL43.compute_shader.atomic-case1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600/sb: fix rotated register in while loop (attempt 2)
From: Dave Airlie
A bunch of CTS tests led me to write
tests/shaders/ssa/fs-while-loop-rotate-value.shader_test
which r600/sb always fell over on.
GCM seems to move some of the copys into other basic blocks,
if we don't allow this to happen then it doesn't seem to schedule
them badly.
Everything I've read on SSA/phi copies say they have to happen
in parallel, so keeping them in the same basic block seems like
a good way to keep some of that property.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/sb/sb_shader.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_shader.cpp
b/src/gallium/drivers/r600/sb/sb_shader.cpp
index 321e24ea25..8959b8391d 100644
--- a/src/gallium/drivers/r600/sb/sb_shader.cpp
+++ b/src/gallium/drivers/r600/sb/sb_shader.cpp
@@ -121,7 +121,7 @@ alu_node* shader::create_copy_mov(value* dst, value* src,
unsigned affcost) {
alu_node *n = create_mov(dst, src);
dst->assign_source(src);
- n->flags |= NF_COPY_MOV | NF_DONT_HOIST;
+ n->flags |= NF_COPY_MOV | NF_DONT_HOIST | NF_DONT_MOVE;
if (affcost && dst->is_sgpr() && src->is_sgpr())
coal.add_edge(src, dst, affcost);
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Adding a SPIR-V target to libclc
On Thu, 2018-02-08 at 15:56 -0800, Francisco Jerez wrote: > Jan Vesely writes: > > > On Thu, 2018-02-08 at 23:16 +0100, Pierre Moreau wrote: > > > (Moving the conversation to its own thread.) > > > > > > > target agnostic libclc is rather difficult to do. CLC includes 3 levels > > > > of precision on float (fp32) operands; full, half, native. The > > > > implementation of each depends on capabilites of specific device (e.g. > > > > vega(VI+?) can do 1 ULP log2/exp2 in hw, other targets need sw > > > > implementation to meet CLC requirement of 3ulp). Any conversion backend > > > > would thus need to implement sw versions of math builtins for targets > > > > that can't perform the op in HW. > > > > > > My initial thought for the target agnostic libclc, was to just provide > > > some > > > (fake?) implementations of OpenCL built-in functions to make clang happy > > > and > > > let me compile kernels using “get_global_id()”, as well as include headers > > > defining OpenCL specific types like “float4” or others. If there is > > > another > > > (better?) way to achieve this, I am all ears. (There is probably one, as > > > I had > > > no issues when using the Khronos LLVM/clang fork rather than Tomeu’s > > > out-of-tree module, the former having also some bits and pieces in clang.) > > > > I don't think you need libclc for this. workitem IDs are > > platform/device specific, and iiuc SPIR-V builtins should handle it in > > an abstract way [0]. any conversion consuming SPIR-V needs to replace > > those with device/platform specific way of obtaining the information. > > you can also use clang's clc header to provide data types [1]. > > > > > > [0] https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#B > > uiltIn > > [1] https://github.com/llvm-mirror/clang/blob/master/lib/Headers/opencl > > -c.h > > > > > > > > > Extending the current libclc to provide target specific SPIR-V binaries > > > > in addition to/in place of LLVM IR is rather straightforward. Adding > > > > additional targets it's more work since it relies on clang to support > > > > those targets. > > > > > > I’m curious how those target specific SPIR-V binaries would look like. I > > > can > > > imagine how some functions like “OpSign” could be implemented using other > > > SPIR-V functions, but how would you handle something like > > > “get_local_id()”? If > > > you define it as the built-in “LocalInvocationId” and don’t supply an > > > implementation of it, then you lose the target specificness. On the other > > > hand, > > > if you want to keep it device-specific, how would you express that in > > > SPIR-V? > > > > getting IDs is not a problem. SPIR-V should provide builtins for that. > > > > The problem I had in mind is when SPIR-V binary calls e.g. exp2(). You > > can either assume that the op needs CLC precision (3 ulp), or device > > native precision. > > That's up to the SPIR-V extended instruction set specification to define > what precision the exp2 built-in is supposed to have. > > > SPIR-V binary can also call exp2(fp64), which does not have an > > equivalent GPU instruction. > > Then it should probably be lowered by the SPIR-V front-end, right? I'm not sure what you mean by "spir-v frontend". If it's the tool that generates SPIR-V, then no, not really. My understanding is that those are run prior to application distribution, and therefore have no information about the target HW. So if a program imports "CLC.std.11" extended instruction set to get access CLC builtin functions. What would a generic SPIR-V libclc provide? > > > It's easier to translate these to libclc function calls (combined with > > the right library implementation of the exp2 builtin), than try to > > generate exp2 algorithm when converting to NIR (or anything else > > really). > > > > But the SPIR-V front-end will need to lower that in terms of > instructions supported by the back-end anyway in order to be able to > handle general SPIR-V shaders as input, right? So why re-implement the > lowering for those operations in libclc in a way that's only going to be > useful for the OpenCL C language but not for other APIs? > > > The current libclc mostly assumes that LLVM ops are done in device > > native precision, and provides sw implementation of operations that > > don't have conformant device instruction. > > But I don't think there is any disadvantage from having a libclc > implementation that doesn't make any precision assumptions beyond what > is stated in the SPIR-V spec. In fact that would have the IMO more > desirable advantage that you could re-use one and the same libclc > implementation for *all* back-ends that want SPIR-V as input. Sure, a compiler-rt library would be more useful (usable by multiple languages). However, unlike target specific libclc, it's not available atm. Jan > > > This obviates the need for compiler-rt library. And alternative > > approach is to assume that the ops provide full precision and
Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm
On Fri, Feb 9, 2018 at 11:06 PM, Rob Herring wrote: > On Fri, Feb 9, 2018 at 3:58 AM, Tomasz Figa wrote: >> On Fri, Feb 2, 2018 at 11:51 PM, Tomasz Figa wrote: >>> On Fri, Feb 2, 2018 at 11:00 PM, Rob Herring wrote: On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa wrote: > Hi Rob, > > On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss > wrote: >>> uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane); >>> uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t >>> plane); >>> uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t >>> plane); >>> uint32_t (*get_stride)(buffer_handle_t handle, uint32_t >>> plane); >>> ... >>> } gralloc_funcs_t; >>> >>> >>> These ones? > >>> Yeah, if we could retrieve such function pointer struct using perform >>> or any equivalent (like the implementation-specific methods in >>> gralloc1, but not sure if that's going to be used in practice >>> anywhere), it could work for us. >> >> >> So this is where you and Rob Herring lose me, I don't think I understand >> quite how the gralloc1 call would be used, and how it would tie into this >> handle struct. I think I could do with some guidance on this. > > This would be very similar to gralloc0 perform call. gralloc1 > implementations need to provide getFunction() callback [1], which > returns a pointer to given function. The list of standard functions is > defined in the gralloc1.h header [2], but we could take some random > big number and use it for our function that fills in provided > gralloc_funcs_t struct with necessary pointers. > > [1] > https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300 > [2] > https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134 This is a deadend because it won't work with a HIDL based implementation (aka gralloc 2.0). You can't set function pointers (or any pointers) because gralloc runs in a different process. Yes, currently gralloc is a pass-thru HAL, but AIUI that will go away. >>> >>> Part of it. I can't see IMapper being implemented by a separate >>> process. You can't map a buffer into one process from another process. >>> >>> But anyway, it's a good point, thanks, I almost forgot about its >>> existence. I'll do further investigation. >> >> Okay, so IMapper indeed breaks the approach I suggested. I'm not sure >> at the moment what we could do about it. (The idea of a dynamic >> library of a pre-defined name, exporting functions we specify, might >> still work, though.) >> >> Note that the DRM_GRALLOC_GET_FD used currently by Mesa will also be >> impossible to implement with IAllocator/IMapper. (Although I still >> think Mesa and Gralloc are free to have separate logic for choosing >> the DRM device to use.) > > I think the need for GET_FD goes away when the render node is used. We > may still need the card node for s/w rendering (if I can ever get that > working) though. Of course, if we use the vgem approach like CrOS then > we wouldn't. Hmm, if so, then we probably wouldn't have any strict need for these function pointers anymore. We already have a makeshift format resolve in place and the only missing bits that we still need to patch up downstream are removing GET_FD, dropping drm_gralloc.h and adding a fallback to kms_swrast if hw driver loading fails. Best regards, Tomasz ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/10] intel/anv: Prepare to add Ice Lake (ICL) support
I made a few fairly trivial comments but it all looks pretty good. Reviewed-by: Jason Ekstrand On Thu, Feb 15, 2018 at 5:44 PM, Anuj Phogat wrote: > This series prepares the driver to enable Ice Lake support > in Vulkan driver. It wires up the build infrastructure and > make few ICL specific changes suggested by h/w documentation. > This is not everything we need to enable Vulkan on Ice Lake. > How much is left? > Series is also available in my review branch at github. > https://github.com/aphogat/mesa.git > > Anuj Phogat (10): > anv/icl: Add gen11 mocs defines > anv/icl: Add #define genX > anv/icl: Don't set ResetGatewayTimer > anv/icl: Don't use SingleVertexDispatch > anv/icl: Don't use DISPATCH_MODE_SIMD4X2 > anv/icl: Generate gen11 entry point functions > anv/icl: Build anv libs for gen11 > anv/icl: Use gen11 functions > anv/icl: Enable float blend optimization > anv/icl: Add render target flush after uploading binding table > > src/intel/Android.vulkan.mk | 21 + > src/intel/Makefile.sources | 4 > src/intel/Makefile.vulkan.am| 7 ++- > src/intel/vulkan/anv_blorp.c| 3 +++ > src/intel/vulkan/anv_device.c | 3 +++ > src/intel/vulkan/anv_entrypoints_gen.py | 6 +- > src/intel/vulkan/anv_private.h | 14 ++ > src/intel/vulkan/genX_cmd_buffer.c | 21 + > src/intel/vulkan/genX_pipeline.c| 11 +++ > src/intel/vulkan/genX_state.c | 2 +- > src/intel/vulkan/meson.build| 2 +- > 11 files changed, 90 insertions(+), 4 deletions(-) > > -- > 2.13.6 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] anv/icl: Enable float blend optimization
On Thu, Feb 15, 2018 at 5:44 PM, Anuj Phogat wrote: > Signed-off-by: Anuj Phogat > --- > src/intel/vulkan/genX_state.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c > index 54fb8634fd..f39508034f 100644 > --- a/src/intel/vulkan/genX_state.c > +++ b/src/intel/vulkan/genX_state.c > @@ -121,7 +121,7 @@ genX(init_device_state)(struct anv_device *device) > } > #endif > > -#if GEN_GEN == 10 > +#if GEN_GEN == 10 || GEN_GEN == 11 > Might as well make this GEN_GEN >= 10 > uint32_t cache_mode_ss; > anv_pack_struct(&cache_mode_ss, GENX(CACHE_MODE_SS), > .FloatBlendOptimizationEnable = true, > -- > 2.13.6 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/10] anv/icl: Add render target flush after uploading binding table
On Thu, Feb 15, 2018 at 5:44 PM, Anuj Phogat wrote:
> The PIPE_CONTROL command description says:
>
> "Whenever a Binding Table Index (BTI) used by a Render Taget Message
> points to a different RENDER_SURFACE_STATE, SW must issue a Render
> Target Cache Flush by enabling this bit. When render target flush
> is set due to new association of BTI, PS Scoreboard Stall bit must
> be set in this packet."
>
> Signed-off-by: Anuj Phogat
> ---
> src/intel/vulkan/genX_cmd_buffer.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> index ce47b8a1cc..e2b6c281e4 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -2001,6 +2001,27 @@ emit_binding_table(struct anv_cmd_buffer
> *cmd_buffer,
> out:
> anv_state_flush(cmd_buffer->device, *bt_state);
>
> +#if GEN_GEN >= 11
> + /* The PIPE_CONTROL command description says:
> +*
> +* "Whenever a Binding Table Index (BTI) used by a Render Taget Message
> +* points to a different RENDER_SURFACE_STATE, SW must issue a Render
> +* Target Cache Flush by enabling this bit. When render target flush
> +* is set due to new association of BTI, PS Scoreboard Stall bit must
> +* be set in this packet."
>
We usually indent block quotes like this.
> +*
> +* FINISHME: Currently we shuffle around the surface states in the
> +* binding table based on if they are getting used or not. So, we've
> +* to do below pipe control flush for every binding table upload.
> +* Make changes so that we do it only when we modify render target
> +* surface states.
> +*/
> + anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pc) {
> + pc.RenderTargetCacheFlushEnable = true;
> + pc.StallAtPixelScoreboard= true;
> + }
> +#endif
> +
> return VK_SUCCESS;
> }
>
> --
> 2.13.6
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105119] Desktop-wide input freeze when vulkan (radv)
https://bugs.freedesktop.org/show_bug.cgi?id=105119 --- Comment #2 from Jakub Okoński --- I ran my code on Windows using AMD's proprietary driver, I can see this message from validation layers: Attempt to reset command buffer (0x026469454060) which is in use. The spec valid usage text states 'commandBuffer must not be in the pending state' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-vkResetCommandBuffer-commandBuffer-00045) Calling vkBeginCommandBuffer() on active command buffer 026469454060 before it has completed. You must check command buffer fence before this call. The spec valid usage text states 'commandBuffer must not be in the recording or pending state.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-vkBeginCommandBuffer-commandBuffer-00049) So I must be misusing the API as described. -- 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 05/10] anv/icl: Don't use DISPATCH_MODE_SIMD4X2
On Thu, Feb 15, 2018 at 5:44 PM, Anuj Phogat wrote:
> Signed-off-by: Anuj Phogat
> ---
> src/intel/vulkan/genX_pipeline.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_
> pipeline.c
> index 85391c93ca..290d78e608 100644
> --- a/src/intel/vulkan/genX_pipeline.c
> +++ b/src/intel/vulkan/genX_pipeline.c
> @@ -1124,6 +1124,9 @@ emit_3dstate_vs(struct anv_pipeline *pipeline)
>pipeline->shaders[MESA_SHADER_VERTEX];
>
> assert(anv_pipeline_has_stage(pipeline, MESA_SHADER_VERTEX));
> +#if GEN_GEN >= 11
> + assert(vs_prog_data->base.dispatch_mode == DISPATCH_MODE_SIMD8);
> +#endif
>
> anv_batch_emit(&pipeline->batch, GENX(3DSTATE_VS), vs) {
>vs.Enable = true;
> @@ -1253,10 +1256,14 @@ emit_3dstate_hs_te_ds(struct anv_pipeline
> *pipeline,
> tes_prog_data->base.base.dispatch_grf_start_reg;
>
> #if GEN_GEN >= 8
> +#if GEN_GEN < 11
>ds.DispatchMode =
> tes_prog_data->base.dispatch_mode == DISPATCH_MODE_SIMD8 ?
> DISPATCH_MODE_SIMD8_SINGLE_PATCH :
> DISPATCH_MODE_SIMD4X2;
> +#else
>
You can just put the assert here.
> + ds.DispatchMode = DISPATCH_MODE_SIMD8_SINGLE_PATCH;
> +#endif
>
>ds.UserClipDistanceClipTestEnableBitmask =
> tes_prog_data->base.clip_distance_mask;
> --
> 2.13.6
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/10] anv/icl: Don't use SingleVertexDispatch
Signed-off-by: Anuj Phogat --- src/intel/vulkan/genX_pipeline.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c index 784559380d..85391c93ca 100644 --- a/src/intel/vulkan/genX_pipeline.c +++ b/src/intel/vulkan/genX_pipeline.c @@ -1135,7 +1135,9 @@ emit_3dstate_vs(struct anv_pipeline *pipeline) #endif assert(!vs_prog_data->base.base.use_alt_mode); +#if GEN_GEN < 11 vs.SingleVertexDispatch = false; +#endif vs.VectorMaskEnable = false; vs.SamplerCount = get_sampler_count(vs_bin); vs.BindingTableEntryCount = get_binding_table_entry_count(vs_bin); -- 2.13.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/10] anv/icl: Don't use DISPATCH_MODE_SIMD4X2
Signed-off-by: Anuj Phogat
---
src/intel/vulkan/genX_pipeline.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 85391c93ca..290d78e608 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1124,6 +1124,9 @@ emit_3dstate_vs(struct anv_pipeline *pipeline)
pipeline->shaders[MESA_SHADER_VERTEX];
assert(anv_pipeline_has_stage(pipeline, MESA_SHADER_VERTEX));
+#if GEN_GEN >= 11
+ assert(vs_prog_data->base.dispatch_mode == DISPATCH_MODE_SIMD8);
+#endif
anv_batch_emit(&pipeline->batch, GENX(3DSTATE_VS), vs) {
vs.Enable = true;
@@ -1253,10 +1256,14 @@ emit_3dstate_hs_te_ds(struct anv_pipeline *pipeline,
tes_prog_data->base.base.dispatch_grf_start_reg;
#if GEN_GEN >= 8
+#if GEN_GEN < 11
ds.DispatchMode =
tes_prog_data->base.dispatch_mode == DISPATCH_MODE_SIMD8 ?
DISPATCH_MODE_SIMD8_SINGLE_PATCH :
DISPATCH_MODE_SIMD4X2;
+#else
+ ds.DispatchMode = DISPATCH_MODE_SIMD8_SINGLE_PATCH;
+#endif
ds.UserClipDistanceClipTestEnableBitmask =
tes_prog_data->base.clip_distance_mask;
--
2.13.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] anv/icl: Generate gen11 entry point functions
Signed-off-by: Anuj Phogat
---
src/intel/vulkan/anv_entrypoints_gen.py | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_entrypoints_gen.py
b/src/intel/vulkan/anv_entrypoints_gen.py
index 1bab885180..c5a654f19b 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -43,7 +43,8 @@ LAYERS = [
'gen75',
'gen8',
'gen9',
-'gen10'
+'gen10',
+'gen11',
]
TEMPLATE_H = Template("""\
@@ -246,6 +247,9 @@ anv_resolve_entrypoint(const struct gen_device_info
*devinfo, uint32_t index)
const struct anv_dispatch_table *genX_table;
switch (devinfo->gen) {
+ case 11:
+ genX_table = &gen11_dispatch_table;
+ break;
case 10:
genX_table = &gen10_dispatch_table;
break;
--
2.13.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/10] anv/icl: Enable float blend optimization
Signed-off-by: Anuj Phogat --- src/intel/vulkan/genX_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c index 54fb8634fd..f39508034f 100644 --- a/src/intel/vulkan/genX_state.c +++ b/src/intel/vulkan/genX_state.c @@ -121,7 +121,7 @@ genX(init_device_state)(struct anv_device *device) } #endif -#if GEN_GEN == 10 +#if GEN_GEN == 10 || GEN_GEN == 11 uint32_t cache_mode_ss; anv_pack_struct(&cache_mode_ss, GENX(CACHE_MODE_SS), .FloatBlendOptimizationEnable = true, -- 2.13.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/10] anv/icl: Add render target flush after uploading binding table
The PIPE_CONTROL command description says:
"Whenever a Binding Table Index (BTI) used by a Render Taget Message
points to a different RENDER_SURFACE_STATE, SW must issue a Render
Target Cache Flush by enabling this bit. When render target flush
is set due to new association of BTI, PS Scoreboard Stall bit must
be set in this packet."
Signed-off-by: Anuj Phogat
---
src/intel/vulkan/genX_cmd_buffer.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index ce47b8a1cc..e2b6c281e4 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -2001,6 +2001,27 @@ emit_binding_table(struct anv_cmd_buffer *cmd_buffer,
out:
anv_state_flush(cmd_buffer->device, *bt_state);
+#if GEN_GEN >= 11
+ /* The PIPE_CONTROL command description says:
+*
+* "Whenever a Binding Table Index (BTI) used by a Render Taget Message
+* points to a different RENDER_SURFACE_STATE, SW must issue a Render
+* Target Cache Flush by enabling this bit. When render target flush
+* is set due to new association of BTI, PS Scoreboard Stall bit must
+* be set in this packet."
+*
+* FINISHME: Currently we shuffle around the surface states in the
+* binding table based on if they are getting used or not. So, we've
+* to do below pipe control flush for every binding table upload.
+* Make changes so that we do it only when we modify render target
+* surface states.
+*/
+ anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pc) {
+ pc.RenderTargetCacheFlushEnable = true;
+ pc.StallAtPixelScoreboard= true;
+ }
+#endif
+
return VK_SUCCESS;
}
--
2.13.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/10] anv/icl: Add gen11 mocs defines
Signed-off-by: Anuj Phogat
---
src/intel/vulkan/anv_private.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index d38dd9e422..009f5304f2 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1148,6 +1148,17 @@ _anv_combine_address(struct anv_batch *batch, void
*location,
.IndextoMOCSTables = 1 \
}
+/* Ice Lake MOCS defines are duplicates of Skylake MOCS defines. */
+#define GEN11_MOCS (struct GEN11_MEMORY_OBJECT_CONTROL_STATE) { \
+ /* TC=LLC/eLLC, LeCC=WB, LRUM=3, L3CC=WB */ \
+ .IndextoMOCSTables = 2 \
+ }
+
+#define GEN11_MOCS_PTE { \
+ /* TC=LLC/eLLC, LeCC=WB, LRUM=3, L3CC=WB */ \
+ .IndextoMOCSTables = 1 \
+ }
+
struct anv_device_memory {
struct anv_bo * bo;
struct anv_memory_type * type;
--
2.13.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/10] anv/icl: Build anv libs for gen11
Signed-off-by: Anuj Phogat --- src/intel/Android.vulkan.mk | 21 + src/intel/Makefile.sources | 4 src/intel/Makefile.vulkan.am | 7 ++- src/intel/vulkan/meson.build | 2 +- 4 files changed, 32 insertions(+), 2 deletions(-) diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk index 32b4892e17..6fe736d397 100644 --- a/src/intel/Android.vulkan.mk +++ b/src/intel/Android.vulkan.mk @@ -185,6 +185,26 @@ include $(MESA_COMMON_MK) include $(BUILD_STATIC_LIBRARY) # +# libanv for gen11 +# + +include $(CLEAR_VARS) +LOCAL_MODULE := libmesa_anv_gen11 +LOCAL_MODULE_CLASS := STATIC_LIBRARIES + +LOCAL_SRC_FILES := $(VULKAN_GEN10_FILES) +LOCAL_CFLAGS := -DGEN_VERSIONx10=110 + +LOCAL_C_INCLUDES := $(ANV_INCLUDES) + +LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml + +LOCAL_SHARED_LIBRARIES := libdrm + +include $(MESA_COMMON_MK) +include $(BUILD_STATIC_LIBRARY) + +# # libmesa_vulkan_common # @@ -270,6 +290,7 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \ libmesa_anv_gen8 \ libmesa_anv_gen9 \ libmesa_anv_gen10 \ + libmesa_anv_gen11 \ libmesa_intel_compiler \ libmesa_anv_entrypoints diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources index 22563cac6a..692c860477 100644 --- a/src/intel/Makefile.sources +++ b/src/intel/Makefile.sources @@ -285,3 +285,7 @@ VULKAN_GEN9_FILES := \ VULKAN_GEN10_FILES := \ vulkan/gen8_cmd_buffer.c \ $(VULKAN_GENX_FILES) + +VULKAN_GEN11_FILES := \ + vulkan/gen8_cmd_buffer.c \ + $(VULKAN_GENX_FILES) diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am index 23fa877e77..891ee698a0 100644 --- a/src/intel/Makefile.vulkan.am +++ b/src/intel/Makefile.vulkan.am @@ -98,7 +98,8 @@ VULKAN_PER_GEN_LIBS = \ vulkan/libanv-gen75.la \ vulkan/libanv-gen8.la \ vulkan/libanv-gen9.la \ - vulkan/libanv-gen10.la + vulkan/libanv-gen10.la \ + vulkan/libanv-gen11.la noinst_LTLIBRARIES += $(VULKAN_PER_GEN_LIBS) @@ -138,6 +139,10 @@ vulkan_libanv_gen10_la_CFLAGS = $(VULKAN_CFLAGS) vulkan_libanv_gen10_la_CPPFLAGS = $(VULKAN_CPPFLAGS) -DGEN_VERSIONx10=100 vulkan_libanv_gen10_la_SOURCES = $(VULKAN_GEN10_FILES) +vulkan_libanv_gen11_la_CFLAGS = $(VULKAN_CFLAGS) +vulkan_libanv_gen11_la_CPPFLAGS = $(VULKAN_CPPFLAGS) -DGEN_VERSIONx10=110 +vulkan_libanv_gen11_la_SOURCES = $(VULKAN_GEN11_FILES) + VULKAN_SOURCES = \ $(VULKAN_GENERATED_FILES) \ $(VULKAN_FILES) diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build index 41dba420cb..f031723670 100644 --- a/src/intel/vulkan/meson.build +++ b/src/intel/vulkan/meson.build @@ -101,7 +101,7 @@ anv_gen_files = files( ) foreach g : [['70', ['gen7_cmd_buffer.c']], ['75', ['gen7_cmd_buffer.c']], ['80', ['gen8_cmd_buffer.c']], ['90', ['gen8_cmd_buffer.c']], - ['100', ['gen8_cmd_buffer.c']]] + ['100', ['gen8_cmd_buffer.c']], ['110', ['gen8_cmd_buffer.c']]] _gen = g[0] libanv_gen_libs += static_library( 'libanv_gen@0@'.format(_gen), -- 2.13.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] anv/icl: Add #define genX
Signed-off-by: Anuj Phogat --- src/intel/vulkan/anv_private.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h index 009f5304f2..9822afb81d 100644 --- a/src/intel/vulkan/anv_private.h +++ b/src/intel/vulkan/anv_private.h @@ -3042,6 +3042,9 @@ ANV_DEFINE_NONDISP_HANDLE_CASTS(anv_ycbcr_conversion, VkSamplerYcbcrConversionKH # define genX(x) gen10_##x # include "anv_genX.h" # undef genX +# define genX(x) gen11_##x +# include "anv_genX.h" +# undef genX #endif #endif /* ANV_PRIVATE_H */ -- 2.13.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] anv/icl: Don't set ResetGatewayTimer
Signed-off-by: Anuj Phogat --- src/intel/vulkan/genX_pipeline.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c index 45ebe31de6..784559380d 100644 --- a/src/intel/vulkan/genX_pipeline.c +++ b/src/intel/vulkan/genX_pipeline.c @@ -1820,7 +1820,9 @@ compute_pipeline_create( vfe.MaximumNumberofThreads = devinfo->max_cs_threads * subslices - 1; vfe.NumberofURBEntries = GEN_GEN <= 7 ? 0 : 2; +#if GEN_GEN < 11 vfe.ResetGatewayTimer = true; +#endif #if GEN_GEN <= 8 vfe.BypassGatewayControl = true; #endif -- 2.13.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/10] anv/icl: Use gen11 functions
Signed-off-by: Anuj Phogat
---
src/intel/vulkan/anv_blorp.c | 3 +++
src/intel/vulkan/anv_device.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index d38b343671..d98bf8364d 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -111,6 +111,9 @@ anv_device_init_blorp(struct anv_device *device)
case 10:
device->blorp.exec = gen10_blorp_exec;
break;
+ case 11:
+ device->blorp.exec = gen11_blorp_exec;
+ break;
default:
unreachable("Unknown hardware generation");
}
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 2c2cd0b2d4..00b0b65333 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1482,6 +1482,9 @@ VkResult anv_CreateDevice(
case 10:
result = gen10_init_device_state(device);
break;
+ case 11:
+ result = gen11_init_device_state(device);
+ break;
default:
/* Shouldn't get here as we don't create physical devices for any other
* gens. */
--
2.13.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/10] intel/anv: Prepare to add Ice Lake (ICL) support
This series prepares the driver to enable Ice Lake support in Vulkan driver. It wires up the build infrastructure and make few ICL specific changes suggested by h/w documentation. This is not everything we need to enable Vulkan on Ice Lake. Series is also available in my review branch at github. https://github.com/aphogat/mesa.git Anuj Phogat (10): anv/icl: Add gen11 mocs defines anv/icl: Add #define genX anv/icl: Don't set ResetGatewayTimer anv/icl: Don't use SingleVertexDispatch anv/icl: Don't use DISPATCH_MODE_SIMD4X2 anv/icl: Generate gen11 entry point functions anv/icl: Build anv libs for gen11 anv/icl: Use gen11 functions anv/icl: Enable float blend optimization anv/icl: Add render target flush after uploading binding table src/intel/Android.vulkan.mk | 21 + src/intel/Makefile.sources | 4 src/intel/Makefile.vulkan.am| 7 ++- src/intel/vulkan/anv_blorp.c| 3 +++ src/intel/vulkan/anv_device.c | 3 +++ src/intel/vulkan/anv_entrypoints_gen.py | 6 +- src/intel/vulkan/anv_private.h | 14 ++ src/intel/vulkan/genX_cmd_buffer.c | 21 + src/intel/vulkan/genX_pipeline.c| 11 +++ src/intel/vulkan/genX_state.c | 2 +- src/intel/vulkan/meson.build| 2 +- 11 files changed, 90 insertions(+), 4 deletions(-) -- 2.13.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: remap query types to hw support.
This also fixes:
dEQP-GLES3.functional.transform_feedback.array.separate*
dEQP-GLES3.functional.transform_feedback.array_element*
dEQP-GLES3.functional.transform_feedback.interpolation.*
Gallium's p_defines.h and virglrenderer's p_defines.h have diverged
quite a bit, so not including
PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE there makes sense for now.
Reviewed-by: Gurchetan Singh
Tested-by: Gurchetan Singh
On Tue, Feb 13, 2018 at 6:58 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> The gallium query types changed, so we need to remap from the
> gallium ones to the virgl ones.
>
> Fixes:
> dEQP-GLES3.functional.transform_feedback.basic_types*
>
> Fixes: 3f6b3d9db (gallium: add PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE)
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/virgl/virgl_query.c | 37
> +++--
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_query.c
> b/src/gallium/drivers/virgl/virgl_query.c
> index e6ca4609c03..3a930d29666 100644
> --- a/src/gallium/drivers/virgl/virgl_query.c
> +++ b/src/gallium/drivers/virgl/virgl_query.c
> @@ -37,6 +37,39 @@ struct virgl_query {
> unsigned result_size;
> unsigned result_gotten_sent;
> };
> +#define VIRGL_QUERY_OCCLUSION_COUNTER 0
> +#define VIRGL_QUERY_OCCLUSION_PREDICATE 1
> +#define VIRGL_QUERY_TIMESTAMP 2
> +#define VIRGL_QUERY_TIMESTAMP_DISJOINT3
> +#define VIRGL_QUERY_TIME_ELAPSED 4
> +#define VIRGL_QUERY_PRIMITIVES_GENERATED 5
> +#define VIRGL_QUERY_PRIMITIVES_EMITTED6
> +#define VIRGL_QUERY_SO_STATISTICS 7
> +#define VIRGL_QUERY_SO_OVERFLOW_PREDICATE 8
> +#define VIRGL_QUERY_GPU_FINISHED 9
> +#define VIRGL_QUERY_PIPELINE_STATISTICS 10
> +
> +static const int pquery_map[] =
> +{
> + VIRGL_QUERY_OCCLUSION_COUNTER,
> + VIRGL_QUERY_OCCLUSION_PREDICATE,
> + -1,
> + VIRGL_QUERY_TIMESTAMP,
> + VIRGL_QUERY_TIMESTAMP_DISJOINT,
> + VIRGL_QUERY_TIME_ELAPSED,
> + VIRGL_QUERY_PRIMITIVES_GENERATED,
> + VIRGL_QUERY_PRIMITIVES_EMITTED,
> + VIRGL_QUERY_SO_STATISTICS,
> + VIRGL_QUERY_SO_OVERFLOW_PREDICATE,
> + -1,
> + VIRGL_QUERY_GPU_FINISHED,
> + VIRGL_QUERY_PIPELINE_STATISTICS,
> +};
> +
> +static int pipe_to_virgl_query(enum pipe_query_type ptype)
> +{
> + return pquery_map[ptype];
> +}
>
> static inline struct virgl_query *virgl_query(struct pipe_query *q)
> {
> @@ -75,11 +108,11 @@ static struct pipe_query *virgl_create_query(struct
> pipe_context *ctx,
> }
>
> handle = virgl_object_assign_handle();
> - query->type = query_type;
> + query->type = pipe_to_virgl_query(query_type);
> query->index = index;
> query->handle = handle;
> query->buf->clean = FALSE;
> - virgl_encoder_create_query(vctx, handle, query_type, index, query->buf,
> 0);
> + virgl_encoder_create_query(vctx, handle, query->type, index, query->buf,
> 0);
>
> return (struct pipe_query *)query;
> }
> --
> 2.14.3
>
> ___
> 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] meson: Add Haiku platform support
February 15, 2018 6:36 PM, "Dylan Baker" wrote: > Quoting Alexander von Gluck IV (2018-02-15 16:04:37) > >> I'm actually not 100% sure here. I have missing symbols at link without both >> included. More investigation needed on my part. > > That may be my fault, on Linux and the BSDs have have to have shared_glapi > because you need it to do GLES, but if you're not doing GLES you should set > shared-glapi to false and then it should work. If you don't get it figured out > I'm looking at Windows (non-cygwin) right now, and that requires non-shared > glapi, so if I run into problems there I'll be sure to ping you :) Thanks! Are things in a good enough state for a "Reviewed-by"? There's more work to be done, but this gets the initial (and furthest reaching) work done. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] radeonsi: add nir shader cache support
In future we might want to try avoid calling nir_serialize() but
this works for now.
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 41 ++---
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 8c9b5a0099..357c75aa37 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -26,6 +26,7 @@
#include "gfx9d.h"
#include "radeon/r600_cs.h"
+#include "compiler/nir/nir_serialize.h"
#include "tgsi/tgsi_parse.h"
#include "tgsi/tgsi_ureg.h"
#include "util/hash_table.h"
@@ -42,22 +43,40 @@
/* SHADER_CACHE */
/**
- * Return the TGSI binary in a buffer. The first 4 bytes contain its size as
- * integer.
+ * Return the IR binary in a buffer. For TGSI the first 4 bytes contain its
+ * size as integer.
*/
-static void *si_get_tgsi_binary(struct si_shader_selector *sel)
+static void *si_get_ir_binary(struct si_shader_selector *sel)
{
- unsigned tgsi_size = tgsi_num_tokens(sel->tokens) *
-sizeof(struct tgsi_token);
- unsigned size = 4 + tgsi_size + sizeof(sel->so);
- char *result = (char*)MALLOC(size);
+ struct blob blob;
+ unsigned ir_size;
+ void *ir_binary;
+
+ if (sel->tokens) {
+ ir_binary = sel->tokens;
+ ir_size = tgsi_num_tokens(sel->tokens) *
+ sizeof(struct tgsi_token);
+ } else {
+ assert(sel->nir);
+
+ blob_init(&blob);
+ nir_serialize(&blob, sel->nir);
+ ir_binary = blob.data;
+ ir_size = blob.size;
+ }
+ unsigned size = 4 + ir_size + sizeof(sel->so);
+ char *result = (char*)MALLOC(size);
if (!result)
return NULL;
*((uint32_t*)result) = size;
- memcpy(result + 4, sel->tokens, tgsi_size);
- memcpy(result + 4 + tgsi_size, &sel->so, sizeof(sel->so));
+ memcpy(result + 4, ir_binary, ir_size);
+ memcpy(result + 4 + ir_size, &sel->so, sizeof(sel->so));
+
+ if (sel->nir)
+ blob_finish(&blob);
+
return result;
}
@@ -1813,8 +1832,8 @@ static void si_init_shader_selector_async(void *job, int
thread_index)
sel->so.num_outputs != 0,
&shader->key);
- if (sel->tokens)
- ir_binary = si_get_tgsi_binary(sel);
+ if (sel->tokens || sel->nir)
+ ir_binary = si_get_ir_binary(sel);
/* Try to load the shader from the shader cache. */
mtx_lock(&sscreen->shader_cache_mutex);
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] st/shader_cache: copy nir pointer to gl_program after deserializing
This fixes a crash when running the arb_get_program_binary-api-errors
piglit test twice.
---
src/mesa/state_tracker/st_shader_cache.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/state_tracker/st_shader_cache.c
b/src/mesa/state_tracker/st_shader_cache.c
index 6ff404220a..3ca3fef1df 100644
--- a/src/mesa/state_tracker/st_shader_cache.c
+++ b/src/mesa/state_tracker/st_shader_cache.c
@@ -215,6 +215,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
stvp->tgsi.type = PIPE_SHADER_IR_NIR;
stvp->shader_program = shProg;
stvp->tgsi.ir.nir = nir_deserialize(NULL, options, &blob_reader);
+ prog->nir = stvp->tgsi.ir.nir;
} else {
read_tgsi_from_cache(&blob_reader, &stvp->tgsi.tokens,
&stvp->num_tgsi_tokens);
@@ -237,6 +238,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
sttcp->tgsi.type = PIPE_SHADER_IR_NIR;
sttcp->shader_program = shProg;
sttcp->tgsi.ir.nir = nir_deserialize(NULL, options, &blob_reader);
+ prog->nir = sttcp->tgsi.ir.nir;
} else {
read_tgsi_from_cache(&blob_reader, &sttcp->tgsi.tokens,
&sttcp->num_tgsi_tokens);
@@ -259,6 +261,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
sttep->tgsi.type = PIPE_SHADER_IR_NIR;
sttep->shader_program = shProg;
sttep->tgsi.ir.nir = nir_deserialize(NULL, options, &blob_reader);
+ prog->nir = sttep->tgsi.ir.nir;
} else {
read_tgsi_from_cache(&blob_reader, &sttep->tgsi.tokens,
&sttep->num_tgsi_tokens);
@@ -281,6 +284,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
stgp->tgsi.type = PIPE_SHADER_IR_NIR;
stgp->shader_program = shProg;
stgp->tgsi.ir.nir = nir_deserialize(NULL, options, &blob_reader);
+ prog->nir = stgp->tgsi.ir.nir;
} else {
read_tgsi_from_cache(&blob_reader, &stgp->tgsi.tokens,
&stgp->num_tgsi_tokens);
@@ -300,6 +304,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
stfp->tgsi.type = PIPE_SHADER_IR_NIR;
stfp->shader_program = shProg;
stfp->tgsi.ir.nir = nir_deserialize(NULL, options, &blob_reader);
+ prog->nir = stfp->tgsi.ir.nir;
} else {
read_tgsi_from_cache(&blob_reader, &stfp->tgsi.tokens,
&stfp->num_tgsi_tokens);
@@ -319,6 +324,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
stcp->tgsi.ir_type = PIPE_SHADER_IR_NIR;
stcp->shader_program = shProg;
stcp->tgsi.prog = nir_deserialize(NULL, options, &blob_reader);
+ prog->nir = (nir_shader *) stcp->tgsi.prog;
} else {
read_tgsi_from_cache(&blob_reader,
(const struct tgsi_token**) &stcp->tgsi.prog,
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] radeonsi: rename variables tgsi_binary -> ir_binary
This better represents that the ir could be either tgsi or nir.
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 42 -
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 2c1d9901ce..8c9b5a0099 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -182,10 +182,10 @@ static bool si_load_shader_binary(struct si_shader
*shader, void *binary)
* Insert a shader into the cache. It's assumed the shader is not in the cache.
* Use si_shader_cache_load_shader before calling this.
*
- * Returns false on failure, in which case the tgsi_binary should be freed.
+ * Returns false on failure, in which case the ir_binary should be freed.
*/
static bool si_shader_cache_insert_shader(struct si_screen *sscreen,
- void *tgsi_binary,
+ void *ir_binary,
struct si_shader *shader,
bool insert_into_disk_cache)
{
@@ -193,7 +193,7 @@ static bool si_shader_cache_insert_shader(struct si_screen
*sscreen,
struct hash_entry *entry;
uint8_t key[CACHE_KEY_SIZE];
- entry = _mesa_hash_table_search(sscreen->shader_cache, tgsi_binary);
+ entry = _mesa_hash_table_search(sscreen->shader_cache, ir_binary);
if (entry)
return false; /* already added */
@@ -201,15 +201,15 @@ static bool si_shader_cache_insert_shader(struct
si_screen *sscreen,
if (!hw_binary)
return false;
- if (_mesa_hash_table_insert(sscreen->shader_cache, tgsi_binary,
+ if (_mesa_hash_table_insert(sscreen->shader_cache, ir_binary,
hw_binary) == NULL) {
FREE(hw_binary);
return false;
}
if (sscreen->disk_shader_cache && insert_into_disk_cache) {
- disk_cache_compute_key(sscreen->disk_shader_cache, tgsi_binary,
- *((uint32_t *)tgsi_binary), key);
+ disk_cache_compute_key(sscreen->disk_shader_cache, ir_binary,
+ *((uint32_t *)ir_binary), key);
disk_cache_put(sscreen->disk_shader_cache, key, hw_binary,
*((uint32_t *) hw_binary), NULL);
}
@@ -218,18 +218,18 @@ static bool si_shader_cache_insert_shader(struct
si_screen *sscreen,
}
static bool si_shader_cache_load_shader(struct si_screen *sscreen,
- void *tgsi_binary,
+ void *ir_binary,
struct si_shader *shader)
{
struct hash_entry *entry =
- _mesa_hash_table_search(sscreen->shader_cache, tgsi_binary);
+ _mesa_hash_table_search(sscreen->shader_cache, ir_binary);
if (!entry) {
if (sscreen->disk_shader_cache) {
unsigned char sha1[CACHE_KEY_SIZE];
- size_t tg_size = *((uint32_t *) tgsi_binary);
+ size_t tg_size = *((uint32_t *) ir_binary);
disk_cache_compute_key(sscreen->disk_shader_cache,
- tgsi_binary, tg_size, sha1);
+ ir_binary, tg_size, sha1);
size_t binary_size;
uint8_t *buffer =
@@ -260,15 +260,15 @@ static bool si_shader_cache_load_shader(struct si_screen
*sscreen,
}
free(buffer);
- if (!si_shader_cache_insert_shader(sscreen, tgsi_binary,
+ if (!si_shader_cache_insert_shader(sscreen, ir_binary,
shader, false))
- FREE(tgsi_binary);
+ FREE(ir_binary);
} else {
return false;
}
} else {
if (si_load_shader_binary(shader, entry->data))
- FREE(tgsi_binary);
+ FREE(ir_binary);
else
return false;
}
@@ -1797,7 +1797,7 @@ static void si_init_shader_selector_async(void *job, int
thread_index)
*/
if (!sscreen->use_monolithic_shaders) {
struct si_shader *shader = CALLOC_STRUCT(si_shader);
- void *tgsi_binary = NULL;
+ void *ir_binary = NULL;
if (!shader) {
fprintf(stderr, "radeonsi: can't allocate a main shader
part\n");
@@ -1814,13 +1814,13 @@ static void si_init_shader_selector_async(void *job,
int thread_index)
Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support
Quoting Alexander von Gluck IV (2018-02-15 16:04:37) > I'm actually not 100% sure here. I have missing symbols at link without both > included. More investigation needed on my part. That may be my fault, on Linux and the BSDs have have to have shared_glapi because you need it to do GLES, but if you're not doing GLES you should set shared-glapi to false and then it should work. If you don't get it figured out I'm looking at Windows (non-cygwin) right now, and that requires non-shared glapi, so if I run into problems there I'll be sure to ping you :) Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] meson: Add Haiku platform support v3
---
include/meson.build| 8 +
meson.build| 18 +++
src/egl/meson.build| 34 -
src/gallium/meson.build| 9 ++
src/gallium/state_trackers/hgl/meson.build | 41 ++
src/gallium/targets/haiku-softpipe/meson.build | 40 +
src/gallium/winsys/sw/hgl/meson.build | 29 ++
src/hgl/GLDispatcher.h | 2 +-
src/hgl/meson.build| 36 ++
src/mapi/es1api/meson.build| 2 +-
src/mapi/es2api/meson.build| 2 +-
src/meson.build| 7 -
12 files changed, 211 insertions(+), 17 deletions(-)
create mode 100644 src/gallium/state_trackers/hgl/meson.build
create mode 100644 src/gallium/targets/haiku-softpipe/meson.build
create mode 100644 src/gallium/winsys/sw/hgl/meson.build
create mode 100644 src/hgl/meson.build
diff --git a/include/meson.build b/include/meson.build
index 1cbc68182c..28ffb33215 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -22,6 +22,7 @@ inc_drm_uapi = include_directories('drm-uapi')
inc_vulkan = include_directories('vulkan')
inc_d3d9 = include_directories('D3D9')
inc_gl_internal = include_directories('GL/internal')
+inc_haikugl = include_directories('HaikuGL')
if with_gles1
install_headers(
@@ -80,6 +81,13 @@ if with_gallium_st_nine
)
endif
+if with_platform_haiku
+ install_headers(
+'HaikuGL/GLRenderer.h', 'HaikuGL/GLView.h', 'HaikuGL/OpenGLKit.h',
+subdir : 'opengl',
+ )
+endif
+
# Only install the headers if we are building a stand alone implementation and
# not an ICD enabled implementation
if with_gallium_opencl and not with_opencl_icd
diff --git a/meson.build b/meson.build
index d6ffa30d9e..30e8a9e9ff 100644
--- a/meson.build
+++ b/meson.build
@@ -99,7 +99,7 @@ if _drivers == 'auto'
else
error('Unknown architecture. Please pass -Ddri-drivers to set driver
options. Patches gladly accepted to fix this.')
endif
- elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+ elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
# only swrast would make sense here, but gallium swrast is a much better
default
_drivers = ''
else
@@ -144,7 +144,7 @@ if _drivers == 'auto'
else
error('Unknown architecture. Please pass -Dgallium-drivers to set driver
options. Patches gladly accepted to fix this.')
endif
- elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+ elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
_drivers = 'swrast'
else
error('Unknown OS. Please pass -Dgallium-drivers to set driver options.
Patches gladly accepted to fix this.')
@@ -181,7 +181,7 @@ if _vulkan_drivers == 'auto'
else
error('Unknown architecture. Please pass -Dvulkan-drivers to set driver
options. Patches gladly accepted to fix this.')
endif
- elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+ elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
# No vulkan driver supports windows or macOS currently
_vulkan_drivers = ''
else
@@ -242,6 +242,8 @@ if _platforms == 'auto'
_platforms = 'x11,wayland,drm,surfaceless'
elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
_platforms = 'x11,surfaceless'
+ elif ['haiku'].contains(host_machine.system())
+_platforms = 'haiku'
else
error('Unknown OS. Please pass -Dplatforms to set platforms. Patches
gladly accepted to fix this.')
endif
@@ -252,6 +254,7 @@ if _platforms != ''
with_platform_x11 = _split.contains('x11')
with_platform_wayland = _split.contains('wayland')
with_platform_drm = _split.contains('drm')
+ with_platform_haiku = _split.contains('haiku')
with_platform_surfaceless = _split.contains('surfaceless')
egl_native_platform = _split[0]
endif
@@ -260,6 +263,8 @@ with_glx = get_option('glx')
if with_glx == 'auto'
if with_dri
with_glx = 'dri'
+ elif with_platform_haiku
+with_glx = 'disabled'
elif with_gallium
# Even when building just gallium drivers the user probably wants dri
with_glx = 'dri'
@@ -375,7 +380,7 @@ if with_any_vk and (with_platform_x11 and not with_dri3)
error('Vulkan drivers require dri3 for X11 support')
endif
if with_dri or with_gallium
- if with_glx == 'disabled' and not with_egl
+ if with_glx == 'disabled' and not with_egl and not with_platform_haiku
error('building dri or gallium drivers require at least one window system')
endif
endif
@@ -642,6 +647,9 @@ if with_platform_android
]
pre_args += '-DHAVE_ANDROID_PLATFORM'
endif
+if with_platform_haiku
+ pre_args += '-DHAVE_HAIKU_PLATFORM'
+endif
prog_python2 = find_program('pyt
Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support
February 15, 2018 5:37 PM, "Dylan Baker" wrote:
> Quoting Alexander von Gluck IV (2018-02-15 13:12:40)
>
>> ---
>> include/meson.build | 8 +
>> meson.build | 18 +++---
>> src/egl/meson.build | 33 +
>> src/gallium/meson.build | 9 +
>> src/gallium/state_trackers/hgl/meson.build | 41 +
>> src/gallium/targets/haiku-softpipe/meson.build | 50
>> ++
>> src/gallium/winsys/sw/hgl/meson.build | 29 +++
>> src/hgl/GLDispatcher.h | 2 +-
>> src/hgl/meson.build | 38
>> src/mapi/es1api/meson.build | 2 +-
>> src/mapi/es2api/meson.build | 2 +-
>> src/meson.build | 7 +++-
>> 12 files changed, 224 insertions(+), 15 deletions(-)
>> create mode 100644 src/gallium/state_trackers/hgl/meson.build
>> create mode 100644 src/gallium/targets/haiku-softpipe/meson.build
>> create mode 100644 src/gallium/winsys/sw/hgl/meson.build
>> create mode 100644 src/hgl/meson.build
>
> This doesn't feel quite right now, this code is DRI2 specific, I think this
> should go in the `if with_dri2` block, or put that in this block.
Ooops.. I agree. That else fits better in the existing with_dri2.
Fixed locally... will resubmit v3
>> diff --git a/src/gallium/targets/haiku-softpipe/meson.build
>> b/src/gallium/targets/haiku-softpipe/meson.build
>> new file mode 100644
>> index 00..f805b2e69b
>> --- /dev/null
>> +++ b/src/gallium/targets/haiku-softpipe/meson.build
>> @@ -0,0 +1,50 @@
>> +# Copyright © 2017 Dylan Baker
>> +
>> +# 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 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.
>> +
>> +hsp_cpp_args = ['-DGALLIUM_SOFTPIPE', '-DGALLIUM_RBUG', '-DGALLIUM_TRACE']
>> +hsp_deps = []
>> +hsp_links = [libsoftpipe]
>> +
>> +if with_llvm
>> + hsp_deps += dep_llvm
>> + hsp_cpp_args += '-DGALLIUM_LLVMPIPE'
>> + hsp_links += libllvmpipe
>> +endif
>
> This is the old way we did things, now we have these handy `driver_*`
> dependencies that provide this stuff, you can replace the hsp_links, hsp_deps,
> and drop the -DGALLIUM_{SOFT,LLVM}PIPE with driver_swrast, which handles
> adding
> the -DGALLIUM args and has softpipe or llvmpipe if it's enabled.
>
> You can look at src/gallium/targets/dri/meson.build if you want to see how
> that
> works.
Will fix.
>> +libswhgl = static_library(
>> + 'swhgl',
>> + files('hgl_sw_winsys.c', 'hgl_sw_winsys.h'),
>
> It doesn't matter, but you don't need to add the .h file, meson will figure
> that
> out.
I was following some patterns I was seeing. Fixed locally :-)
>> +libgl = shared_library(
>> + 'GL',
>> + files(
>> + 'GLView.cpp', 'GLRenderer.cpp', 'GLRendererRoster.cpp', 'GLDispatcher.cpp',
>> + ),
>> + link_args : [ld_args_bsymbolic, ld_args_gc_sections],
>> + include_directories : [
>> + inc_src, inc_mapi, inc_mesa, inc_include, inc_glapi, inc_haikugl,
>> + inc_gl_internal, include_directories('/system/develop/headers/private')
>> + ],
>> + link_with : [libglapi_static, libglapi],
>
> this seems odd, why do you need both shared and static glapi? In SCons only
> static glapi is used here.
I'm actually not 100% sure here. I have missing symbols at link without both
included. More investigation needed on my part.
>> + dependencies : cpp.find_library('be'),
>> + install : true,
>> +)
>> +
>> +#if with_tests
>> +# subdir('tests')
>> +#endif
>
> I'd prefer not to have the commented code, let's either implement the tests or
> delete this and ad a TODO
Fixed locally in v3.
Thanks!
-- Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support
Quoting Alexander von Gluck IV (2018-02-15 13:12:40)
> ---
> include/meson.build| 8 +
> meson.build| 18 +++---
> src/egl/meson.build| 33 +
> src/gallium/meson.build| 9 +
> src/gallium/state_trackers/hgl/meson.build | 41 +
> src/gallium/targets/haiku-softpipe/meson.build | 50
> ++
> src/gallium/winsys/sw/hgl/meson.build | 29 +++
> src/hgl/GLDispatcher.h | 2 +-
> src/hgl/meson.build| 38
> src/mapi/es1api/meson.build| 2 +-
> src/mapi/es2api/meson.build| 2 +-
> src/meson.build| 7 +++-
> 12 files changed, 224 insertions(+), 15 deletions(-)
> create mode 100644 src/gallium/state_trackers/hgl/meson.build
> create mode 100644 src/gallium/targets/haiku-softpipe/meson.build
> create mode 100644 src/gallium/winsys/sw/hgl/meson.build
> create mode 100644 src/hgl/meson.build
>
> diff --git a/include/meson.build b/include/meson.build
> index 1cbc68182c..28ffb33215 100644
> --- a/include/meson.build
> +++ b/include/meson.build
> @@ -22,6 +22,7 @@ inc_drm_uapi = include_directories('drm-uapi')
> inc_vulkan = include_directories('vulkan')
> inc_d3d9 = include_directories('D3D9')
> inc_gl_internal = include_directories('GL/internal')
> +inc_haikugl = include_directories('HaikuGL')
>
> if with_gles1
>install_headers(
> @@ -80,6 +81,13 @@ if with_gallium_st_nine
>)
> endif
>
> +if with_platform_haiku
> + install_headers(
> +'HaikuGL/GLRenderer.h', 'HaikuGL/GLView.h', 'HaikuGL/OpenGLKit.h',
> +subdir : 'opengl',
> + )
> +endif
> +
> # Only install the headers if we are building a stand alone implementation
> and
> # not an ICD enabled implementation
> if with_gallium_opencl and not with_opencl_icd
> diff --git a/meson.build b/meson.build
> index 3925ec483e..d476f70bbe 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -103,7 +103,7 @@ if _drivers == 'auto'
> else
>error('Unknown architecture. Please pass -Ddri-drivers to set driver
> options. Patches gladly accepted to fix this.')
> endif
> - elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> + elif ['darwin', 'windows', 'cygwin',
> 'haiku'].contains(host_machine.system())
> # only swrast would make sense here, but gallium swrast is a much better
> default
> _drivers = ''
>else
> @@ -148,7 +148,7 @@ if _drivers == 'auto'
> else
>error('Unknown architecture. Please pass -Dgallium-drivers to set
> driver options. Patches gladly accepted to fix this.')
> endif
> - elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> + elif ['darwin', 'windows', 'cygwin',
> 'haiku'].contains(host_machine.system())
> _drivers = 'swrast'
>else
> error('Unknown OS. Please pass -Dgallium-drivers to set driver options.
> Patches gladly accepted to fix this.')
> @@ -185,7 +185,7 @@ if _vulkan_drivers == 'auto'
> else
>error('Unknown architecture. Please pass -Dvulkan-drivers to set
> driver options. Patches gladly accepted to fix this.')
> endif
> - elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> + elif ['darwin', 'windows', 'cygwin',
> 'haiku'].contains(host_machine.system())
> # No vulkan driver supports windows or macOS currently
> _vulkan_drivers = ''
>else
> @@ -246,6 +246,8 @@ if _platforms == 'auto'
> _platforms = 'x11,wayland,drm,surfaceless'
>elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> _platforms = 'x11,surfaceless'
> + elif ['haiku'].contains(host_machine.system())
> +_platforms = 'haiku'
>else
> error('Unknown OS. Please pass -Dplatforms to set platforms. Patches
> gladly accepted to fix this.')
>endif
> @@ -256,6 +258,7 @@ if _platforms != ''
>with_platform_x11 = _split.contains('x11')
>with_platform_wayland = _split.contains('wayland')
>with_platform_drm = _split.contains('drm')
> + with_platform_haiku = _split.contains('haiku')
>with_platform_surfaceless = _split.contains('surfaceless')
>egl_native_platform = _split[0]
> endif
> @@ -264,6 +267,8 @@ with_glx = get_option('glx')
> if with_glx == 'auto'
>if with_dri
> with_glx = 'dri'
> + elif with_platform_haiku
> +with_glx = 'disabled'
>elif with_gallium
> # Even when building just gallium drivers the user probably wants dri
> with_glx = 'dri'
> @@ -379,7 +384,7 @@ if with_any_vk and (with_platform_x11 and not with_dri3)
>error('Vulkan drivers require dri3 for X11 support')
> endif
> if with_dri or with_gallium
> - if with_glx == 'disabled' and not with_egl
> + if with_glx == 'disabled' and not with_egl and not with_platform_haiku
> error('buil
Re: [Mesa-dev] [PATCH 06/13] vbo: Use _DrawVAO for array type draw commands.
On 02/15/2018 12:55 PM, mathias.froehl...@gmx.net wrote:
From: Mathias Fröhlich
Switch over to use the _DrawVAO for all the array type draws.
The _DrawVAO needs to be set before we enter _mesa_update_state,
so move setting the draw method in front of the first call
to _mesa_update_state which is in turn called from the *validate*Draw*
calls. Using the gl_vertex_array_object::_Enabled bitmask,
gl_vertex_program_state::_VPMode and gl_vertex_array_object::_AttributeMapMode
we can already set varying_vp_inputs before we call _mesa_update_state
the first time. Thus remove duplicate state validation.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_context.c| 8 ++-
src/mesa/vbo/vbo_exec.h | 6 --
src/mesa/vbo/vbo_exec_array.c | 159 +-
3 files changed, 100 insertions(+), 73 deletions(-)
diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index cc9cbffc51..1a9935d5e8 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -206,11 +206,15 @@ vbo_exec_invalidate_state(struct gl_context *ctx)
struct vbo_exec_context *exec = &vbo->exec;
if (ctx->NewState & (_NEW_PROGRAM | _NEW_ARRAY)) {
- if (!exec->validating)
- exec->array.recalculate_inputs = GL_TRUE;
+ exec->array.recalculate_inputs = GL_TRUE;
_ae_invalidate_state(ctx);
}
+ /* If _mesa_update_state is called in a non draw code path,
+* changes in the VAO need to be captured.
+*/
+ if (ctx->Array.VAO->NewArrays)
+ exec->array.recalculate_inputs = GL_TRUE;
if (ctx->NewState & _NEW_EVAL)
exec->eval.recalculate_maps = GL_TRUE;
diff --git a/src/mesa/vbo/vbo_exec.h b/src/mesa/vbo/vbo_exec.h
index 7e00d45de0..b00045c7c8 100644
--- a/src/mesa/vbo/vbo_exec.h
+++ b/src/mesa/vbo/vbo_exec.h
@@ -76,7 +76,6 @@ struct vbo_exec_context
struct gl_context *ctx;
GLvertexformat vtxfmt;
GLvertexformat vtxfmt_noop;
- GLboolean validating; /**< if we're in the middle of state validation */
struct {
struct gl_buffer_object *bufferobj;
@@ -119,11 +118,6 @@ struct vbo_exec_context
} eval;
struct {
- /* Arrays and current values manipulated according to program
- * mode, etc. These are the attributes as seen by vertex
- * programs:
- */
- const struct gl_vertex_array *inputs[VERT_ATTRIB_MAX];
GLboolean recalculate_inputs;
} array;
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 0c3c9017b1..5741696943 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -319,29 +319,14 @@ print_draw_arrays(struct gl_context *ctx,
/**
- * Set the vbo->exec->inputs[] pointers to point to the enabled
- * vertex arrays. This depends on the current vertex program/shader
- * being executed because of whether or not generic vertex arrays
- * alias the conventional vertex arrays.
- * For arrays that aren't enabled, we set the input[attrib] pointer
- * to point at a zero-stride current value "array".
+ * Return a filter mask for the net enabled vao arrays.
+ * This is to maks out arrays that would otherwise superseed required current
"mask", "supersede"
I don't have time to review the rest of the series today. I'll try to
resume tomorrow.
-Brian
+ * values for the fixed function shaders for example.
*/
-static void
-recalculate_input_bindings(struct gl_context *ctx)
+static GLbitfield
+enabled_filter(const struct gl_context *ctx)
{
- struct vbo_context *vbo = vbo_context(ctx);
- struct vbo_exec_context *exec = &vbo->exec;
- const struct gl_vertex_array_object *vao = ctx->Array.VAO;
- const struct gl_vertex_array *vertexAttrib = vao->_VertexArray;
- const struct gl_vertex_array **inputs = &exec->array.inputs[0];
-
- /* May shuffle the position and generic0 bits around */
- GLbitfield vp_inputs = _mesa_get_vao_vp_inputs(vao);
-
- const gl_vertex_processing_mode processing_mode
- = ctx->VertexProgram._VPMode;
- const GLubyte * const map = _vbo_attribute_alias_map[processing_mode];
- switch (processing_mode) {
+ switch (ctx->VertexProgram._VPMode) {
case VP_MODE_FF:
/* When no vertex program is active (or the vertex program is generated
* from fixed-function state). We put the material values into the
@@ -349,9 +334,7 @@ recalculate_input_bindings(struct gl_context *ctx)
* slots from the enabled arrays so that the current material values
* are pulled instead of the vao arrays.
*/
- vp_inputs &= VERT_BIT_FF_ALL;
-
- break;
+ return VERT_BIT_FF_ALL;
case VP_MODE_SHADER:
/* There are no shaders in OpenGL ES 1.x, so this code path should be
@@ -360,40 +343,20 @@ recalculate_input_bindings(struct gl_context *ctx)
*/
assert(ctx->API != API_OPENGLES);
- /* In the compatibility profile of desktop OpenGL, the generic[0]
- * a
Re: [Mesa-dev] [PATCH 05/13] vbo: Implement method to track the inputs array.
On 02/15/2018 12:55 PM, mathias.froehl...@gmx.net wrote:
From: Mathias Fröhlich
Provided the _DrawVAO and the derived state that is
maintained if we have the _DrawVAO set, implement a
method to incrementally update the array of
gl_vertex_array input pointers.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo.h | 28 +
src/mesa/vbo/vbo_context.c | 1 +
src/mesa/vbo/vbo_exec.c| 76 ++
src/mesa/vbo/vbo_private.h | 2 ++
4 files changed, 107 insertions(+)
diff --git a/src/mesa/vbo/vbo.h b/src/mesa/vbo/vbo.h
index d594ba8f6a..bb8ab7a745 100644
--- a/src/mesa/vbo/vbo.h
+++ b/src/mesa/vbo/vbo.h
@@ -254,6 +254,34 @@ vbo_sw_primitive_restart(struct gl_context *ctx,
const struct _mesa_index_buffer *ib,
struct gl_buffer_object *indirect);
+
+/**
+ * Utility that tracks and updates the current array entries.
+ */
+struct vbo_inputs
+{
+ const struct gl_vertex_array *inputs[VERT_ATTRIB_MAX];
+ GLbitfield current;
/* Can you put a comment on the 'current' field?
+ gl_vertex_processing_mode vertex_processing_mode;
+};
+
+
+/**
+ * Initialize inputs.
+ */
+void
+_vbo_array_init(struct vbo_inputs *inputs);
+
+
+/**
+ * Update the gl_vertex_array array inside the vbo_inputs structure
+ * provided the current _VPMode, the provided vao and
+ * the vao's enabled arrays filtered by the filter bitmask.
+ */
+void
+_vbo_update_inputs(struct gl_context *ctx, struct vbo_inputs *inputs);
If that struct and the two prototypes aren't going to be used outside
the VBO module, they should go into vbo_private.h
+
+
void GLAPIENTRY
_es_Color4f(GLfloat r, GLfloat g, GLfloat b, GLfloat a);
diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index 5bc6bf0acd..cc9cbffc51 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -234,6 +234,7 @@ _vbo_CreateContext(struct gl_context *ctx)
init_legacy_currval(ctx);
init_generic_currval(ctx);
init_mat_currval(ctx);
+ _vbo_array_init(&vbo->array);
vbo_set_indirect_draw_func(ctx, vbo_draw_indirect_prims);
/* make sure all VBO_ATTRIB_ values can fit in an unsigned byte */
diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c
index 372d0237aa..c5f01e3e4d 100644
--- a/src/mesa/vbo/vbo_exec.c
+++ b/src/mesa/vbo/vbo_exec.c
@@ -27,6 +27,7 @@
#include "main/glheader.h"
+#include "main/arrayobj.h"
#include "main/mtypes.h"
#include "main/api_arrayelt.h"
#include "main/vtxfmt.h"
@@ -240,3 +241,78 @@ vbo_merge_prims(struct _mesa_prim *p0, const struct
_mesa_prim *p1)
p0->count += p1->count;
p0->end = p1->end;
}
+
+
+void
+_vbo_array_init(struct vbo_inputs *inputs)
The function name doesn't seem to really match what it does. Maybe
_vbo_init_inputs() ?
+{
+ inputs->current = 0;
+ inputs->vertex_processing_mode = VP_MODE_FF;
+}
+
+
+/**
+ * Update those gl_vertex_array array inside the vbo_inputs structure
+ * from the enable bits pointing into the provided vao.
+ */
+static inline void
+update_vao_inputs(struct gl_context *ctx,
+ struct vbo_inputs *inputs, GLbitfield enable)
+{
+ const struct gl_vertex_array_object *vao = ctx->Array._DrawVAO;
+
+ /* Make sure we process only arrays enabled in the VAO */
+ assert((enable & ~_mesa_get_vao_vp_inputs(vao)) == 0);
+
+ /* Fill in the client arrays from the VAO */
+ const GLubyte *const map = _mesa_vao_attribute_map[vao->_AttributeMapMode];
+ const struct gl_vertex_array *array = vao->_VertexArray;
+ const struct gl_vertex_array **iarray = &inputs->inputs[0];
+ while (enable) {
+ const int attr = u_bit_scan(&enable);
+ iarray[attr] = &array[map[attr]];
+ }
+}
+
+
+/**
+ * Update those gl_vertex_array array inside the vbo_inputs structure
+ * from the current bits pointing into the current values.
How about:
Update the vbo_inputs's arrays to point to the vbo->currval arrays
according to the 'current' bitmask.
\param current bitfield of VERT_BIT_x flags.
+ */
+static inline void
+update_current_inputs(struct gl_context *ctx,
+ struct vbo_inputs *inputs, GLbitfield current)
+{
+ gl_vertex_processing_mode mode = ctx->VertexProgram._VPMode;
+
+ /* All previously non current array pointers need update. */
+ GLbitfield mask = current & ~inputs->current;
+ /* On mode change, the slots aliasing with materials need update too */
+ if (mode != inputs->vertex_processing_mode)
+ mask |= current & VERT_BIT_MAT_ALL;
+
+ struct vbo_context *vbo = vbo_context(ctx);
+ const struct gl_vertex_array *const currval = &vbo->currval[0];
+ const struct gl_vertex_array **iarray = &inputs->inputs[0];
+ const GLubyte *const map = _vbo_attribute_alias_map[mode];
+ while (mask) {
+ const int attr = u_bit_scan(&mask);
+ iarray[attr] = &currval[map[attr]];
+ }
+
+ inputs->current = current;
+ inputs->vert
Re: [Mesa-dev] [PATCH 04/13] mesa: Introduce a yet unused _DrawVAO.
On 02/15/2018 12:55 PM, mathias.froehl...@gmx.net wrote:
From: Mathias Fröhlich
During the patch series this VAO gets populated with
either the currently bound VAO or an internal VAO that
will be used for immediate mode and dlist rendering.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/arrayobj.c | 4
src/mesa/main/attrib.c | 2 ++
src/mesa/main/context.c | 2 ++
src/mesa/main/mtypes.h | 7 +++
src/mesa/main/state.c| 21 +
src/mesa/main/state.h| 8
src/mesa/main/varray.c | 2 ++
7 files changed, 46 insertions(+)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index a6fa33c82c..cf9c5d7ecc 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -49,6 +49,7 @@
#include "arrayobj.h"
#include "macros.h"
#include "mtypes.h"
+#include "state.h"
#include "varray.h"
#include "main/dispatch.h"
#include "util/bitscan.h"
@@ -578,6 +579,7 @@ bind_vertex_array(struct gl_context *ctx, GLuint id, bool
no_error)
* deleted.
*/
_mesa_set_drawing_arrays(ctx, NULL);
+ _mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);
ctx->NewState |= _NEW_ARRAY;
_mesa_reference_vao(ctx, &ctx->Array.VAO, newObj);
@@ -629,6 +631,8 @@ delete_vertex_arrays(struct gl_context *ctx, GLsizei n,
const GLuint *ids)
if (ctx->Array.LastLookedUpVAO == obj)
_mesa_reference_vao(ctx, &ctx->Array.LastLookedUpVAO, NULL);
+ if (ctx->Array._DrawVAO == obj)
+_mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);
/* Unreference the array object.
* If refcount hits zero, the object will be deleted.
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 398ff653b7..dd6b98ce04 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -57,6 +57,7 @@
#include "viewport.h"
#include "mtypes.h"
#include "main/dispatch.h"
+#include "state.h"
#include "hash.h"
#include
@@ -1548,6 +1549,7 @@ copy_array_attrib(struct gl_context *ctx,
/* Invalidate array state. It will be updated during the next draw. */
_mesa_set_drawing_arrays(ctx, NULL);
+ _mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);
}
/**
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 0aa2e3639f..e13343b5e6 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1335,6 +1335,8 @@ _mesa_free_context_data( struct gl_context *ctx )
_mesa_reference_vao(ctx, &ctx->Array.VAO, NULL);
_mesa_reference_vao(ctx, &ctx->Array.DefaultVAO, NULL);
+ _mesa_reference_vao(ctx, &ctx->Array._EmptyVAO, NULL);
+ _mesa_reference_vao(ctx, &ctx->Array._DrawVAO, NULL);
_mesa_free_attrib_data(ctx);
_mesa_free_buffer_objects(ctx);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 41df04d38d..b6fdb69283 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1691,6 +1691,13 @@ struct gl_array_attrib
/* GL_ARB_vertex_buffer_object */
struct gl_buffer_object *ArrayBufferObj;
+ /** Vertex array object used when no specific DrawVAO is bound */
+ struct gl_vertex_array_object *_EmptyVAO;
I'm not sure I understand the purpose of that. By "used" do you mean
when drawing?
+ /** Vertex array object used for the current draw */
+ struct gl_vertex_array_object *_DrawVAO;
+ /** The possibly reduced set of enabled vertex attributes from the above */
+ GLbitfield _DrawVAOEnabled;
_DrawVAOEnabledAttribs?
+
/**
* Vertex arrays as consumed by a driver.
* The array pointer is set up only by the VBO module.
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 2fd4fb9d32..42bf483682 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -479,3 +479,24 @@ _mesa_update_vertex_processing_mode(struct gl_context *ctx)
else
ctx->VertexProgram._VPMode = VP_MODE_FF;
}
+
+
+void
+_mesa_set_draw_vao(struct gl_context *ctx, struct gl_vertex_array_object *vao,
+ GLbitfield filter)
Can you put a comment on this function to explain it, and specifically,
the filter parameter?
+{
+ struct gl_vertex_array_object **ptr = &ctx->Array._DrawVAO;
+ if (*ptr != vao) {
+ _mesa_reference_vao_(ctx, ptr, vao);
+ ctx->NewDriverState |= ctx->DriverFlags.NewArray;
+ } else if (vao->NewArrays) {
+ ctx->NewDriverState |= ctx->DriverFlags.NewArray;
+ }
+
+ /* May shuffle the position and generic0 bits around, filter out unwanted */
+ const GLbitfield enabled = filter & _mesa_get_vao_vp_inputs(vao);
+ if (ctx->Array._DrawVAOEnabled != enabled)
+ ctx->NewDriverState |= ctx->DriverFlags.NewArray;
+ ctx->Array._DrawVAOEnabled = enabled;
+ _mesa_set_varying_vp_inputs(ctx, enabled);
+}
diff --git a/src/mesa/main/state.h b/src/mesa/main/state.h
index 049166578c..589c6650ad 100644
--- a/src/mesa/main/state.h
+++ b/src/mesa/main/state.h
@@ -53,6 +53,14 @@ extern void
_mes
Re: [Mesa-dev] [PATCH V2 16/16] i965/icl: Add render target flush after uploading binding table
On Thursday, February 15, 2018 2:16:54 PM PST Anuj Phogat wrote:
> +Ken
>
> On Thu, Feb 15, 2018 at 11:11 AM, Anuj Phogat wrote:
> > From PIPE_CONTROL command description in gfxspecs:
> >
> > "Whenever a Binding Table Index (BTI) used by a Render Taget Message
> > points to a different RENDER_SURFACE_STATE, SW must issue a Render
> > Target Cache Flush by enabling this bit. When render target flush
> > is set due to new association of BTI, PS Scoreboard Stall bit must
> > be set in this packet."
> >
> > V2: Move the PIPE_CONTROL to update_renderbuffer_surfaces() in
> > brw_wm_surface_state.c (Ken).
> >
> > Fixes a fulsim error and a GPU hang described in below JIRA.
> > JIRA: MD5-322
> > Signed-off-by: Anuj Phogat
> > ---
> > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > 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 44c87df17d..84c5a81227 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > @@ -971,6 +971,20 @@ update_renderbuffer_surfaces(struct brw_context *brw)
> >emit_null_surface_state(brw, fb, &surf_offsets[rt_start]);
> > }
> >
> > + /* From PIPE_CONTROL command description in gfxspecs:
> > +
> > + "Whenever a Binding Table Index (BTI) used by a Render Taget Message
> > + points to a different RENDER_SURFACE_STATE, SW must issue a Render
> > + Target Cache Flush by enabling this bit. When render target flush
> > + is set due to new association of BTI, PS Scoreboard Stall bit must
> > + be set in this packet."
> > + */
Mesa coding style is:
/* The PIPE_CONTROL command description says:
*
* "Whenever a Binding Table Index (BTI) used by a Render Target Message
* ...
* be set in this packet."
*/
With that fixed,
Reviewed-by: Kenneth Graunke
> > + if (devinfo->gen >= 11) {
> > + brw_emit_pipe_control_flush(brw,
> > + PIPE_CONTROL_RENDER_TARGET_FLUSH |
> > + PIPE_CONTROL_STALL_AT_SCOREBOARD);
> > + }
> > +
> > brw->ctx.NewDriverState |= BRW_NEW_SURFACES;
> > }
> >
> > --
> > 2.13.6
> >
>
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
Re: [Mesa-dev] [PATCH 11/11] egl/x11: Re-allocate buffers if format is suboptimal
On Thu, Feb 15, 2018 at 7:57 AM, Daniel Stone wrote:
> From: Louis-Francis Ratté-Boulianne
>
> If PresentCompleteNotify event says the pixmap was presented
> with mode PresentCompleteModeSuboptimalCopy, it means the pixmap
> could possibly have been flipped instead if allocated with a
> different format/modifier.
>
> Signed-off-by: Louis-Francis Ratté-Boulianne
> Reviewed-by: Daniel Stone
> Signed-off-by: Daniel Stone
> ---
> src/egl/drivers/dri2/egl_dri2.c | 2 ++
> src/egl/drivers/dri2/egl_dri2.h | 2 ++
> src/egl/drivers/dri2/platform_x11_dri3.c | 3 +++
> src/loader/loader_dri3_helper.c | 37
>
> src/loader/loader_dri3_helper.h | 2 ++
> src/loader/meson.build | 2 +-
> 6 files changed, 43 insertions(+), 5 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_
> dri2.c
> index 9a7e43bafb6..921d1a52931 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -885,6 +885,8 @@ dri2_setup_extensions(_EGLDisplay *disp)
> dri2_dpy->multibuffers_available =
>(dri2_dpy->dri3_major_version > 1 || (dri2_dpy->dri3_major_version
> == 1 &&
> dri2_dpy->dri3_minor_version
> >= 1)) &&
> + (dri2_dpy->present_major_version > 1 ||
> (dri2_dpy->present_major_version
> == 1 &&
> +
> dri2_dpy->present_minor_version
> >= 1)) &&
>(dri2_dpy->image && dri2_dpy->image->base.version >= 15);
> #endif
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_
> dri2.h
> index 00c4768d421..bd637f73c9d 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -202,6 +202,8 @@ struct dri2_egl_display
> bool multibuffers_available;
> int dri3_major_version;
> int dri3_minor_version;
> + int present_major_version;
> + int present_minor_version;
> struct loader_dri3_extensions loader_dri3_ext;
> #endif
> #endif
> diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c
> b/src/egl/drivers/dri2/platform_x11_dri3.c
> index 15c349eb828..ae2588d04c4 100644
> --- a/src/egl/drivers/dri2/platform_x11_dri3.c
> +++ b/src/egl/drivers/dri2/platform_x11_dri3.c
> @@ -557,6 +557,9 @@ dri3_x11_connect(struct dri2_egl_display *dri2_dpy)
>free(error);
>return EGL_FALSE;
> }
> +
> + dri2_dpy->present_major_version = present_query->major_version;
> + dri2_dpy->present_minor_version = present_query->minor_version;
> free(present_query);
>
> dri2_dpy->fd = loader_dri3_open(dri2_dpy->conn,
> dri2_dpy->screen->root, 0);
> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_
> helper.c
> index 038216c2637..855ec5ce343 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -34,6 +34,8 @@
> #include
>
> #include "loader_dri3_helper.h"
> +#include "util/macros.h"
> +#include "drm_fourcc.h"
>
> /* From xmlpool/options.h, user exposed so should be stable */
> #define DRI_CONF_VBLANK_NEVER 0
> @@ -373,11 +375,25 @@ dri3_handle_present_event(struct
> loader_dri3_drawable *draw,
> draw->recv_sbc -= 0x1;
> switch (ce->mode) {
> case XCB_PRESENT_COMPLETE_MODE_FLIP:
> -draw->flipping = true;
> +if (!draw->flipping) {
> + draw->flipping = true;
> + for (int b = 0; b < ARRAY_SIZE(draw->buffers); b++) {
> + if (draw->buffers[b])
> + draw->buffers[b]->realloc_suboptimal = true;
> + }
> +}
> break;
> case XCB_PRESENT_COMPLETE_MODE_COPY:
> draw->flipping = false;
> break;
> +#if XCB_PRESENT_MAJOR_VERSION > 1 || (XCB_PRESENT_MAJOR_VERSION == 1 &&
> XCB_PRESENT_MINOR_VERSION >= 1)
> + case XCB_PRESENT_COMPLETE_MODE_SUBOPTIMAL_COPY:
> +draw->flipping = false;
> +for (int b = 0; b < ARRAY_SIZE(draw->buffers); b++) {
> + if (draw->buffers[b])
> + draw->buffers[b]->suboptimal = true;
> +}
> +#endif
> }
>
> if (draw->vtable->show_fps)
> @@ -885,6 +901,11 @@ loader_dri3_swap_buffers_msc(struct
> loader_dri3_drawable *draw,
>if (!loader_dri3_have_image_blit(draw) && draw->cur_blit_source !=
> -1)
> options |= XCB_PRESENT_OPTION_COPY;
>
> +#if XCB_PRESENT_MAJOR_VERSION > 1 || (XCB_PRESENT_MAJOR_VERSION == 1 &&
> XCB_PRESENT_MINOR_VERSION >= 1)
> + if (draw->multiplanes_available)
> + options |= XCB_PRESENT_OPTION_SUBOPTIMAL;
> +#endif
> +
>back->busy = 1;
>back->last_swap = draw->send_sbc;
>xcb_present_pixmap(draw->conn,
> @@ -1287,6 +1308,8 @@ dri3_alloc_render_buffer(struct
> loader_dri3_draw
Re: [Mesa-dev] [PATCH 10/11] egl/x11: Support DRI3 v1.1
On Thu, Feb 15, 2018 at 7:57 AM, Daniel Stone wrote:
> From: Louis-Francis Ratté-Boulianne
>
> Add support for DRI3 v1.1, which allows pixmaps to be backed by
> multi-planar buffers, or those with format modifiers. This is both
> for allocating render buffers, as well as EGLImage imports from a
> native pixmap (EGL_NATIVE_PIXMAP_KHR).
>
> Signed-off-by: Louis-Francis Ratté-Boulianne
> Reviewed-by: Eric Engestrom
> Reviewed-by: Emil Velikov
> Reviewed-by: Daniel Stone
> Signed-off-by: Daniel Stone
> ---
> src/egl/drivers/dri2/egl_dri2.c | 7 +
> src/egl/drivers/dri2/egl_dri2.h | 3 +
> src/egl/drivers/dri2/platform_x11_dri3.c | 105 +--
> src/glx/dri3_glx.c | 10 +-
> src/loader/loader_dri3_helper.c | 306
> +++
> src/loader/loader_dri3_helper.h | 17 +-
> 6 files changed, 393 insertions(+), 55 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_
> dri2.c
> index 17b646e7ede..9a7e43bafb6 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -881,6 +881,13 @@ dri2_setup_extensions(_EGLDisplay *disp)
> if (!dri2_bind_extensions(dri2_dpy, mandatory_core_extensions,
> extensions, false))
>return EGL_FALSE;
>
> +#ifdef HAVE_DRI3
> + dri2_dpy->multibuffers_available =
> + (dri2_dpy->dri3_major_version > 1 || (dri2_dpy->dri3_major_version
> == 1 &&
> +dri2_dpy->dri3_minor_version
> >= 1)) &&
> + (dri2_dpy->image && dri2_dpy->image->base.version >= 15);
> +#endif
> +
> dri2_bind_extensions(dri2_dpy, optional_core_extensions, extensions,
> true);
> return EGL_TRUE;
> }
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_
> dri2.h
> index d36d02c3c49..00c4768d421 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -199,6 +199,9 @@ struct dri2_egl_display
> xcb_screen_t *screen;
> bool swap_available;
> #ifdef HAVE_DRI3
> + bool multibuffers_available;
> + int dri3_major_version;
> + int dri3_minor_version;
> struct loader_dri3_extensions loader_dri3_ext;
> #endif
> #endif
> diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c
> b/src/egl/drivers/dri2/platform_x11_dri3.c
> index 6ead4d0a222..15c349eb828 100644
> --- a/src/egl/drivers/dri2/platform_x11_dri3.c
> +++ b/src/egl/drivers/dri2/platform_x11_dri3.c
> @@ -39,6 +39,23 @@
> #include "loader.h"
> #include "loader_dri3_helper.h"
>
> +static uint32_t
> +dri3_format_for_depth(uint32_t depth)
> +{
> + switch (depth) {
> + case 16:
> + return __DRI_IMAGE_FORMAT_RGB565;
> + case 24:
> + return __DRI_IMAGE_FORMAT_XRGB;
> + case 30:
> + return __DRI_IMAGE_FORMAT_XRGB2101010;
> + case 32:
> + return __DRI_IMAGE_FORMAT_ARGB;
> + default:
> + return __DRI_IMAGE_FORMAT_NONE;
> + }
> +}
> +
> static struct dri3_egl_surface *
> loader_drawable_to_egl_surface(struct loader_dri3_drawable *draw) {
> size_t offset = offsetof(struct dri3_egl_surface, loader_drawable);
> @@ -156,7 +173,9 @@ dri3_create_surface(_EGLDriver *drv, _EGLDisplay
> *disp, EGLint type,
>
> if (loader_dri3_drawable_init(dri2_dpy->conn, drawable,
> dri2_dpy->dri_screen,
> - dri2_dpy->is_different_gpu, dri_config,
> + dri2_dpy->is_different_gpu,
> + dri2_dpy->multibuffers_available,
> + dri_config,
> &dri2_dpy->loader_dri3_ext,
> &egl_dri3_vtable,
> &dri3_surf->loader_drawable)) {
> @@ -262,20 +281,8 @@ dri3_create_image_khr_pixmap(_EGLDisplay *disp,
> _EGLContext *ctx,
>return NULL;
> }
>
> - switch (bp_reply->depth) {
> - case 16:
> - format = __DRI_IMAGE_FORMAT_RGB565;
> - break;
> - case 24:
> - format = __DRI_IMAGE_FORMAT_XRGB;
> - break;
> - case 30:
> - format = __DRI_IMAGE_FORMAT_XRGB2101010;
> - break;
> - case 32:
> - format = __DRI_IMAGE_FORMAT_ARGB;
> - break;
> - default:
> + format = dri3_format_for_depth(bp_reply->depth);
> + if (format == __DRI_IMAGE_FORMAT_NONE) {
>_eglError(EGL_BAD_PARAMETER,
> "dri3_create_image_khr: unsupported pixmap depth");
>free(bp_reply);
> @@ -303,13 +310,78 @@ dri3_create_image_khr_pixmap(_EGLDisplay *disp,
> _EGLContext *ctx,
> return &dri2_img->base;
> }
>
> +#if XCB_DRI3_MAJOR_VERSION > 1 || (XCB_DRI3_MAJOR_VERSION == 1 &&
> XCB_DRI3_MINOR_VERSION >= 1)
> +static _EGLImage *
> +dri3_create_image_khr_pixmap_from_buffers(_EGLDisplay *disp, _EGLContext
> *ctx,
> + EGLCl
Re: [Mesa-dev] [PATCH V2 16/16] i965/icl: Add render target flush after uploading binding table
+Ken
On Thu, Feb 15, 2018 at 11:11 AM, Anuj Phogat wrote:
> From PIPE_CONTROL command description in gfxspecs:
>
> "Whenever a Binding Table Index (BTI) used by a Render Taget Message
> points to a different RENDER_SURFACE_STATE, SW must issue a Render
> Target Cache Flush by enabling this bit. When render target flush
> is set due to new association of BTI, PS Scoreboard Stall bit must
> be set in this packet."
>
> V2: Move the PIPE_CONTROL to update_renderbuffer_surfaces() in
> brw_wm_surface_state.c (Ken).
>
> Fixes a fulsim error and a GPU hang described in below JIRA.
> JIRA: MD5-322
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> 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 44c87df17d..84c5a81227 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -971,6 +971,20 @@ update_renderbuffer_surfaces(struct brw_context *brw)
>emit_null_surface_state(brw, fb, &surf_offsets[rt_start]);
> }
>
> + /* From PIPE_CONTROL command description in gfxspecs:
> +
> + "Whenever a Binding Table Index (BTI) used by a Render Taget Message
> + points to a different RENDER_SURFACE_STATE, SW must issue a Render
> + Target Cache Flush by enabling this bit. When render target flush
> + is set due to new association of BTI, PS Scoreboard Stall bit must
> + be set in this packet."
> + */
> + if (devinfo->gen >= 11) {
> + brw_emit_pipe_control_flush(brw,
> + PIPE_CONTROL_RENDER_TARGET_FLUSH |
> + PIPE_CONTROL_STALL_AT_SCOREBOARD);
> + }
> +
> brw->ctx.NewDriverState |= BRW_NEW_SURFACES;
> }
>
> --
> 2.13.6
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 104662] OpenGL 4.5 needs to be active by default instead of using 3.0 by default
https://bugs.freedesktop.org/show_bug.cgi?id=104662 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #5 from Timothy Arceri --- (In reply to mirh from comment #4) > https://lists.freedesktop.org/archives/mesa-dev/2018-February/185646.html > > Compatibility context is very, very shyly advancing.. > Maybe this bug should be renamed to just that? Compatibility is a missing feature of the various drivers not a bug, there is no need to track it in bugzilla. I'm resolving this as not a bug. -- 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 1/1] clover: Fix build after llvm r325155 and r325160
Jan Vesely writes:
> r325155 ("Pass a reference to a module to the bitcode writer.")
> and
> r325160 ("Pass module reference to CloneModule")
>
> change function interface from pointer to reference.
>
> Signed-off-by: Jan Vesely
> ---
> .../state_trackers/clover/llvm/codegen/bitcode.cpp | 2 +-
> .../state_trackers/clover/llvm/codegen/native.cpp | 2 +-
> src/gallium/state_trackers/clover/llvm/compat.hpp | 28
> ++
> 3 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> index 679ecd8758..40bb426218 100644
> --- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> @@ -66,7 +66,7 @@ namespace {
> emit_code(const ::llvm::Module &mod) {
>::llvm::SmallVector data;
>::llvm::raw_svector_ostream os { data };
> - WriteBitcodeToFile(&mod, os);
> + compat::write_bitcode_to_file(mod, os);
>return { os.str().begin(), os.str().end() };
> }
> }
> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
> b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
> index 12c83a92b6..409f8ac32f 100644
> --- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
> @@ -156,7 +156,7 @@ clover::llvm::print_module_native(const ::llvm::Module
> &mod,
>const target &target) {
> std::string log;
> try {
> - std::unique_ptr< ::llvm::Module> cmod { CloneModule(&mod) };
> + std::unique_ptr< ::llvm::Module> cmod { compat::clone_module(mod) };
>return as_string(emit_code(*cmod, target,
> TargetMachine::CGFT_AssemblyFile, log));
> } catch (...) {
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index 6fc75fb250..db9e8020cf 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -36,9 +36,17 @@
>
> #include "util/algorithm.hpp"
>
> +#if HAVE_LLVM < 0x0400
> +#include
> +#else
> +#include
> +#include
> +#endif
> +
> #include
> #include
> #include
> +#include
> #include
> #if HAVE_LLVM >= 0x0400
> #include
> @@ -217,6 +225,26 @@ namespace clover {
> ctx.setDiagnosticHandler(diagnostic_handler, data);
> #endif
> }
> +
> + inline std::unique_ptr< ::llvm::Module>
> + clone_module(const ::llvm::Module &mod)
> + {
> +#if HAVE_LLVM >= 0x0700
> + return ::llvm::CloneModule(mod);
> +#else
> + return ::llvm::CloneModule(&mod);
> +#endif
> + }
> +
> +template void
Weird indentation. Other than that:
Reviewed-by: Francisco Jerez
> + write_bitcode_to_file(const ::llvm::Module &mod, T &os)
> + {
> +#if HAVE_LLVM >= 0x0700
> + ::llvm::WriteBitcodeToFile(mod, os);
> +#else
> + ::llvm::WriteBitcodeToFile(&mod, os);
> +#endif
> + }
>}
> }
> }
> --
> 2.14.3
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105119] Desktop-wide input freeze when vulkan (radv)
https://bugs.freedesktop.org/show_bug.cgi?id=105119 Jakub Okoński changed: What|Removed |Added CC||ja...@okonski.org -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105119] Desktop-wide input freeze when vulkan (radv)
https://bugs.freedesktop.org/show_bug.cgi?id=105119 --- Comment #1 from Jakub Okoński --- Created attachment 137385 --> https://bugs.freedesktop.org/attachment.cgi?id=137385&action=edit single frame render that exits cleanly -- 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 105119] Desktop-wide input freeze when vulkan (radv)
https://bugs.freedesktop.org/show_bug.cgi?id=105119 Bug ID: 105119 Summary: Desktop-wide input freeze when vulkan (radv) Product: Mesa Version: 17.3 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: ja...@okonski.org QA Contact: mesa-dev@lists.freedesktop.org Created attachment 137384 --> https://bugs.freedesktop.org/attachment.cgi?id=137384&action=edit trace #1 with long vkDeviceWaitIdle I'm experimenting with vulkan, and, after my application exits cleanly, keyboard input is ignored until I switch to another window using my mouse (that I can still use). This is not the main problem though, I found a sequence of commands that triggers a desktop-wide freeze. I can still move my mouse, but windows don't redraw as far as I can tell. I also cannot focus other windows with mouse/keyboard, I cannot use ctrl+alt+f[1-9] to jump back to tty. Because I have a physical tachometer on the GPU, I also noticed that it is being utilized 100%, at least that's what the LEDs say. I tried doing a vulkan trace and replay, but the replay does not trigger it. I'm attaching two vktrace files, first one is my original case, where I render two frames and exit cleanly (or at least try to). Of note is the never-ending vkDeviceWaitIdle call (it actually does end as soon as I press the power button on my PC, more on this in a second). The second trace I attached is one where I only render one frame and then exit the application (cleanly). Interestingly, in this case there is no failure So after the desktop is frozen, I can only press the power button, which immediately exits xorg server, I again see my tty (I launch startx directly from tty, no GUI login manager). The control is never yielded back to my tty though, I can see a snippet of xorg logs but the process has not exited (and the GPU leds show 100% utilisation still). Mesa, radv 17.3.3, xorg 1.19.6, linux 4.15.3 with RX Vega 64 GPU. Let me know if there are additional debugging steps I can take, I can also provide source code for reproduction steps. -- 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] radv: Always lower indirect derefs after nir_lower_global_vars_to_local.
Reviewed-by: Timothy Arceri
On 16/02/18 07:40, Bas Nieuwenhuizen wrote:
Otherwise new local variables can cause hangs on vega.
CC:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105098
---
src/amd/vulkan/radv_pipeline.c | 11 +--
src/amd/vulkan/radv_shader.c | 74 +++---
src/amd/vulkan/radv_shader.h | 4 +++
3 files changed, 53 insertions(+), 36 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 8f872e7c14..0d1958fc93 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1525,9 +1525,16 @@ radv_link_shaders(struct radv_pipeline *pipeline,
nir_shader **shaders)
ordered_shaders[i -
1]);
if (progress) {
- nir_lower_global_vars_to_local(ordered_shaders[i]);
+ if (nir_lower_global_vars_to_local(ordered_shaders[i]))
{
+ radv_lower_indirect_derefs(ordered_shaders[i],
+
pipeline->device->physical_device);
+ }
radv_optimize_nir(ordered_shaders[i]);
- nir_lower_global_vars_to_local(ordered_shaders[i - 1]);
+
+ if (nir_lower_global_vars_to_local(ordered_shaders[i -
1])) {
+ radv_lower_indirect_derefs(ordered_shaders[i -
1],
+
pipeline->device->physical_device);
+ }
radv_optimize_nir(ordered_shaders[i - 1]);
}
}
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 42f83bb335..d9b8e209a9 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -114,6 +114,45 @@ void radv_DestroyShaderModule(
vk_free2(&device->alloc, pAllocator, module);
}
+bool
+radv_lower_indirect_derefs(struct nir_shader *nir,
+ struct radv_physical_device *device)
+{
+ /* While it would be nice not to have this flag, we are constrained
+* by the reality that LLVM 5.0 doesn't have working VGPR indexing
+* on GFX9.
+*/
+ bool llvm_has_working_vgpr_indexing =
+ device->rad_info.chip_class <= VI;
+
+ /* TODO: Indirect indexing of GS inputs is unimplemented.
+*
+* TCS and TES load inputs directly from LDS or offchip memory, so
+* indirect indexing is trivial.
+*/
+ nir_variable_mode indirect_mask = 0;
+ if (nir->info.stage == MESA_SHADER_GEOMETRY ||
+ (nir->info.stage != MESA_SHADER_TESS_CTRL &&
+nir->info.stage != MESA_SHADER_TESS_EVAL &&
+!llvm_has_working_vgpr_indexing)) {
+ indirect_mask |= nir_var_shader_in;
+ }
+ if (!llvm_has_working_vgpr_indexing &&
+ nir->info.stage != MESA_SHADER_TESS_CTRL)
+ indirect_mask |= nir_var_shader_out;
+
+ /* TODO: We shouldn't need to do this, however LLVM isn't currently
+* smart enough to handle indirects without causing excess spilling
+* causing the gpu to hang.
+*
+* See the following thread for more details of the problem:
+* https://lists.freedesktop.org/archives/mesa-dev/2017-July/162106.html
+*/
+ indirect_mask |= nir_var_local;
+
+ return nir_lower_indirect_derefs(nir, indirect_mask);
+}
+
void
radv_optimize_nir(struct nir_shader *shader)
{
@@ -254,40 +293,6 @@ radv_shader_compile_to_nir(struct radv_device *device,
nir_shader_gather_info(nir, entry_point->impl);
- /* While it would be nice not to have this flag, we are constrained
-* by the reality that LLVM 5.0 doesn't have working VGPR indexing
-* on GFX9.
-*/
- bool llvm_has_working_vgpr_indexing =
- device->physical_device->rad_info.chip_class <= VI;
-
- /* TODO: Indirect indexing of GS inputs is unimplemented.
-*
-* TCS and TES load inputs directly from LDS or offchip memory, so
-* indirect indexing is trivial.
-*/
- nir_variable_mode indirect_mask = 0;
- if (nir->info.stage == MESA_SHADER_GEOMETRY ||
- (nir->info.stage != MESA_SHADER_TESS_CTRL &&
-nir->info.stage != MESA_SHADER_TESS_EVAL &&
-!llvm_has_working_vgpr_indexing)) {
- indirect_mask |= nir_var_shader_in;
- }
- if (!llvm_has_working_vgpr_indexing &&
- nir->info.stage != MESA_SHADER_TESS_CTRL)
- indirect_mask |= nir_var_shader_out;
-
- /* TODO: We shouldn't need to do this, however LLVM isn't currently
-* smart enough to handle indirects without causing excess spilling
-* causing the gpu to hang.
-*
-* See the following thread for more details of the p
Re: [Mesa-dev] [PATCH] nir: add is_used_once for fmul(fexp2(a), fexp2(b)) to fexp2(fadd(a, b))
Here are the IVB shader-db results:
instructions helped: shaders/closed/steam/dex/63.shader_test FS SIMD8:
1303 -> 1300 (-0.23%)
instructions helped: shaders/closed/steam/gang-beasts/111.shader_test
FS SIMD8: 1303 -> 1300 (-0.23%)
instructions helped:
shaders/closed/steam/rocketsrocketsrockets/81.shader_test FS SIMD8: 1303
-> 1300 (-0.23%)
instructions helped:
shaders/closed/steam/kerbal-space-program/687.shader_test FS SIMD8: 1303
-> 1300 (-0.23%)
instructions helped:
shaders/closed/steam/chivalry-medieval-warfare/834.shader_test FS
SIMD16: 391 -> 389 (-0.51%)
instructions helped:
shaders/closed/steam/saints-row-the-third/834.shader_test FS SIMD16: 391
-> 389 (-0.51%)
instructions helped:
shaders/closed/steam/chivalry-medieval-warfare/834.shader_test FS SIMD8:
338 -> 336 (-0.59%)
instructions helped:
shaders/closed/steam/saints-row-the-third/834.shader_test FS SIMD8: 338
-> 336 (-0.59%)
instructions helped:
shaders/closed/steam/dota-2-reborn/1243.shader_test FS SIMD16: 148 ->
141 (-4.73%)
instructions helped: shaders/closed/steam-big-picture/1.shader_test FS
SIMD16: 145 -> 138 (-4.83%)
instructions helped:
shaders/closed/steam/dota-2-reborn/1243.shader_test FS SIMD8: 100 -> 93
(-7.00%)
instructions helped: shaders/closed/steam-big-picture/1.shader_test FS
SIMD8: 97 -> 90 (-7.22%)
instructions HURT:
shaders/closed/UnrealEngine4/VehicleGame/234.shader_test FS SIMD8: 146
-> 147 (0.68%)
instructions HURT:
shaders/closed/UnrealEngine4/Lightroominteriorday/175.shader_test FS
SIMD8: 139 -> 140 (0.72%)
instructions HURT:
shaders/closed/UnrealEngine4/VehicleGame/234.shader_test FS SIMD16: 178
-> 180 (1.12%)
instructions HURT:
shaders/closed/UnrealEngine4/Lightroominteriorday/175.shader_test FS
SIMD16: 171 -> 173 (1.17%)
cycles helped:
shaders/closed/steam/chivalry-medieval-warfare/834.shader_test FS SIMD8:
2790 -> 2784 (-0.22%)
cycles helped:
shaders/closed/steam/saints-row-the-third/834.shader_test FS SIMD8: 2790
-> 2784 (-0.22%)
cycles helped:
shaders/closed/steam/chivalry-medieval-warfare/834.shader_test FS
SIMD16: 3399 -> 3383 (-0.47%)
cycles helped:
shaders/closed/steam/saints-row-the-third/834.shader_test FS SIMD16:
3399 -> 3383 (-0.47%)
cycles helped:
shaders/closed/UnrealEngine4/VehicleGame/234.shader_test FS SIMD8: 7944
-> 7904 (-0.50%)
cycles helped:
shaders/closed/UnrealEngine4/Lightroominteriorday/175.shader_test FS
SIMD8: 7726 -> 7686 (-0.52%)
cycles helped:
shaders/closed/UnrealEngine4/VehicleGame/234.shader_test FS SIMD16:
10557 -> 10471 (-0.81%)
cycles helped:
shaders/closed/UnrealEngine4/Lightroominteriorday/175.shader_test FS
SIMD16: 10335 -> 10249 (-0.83%)
cycles helped: shaders/closed/steam/dota-2-reborn/1243.shader_test FS
SIMD16: 974 -> 883 (-9.34%)
cycles helped: shaders/closed/steam/dota-2-reborn/1243.shader_test FS
SIMD8: 951 -> 841 (-11.57%)
cycles helped: shaders/closed/steam-big-picture/1.shader_test FS
SIMD16: 1155 -> 958 (-17.06%)
cycles helped: shaders/closed/steam-big-picture/1.shader_test FS
SIMD8: 1056 -> 845 (-19.98%)
cycles HURT: shaders/closed/steam/dex/63.shader_test FS SIMD8: 13165
-> 13240 (0.57%)
cycles HURT: shaders/closed/steam/gang-beasts/111.shader_test FS
SIMD8: 13165 -> 13240 (0.57%)
cycles HURT: shaders/closed/steam/rocketsrocketsrockets/81.shader_test
FS SIMD8: 13165 -> 13240 (0.57%)
cycles HURT: shaders/closed/steam/kerbal-space-program/687.shader_test
FS SIMD8: 13165 -> 13240 (0.57%)
cycles HURT: shaders/closed/steam/dungeon-defenders/8409.shader_test
FS SIMD8: 573 -> 579 (1.05%)
cycles HURT: shaders/closed/steam/dungeon-defenders/8409.shader_test
FS SIMD16: 635 -> 645 (1.57%)
total instructions in shared programs: 10114499 -> 10114457 (-0.00%)
instructions in affected programs: 7794 -> 7752 (-0.54%)
helped: 12
HURT: 4
total cycles in shared programs: 230925909 -> 230925320 (-0.00%)
cycles in affected programs: 106944 -> 106355 (-0.55%)
helped: 12
HURT: 6
total loops in shared programs: 2436 -> 2436 (0.00%)
loops in affected programs: 0 -> 0
helped: 0
HURT: 0
total spills in shared programs: 5435 -> 5435 (0.00%)
spills in affected programs: 0 -> 0
helped: 0
HURT: 0
total fills in shared programs: 6069 -> 6069 (0.00%)
fills in affected programs: 0 -> 0
helped: 0
HURT: 0
LOST: 0
GAINED: 0
On 15/02/18 12:36, Ian Romanick wrote:
Do you have shader-db results? Did you try having only one is_used_once?
On 02/05/2018 07:07 AM, Samuel Pitoiset wrote:
Otherwise the code size increases because the original fexp2()
instructions can't be deleted.
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_opt_algebraic.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
index b30d1df199..d40d59b5cd 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -336,7 +336,7 @@ optimizations = [
(('~flog2', ('frcp', a)), ('fneg', ('flog2'
Re: [Mesa-dev] [PATCH 09/11] vulkan/wsi: Return VK_SUBOPTIMAL_KHR for X11
On Thu, Feb 15, 2018 at 7:57 AM, Daniel Stone wrote:
> From: Louis-Francis Ratté-Boulianne
>
> When it is detected that a window could have been flipped
> but has been copied because of suboptimal format/modifier.
> The Vulkan client should then re-create the swapchain.
>
> Signed-off-by: Louis-Francis Ratté-Boulianne
> Reviewed-by: Daniel Stone
> Signed-off-by: Daniel Stone
> ---
> src/vulkan/wsi/wsi_common_x11.c | 64 ++
> +++
> 1 file changed, 58 insertions(+), 6 deletions(-)
>
> diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_
> x11.c
> index c569aa17187..a9929af338c 100644
> --- a/src/vulkan/wsi/wsi_common_x11.c
> +++ b/src/vulkan/wsi/wsi_common_x11.c
> @@ -130,6 +130,8 @@ wsi_x11_connection_create(const VkAllocationCallbacks
> *alloc,
> {
> xcb_query_extension_cookie_t dri3_cookie, pres_cookie, amd_cookie,
> nv_cookie;
> xcb_query_extension_reply_t *dri3_reply, *pres_reply, *amd_reply,
> *nv_reply;
> + bool has_dri3_v1_1 = false;
> + bool has_present_v1_1 = false;
>
> struct wsi_x11_connection *wsi_conn =
>vk_alloc(alloc, sizeof(*wsi_conn), 8,
> @@ -138,7 +140,7 @@ wsi_x11_connection_create(const VkAllocationCallbacks
> *alloc,
>return NULL;
>
> dri3_cookie = xcb_query_extension(conn, 4, "DRI3");
> - pres_cookie = xcb_query_extension(conn, 7, "PRESENT");
> + pres_cookie = xcb_query_extension(conn, 7, "Present");
>
This seems a bit odd. Did we just not use it before? Looking through
things, it appears we didn't.
> /* We try to be nice to users and emit a warning if they try to use a
> * Vulkan application on a system without DRI3 enabled. However, this
> ends
> @@ -173,13 +175,27 @@ wsi_x11_connection_create(const
> VkAllocationCallbacks *alloc,
>
>ver_cookie = xcb_dri3_query_version(conn, 1, 1);
>ver_reply = xcb_dri3_query_version_reply(conn, ver_cookie, NULL);
> - wsi_conn->has_dri3_modifiers =
> + has_dri3_v1_1 =
> (ver_reply->major_version > 1 || ver_reply->minor_version >= 1);
>free(ver_reply);
> }
> #endif
>
> wsi_conn->has_present = pres_reply->present != 0;
> +#if XCB_PRESENT_MAJOR_VERSION > 1 || XCB_PRESENT_MINOR_VERSION >= 1
> + if (wsi_conn->has_present) {
> + xcb_present_query_version_cookie_t ver_cookie;
> + xcb_present_query_version_reply_t *ver_reply;
> +
> + ver_cookie = xcb_present_query_version(conn, 1, 1);
> + ver_reply = xcb_present_query_version_reply(conn, ver_cookie,
> NULL);
> + has_present_v1_1 =
> +(ver_reply->major_version > 1 || ver_reply->minor_version >= 1);
> + free(ver_reply);
> + }
> +#endif
> +
> + wsi_conn->has_dri3_modifiers = has_dri3_v1_1 && has_present_v1_1;
> wsi_conn->is_proprietary_x11 = false;
> if (amd_reply && amd_reply->present)
>wsi_conn->is_proprietary_x11 = true;
> @@ -651,6 +667,8 @@ struct x11_swapchain {
>
> bool threaded;
> VkResult status;
> + bool suboptimal;
> + bool realloc_suboptimal;
> struct wsi_queue present_queue;
> struct wsi_queue acquire_queue;
> pthread_tqueue_manager;
> @@ -699,6 +717,10 @@ x11_handle_dri3_present_event(struct x11_swapchain
> *chain,
>xcb_present_complete_notify_event_t *complete = (void *) event;
>if (complete->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP)
> chain->last_present_msc = complete->msc;
> +#if XCB_PRESENT_MAJOR_VERSION > 1 || XCB_PRESENT_MINOR_VERSION >= 1
> + if (complete->mode == XCB_PRESENT_COMPLETE_MODE_SUBOPTIMAL_COPY)
> + chain->suboptimal = true;
>
I think I like the approach taken in GLX better. Here, we'll properly
reallocate when we go from not flipping to flipping but, what happens if we
stop flipping? In that case, we can do better if we reallocate again.
Also, I find "chain->suboptimal" and "chain->realloc_suboptimal" to be very
confusing. chain->suboptimal has an obvious meaning but the other
doesn't. At the very least we need better documentation as to what they
mean.
> +#endif
>break;
> }
>
> @@ -828,6 +850,11 @@ x11_present_to_x11(struct x11_swapchain *chain,
> uint32_t image_index,
> if (chain->base.present_mode == VK_PRESENT_MODE_IMMEDIATE_KHR)
>options |= XCB_PRESENT_OPTION_ASYNC;
>
> +#if XCB_PRESENT_MAJOR_VERSION > 1 || XCB_PRESENT_MINOR_VERSION >= 1
> + if (chain->has_dri3_modifiers)
> + options |= XCB_PRESENT_OPTION_SUBOPTIMAL;
> +#endif
> +
> xshmfence_reset(image->shm_fence);
>
> ++chain->send_sbc;
> @@ -862,11 +889,19 @@ x11_acquire_next_image(struct wsi_swapchain
> *anv_chain,
> uint32_t *image_index)
> {
> struct x11_swapchain *chain = (struct x11_swapchain *)anv_chain;
Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v2
February 15, 2018 3:22 PM, "Alexander von Gluck IV" wrote: > --- > include/meson.build | 8 + > meson.build | 18 +++--- > src/egl/meson.build | 35 +- > src/gallium/meson.build | 9 + > src/gallium/state_trackers/hgl/meson.build | 41 + > src/gallium/targets/haiku-softpipe/meson.build | 50 ++ > src/gallium/winsys/sw/hgl/meson.build | 29 +++ > src/hgl/GLDispatcher.h | 2 +- > src/hgl/meson.build | 38 > src/mapi/es1api/meson.build | 2 +- > src/mapi/es2api/meson.build | 2 +- > src/meson.build | 7 +++- > 12 files changed, 224 insertions(+), 17 deletions(-) > create mode 100644 src/gallium/state_trackers/hgl/meson.build > create mode 100644 src/gallium/targets/haiku-softpipe/meson.build > create mode 100644 src/gallium/winsys/sw/hgl/meson.build > create mode 100644 src/hgl/meson.build Sorry for the v2.. I did a test build on Linux and noticed I broke egl. A diff of what changed in v2: $ git diff diff --git a/src/egl/meson.build b/src/egl/meson.build index 1fd2b241bb..8880d4631b 100644 --- a/src/egl/meson.build +++ b/src/egl/meson.build @@ -148,7 +148,7 @@ if with_platform_haiku else incs_for_egl += [inc_loader, inc_gbm] c_args_for_egl += [ -'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir), +'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path), '-D_EGL_BUILT_IN_DRIVER_DRI2', ] link_for_egl += [libloader, libxmlconfig] @@ -181,8 +181,6 @@ libegl = shared_library( c_args : [ c_vis_args, c_args_for_egl, -'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path), -'-D_EGL_BUILT_IN_DRIVER_DRI2', '-D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_@0@'.format(egl_native_platform.to_upper()), ], include_directories : incs_for_egl, There are a lot of changes here... If it isn't perfect I ask to get it in to make adjustments to avoid the need of rebasing over and over. As for Haiku support, meson successfully generates all the needed binaries... there are a few minor issues around TLS i need to sort still however. Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105098] [RADV] GPU freeze with simple Vulkan App
https://bugs.freedesktop.org/show_bug.cgi?id=105098 --- Comment #6 from Lukas Kahnert --- My App is more or less the same than the triangle demo(I try to learn Vulkan, but this issue was definitely not normal for invalid API usage ;)). With this patch it does't hang now and works as expected. Thanks :) -- 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 14/16] intel/common/icl: Add has_sample_with_hiz flag in gen_device_info
On Thursday, February 15, 2018 11:09:09 AM PST Anuj Phogat wrote: > Sampling from hiz is enabled in i965 for GEN9+ but this feature has > been removed from gen11. So, this new flag will be useful to turn > the feature on/off for different gen h/w. It will be used later > in a patch adding device info for gen11. > > Suggested-by: Kenneth Graunke > Signed-off-by: Anuj Phogat > Cc: Kenneth Graunke > --- > src/intel/common/gen_device_info.c| 7 +++ > src/intel/common/gen_device_info.h| 2 +- > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 + > 3 files changed, 9 insertions(+), 5 deletions(-) Reviewed-by: Kenneth Graunke 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] meson: Add Haiku platform support v2
---
include/meson.build| 8 +
meson.build| 18 +++---
src/egl/meson.build| 35 +-
src/gallium/meson.build| 9 +
src/gallium/state_trackers/hgl/meson.build | 41 +
src/gallium/targets/haiku-softpipe/meson.build | 50 ++
src/gallium/winsys/sw/hgl/meson.build | 29 +++
src/hgl/GLDispatcher.h | 2 +-
src/hgl/meson.build| 38
src/mapi/es1api/meson.build| 2 +-
src/mapi/es2api/meson.build| 2 +-
src/meson.build| 7 +++-
12 files changed, 224 insertions(+), 17 deletions(-)
create mode 100644 src/gallium/state_trackers/hgl/meson.build
create mode 100644 src/gallium/targets/haiku-softpipe/meson.build
create mode 100644 src/gallium/winsys/sw/hgl/meson.build
create mode 100644 src/hgl/meson.build
diff --git a/include/meson.build b/include/meson.build
index 1cbc68182c..28ffb33215 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -22,6 +22,7 @@ inc_drm_uapi = include_directories('drm-uapi')
inc_vulkan = include_directories('vulkan')
inc_d3d9 = include_directories('D3D9')
inc_gl_internal = include_directories('GL/internal')
+inc_haikugl = include_directories('HaikuGL')
if with_gles1
install_headers(
@@ -80,6 +81,13 @@ if with_gallium_st_nine
)
endif
+if with_platform_haiku
+ install_headers(
+'HaikuGL/GLRenderer.h', 'HaikuGL/GLView.h', 'HaikuGL/OpenGLKit.h',
+subdir : 'opengl',
+ )
+endif
+
# Only install the headers if we are building a stand alone implementation and
# not an ICD enabled implementation
if with_gallium_opencl and not with_opencl_icd
diff --git a/meson.build b/meson.build
index 3925ec483e..d476f70bbe 100644
--- a/meson.build
+++ b/meson.build
@@ -103,7 +103,7 @@ if _drivers == 'auto'
else
error('Unknown architecture. Please pass -Ddri-drivers to set driver
options. Patches gladly accepted to fix this.')
endif
- elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+ elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
# only swrast would make sense here, but gallium swrast is a much better
default
_drivers = ''
else
@@ -148,7 +148,7 @@ if _drivers == 'auto'
else
error('Unknown architecture. Please pass -Dgallium-drivers to set driver
options. Patches gladly accepted to fix this.')
endif
- elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+ elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
_drivers = 'swrast'
else
error('Unknown OS. Please pass -Dgallium-drivers to set driver options.
Patches gladly accepted to fix this.')
@@ -185,7 +185,7 @@ if _vulkan_drivers == 'auto'
else
error('Unknown architecture. Please pass -Dvulkan-drivers to set driver
options. Patches gladly accepted to fix this.')
endif
- elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+ elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
# No vulkan driver supports windows or macOS currently
_vulkan_drivers = ''
else
@@ -246,6 +246,8 @@ if _platforms == 'auto'
_platforms = 'x11,wayland,drm,surfaceless'
elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
_platforms = 'x11,surfaceless'
+ elif ['haiku'].contains(host_machine.system())
+_platforms = 'haiku'
else
error('Unknown OS. Please pass -Dplatforms to set platforms. Patches
gladly accepted to fix this.')
endif
@@ -256,6 +258,7 @@ if _platforms != ''
with_platform_x11 = _split.contains('x11')
with_platform_wayland = _split.contains('wayland')
with_platform_drm = _split.contains('drm')
+ with_platform_haiku = _split.contains('haiku')
with_platform_surfaceless = _split.contains('surfaceless')
egl_native_platform = _split[0]
endif
@@ -264,6 +267,8 @@ with_glx = get_option('glx')
if with_glx == 'auto'
if with_dri
with_glx = 'dri'
+ elif with_platform_haiku
+with_glx = 'disabled'
elif with_gallium
# Even when building just gallium drivers the user probably wants dri
with_glx = 'dri'
@@ -379,7 +384,7 @@ if with_any_vk and (with_platform_x11 and not with_dri3)
error('Vulkan drivers require dri3 for X11 support')
endif
if with_dri or with_gallium
- if with_glx == 'disabled' and not with_egl
+ if with_glx == 'disabled' and not with_egl and not with_platform_haiku
error('building dri or gallium drivers require at least one window system')
endif
endif
@@ -640,6 +645,9 @@ if with_platform_android
]
pre_args += '-DHAVE_ANDROID_PLATFORM'
endif
+if with_platform_haiku
+ pre_args += '-DHAVE_HAIKU_PLATFORM'
+endif
prog_python2 = find_program('python2')
has_m
[Mesa-dev] [PATCH] meson: Add Haiku platform support
---
include/meson.build| 8 +
meson.build| 18 +++---
src/egl/meson.build| 33 +
src/gallium/meson.build| 9 +
src/gallium/state_trackers/hgl/meson.build | 41 +
src/gallium/targets/haiku-softpipe/meson.build | 50 ++
src/gallium/winsys/sw/hgl/meson.build | 29 +++
src/hgl/GLDispatcher.h | 2 +-
src/hgl/meson.build| 38
src/mapi/es1api/meson.build| 2 +-
src/mapi/es2api/meson.build| 2 +-
src/meson.build| 7 +++-
12 files changed, 224 insertions(+), 15 deletions(-)
create mode 100644 src/gallium/state_trackers/hgl/meson.build
create mode 100644 src/gallium/targets/haiku-softpipe/meson.build
create mode 100644 src/gallium/winsys/sw/hgl/meson.build
create mode 100644 src/hgl/meson.build
diff --git a/include/meson.build b/include/meson.build
index 1cbc68182c..28ffb33215 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -22,6 +22,7 @@ inc_drm_uapi = include_directories('drm-uapi')
inc_vulkan = include_directories('vulkan')
inc_d3d9 = include_directories('D3D9')
inc_gl_internal = include_directories('GL/internal')
+inc_haikugl = include_directories('HaikuGL')
if with_gles1
install_headers(
@@ -80,6 +81,13 @@ if with_gallium_st_nine
)
endif
+if with_platform_haiku
+ install_headers(
+'HaikuGL/GLRenderer.h', 'HaikuGL/GLView.h', 'HaikuGL/OpenGLKit.h',
+subdir : 'opengl',
+ )
+endif
+
# Only install the headers if we are building a stand alone implementation and
# not an ICD enabled implementation
if with_gallium_opencl and not with_opencl_icd
diff --git a/meson.build b/meson.build
index 3925ec483e..d476f70bbe 100644
--- a/meson.build
+++ b/meson.build
@@ -103,7 +103,7 @@ if _drivers == 'auto'
else
error('Unknown architecture. Please pass -Ddri-drivers to set driver
options. Patches gladly accepted to fix this.')
endif
- elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+ elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
# only swrast would make sense here, but gallium swrast is a much better
default
_drivers = ''
else
@@ -148,7 +148,7 @@ if _drivers == 'auto'
else
error('Unknown architecture. Please pass -Dgallium-drivers to set driver
options. Patches gladly accepted to fix this.')
endif
- elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+ elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
_drivers = 'swrast'
else
error('Unknown OS. Please pass -Dgallium-drivers to set driver options.
Patches gladly accepted to fix this.')
@@ -185,7 +185,7 @@ if _vulkan_drivers == 'auto'
else
error('Unknown architecture. Please pass -Dvulkan-drivers to set driver
options. Patches gladly accepted to fix this.')
endif
- elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+ elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
# No vulkan driver supports windows or macOS currently
_vulkan_drivers = ''
else
@@ -246,6 +246,8 @@ if _platforms == 'auto'
_platforms = 'x11,wayland,drm,surfaceless'
elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
_platforms = 'x11,surfaceless'
+ elif ['haiku'].contains(host_machine.system())
+_platforms = 'haiku'
else
error('Unknown OS. Please pass -Dplatforms to set platforms. Patches
gladly accepted to fix this.')
endif
@@ -256,6 +258,7 @@ if _platforms != ''
with_platform_x11 = _split.contains('x11')
with_platform_wayland = _split.contains('wayland')
with_platform_drm = _split.contains('drm')
+ with_platform_haiku = _split.contains('haiku')
with_platform_surfaceless = _split.contains('surfaceless')
egl_native_platform = _split[0]
endif
@@ -264,6 +267,8 @@ with_glx = get_option('glx')
if with_glx == 'auto'
if with_dri
with_glx = 'dri'
+ elif with_platform_haiku
+with_glx = 'disabled'
elif with_gallium
# Even when building just gallium drivers the user probably wants dri
with_glx = 'dri'
@@ -379,7 +384,7 @@ if with_any_vk and (with_platform_x11 and not with_dri3)
error('Vulkan drivers require dri3 for X11 support')
endif
if with_dri or with_gallium
- if with_glx == 'disabled' and not with_egl
+ if with_glx == 'disabled' and not with_egl and not with_platform_haiku
error('building dri or gallium drivers require at least one window system')
endif
endif
@@ -640,6 +645,9 @@ if with_platform_android
]
pre_args += '-DHAVE_ANDROID_PLATFORM'
endif
+if with_platform_haiku
+ pre_args += '-DHAVE_HAIKU_PLATFORM'
+endif
prog_python2 = find_program('python2')
has_ma
Re: [Mesa-dev] [PATCH] i965: Fix aux-surface size check
On Thu, Feb 15, 2018 at 7:42 AM, Daniel Stone wrote:
> The previous commit reworked the checks intel_from_planar() to check the
> right individual cases for regular/planar/aux buffers, and do size
> checks in all cases.
>
> Unfortunately, the aux size check was broken, and required the aux
> surface to be allocated with the correct aux stride, but full image
> height (!).
>
> As the ISL aux surface is not recorded in the DRIimage, we cannot easily
> access it to check. Instead, store the aux size from when we do have the
> ISL surface to hand, and check against that later when we go to access
> the aux surface.
>
> Signed-off-by: Daniel Stone
> Fixes: c2c4e5bae3ba ("i965: Fix bugs in intel_from_planar")
> Cc: Jason Ekstrand
> ---
> src/mesa/drivers/dri/i965/intel_image.h | 3 +++
> src/mesa/drivers/dri/i965/intel_screen.c | 10 +++---
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_image.h
> b/src/mesa/drivers/dri/i965/intel_image.h
> index 78d689a11a3..a8193c6def9 100644
> --- a/src/mesa/drivers/dri/i965/intel_image.h
> +++ b/src/mesa/drivers/dri/i965/intel_image.h
> @@ -98,6 +98,9 @@ struct __DRIimageRec {
> /** Pitch of the auxiliary compression surface. */
> uint32_t aux_pitch;
>
> + /** Total size in bytes of the auxiliary compression surface. */
> + uint32_t aux_size;
> +
> /**
> * Provided by EGL_EXT_image_dma_buf_import.
> * \{
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index 1c0fffa2e96..a21b08e51b1 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -750,6 +750,7 @@ intel_create_image_common(__DRIscreen *dri_screen,
> if (aux_surf.size) {
>image->aux_offset = surf.size;
>image->aux_pitch = aux_surf.row_pitch;
> + image->aux_size = aux_surf.size;
>
We also need to do this in create_image_from_fds_common
> }
>
> return image;
> @@ -1312,7 +1313,7 @@ intel_query_dma_buf_modifiers(__DRIscreen *_screen,
> int fourcc, int max,
> static __DRIimage *
> intel_from_planar(__DRIimage *parent, int plane, void *loaderPrivate)
> {
> -int width, height, offset, stride, dri_format;
> +int width, height, offset, stride, size, dri_format;
> __DRIimage *image;
>
> if (parent == NULL)
> @@ -1331,24 +1332,27 @@ intel_from_planar(__DRIimage *parent, int plane,
> void *loaderPrivate)
> int index = f->planes[plane].buffer_index;
> offset = parent->offsets[index];
> stride = parent->strides[index];
> + size = height * stride;
> } else if (plane == 0) {
> /* The only plane of a non-planar image: copy the parent definition
> * directly. */
> dri_format = parent->dri_format;
> offset = parent->offset;
> stride = parent->pitch;
> + size = height * stride;
> } else if (plane == 1 && parent->modifier != DRM_FORMAT_MOD_INVALID &&
> isl_drm_modifier_has_aux(parent->modifier)) {
> /* Auxiliary plane */
> dri_format = parent->dri_format;
> offset = parent->aux_offset;
> stride = parent->aux_pitch;
> + size = parent->aux_size;
> } else {
> return NULL;
> }
>
> -if (offset + height * stride > parent->bo->size) {
> - _mesa_warning(NULL, "intel_create_sub_image: subimage out of
> bounds");
> +if (offset + size > parent->bo->size) {
> + _mesa_warning(NULL, "intel_from_planar: subimage out of bounds");
> return NULL;
> }
>
> --
> 2.14.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105098] [RADV] GPU freeze with simple Vulkan App
https://bugs.freedesktop.org/show_bug.cgi?id=105098 Bas Nieuwenhuizen changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #5 from Bas Nieuwenhuizen --- The non-constant indexing was indeed the issue. Normally we use some instructions for those but Vega switched to different instruction and a bug in LLVM causes a hang with them. We had a workaround for that but it turned out it did not trigger for this shader due to declaring the array in global scope. https://patchwork.freedesktop.org/patch/205018/ should fix the issue. Does this also fix your app? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: Always lower indirect derefs after nir_lower_global_vars_to_local.
Otherwise new local variables can cause hangs on vega.
CC:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105098
---
src/amd/vulkan/radv_pipeline.c | 11 +--
src/amd/vulkan/radv_shader.c | 74 +++---
src/amd/vulkan/radv_shader.h | 4 +++
3 files changed, 53 insertions(+), 36 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 8f872e7c14..0d1958fc93 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1525,9 +1525,16 @@ radv_link_shaders(struct radv_pipeline *pipeline,
nir_shader **shaders)
ordered_shaders[i -
1]);
if (progress) {
- nir_lower_global_vars_to_local(ordered_shaders[i]);
+ if (nir_lower_global_vars_to_local(ordered_shaders[i]))
{
+ radv_lower_indirect_derefs(ordered_shaders[i],
+
pipeline->device->physical_device);
+ }
radv_optimize_nir(ordered_shaders[i]);
- nir_lower_global_vars_to_local(ordered_shaders[i - 1]);
+
+ if (nir_lower_global_vars_to_local(ordered_shaders[i -
1])) {
+ radv_lower_indirect_derefs(ordered_shaders[i -
1],
+
pipeline->device->physical_device);
+ }
radv_optimize_nir(ordered_shaders[i - 1]);
}
}
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 42f83bb335..d9b8e209a9 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -114,6 +114,45 @@ void radv_DestroyShaderModule(
vk_free2(&device->alloc, pAllocator, module);
}
+bool
+radv_lower_indirect_derefs(struct nir_shader *nir,
+ struct radv_physical_device *device)
+{
+ /* While it would be nice not to have this flag, we are constrained
+* by the reality that LLVM 5.0 doesn't have working VGPR indexing
+* on GFX9.
+*/
+ bool llvm_has_working_vgpr_indexing =
+ device->rad_info.chip_class <= VI;
+
+ /* TODO: Indirect indexing of GS inputs is unimplemented.
+*
+* TCS and TES load inputs directly from LDS or offchip memory, so
+* indirect indexing is trivial.
+*/
+ nir_variable_mode indirect_mask = 0;
+ if (nir->info.stage == MESA_SHADER_GEOMETRY ||
+ (nir->info.stage != MESA_SHADER_TESS_CTRL &&
+nir->info.stage != MESA_SHADER_TESS_EVAL &&
+!llvm_has_working_vgpr_indexing)) {
+ indirect_mask |= nir_var_shader_in;
+ }
+ if (!llvm_has_working_vgpr_indexing &&
+ nir->info.stage != MESA_SHADER_TESS_CTRL)
+ indirect_mask |= nir_var_shader_out;
+
+ /* TODO: We shouldn't need to do this, however LLVM isn't currently
+* smart enough to handle indirects without causing excess spilling
+* causing the gpu to hang.
+*
+* See the following thread for more details of the problem:
+* https://lists.freedesktop.org/archives/mesa-dev/2017-July/162106.html
+*/
+ indirect_mask |= nir_var_local;
+
+ return nir_lower_indirect_derefs(nir, indirect_mask);
+}
+
void
radv_optimize_nir(struct nir_shader *shader)
{
@@ -254,40 +293,6 @@ radv_shader_compile_to_nir(struct radv_device *device,
nir_shader_gather_info(nir, entry_point->impl);
- /* While it would be nice not to have this flag, we are constrained
-* by the reality that LLVM 5.0 doesn't have working VGPR indexing
-* on GFX9.
-*/
- bool llvm_has_working_vgpr_indexing =
- device->physical_device->rad_info.chip_class <= VI;
-
- /* TODO: Indirect indexing of GS inputs is unimplemented.
-*
-* TCS and TES load inputs directly from LDS or offchip memory, so
-* indirect indexing is trivial.
-*/
- nir_variable_mode indirect_mask = 0;
- if (nir->info.stage == MESA_SHADER_GEOMETRY ||
- (nir->info.stage != MESA_SHADER_TESS_CTRL &&
-nir->info.stage != MESA_SHADER_TESS_EVAL &&
-!llvm_has_working_vgpr_indexing)) {
- indirect_mask |= nir_var_shader_in;
- }
- if (!llvm_has_working_vgpr_indexing &&
- nir->info.stage != MESA_SHADER_TESS_CTRL)
- indirect_mask |= nir_var_shader_out;
-
- /* TODO: We shouldn't need to do this, however LLVM isn't currently
-* smart enough to handle indirects without causing excess spilling
-* causing the gpu to hang.
-*
-* See the following thread for more details of the problem:
-* https://lists.freedesktop.org/archives/mesa-dev/2
Re: [Mesa-dev] [PATCH 07/21] vulkan: Add EXT_acquire_xlib_display
Eric Engestrom writes:
> Can be simplified a bit:
>
> _xlib_lease = get_option('xlib-lease')
> if _xlib_lease == 'auto'
> with_xlib_lease = with_platform_x11 and with_platform_display
> else
> with_xlib_lease = _xlib_lease == 'true'
> endif
>
> (We also usually try to avoid changing the type of a var, and meson might
> start being more strict with types in future releases)
I wondered about that in the places I copied my code from. Good to know
there's a better practice. I've switched to using this form.
>> +if with_xlib_lease
>> + vulkan_wsi_deps += dep_xcb_xrandr
>> + vulkan_wsi_args += [
>> +'-DVK_USE_PLATFORM_XLIB_XRANDR_EXT',
>> + ]
>
> vulkan_wsi_args += '-DVK_USE_PLATFORM_XLIB_XRANDR_EXT'
I switched all of the inappropriate usage to this form for six separate
patches (three each for core/anv/radv by two extensions (DISPLAY and
XLIB_XRANDR).
> with that, the meson part of this is
> Reviewed-by: Eric Engestrom
Awesome!
Thanks for reviewing the build system bits; I'm just starting to use
meson and every new change is a learning opportunity at this point.
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] clover: Fix build after llvm r325155 and r325160
r325155 ("Pass a reference to a module to the bitcode writer.")
and
r325160 ("Pass module reference to CloneModule")
change function interface from pointer to reference.
Signed-off-by: Jan Vesely
---
.../state_trackers/clover/llvm/codegen/bitcode.cpp | 2 +-
.../state_trackers/clover/llvm/codegen/native.cpp | 2 +-
src/gallium/state_trackers/clover/llvm/compat.hpp | 28 ++
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
index 679ecd8758..40bb426218 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
@@ -66,7 +66,7 @@ namespace {
emit_code(const ::llvm::Module &mod) {
::llvm::SmallVector data;
::llvm::raw_svector_ostream os { data };
- WriteBitcodeToFile(&mod, os);
+ compat::write_bitcode_to_file(mod, os);
return { os.str().begin(), os.str().end() };
}
}
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
index 12c83a92b6..409f8ac32f 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
@@ -156,7 +156,7 @@ clover::llvm::print_module_native(const ::llvm::Module &mod,
const target &target) {
std::string log;
try {
- std::unique_ptr< ::llvm::Module> cmod { CloneModule(&mod) };
+ std::unique_ptr< ::llvm::Module> cmod { compat::clone_module(mod) };
return as_string(emit_code(*cmod, target,
TargetMachine::CGFT_AssemblyFile, log));
} catch (...) {
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 6fc75fb250..db9e8020cf 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -36,9 +36,17 @@
#include "util/algorithm.hpp"
+#if HAVE_LLVM < 0x0400
+#include
+#else
+#include
+#include
+#endif
+
#include
#include
#include
+#include
#include
#if HAVE_LLVM >= 0x0400
#include
@@ -217,6 +225,26 @@ namespace clover {
ctx.setDiagnosticHandler(diagnostic_handler, data);
#endif
}
+
+ inline std::unique_ptr< ::llvm::Module>
+ clone_module(const ::llvm::Module &mod)
+ {
+#if HAVE_LLVM >= 0x0700
+ return ::llvm::CloneModule(mod);
+#else
+ return ::llvm::CloneModule(&mod);
+#endif
+ }
+
+template void
+ write_bitcode_to_file(const ::llvm::Module &mod, T &os)
+ {
+#if HAVE_LLVM >= 0x0700
+ ::llvm::WriteBitcodeToFile(mod, os);
+#else
+ ::llvm::WriteBitcodeToFile(&mod, os);
+#endif
+ }
}
}
}
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/13] mesa: Make _mesa_vertex_attrib_binding public.
From: Mathias Fröhlich
Change vertex_attrib_binding() to _mesa_vertex_attrib_binding(),
add a flush_vertices argument, and make it publically
available.
The function will be needed later in the series.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/varray.c | 38 --
src/mesa/main/varray.h | 7 +++
2 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 90b874aa49..f7d32fdbef 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -155,11 +155,11 @@ update_attribute_map_mode(const struct gl_context *ctx,
* Sets the BufferBindingIndex field for the vertex attribute given by
* attribIndex.
*/
-static void
-vertex_attrib_binding(struct gl_context *ctx,
- struct gl_vertex_array_object *vao,
- gl_vert_attrib attribIndex,
- GLuint bindingIndex)
+void
+_mesa_vertex_attrib_binding(struct gl_context *ctx,
+struct gl_vertex_array_object *vao,
+gl_vert_attrib attribIndex,
+GLuint bindingIndex, bool flush_vertices)
{
struct gl_array_attributes *array = &vao->VertexAttrib[attribIndex];
@@ -171,7 +171,9 @@ vertex_attrib_binding(struct gl_context *ctx,
else
vao->VertexAttribBufferMask &= ~array_bit;
- FLUSH_VERTICES(ctx, _NEW_ARRAY);
+ if (flush_vertices) {
+ FLUSH_VERTICES(ctx, _NEW_ARRAY);
+ }
vao->BufferBinding[array->BufferBindingIndex]._BoundArrays &= ~array_bit;
vao->BufferBinding[bindingIndex]._BoundArrays |= array_bit;
@@ -592,7 +594,7 @@ update_array(struct gl_context *ctx,
normalized, integer, doubles, 0);
/* Reset the vertex attrib binding */
- vertex_attrib_binding(ctx, vao, attrib, attrib);
+ _mesa_vertex_attrib_binding(ctx, vao, attrib, attrib, true);
/* The Stride and Ptr fields are not set by update_array_format() */
struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
@@ -2030,7 +2032,7 @@ _mesa_VertexAttribDivisor_no_error(GLuint index, GLuint
divisor)
* VertexAttribBinding(index, index);
* VertexBindingDivisor(index, divisor);"
*/
- vertex_attrib_binding(ctx, vao, genericIndex, genericIndex);
+ _mesa_vertex_attrib_binding(ctx, vao, genericIndex, genericIndex, true);
vertex_binding_divisor(ctx, vao, genericIndex, divisor);
}
@@ -2072,7 +2074,7 @@ _mesa_VertexAttribDivisor(GLuint index, GLuint divisor)
* VertexAttribBinding(index, index);
* VertexBindingDivisor(index, divisor);"
*/
- vertex_attrib_binding(ctx, vao, genericIndex, genericIndex);
+ _mesa_vertex_attrib_binding(ctx, vao, genericIndex, genericIndex, true);
vertex_binding_divisor(ctx, vao, genericIndex, divisor);
}
@@ -2674,9 +2676,9 @@ vertex_array_attrib_binding(struct gl_context *ctx,
assert(VERT_ATTRIB_GENERIC(attribIndex) < ARRAY_SIZE(vao->VertexAttrib));
- vertex_attrib_binding(ctx, vao,
- VERT_ATTRIB_GENERIC(attribIndex),
- VERT_ATTRIB_GENERIC(bindingIndex));
+ _mesa_vertex_attrib_binding(ctx, vao,
+ VERT_ATTRIB_GENERIC(attribIndex),
+ VERT_ATTRIB_GENERIC(bindingIndex), true);
}
@@ -2684,9 +2686,9 @@ void GLAPIENTRY
_mesa_VertexAttribBinding_no_error(GLuint attribIndex, GLuint bindingIndex)
{
GET_CURRENT_CONTEXT(ctx);
- vertex_attrib_binding(ctx, ctx->Array.VAO,
- VERT_ATTRIB_GENERIC(attribIndex),
- VERT_ATTRIB_GENERIC(bindingIndex));
+ _mesa_vertex_attrib_binding(ctx, ctx->Array.VAO,
+ VERT_ATTRIB_GENERIC(attribIndex),
+ VERT_ATTRIB_GENERIC(bindingIndex), true);
}
@@ -2720,9 +2722,9 @@ _mesa_VertexArrayAttribBinding_no_error(GLuint vaobj,
GLuint attribIndex,
GET_CURRENT_CONTEXT(ctx);
struct gl_vertex_array_object *vao = _mesa_lookup_vao(ctx, vaobj);
- vertex_attrib_binding(ctx, vao,
- VERT_ATTRIB_GENERIC(attribIndex),
- VERT_ATTRIB_GENERIC(bindingIndex));
+ _mesa_vertex_attrib_binding(ctx, vao,
+ VERT_ATTRIB_GENERIC(attribIndex),
+ VERT_ATTRIB_GENERIC(bindingIndex), true);
}
diff --git a/src/mesa/main/varray.h b/src/mesa/main/varray.h
index 93ffb37a0d..6585355771 100644
--- a/src/mesa/main/varray.h
+++ b/src/mesa/main/varray.h
@@ -120,6 +120,13 @@ _mesa_disable_vertex_array_attrib(struct gl_context *ctx,
gl_vert_attrib attrib, bool flush_vertices);
+extern void
+_mesa_vertex_attrib_binding(struct gl_context *ctx,
+struct gl_vertex_array_object *vao,
+gl_vert_attrib attribIndex,
+
[Mesa-dev] [PATCH 05/13] vbo: Implement method to track the inputs array.
From: Mathias Fröhlich
Provided the _DrawVAO and the derived state that is
maintained if we have the _DrawVAO set, implement a
method to incrementally update the array of
gl_vertex_array input pointers.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo.h | 28 +
src/mesa/vbo/vbo_context.c | 1 +
src/mesa/vbo/vbo_exec.c| 76 ++
src/mesa/vbo/vbo_private.h | 2 ++
4 files changed, 107 insertions(+)
diff --git a/src/mesa/vbo/vbo.h b/src/mesa/vbo/vbo.h
index d594ba8f6a..bb8ab7a745 100644
--- a/src/mesa/vbo/vbo.h
+++ b/src/mesa/vbo/vbo.h
@@ -254,6 +254,34 @@ vbo_sw_primitive_restart(struct gl_context *ctx,
const struct _mesa_index_buffer *ib,
struct gl_buffer_object *indirect);
+
+/**
+ * Utility that tracks and updates the current array entries.
+ */
+struct vbo_inputs
+{
+ const struct gl_vertex_array *inputs[VERT_ATTRIB_MAX];
+ GLbitfield current;
+ gl_vertex_processing_mode vertex_processing_mode;
+};
+
+
+/**
+ * Initialize inputs.
+ */
+void
+_vbo_array_init(struct vbo_inputs *inputs);
+
+
+/**
+ * Update the gl_vertex_array array inside the vbo_inputs structure
+ * provided the current _VPMode, the provided vao and
+ * the vao's enabled arrays filtered by the filter bitmask.
+ */
+void
+_vbo_update_inputs(struct gl_context *ctx, struct vbo_inputs *inputs);
+
+
void GLAPIENTRY
_es_Color4f(GLfloat r, GLfloat g, GLfloat b, GLfloat a);
diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index 5bc6bf0acd..cc9cbffc51 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -234,6 +234,7 @@ _vbo_CreateContext(struct gl_context *ctx)
init_legacy_currval(ctx);
init_generic_currval(ctx);
init_mat_currval(ctx);
+ _vbo_array_init(&vbo->array);
vbo_set_indirect_draw_func(ctx, vbo_draw_indirect_prims);
/* make sure all VBO_ATTRIB_ values can fit in an unsigned byte */
diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c
index 372d0237aa..c5f01e3e4d 100644
--- a/src/mesa/vbo/vbo_exec.c
+++ b/src/mesa/vbo/vbo_exec.c
@@ -27,6 +27,7 @@
#include "main/glheader.h"
+#include "main/arrayobj.h"
#include "main/mtypes.h"
#include "main/api_arrayelt.h"
#include "main/vtxfmt.h"
@@ -240,3 +241,78 @@ vbo_merge_prims(struct _mesa_prim *p0, const struct
_mesa_prim *p1)
p0->count += p1->count;
p0->end = p1->end;
}
+
+
+void
+_vbo_array_init(struct vbo_inputs *inputs)
+{
+ inputs->current = 0;
+ inputs->vertex_processing_mode = VP_MODE_FF;
+}
+
+
+/**
+ * Update those gl_vertex_array array inside the vbo_inputs structure
+ * from the enable bits pointing into the provided vao.
+ */
+static inline void
+update_vao_inputs(struct gl_context *ctx,
+ struct vbo_inputs *inputs, GLbitfield enable)
+{
+ const struct gl_vertex_array_object *vao = ctx->Array._DrawVAO;
+
+ /* Make sure we process only arrays enabled in the VAO */
+ assert((enable & ~_mesa_get_vao_vp_inputs(vao)) == 0);
+
+ /* Fill in the client arrays from the VAO */
+ const GLubyte *const map = _mesa_vao_attribute_map[vao->_AttributeMapMode];
+ const struct gl_vertex_array *array = vao->_VertexArray;
+ const struct gl_vertex_array **iarray = &inputs->inputs[0];
+ while (enable) {
+ const int attr = u_bit_scan(&enable);
+ iarray[attr] = &array[map[attr]];
+ }
+}
+
+
+/**
+ * Update those gl_vertex_array array inside the vbo_inputs structure
+ * from the current bits pointing into the current values.
+ */
+static inline void
+update_current_inputs(struct gl_context *ctx,
+ struct vbo_inputs *inputs, GLbitfield current)
+{
+ gl_vertex_processing_mode mode = ctx->VertexProgram._VPMode;
+
+ /* All previously non current array pointers need update. */
+ GLbitfield mask = current & ~inputs->current;
+ /* On mode change, the slots aliasing with materials need update too */
+ if (mode != inputs->vertex_processing_mode)
+ mask |= current & VERT_BIT_MAT_ALL;
+
+ struct vbo_context *vbo = vbo_context(ctx);
+ const struct gl_vertex_array *const currval = &vbo->currval[0];
+ const struct gl_vertex_array **iarray = &inputs->inputs[0];
+ const GLubyte *const map = _vbo_attribute_alias_map[mode];
+ while (mask) {
+ const int attr = u_bit_scan(&mask);
+ iarray[attr] = &currval[map[attr]];
+ }
+
+ inputs->current = current;
+ inputs->vertex_processing_mode = mode;
+}
+
+
+void
+_vbo_update_inputs(struct gl_context *ctx, struct vbo_inputs *inputs)
+{
+ const GLbitfield enable = ctx->Array._DrawVAOEnabled;
+
+ /* Update array input pointers */
+ update_vao_inputs(ctx, inputs, enable);
+
+ /* The rest must be current inputs. */
+ update_current_inputs(ctx, inputs, ~enable & VERT_BIT_ALL);
+}
diff --git a/src/mesa/vbo/vbo_private.h b/src/mesa/vbo/vbo_private.h
index 49922892e5..545daa3b87 100644
--- a/src/mesa/vbo/vbo_private.h
+++ b/src/mesa/vbo/vbo_pri
[Mesa-dev] [PATCH 04/13] mesa: Introduce a yet unused _DrawVAO.
From: Mathias Fröhlich
During the patch series this VAO gets populated with
either the currently bound VAO or an internal VAO that
will be used for immediate mode and dlist rendering.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/arrayobj.c | 4
src/mesa/main/attrib.c | 2 ++
src/mesa/main/context.c | 2 ++
src/mesa/main/mtypes.h | 7 +++
src/mesa/main/state.c| 21 +
src/mesa/main/state.h| 8
src/mesa/main/varray.c | 2 ++
7 files changed, 46 insertions(+)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index a6fa33c82c..cf9c5d7ecc 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -49,6 +49,7 @@
#include "arrayobj.h"
#include "macros.h"
#include "mtypes.h"
+#include "state.h"
#include "varray.h"
#include "main/dispatch.h"
#include "util/bitscan.h"
@@ -578,6 +579,7 @@ bind_vertex_array(struct gl_context *ctx, GLuint id, bool
no_error)
* deleted.
*/
_mesa_set_drawing_arrays(ctx, NULL);
+ _mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);
ctx->NewState |= _NEW_ARRAY;
_mesa_reference_vao(ctx, &ctx->Array.VAO, newObj);
@@ -629,6 +631,8 @@ delete_vertex_arrays(struct gl_context *ctx, GLsizei n,
const GLuint *ids)
if (ctx->Array.LastLookedUpVAO == obj)
_mesa_reference_vao(ctx, &ctx->Array.LastLookedUpVAO, NULL);
+ if (ctx->Array._DrawVAO == obj)
+_mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);
/* Unreference the array object.
* If refcount hits zero, the object will be deleted.
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 398ff653b7..dd6b98ce04 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -57,6 +57,7 @@
#include "viewport.h"
#include "mtypes.h"
#include "main/dispatch.h"
+#include "state.h"
#include "hash.h"
#include
@@ -1548,6 +1549,7 @@ copy_array_attrib(struct gl_context *ctx,
/* Invalidate array state. It will be updated during the next draw. */
_mesa_set_drawing_arrays(ctx, NULL);
+ _mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);
}
/**
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 0aa2e3639f..e13343b5e6 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1335,6 +1335,8 @@ _mesa_free_context_data( struct gl_context *ctx )
_mesa_reference_vao(ctx, &ctx->Array.VAO, NULL);
_mesa_reference_vao(ctx, &ctx->Array.DefaultVAO, NULL);
+ _mesa_reference_vao(ctx, &ctx->Array._EmptyVAO, NULL);
+ _mesa_reference_vao(ctx, &ctx->Array._DrawVAO, NULL);
_mesa_free_attrib_data(ctx);
_mesa_free_buffer_objects(ctx);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 41df04d38d..b6fdb69283 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1691,6 +1691,13 @@ struct gl_array_attrib
/* GL_ARB_vertex_buffer_object */
struct gl_buffer_object *ArrayBufferObj;
+ /** Vertex array object used when no specific DrawVAO is bound */
+ struct gl_vertex_array_object *_EmptyVAO;
+ /** Vertex array object used for the current draw */
+ struct gl_vertex_array_object *_DrawVAO;
+ /** The possibly reduced set of enabled vertex attributes from the above */
+ GLbitfield _DrawVAOEnabled;
+
/**
* Vertex arrays as consumed by a driver.
* The array pointer is set up only by the VBO module.
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 2fd4fb9d32..42bf483682 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -479,3 +479,24 @@ _mesa_update_vertex_processing_mode(struct gl_context *ctx)
else
ctx->VertexProgram._VPMode = VP_MODE_FF;
}
+
+
+void
+_mesa_set_draw_vao(struct gl_context *ctx, struct gl_vertex_array_object *vao,
+ GLbitfield filter)
+{
+ struct gl_vertex_array_object **ptr = &ctx->Array._DrawVAO;
+ if (*ptr != vao) {
+ _mesa_reference_vao_(ctx, ptr, vao);
+ ctx->NewDriverState |= ctx->DriverFlags.NewArray;
+ } else if (vao->NewArrays) {
+ ctx->NewDriverState |= ctx->DriverFlags.NewArray;
+ }
+
+ /* May shuffle the position and generic0 bits around, filter out unwanted */
+ const GLbitfield enabled = filter & _mesa_get_vao_vp_inputs(vao);
+ if (ctx->Array._DrawVAOEnabled != enabled)
+ ctx->NewDriverState |= ctx->DriverFlags.NewArray;
+ ctx->Array._DrawVAOEnabled = enabled;
+ _mesa_set_varying_vp_inputs(ctx, enabled);
+}
diff --git a/src/mesa/main/state.h b/src/mesa/main/state.h
index 049166578c..589c6650ad 100644
--- a/src/mesa/main/state.h
+++ b/src/mesa/main/state.h
@@ -53,6 +53,14 @@ extern void
_mesa_update_vertex_processing_mode(struct gl_context *ctx);
+/**
+ * Set the _DrawVAO and the net enabled arrays.
+ */
+void
+_mesa_set_draw_vao(struct gl_context *ctx, struct gl_vertex_array_object *vao,
+ GLbitfield filter);
+
+
static inline bool
_mesa_ati_fragment_shader_enabled(const struct gl_context *ctx)
{
dif
[Mesa-dev] [PATCH 06/13] vbo: Use _DrawVAO for array type draw commands.
From: Mathias Fröhlich
Switch over to use the _DrawVAO for all the array type draws.
The _DrawVAO needs to be set before we enter _mesa_update_state,
so move setting the draw method in front of the first call
to _mesa_update_state which is in turn called from the *validate*Draw*
calls. Using the gl_vertex_array_object::_Enabled bitmask,
gl_vertex_program_state::_VPMode and gl_vertex_array_object::_AttributeMapMode
we can already set varying_vp_inputs before we call _mesa_update_state
the first time. Thus remove duplicate state validation.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_context.c| 8 ++-
src/mesa/vbo/vbo_exec.h | 6 --
src/mesa/vbo/vbo_exec_array.c | 159 +-
3 files changed, 100 insertions(+), 73 deletions(-)
diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index cc9cbffc51..1a9935d5e8 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -206,11 +206,15 @@ vbo_exec_invalidate_state(struct gl_context *ctx)
struct vbo_exec_context *exec = &vbo->exec;
if (ctx->NewState & (_NEW_PROGRAM | _NEW_ARRAY)) {
- if (!exec->validating)
- exec->array.recalculate_inputs = GL_TRUE;
+ exec->array.recalculate_inputs = GL_TRUE;
_ae_invalidate_state(ctx);
}
+ /* If _mesa_update_state is called in a non draw code path,
+* changes in the VAO need to be captured.
+*/
+ if (ctx->Array.VAO->NewArrays)
+ exec->array.recalculate_inputs = GL_TRUE;
if (ctx->NewState & _NEW_EVAL)
exec->eval.recalculate_maps = GL_TRUE;
diff --git a/src/mesa/vbo/vbo_exec.h b/src/mesa/vbo/vbo_exec.h
index 7e00d45de0..b00045c7c8 100644
--- a/src/mesa/vbo/vbo_exec.h
+++ b/src/mesa/vbo/vbo_exec.h
@@ -76,7 +76,6 @@ struct vbo_exec_context
struct gl_context *ctx;
GLvertexformat vtxfmt;
GLvertexformat vtxfmt_noop;
- GLboolean validating; /**< if we're in the middle of state validation */
struct {
struct gl_buffer_object *bufferobj;
@@ -119,11 +118,6 @@ struct vbo_exec_context
} eval;
struct {
- /* Arrays and current values manipulated according to program
- * mode, etc. These are the attributes as seen by vertex
- * programs:
- */
- const struct gl_vertex_array *inputs[VERT_ATTRIB_MAX];
GLboolean recalculate_inputs;
} array;
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 0c3c9017b1..5741696943 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -319,29 +319,14 @@ print_draw_arrays(struct gl_context *ctx,
/**
- * Set the vbo->exec->inputs[] pointers to point to the enabled
- * vertex arrays. This depends on the current vertex program/shader
- * being executed because of whether or not generic vertex arrays
- * alias the conventional vertex arrays.
- * For arrays that aren't enabled, we set the input[attrib] pointer
- * to point at a zero-stride current value "array".
+ * Return a filter mask for the net enabled vao arrays.
+ * This is to maks out arrays that would otherwise superseed required current
+ * values for the fixed function shaders for example.
*/
-static void
-recalculate_input_bindings(struct gl_context *ctx)
+static GLbitfield
+enabled_filter(const struct gl_context *ctx)
{
- struct vbo_context *vbo = vbo_context(ctx);
- struct vbo_exec_context *exec = &vbo->exec;
- const struct gl_vertex_array_object *vao = ctx->Array.VAO;
- const struct gl_vertex_array *vertexAttrib = vao->_VertexArray;
- const struct gl_vertex_array **inputs = &exec->array.inputs[0];
-
- /* May shuffle the position and generic0 bits around */
- GLbitfield vp_inputs = _mesa_get_vao_vp_inputs(vao);
-
- const gl_vertex_processing_mode processing_mode
- = ctx->VertexProgram._VPMode;
- const GLubyte * const map = _vbo_attribute_alias_map[processing_mode];
- switch (processing_mode) {
+ switch (ctx->VertexProgram._VPMode) {
case VP_MODE_FF:
/* When no vertex program is active (or the vertex program is generated
* from fixed-function state). We put the material values into the
@@ -349,9 +334,7 @@ recalculate_input_bindings(struct gl_context *ctx)
* slots from the enabled arrays so that the current material values
* are pulled instead of the vao arrays.
*/
- vp_inputs &= VERT_BIT_FF_ALL;
-
- break;
+ return VERT_BIT_FF_ALL;
case VP_MODE_SHADER:
/* There are no shaders in OpenGL ES 1.x, so this code path should be
@@ -360,40 +343,20 @@ recalculate_input_bindings(struct gl_context *ctx)
*/
assert(ctx->API != API_OPENGLES);
- /* In the compatibility profile of desktop OpenGL, the generic[0]
- * attribute array aliases and overrides the legacy position array.
- * Otherwise, legacy attributes available in the legacy slots,
- * generic attributes in the generic slots and materials are not
- * available as per-v
[Mesa-dev] [PATCH 07/13] mesa: Add flush_vertices to _mesa_{enable, disable}_vertex_array_attrib.
From: Mathias Fröhlich
We will need the flush_vertices argument later in this series.
Signed-off-by: Mathias Fröhlich
---
src/mesa/drivers/common/meta.c | 18 +++---
src/mesa/main/enable.c | 4 ++--
src/mesa/main/varray.c | 30 +++---
src/mesa/main/varray.h | 4 ++--
4 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 0cb2ef450e..3d9833dabb 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -350,7 +350,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_GENERIC(0),
*buf_obj, 0, sizeof(struct vertex));
_mesa_enable_vertex_array_attrib(ctx, array_obj,
- VERT_ATTRIB_GENERIC(0));
+ VERT_ATTRIB_GENERIC(0), true);
if (texcoord_size > 0) {
_mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_GENERIC(1),
texcoord_size, GL_FLOAT, GL_RGBA,
@@ -359,7 +359,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_GENERIC(1),
*buf_obj, 0, sizeof(struct vertex));
_mesa_enable_vertex_array_attrib(ctx, array_obj,
- VERT_ATTRIB_GENERIC(1));
+ VERT_ATTRIB_GENERIC(1), true);
}
} else {
_mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_POS,
@@ -368,7 +368,8 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
offsetof(struct vertex, x));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_POS,
*buf_obj, 0, sizeof(struct vertex));
- _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_POS);
+ _mesa_enable_vertex_array_attrib(ctx, array_obj,
+ VERT_ATTRIB_POS, true);
if (texcoord_size > 0) {
_mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_TEX(0),
@@ -377,7 +378,8 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
offsetof(struct vertex, tex));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_TEX(0),
*buf_obj, 0, sizeof(struct vertex));
-_mesa_enable_vertex_array_attrib(ctx, array_obj,
VERT_ATTRIB_TEX(0));
+_mesa_enable_vertex_array_attrib(ctx, array_obj,
+ VERT_ATTRIB_TEX(0), true);
}
if (color_size > 0) {
@@ -387,7 +389,8 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
offsetof(struct vertex, r));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_COLOR0,
*buf_obj, 0, sizeof(struct vertex));
-_mesa_enable_vertex_array_attrib(ctx, array_obj,
VERT_ATTRIB_COLOR0);
+_mesa_enable_vertex_array_attrib(ctx, array_obj,
+ VERT_ATTRIB_COLOR0, true);
}
}
} else {
@@ -3345,7 +3348,7 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x,
GLfloat y, GLfloat z,
offsetof(struct vertex, x));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_POS,
drawtex->buf_obj, 0, sizeof(struct vertex));
- _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_POS);
+ _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_POS, true);
for (i = 0; i < ctx->Const.MaxTextureUnits; i++) {
@@ -3356,7 +3359,8 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x,
GLfloat y, GLfloat z,
offsetof(struct vertex, st[i]));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_TEX(i),
drawtex->buf_obj, 0, sizeof(struct vertex));
- _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_TEX(i));
+ _mesa_enable_vertex_array_attrib(ctx, array_obj,
+ VERT_ATTRIB_TEX(i), true);
}
}
else {
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index 868b73ac68..7625a4c957 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -68,9 +68,9 @@ static void
vao_state(struct gl_context *ctx, gl_vert_attrib attr, GLboolean state)
{
if (state)
- _mesa_enable_vertex_array_attrib(ctx, ctx->Array.VAO, attr);
+ _mesa_enable_vertex_array_attrib(ctx, ctx->Array.VAO, attr, true);
else
- _mesa_disable_vertex_array_attrib(ctx, ctx->Array.VAO, attr);
+
[Mesa-dev] [PATCH 00/13] Switch over to use VAOs for drawing.
From: Mathias Fröhlich
Hi,
The following series moves over to draw via a VAO in all draw
paths. At the current stage this introduces an additional
indirection for the immediate mode and display list draws.
But in the mid term using a VAO should enable drivers to make
use of the binding information already present in the VAO
that gets lost when transforming VAO to a gl_vertex_array list.
In the mid term todays fast vbo_exec_array draw path should
move closer to the backend drivers. But the old style dlist
draw path does as well benefit from the preserved single
vbo binding information still visible in the VAO.
The changeset just cleans up the most obvious parts that are
directly involved with the changes done. For example the
duplicate _mesa_update_state call is no longer needed with the
series and cleaned up. But the series enables much more cleanup.
The series is tested without piglit regressions with my
available hardware that is i965, classic swrast and radeonsi.
Please review
Thanks!
Mathias
Mathias Fröhlich (13):
mesa: Provide an alternative to get_vp_mode()
vbo: Use _VPMode instead of get_vp_mode().
vbo: Remove get_vp_mode() and enum vp_mode.
mesa: Introduce a yet unused _DrawVAO.
vbo: Implement method to track the inputs array.
vbo: Use _DrawVAO for array type draw commands.
mesa: Add flush_vertices to
_mesa_{enable,disable}_vertex_array_attrib.
mesa: Make _mesa_vertex_attrib_binding public.
mesa: Add flush_vertices to _mesa_bind_vertex_buffer.
vbo: Implement tool functions for vbo specific VAO setup.
vbo: Make use of _DrawVAO from immediate mode draw
mesa: Use atomics for shared VAO reference counts.
vbo: Make use of _DrawVAO from the dlist code.
src/mesa/drivers/common/meta.c | 36 +
src/mesa/main/arbprogram.c | 5 ++
src/mesa/main/arrayobj.c | 39 --
src/mesa/main/arrayobj.h | 9 +++
src/mesa/main/attrib.c | 2 +
src/mesa/main/bufferobj.c | 2 +-
src/mesa/main/context.c| 5 ++
src/mesa/main/enable.c | 6 +-
src/mesa/main/mtypes.h | 38 ++
src/mesa/main/pipelineobj.c| 3 +
src/mesa/main/shaderapi.c | 5 ++
src/mesa/main/state.c | 44 +++
src/mesa/main/state.h | 15
src/mesa/main/varray.c | 85 -
src/mesa/main/varray.h | 13 +++-
src/mesa/program/program.c | 1 +
src/mesa/vbo/vbo.h | 28 +++
src/mesa/vbo/vbo_attrib.h | 4 +-
src/mesa/vbo/vbo_context.c | 17 -
src/mesa/vbo/vbo_exec.c| 80 +++-
src/mesa/vbo/vbo_exec.h| 14
src/mesa/vbo/vbo_exec_api.c| 47 +---
src/mesa/vbo/vbo_exec_array.c | 162 -
src/mesa/vbo/vbo_exec_draw.c | 116 -
src/mesa/vbo/vbo_private.h | 84 ++---
src/mesa/vbo/vbo_save.c| 37 ++
src/mesa/vbo/vbo_save.h| 4 +-
src/mesa/vbo/vbo_save_api.c| 132 +++--
src/mesa/vbo/vbo_save_draw.c | 63 +++-
29 files changed, 735 insertions(+), 361 deletions(-)
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/13] vbo: Make use of _DrawVAO from the dlist code.
From: Mathias Fröhlich
Finally use an internal VAO to execute display
list draws. Avoid duplicate state validation
for display list draws. Remove client arrays
previously used exclusively for display lists.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_save.c | 37 ++--
src/mesa/vbo/vbo_save.h | 4 +-
src/mesa/vbo/vbo_save_api.c | 132 +--
src/mesa/vbo/vbo_save_draw.c | 64 -
4 files changed, 144 insertions(+), 93 deletions(-)
diff --git a/src/mesa/vbo/vbo_save.c b/src/mesa/vbo/vbo_save.c
index 19c40ec530..f106cf279a 100644
--- a/src/mesa/vbo/vbo_save.c
+++ b/src/mesa/vbo/vbo_save.c
@@ -27,6 +27,7 @@
#include "main/mtypes.h"
+#include "main/arrayobj.h"
#include "main/bufferobj.h"
#include "vbo_private.h"
@@ -44,32 +45,8 @@ void vbo_save_init( struct gl_context *ctx )
vbo_save_api_init( save );
- {
- struct gl_vertex_array *arrays = save->arrays;
- unsigned i;
-
- memcpy(arrays, &vbo->currval[VBO_ATTRIB_POS],
- VERT_ATTRIB_FF_MAX * sizeof(arrays[0]));
- for (i = 0; i < VERT_ATTRIB_FF_MAX; ++i) {
- struct gl_vertex_array *array;
- array = &arrays[VERT_ATTRIB_FF(i)];
- array->BufferObj = NULL;
- _mesa_reference_buffer_object(ctx, &arrays->BufferObj,
-
vbo->currval[VBO_ATTRIB_POS+i].BufferObj);
- }
-
- memcpy(arrays + VERT_ATTRIB_GENERIC(0),
- &vbo->currval[VBO_ATTRIB_GENERIC0],
- VERT_ATTRIB_GENERIC_MAX * sizeof(arrays[0]));
-
- for (i = 0; i < VERT_ATTRIB_GENERIC_MAX; ++i) {
- struct gl_vertex_array *array;
- array = &arrays[VERT_ATTRIB_GENERIC(i)];
- array->BufferObj = NULL;
- _mesa_reference_buffer_object(ctx, &array->BufferObj,
- vbo->currval[VBO_ATTRIB_GENERIC0+i].BufferObj);
- }
- }
+ for (gl_vertex_processing_mode vpm = VP_MODE_FF; vpm < VP_MODE_MAX; ++vpm)
+ save->VAO[vpm] = NULL;
ctx->Driver.CurrentSavePrimitive = PRIM_OUTSIDE_BEGIN_END;
}
@@ -79,7 +56,9 @@ void vbo_save_destroy( struct gl_context *ctx )
{
struct vbo_context *vbo = vbo_context(ctx);
struct vbo_save_context *save = &vbo->save;
- GLuint i;
+
+ for (gl_vertex_processing_mode vpm = VP_MODE_FF; vpm < VP_MODE_MAX; ++vpm)
+ _mesa_reference_vao(ctx, &save->VAO[vpm], NULL);
if (save->prim_store) {
if ( --save->prim_store->refcount == 0 ) {
@@ -93,10 +72,6 @@ void vbo_save_destroy( struct gl_context *ctx )
save->vertex_store = NULL;
}
}
-
- for (i = 0; i < VBO_ATTRIB_MAX; i++) {
- _mesa_reference_buffer_object(ctx, &save->arrays[i].BufferObj, NULL);
- }
}
diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index cb0bff2341..edbce3673d 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -66,6 +66,7 @@ struct vbo_save_vertex_list {
GLenum16 attrtype[VBO_ATTRIB_MAX];
GLuint offsets[VBO_ATTRIB_MAX];
GLuint vertex_size; /**< size in GLfloats */
+ struct gl_vertex_array_object *VAO[VP_MODE_MAX];
/* Copy of the final vertex from node->vertex_store->bufferobj.
* Keep this in regular (non-VBO) memory to avoid repeated
@@ -140,14 +141,13 @@ struct vbo_save_context {
struct gl_context *ctx;
GLvertexformat vtxfmt;
GLvertexformat vtxfmt_noop; /**< Used if out_of_memory is true */
- struct gl_vertex_array arrays[VBO_ATTRIB_MAX];
- const struct gl_vertex_array *inputs[VBO_ATTRIB_MAX];
GLbitfield64 enabled; /**< mask of enabled vbo arrays. */
GLubyte attrsz[VBO_ATTRIB_MAX]; /**< 1, 2, 3 or 4 */
GLenum16 attrtype[VBO_ATTRIB_MAX]; /**< GL_FLOAT, GL_INT, etc */
GLubyte active_sz[VBO_ATTRIB_MAX]; /**< 1, 2, 3 or 4 */
GLuint vertex_size; /**< size in GLfloats */
+ struct gl_vertex_array_object *VAO[VP_MODE_MAX];
GLboolean out_of_memory; /**< True if last VBO allocation failed */
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index fb51bdb84e..1edf7b9dfa 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -68,6 +68,7 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
#include "main/glheader.h"
+#include "main/arrayobj.h"
#include "main/bufferobj.h"
#include "main/context.h"
#include "main/dlist.h"
@@ -79,6 +80,7 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
#include "main/vtxfmt.h"
#include "main/dispatch.h"
#include "main/state.h"
+#include "main/varray.h"
#include "util/bitscan.h"
#include "vbo_noop.h"
@@ -411,6 +413,112 @@ convert_line_loop_to_strip(struct vbo_save_context *save,
}
+/* Compare the present vao if it has the same setup. */
+static bool
+compare_vao(gl_vertex_processing_mode mode,
+const struct gl_vertex_array_object *vao,
+const struct gl_buffer_object *bo, GLintptr buffer_offset,
+GLuint stride, GLbitfield64 vao_enabled,
+const GLubyte size[V
[Mesa-dev] [PATCH 12/13] mesa: Use atomics for shared VAO reference counts.
From: Mathias Fröhlich
VAOs will be used in the next change as immutable object
across multiple contexts. Only reference counting may write
concurrently on the VAO. So, make the reference count
thread safe for those and only those VAO objects.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/arrayobj.c | 35 ++-
src/mesa/main/arrayobj.h | 9 +
src/mesa/main/mtypes.h | 7 +++
3 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index cf9c5d7ecc..063856d984 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -53,6 +53,7 @@
#include "varray.h"
#include "main/dispatch.h"
#include "util/bitscan.h"
+#include "util/u_atomic.h"
const GLubyte
@@ -331,10 +332,16 @@ _mesa_reference_vao_(struct gl_context *ctx,
/* Unreference the old array object */
struct gl_vertex_array_object *oldObj = *ptr;
- assert(oldObj->RefCount > 0);
- oldObj->RefCount--;
+ bool deleteFlag;
+ if (oldObj->SharedAndImmutable) {
+ deleteFlag = p_atomic_dec_zero(&oldObj->RefCount);
+ } else {
+ assert(oldObj->RefCount > 0);
+ oldObj->RefCount--;
+ deleteFlag = (oldObj->RefCount == 0);
+ }
- if (oldObj->RefCount == 0)
+ if (deleteFlag)
_mesa_delete_vao(ctx, oldObj);
*ptr = NULL;
@@ -343,9 +350,13 @@ _mesa_reference_vao_(struct gl_context *ctx,
if (vao) {
/* reference new array object */
- assert(vao->RefCount > 0);
+ if (vao->SharedAndImmutable) {
+ p_atomic_inc(&vao->RefCount);
+ } else {
+ assert(vao->RefCount > 0);
+ vao->RefCount++;
+ }
- vao->RefCount++;
*ptr = vao;
}
}
@@ -407,6 +418,7 @@ _mesa_initialize_vao(struct gl_context *ctx,
vao->Name = name;
vao->RefCount = 1;
+ vao->SharedAndImmutable = GL_FALSE;
/* Init the individual arrays */
for (i = 0; i < ARRAY_SIZE(vao->VertexAttrib); i++) {
@@ -452,6 +464,9 @@ _mesa_update_vao_derived_arrays(struct gl_context *ctx,
{
GLbitfield arrays = vao->NewArrays;
+ /* Make sure we do not run into problems with shared objects */
+ assert(!vao->SharedAndImmutable || vao->NewArrays == 0);
+
while (arrays) {
const int attrib = u_bit_scan(&arrays);
struct gl_vertex_array *array = &vao->_VertexArray[attrib];
@@ -465,6 +480,16 @@ _mesa_update_vao_derived_arrays(struct gl_context *ctx,
}
+void
+_mesa_set_vao_immutable(struct gl_context *ctx,
+struct gl_vertex_array_object *vao)
+{
+ _mesa_update_vao_derived_arrays(ctx, vao);
+ vao->NewArrays = 0;
+ vao->SharedAndImmutable = GL_TRUE;
+}
+
+
bool
_mesa_all_varyings_in_vbos(const struct gl_vertex_array_object *vao)
{
diff --git a/src/mesa/main/arrayobj.h b/src/mesa/main/arrayobj.h
index 5de74505bb..8da5c9ffe0 100644
--- a/src/mesa/main/arrayobj.h
+++ b/src/mesa/main/arrayobj.h
@@ -81,6 +81,15 @@ extern void
_mesa_update_vao_derived_arrays(struct gl_context *ctx,
struct gl_vertex_array_object *vao);
+
+/**
+ * Mark the vao as shared and immutable, do remaining updates.
+ */
+extern void
+_mesa_set_vao_immutable(struct gl_context *ctx,
+struct gl_vertex_array_object *vao);
+
+
/* Returns true if all varying arrays reside in vbos */
extern bool
_mesa_all_varyings_in_vbos(const struct gl_vertex_array_object *vao);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index b6fdb69283..93ad5a9057 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1607,6 +1607,13 @@ struct gl_vertex_array_object
*/
GLboolean EverBound;
+ /**
+* Marked to true if the object is shared between contexts and immutable.
+* Then reference counting is done using atomics and thread safe.
+* Is used for dlist VAOs.
+*/
+ GLboolean SharedAndImmutable;
+
/**
* Derived vertex attribute arrays
*
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/13] mesa: Add flush_vertices to _mesa_bind_vertex_buffer.
From: Mathias Fröhlich
We will need the flush_vertices argument later in this series.
Signed-off-by: Mathias Fröhlich
---
src/mesa/drivers/common/meta.c | 16 +---
src/mesa/main/bufferobj.c | 2 +-
src/mesa/main/varray.c | 15 ---
src/mesa/main/varray.h | 2 +-
4 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 3d9833dabb..830d82ad49 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -348,7 +348,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
GL_FALSE, GL_FALSE,
offsetof(struct vertex, x));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_GENERIC(0),
- *buf_obj, 0, sizeof(struct vertex));
+ *buf_obj, 0, sizeof(struct vertex), true);
_mesa_enable_vertex_array_attrib(ctx, array_obj,
VERT_ATTRIB_GENERIC(0), true);
if (texcoord_size > 0) {
@@ -357,7 +357,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
GL_FALSE, GL_FALSE, GL_FALSE,
offsetof(struct vertex, tex));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_GENERIC(1),
- *buf_obj, 0, sizeof(struct vertex));
+ *buf_obj, 0, sizeof(struct vertex), true);
_mesa_enable_vertex_array_attrib(ctx, array_obj,
VERT_ATTRIB_GENERIC(1), true);
}
@@ -367,7 +367,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
GL_FALSE, GL_FALSE,
offsetof(struct vertex, x));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_POS,
- *buf_obj, 0, sizeof(struct vertex));
+ *buf_obj, 0, sizeof(struct vertex), true);
_mesa_enable_vertex_array_attrib(ctx, array_obj,
VERT_ATTRIB_POS, true);
@@ -377,7 +377,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
GL_FALSE, GL_FALSE,
offsetof(struct vertex, tex));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_TEX(0),
- *buf_obj, 0, sizeof(struct vertex));
+ *buf_obj, 0, sizeof(struct vertex), true);
_mesa_enable_vertex_array_attrib(ctx, array_obj,
VERT_ATTRIB_TEX(0), true);
}
@@ -388,7 +388,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
GL_FALSE, GL_FALSE,
offsetof(struct vertex, r));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_COLOR0,
- *buf_obj, 0, sizeof(struct vertex));
+ *buf_obj, 0, sizeof(struct vertex), true);
_mesa_enable_vertex_array_attrib(ctx, array_obj,
VERT_ATTRIB_COLOR0, true);
}
@@ -3347,7 +3347,8 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x,
GLfloat y, GLfloat z,
GL_FALSE, GL_FALSE,
offsetof(struct vertex, x));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_POS,
- drawtex->buf_obj, 0, sizeof(struct vertex));
+ drawtex->buf_obj, 0,
+ sizeof(struct vertex), true);
_mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_POS, true);
@@ -3358,7 +3359,8 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x,
GLfloat y, GLfloat z,
GL_FALSE, GL_FALSE,
offsetof(struct vertex, st[i]));
_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_TEX(i),
- drawtex->buf_obj, 0, sizeof(struct vertex));
+ drawtex->buf_obj, 0,
+ sizeof(struct vertex), true);
_mesa_enable_vertex_array_attrib(ctx, array_obj,
VERT_ATTRIB_TEX(i), true);
}
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 67f9cd0a90..068c7dd434 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1167,7 +1167,7 @@ unbind(struct gl_context *ctx,
if (vao->BufferBinding[index].BufferObj == obj) {
_mesa_bind_vertex_buffer(ctx, vao, index, ctx->Shared->NullBufferObj,
[Mesa-dev] [PATCH 10/13] vbo: Implement tool functions for vbo specific VAO setup.
From: Mathias Fröhlich
Correct VBO_MATERIAL_SHIFT value.
The functions will be used next in this series.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_attrib.h | 4 ++--
src/mesa/vbo/vbo_private.h | 53 ++
2 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/src/mesa/vbo/vbo_attrib.h b/src/mesa/vbo/vbo_attrib.h
index fb178e17d6..0592d845ba 100644
--- a/src/mesa/vbo/vbo_attrib.h
+++ b/src/mesa/vbo/vbo_attrib.h
@@ -113,8 +113,8 @@ enum vbo_attrib {
VBO_ATTRIB_LAST_MATERIAL - VBO_ATTRIB_FIRST_MATERIAL + 1)
/** Shift to move legacy material attribs into generic slots */
-#define VBO_MATERIAL_SHIFT (VBO_ATTRIB_FIRST_MATERIAL - VBO_ATTRIB_GENERIC0)
-
+#define VBO_MATERIAL_SHIFT \
+ (VBO_ATTRIB_LAST_MATERIAL - VBO_ATTRIB_FIRST_MATERIAL + 1)
diff --git a/src/mesa/vbo/vbo_private.h b/src/mesa/vbo/vbo_private.h
index 545daa3b87..503a533244 100644
--- a/src/mesa/vbo/vbo_private.h
+++ b/src/mesa/vbo/vbo_private.h
@@ -36,6 +36,7 @@
#include "vbo/vbo_exec.h"
#include "vbo/vbo_save.h"
#include "main/mtypes.h"
+#include "main/varray.h"
struct _glapi_table;
@@ -172,4 +173,56 @@ void
vbo_merge_prims(struct _mesa_prim *p0, const struct _mesa_prim *p1);
+/**
+ * Get the filter mask for vbo draws depending on the vertex_processing_mode.
+ */
+static inline GLbitfield
+_vbo_get_vao_filter(gl_vertex_processing_mode vertex_processing_mode)
+{
+ if (vertex_processing_mode == VP_MODE_FF) {
+ /* The materials mapped into the generic arrays */
+ return VERT_BIT_FF_ALL | VERT_BIT_MAT_ALL;
+ } else {
+ return VERT_BIT_ALL;
+ }
+}
+
+
+/**
+ * Translate the bitmask of VBO_ATTRIB_BITs to VERT_ATTRIB_BITS.
+ * Note that position/generic0 attribute aliasing is done
+ * generically in the VAO.
+ */
+static inline GLbitfield
+_vbo_get_vao_enabled_from_vbo(gl_vertex_processing_mode vertex_processing_mode,
+ GLbitfield64 enabled)
+{
+ if (vertex_processing_mode == VP_MODE_FF) {
+ /* The materials mapped into the generic arrays */
+ return (((GLbitfield)enabled) & VERT_BIT_FF_ALL)
+ | (((GLbitfield)(enabled >> VBO_MATERIAL_SHIFT)) & VERT_BIT_MAT_ALL);
+ } else {
+ return ((GLbitfield)enabled) & VERT_BIT_ALL;
+ }
+}
+
+
+/**
+ * Set the vertex attrib for vbo draw use.
+ */
+static inline void
+_vbo_set_attrib_format(struct gl_context *ctx,
+ struct gl_vertex_array_object *vao,
+ gl_vert_attrib attr, GLintptr buffer_offset,
+ GLubyte size, GLenum16 type, GLuint offset)
+{
+ const GLboolean integer = vbo_attrtype_to_integer_flag(type);
+ const GLboolean doubles = vbo_attrtype_to_double_flag(type);
+ _mesa_update_array_format(ctx, vao, attr, size, type, GL_RGBA,
+ GL_FALSE, integer, doubles, offset);
+ /* Ptr for userspace arrays */
+ vao->VertexAttrib[attr].Ptr = ADD_POINTERS(buffer_offset, offset);
+}
+
+
#endif /* VBO_PRIVATE_H */
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/13] vbo: Use _VPMode instead of get_vp_mode().
From: Mathias Fröhlich
At those places where we used get_vp_mode() use
gl_vertex_program_state::_VPMode instead.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_exec.c | 4 ++--
src/mesa/vbo/vbo_exec_array.c | 11 ++-
src/mesa/vbo/vbo_exec_draw.c | 5 +++--
src/mesa/vbo/vbo_save_draw.c | 5 +++--
4 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c
index fc06979dcb..372d0237aa 100644
--- a/src/mesa/vbo/vbo_exec.c
+++ b/src/mesa/vbo/vbo_exec.c
@@ -34,7 +34,7 @@
const GLubyte
_vbo_attribute_alias_map[VP_MODE_MAX][VERT_ATTRIB_MAX] = {
- /* VP_FF: */
+ /* VP_MODE_FF: */
{
VBO_ATTRIB_POS, /* VERT_ATTRIB_POS */
VBO_ATTRIB_NORMAL, /* VERT_ATTRIB_NORMAL */
@@ -70,7 +70,7 @@ _vbo_attribute_alias_map[VP_MODE_MAX][VERT_ATTRIB_MAX] = {
VBO_ATTRIB_MAT_BACK_INDEXES /* VERT_ATTRIB_GENERIC15 */
},
- /* VP_SHADER: */
+ /* VP_MODE_SHADER: */
{
VBO_ATTRIB_POS, /* VERT_ATTRIB_POS */
VBO_ATTRIB_NORMAL, /* VERT_ATTRIB_NORMAL */
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 25abe09559..0c3c9017b1 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -338,10 +338,11 @@ recalculate_input_bindings(struct gl_context *ctx)
/* May shuffle the position and generic0 bits around */
GLbitfield vp_inputs = _mesa_get_vao_vp_inputs(vao);
- const enum vp_mode program_mode = get_vp_mode(ctx);
- const GLubyte *const map = _vbo_attribute_alias_map[program_mode];
- switch (program_mode) {
- case VP_FF:
+ const gl_vertex_processing_mode processing_mode
+ = ctx->VertexProgram._VPMode;
+ const GLubyte * const map = _vbo_attribute_alias_map[processing_mode];
+ switch (processing_mode) {
+ case VP_MODE_FF:
/* When no vertex program is active (or the vertex program is generated
* from fixed-function state). We put the material values into the
* generic slots. Since the vao has no material arrays, mute these
@@ -352,7 +353,7 @@ recalculate_input_bindings(struct gl_context *ctx)
break;
- case VP_SHADER:
+ case VP_MODE_SHADER:
/* There are no shaders in OpenGL ES 1.x, so this code path should be
* impossible to reach. The meta code is careful to not use shaders in
* ES1.
diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
index b0cc394642..4421496072 100644
--- a/src/mesa/vbo/vbo_exec_draw.c
+++ b/src/mesa/vbo/vbo_exec_draw.c
@@ -178,8 +178,9 @@ vbo_exec_bind_arrays(struct gl_context *ctx)
GLuint attr;
GLbitfield varying_inputs = 0x0;
- const enum vp_mode program_mode = get_vp_mode(exec->ctx);
- const GLubyte * const map = _vbo_attribute_alias_map[program_mode];
+ const gl_vertex_processing_mode processing_mode
+ = ctx->VertexProgram._VPMode;
+ const GLubyte * const map = _vbo_attribute_alias_map[processing_mode];
/* Grab VERT_ATTRIB_{POS,GENERIC0} from VBO_ATTRIB_POS */
const gl_attribute_map_mode mode = ATTRIBUTE_MAP_MODE_POSITION;
diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 96a9bab029..8c58fecf40 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -142,8 +142,9 @@ bind_vertex_list(struct gl_context *ctx,
GLuint attr;
GLbitfield varying_inputs = 0x0;
- const enum vp_mode program_mode = get_vp_mode(ctx);
- const GLubyte * const map = _vbo_attribute_alias_map[program_mode];
+ const gl_vertex_processing_mode processing_mode
+ = ctx->VertexProgram._VPMode;
+ const GLubyte * const map = _vbo_attribute_alias_map[processing_mode];
/* Grab VERT_ATTRIB_{POS,GENERIC0} from VBO_ATTRIB_POS */
const gl_attribute_map_mode mode = ATTRIBUTE_MAP_MODE_POSITION;
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/13] vbo: Make use of _DrawVAO from immediate mode draw
From: Mathias Fröhlich
Finally use an internal VAO to execute immediate
mode draws. Avoid duplicate state validation
for immediate mode draws. Remove client arrays
previously used exclusively for immediate
mode draws.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_context.c | 8 +++
src/mesa/vbo/vbo_exec.h | 8 ---
src/mesa/vbo/vbo_exec_api.c | 47 +
src/mesa/vbo/vbo_exec_draw.c | 117 ---
src/mesa/vbo/vbo_private.h | 2 +
5 files changed, 78 insertions(+), 104 deletions(-)
diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index 1a9935d5e8..bcd87b4c40 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -30,6 +30,8 @@
#include "math/m_eval.h"
#include "main/vtxfmt.h"
#include "main/api_arrayelt.h"
+#include "main/arrayobj.h"
+#include "main/varray.h"
#include "vbo.h"
#include "vbo_private.h"
@@ -252,6 +254,11 @@ _vbo_CreateContext(struct gl_context *ctx)
if (ctx->API == API_OPENGL_COMPAT)
vbo_save_init(ctx);
+ vbo->VAO = _mesa_new_vao(ctx, ~((GLuint)0));
+ /* The exec VAO assumes to have all arributes bound to binding 0 */
+ for (unsigned i = 0; i < VERT_ATTRIB_MAX; ++i)
+ _mesa_vertex_attrib_binding(ctx, vbo->VAO, i, 0, false);
+
_math_init_eval();
return GL_TRUE;
@@ -278,6 +285,7 @@ _vbo_DestroyContext(struct gl_context *ctx)
vbo_exec_destroy(ctx);
if (ctx->API == API_OPENGL_COMPAT)
vbo_save_destroy(ctx);
+ _mesa_reference_vao(ctx, &vbo->VAO, NULL);
free(vbo);
ctx->vbo_context = NULL;
}
diff --git a/src/mesa/vbo/vbo_exec.h b/src/mesa/vbo/vbo_exec.h
index b00045c7c8..07ab5cc837 100644
--- a/src/mesa/vbo/vbo_exec.h
+++ b/src/mesa/vbo/vbo_exec.h
@@ -101,14 +101,6 @@ struct vbo_exec_context
/** pointers into the current 'vertex' array, declared above */
fi_type *attrptr[VBO_ATTRIB_MAX];
-
- struct gl_vertex_array arrays[VERT_ATTRIB_MAX];
-
- /* According to program mode, the values above plus current
- * values are squashed down to the 32 attributes passed to the
- * vertex program below:
- */
- const struct gl_vertex_array *inputs[VERT_ATTRIB_MAX];
} vtx;
struct {
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index 64e792bfa2..317fc43d1c 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -758,7 +758,8 @@ static void GLAPIENTRY
vbo_exec_Begin(GLenum mode)
{
GET_CURRENT_CONTEXT(ctx);
- struct vbo_exec_context *exec = &vbo_context(ctx)->exec;
+ struct vbo_context *vbo = vbo_context(ctx);
+ struct vbo_exec_context *exec = &vbo->exec;
int i;
if (_mesa_inside_begin_end(ctx)) {
@@ -770,8 +771,6 @@ vbo_exec_Begin(GLenum mode)
return;
}
- _mesa_set_drawing_arrays(ctx, exec->vtx.inputs);
-
if (ctx->NewState) {
_mesa_update_state(ctx);
@@ -1162,7 +1161,6 @@ void
vbo_exec_vtx_init(struct vbo_exec_context *exec)
{
struct gl_context *ctx = exec->ctx;
- struct vbo_context *vbo = vbo_context(ctx);
GLuint i;
/* Allocate a buffer object. Will just reuse this object
@@ -1189,38 +1187,6 @@ vbo_exec_vtx_init(struct vbo_exec_context *exec)
assert(i < ARRAY_SIZE(exec->vtx.active_sz));
exec->vtx.active_sz[i] = 0;
}
- for (i = 0 ; i < VERT_ATTRIB_MAX; i++) {
- assert(i < ARRAY_SIZE(exec->vtx.inputs));
- assert(i < ARRAY_SIZE(exec->vtx.arrays));
- exec->vtx.inputs[i] = &exec->vtx.arrays[i];
- }
-
- {
- struct gl_vertex_array *arrays = exec->vtx.arrays;
- unsigned i;
-
- memcpy(arrays, &vbo->currval[VBO_ATTRIB_POS],
- VERT_ATTRIB_FF_MAX * sizeof(arrays[0]));
- for (i = 0; i < VERT_ATTRIB_FF_MAX; ++i) {
- struct gl_vertex_array *array;
- array = &arrays[VERT_ATTRIB_FF(i)];
- array->BufferObj = NULL;
- _mesa_reference_buffer_object(ctx, &array->BufferObj,
-
vbo->currval[VBO_ATTRIB_POS+i].BufferObj);
- }
-
- memcpy(arrays + VERT_ATTRIB_GENERIC(0),
- &vbo->currval[VBO_ATTRIB_GENERIC0],
- VERT_ATTRIB_GENERIC_MAX * sizeof(arrays[0]));
-
- for (i = 0; i < VERT_ATTRIB_GENERIC_MAX; ++i) {
- struct gl_vertex_array *array;
- array = &arrays[VERT_ATTRIB_GENERIC(i)];
- array->BufferObj = NULL;
- _mesa_reference_buffer_object(ctx, &array->BufferObj,
- vbo->currval[VBO_ATTRIB_GENERIC0+i].BufferObj);
- }
- }
exec->vtx.vertex_size = 0;
@@ -1233,7 +1199,6 @@ vbo_exec_vtx_destroy(struct vbo_exec_context *exec)
{
/* using a real VBO for vertex data */
struct gl_context *ctx = exec->ctx;
- unsigned i;
/* True VBOs should already be unmapped
*/
@@ -1247,14 +1212,6 @@ vbo_exec_vtx_destroy(struct vbo_exec_context *exec)
}
}
- /* Drop any outstanding reference to the vertex buffer
-
[Mesa-dev] [PATCH 03/13] vbo: Remove get_vp_mode() and enum vp_mode.
From: Mathias Fröhlich
Is now unused.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_private.h | 27 ---
1 file changed, 27 deletions(-)
diff --git a/src/mesa/vbo/vbo_private.h b/src/mesa/vbo/vbo_private.h
index e44a521b11..49922892e5 100644
--- a/src/mesa/vbo/vbo_private.h
+++ b/src/mesa/vbo/vbo_private.h
@@ -68,33 +68,6 @@ vbo_context(struct gl_context *ctx)
}
-/**
- * Current vertex processing mode: fixed function vs. shader.
- * In reality, fixed function is probably implemented by a shader but that's
- * not what we care about here.
- */
-enum vp_mode {
- VP_FF,/**< legacy / fixed function */
- VP_SHADER, /**< ARB vertex program or GLSL vertex shader */
- VP_MODE_MAX /**< for sizing arrays */
-};
-
-
-/**
- * Get current vertex processing mode (fixed function vs. shader).
- */
-static inline enum vp_mode
-get_vp_mode( struct gl_context *ctx )
-{
- if (!ctx->VertexProgram._Current)
- return VP_FF;
- else if (ctx->VertexProgram._Current == ctx->VertexProgram._TnlProgram)
- return VP_FF;
- else
- return VP_SHADER;
-}
-
-
/**
* Array to apply the fixed function material aliasing map to
* an attribute value used in vbo processing inputs to an attribute
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/13] mesa: Provide an alternative to get_vp_mode()
From: Mathias Fröhlich
To get equivalent information than get_vp_mode(), track the
vertex processing mode in a per context variable at
gl_vertex_program_state::_VPMode.
This aims to replace get_vp_mode() as seen in the vbo module.
But instead of the get_vp_mode() implementation which only
gives correct answers past calling _mesa_update_state() this
context variable is immediately tracked when the vertex
processing state is modified. The correctness of this value
is asserted on state validation.
With this in place we should be able to untangle the
dependency with varying_vp_inputs and state invalidation.
Signed-off-by: Mathias Fröhlich
---
src/mesa/drivers/common/meta.c | 2 ++
src/mesa/main/arbprogram.c | 5 +
src/mesa/main/context.c| 3 +++
src/mesa/main/enable.c | 2 ++
src/mesa/main/mtypes.h | 24
src/mesa/main/pipelineobj.c| 3 +++
src/mesa/main/shaderapi.c | 5 +
src/mesa/main/state.c | 23 +++
src/mesa/main/state.h | 7 +++
src/mesa/program/program.c | 1 +
10 files changed, 75 insertions(+)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index cd898e26f6..0cb2ef450e 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -1012,6 +1012,8 @@ _mesa_meta_end(struct gl_context *ctx)
_mesa_reference_pipeline_object(ctx, &save->Pipeline, NULL);
}
+
+ _mesa_update_vertex_processing_mode(ctx);
}
if (state & MESA_META_STENCIL_TEST) {
diff --git a/src/mesa/main/arbprogram.c b/src/mesa/main/arbprogram.c
index 625dc667f8..b169bce0c5 100644
--- a/src/mesa/main/arbprogram.c
+++ b/src/mesa/main/arbprogram.c
@@ -37,6 +37,7 @@
#include "main/mtypes.h"
#include "main/arbprogram.h"
#include "main/shaderapi.h"
+#include "main/state.h"
#include "program/arbprogparse.h"
#include "program/program.h"
#include "program/prog_print.h"
@@ -133,6 +134,8 @@ _mesa_BindProgramARB(GLenum target, GLuint id)
_mesa_reference_program(ctx, &ctx->FragmentProgram.Current, newProg);
}
+ _mesa_update_vertex_processing_mode(ctx);
+
/* Never null pointers */
assert(ctx->VertexProgram.Current);
assert(ctx->FragmentProgram.Current);
@@ -369,6 +372,8 @@ _mesa_ProgramStringARB(GLenum target, GLenum format,
GLsizei len,
}
}
+ _mesa_update_vertex_processing_mode(ctx);
+
if (ctx->_Shader->Flags & GLSL_DUMP) {
const char *shader_type =
target == GL_FRAGMENT_PROGRAM_ARB ? "fragment" : "vertex";
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 79d3e39e92..0aa2e3639f 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -123,6 +123,7 @@
#include "shared.h"
#include "shaderobj.h"
#include "shaderimage.h"
+#include "state.h"
#include "util/debug.h"
#include "util/disk_cache.h"
#include "util/strtod.h"
@@ -1579,6 +1580,8 @@ handle_first_current(struct gl_context *ctx)
check_context_limits(ctx);
+ _mesa_update_vertex_processing_mode(ctx);
+
/* According to GL_MESA_configless_context the default value of
* glDrawBuffers depends on the config of the first surface it is bound to.
* For GLES it is always GL_BACK which has a magic interpretation.
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index f23673a6cd..868b73ac68 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -39,6 +39,7 @@
#include "light.h"
#include "mtypes.h"
#include "enums.h"
+#include "state.h"
#include "texstate.h"
#include "varray.h"
@@ -919,6 +920,7 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap,
GLboolean state)
return;
FLUSH_VERTICES(ctx, _NEW_PROGRAM);
ctx->VertexProgram.Enabled = state;
+ _mesa_update_vertex_processing_mode(ctx);
break;
case GL_VERTEX_PROGRAM_POINT_SIZE_ARB:
/* This was added with ARB_vertex_program, but it is also used with
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 7da3240da7..41df04d38d 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2136,6 +2136,19 @@ typedef enum
} gl_register_file;
+/**
+ * Current vertex processing mode: fixed function vs. shader.
+ * In reality, fixed function is probably implemented by a shader but that's
+ * not what we care about here.
+ */
+typedef enum
+{
+ VP_MODE_FF, /**< legacy / fixed function */
+ VP_MODE_SHADER, /**< ARB vertex program or GLSL vertex shader */
+ VP_MODE_MAX /**< for sizing arrays */
+} gl_vertex_processing_mode;
+
+
/**
* Base class for any kind of program object
*/
@@ -2362,6 +2375,17 @@ struct gl_vertex_program_state
struct gl_program_cache *Cache;
GLboolean _Overriden;
+
+ /**
+* If we have a vertex program, a TNL program or no program at all.
+* Note that this value should be kept up to date all the time,
+* nevertheless its correctness is asserted in _mesa_upd
Re: [Mesa-dev] [PATCH 03/11] vulkan/wsi: Add modifiers support to wsi_create_native_image
On Thu, Feb 15, 2018 at 7:57 AM, Daniel Stone wrote:
> From: Jason Ekstrand
>
> This involves extending our fake extension a bit to allow for additional
> querying and passing of modifier information. The added bits are
> intended to look a lot like the draft of VK_EXT_image_drm_format_modifier.
> Once the extension gets finalized, we'll simply transition all of the
> structs used in wsi_common to the real extension structs.
>
> Reviewed-by: Daniel Stone
> Signed-off-by: Daniel Stone
> ---
> src/vulkan/wsi/wsi_common.c | 164 ++
> ++
> src/vulkan/wsi/wsi_common.h | 23 +
> src/vulkan/wsi/wsi_common_private.h | 3 +
> src/vulkan/wsi/wsi_common_wayland.c | 3 +-
> src/vulkan/wsi/wsi_common_x11.c | 3 +-
> 5 files changed, 177 insertions(+), 19 deletions(-)
>
> diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
> index c235128e562..edba13a13de 100644
> --- a/src/vulkan/wsi/wsi_common.c
> +++ b/src/vulkan/wsi/wsi_common.c
> @@ -26,6 +26,8 @@
> #include "util/macros.h"
> #include "vk_util.h"
>
> +#include
> +
> VkResult
> wsi_device_init(struct wsi_device *wsi,
> VkPhysicalDevice pdevice,
> @@ -36,6 +38,8 @@ wsi_device_init(struct wsi_device *wsi,
>
> memset(wsi, 0, sizeof(*wsi));
>
> + wsi->pdevice = pdevice;
> +
> #define WSI_GET_CB(func) \
> PFN_vk##func func = (PFN_vk##func)proc_addr(pdevice, "vk" #func)
> WSI_GET_CB(GetPhysicalDeviceMemoryProperties);
> @@ -69,6 +73,7 @@ wsi_device_init(struct wsi_device *wsi,
> WSI_GET_CB(GetImageSubresourceLayout);
> WSI_GET_CB(GetMemoryFdKHR);
> WSI_GET_CB(GetPhysicalDeviceFormatProperties);
> + WSI_GET_CB(GetPhysicalDeviceFormatProperties2KHR);
> WSI_GET_CB(ResetFences);
> WSI_GET_CB(QueueSubmit);
> WSI_GET_CB(WaitForFences);
> @@ -196,6 +201,9 @@ align_u32(uint32_t v, uint32_t a)
> VkResult
> wsi_create_native_image(const struct wsi_swapchain *chain,
> const VkSwapchainCreateInfoKHR *pCreateInfo,
> +uint32_t num_modifier_lists,
> +const uint32_t *num_modifiers,
> +const uint64_t *const *modifiers,
> struct wsi_image *image)
> {
> const struct wsi_device *wsi = chain->wsi;
> @@ -205,11 +213,91 @@ wsi_create_native_image(const struct wsi_swapchain
> *chain,
> for (int i = 0; i < ARRAY_SIZE(image->fds); i++)
>image->fds[i] = -1;
>
> - const struct wsi_image_create_info image_wsi_info = {
> + struct wsi_image_create_info image_wsi_info = {
>.sType = VK_STRUCTURE_TYPE_WSI_IMAGE_CREATE_INFO_MESA,
>.pNext = NULL,
> - .scanout = true,
> };
> +
> + uint32_t image_modifier_count = 0, modifier_prop_count = 0;
> + struct wsi_format_modifier_properties *modifier_props = NULL;
> + uint64_t *image_modifiers = NULL;
> + if (num_modifier_lists == 0) {
> + /* If we don't have modifiers, fall back to the legacy "scanout"
> flag */
> + image_wsi_info.scanout = true;
> + } else {
> + /* The winsys can't request modifiers if we don't support them. */
> + assert(wsi->supports_modifiers);
> + struct wsi_format_modifier_properties_list modifier_props_list = {
> + .sType = VK_STRUCTURE_TYPE_WSI_FORMAT_M
> ODIFIER_PROPERTIES_LIST_MESA,
> + .pNext = NULL,
> + };
> + VkFormatProperties2KHR format_props = {
> + .sType = VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_2_KHR,
> + .pNext = &modifier_props_list,
> + };
> + wsi->GetPhysicalDeviceFormatProperties2KHR(wsi->pdevice,
> + pCreateInfo->imageFormat,
> + &format_props);
> + assert(modifier_props_list.modifier_count > 0);
> + modifier_props = vk_alloc(&chain->alloc,
> +sizeof(*modifier_props) *
> +modifier_props_list.modifier_count,
> +8,
> +VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
> + if (!modifier_props) {
> + result = VK_ERROR_OUT_OF_HOST_MEMORY;
> + goto fail;
> + }
> +
> + modifier_props_list.modifier_properties = modifier_props;
> + wsi->GetPhysicalDeviceFormatProperties2KHR(wsi->pdevice,
> + pCreateInfo->imageFormat,
> + &format_props);
> + modifier_prop_count = modifier_props_list.modifier_count;
> +
> + uint32_t max_modifier_count = 0;
> + for (uint32_t l = 0; l < num_modifier_lists; l++)
> + max_modifier_count = MAX2(max_modifier_count, num_modifiers[l]);
> +
> + image_modifiers = vk_alloc(&chain->alloc,
> + sizeof(*image_modifiers) *
> + max_modifier_count,
> + 8,
>
Re: [Mesa-dev] [PATCH 06/11] meson: Move Wayland dmabuf to wayland-drm
Quoting Daniel Stone (2018-02-15 07:57:36) > As the comment notes: linux-dmabuf has nothing to do with wayland-drm, > but we need a single place to build these files we can use from both EGL > and Vulkan, which is guaranteed to be included before both EGL and > Vulkan WSI. > > Signed-off-by: Daniel Stone > Cc: Emil Velikov > --- > src/egl/meson.build | 14 -- > src/egl/wayland/wayland-drm/meson.build | 22 ++ > 2 files changed, 22 insertions(+), 14 deletions(-) > > diff --git a/src/egl/meson.build b/src/egl/meson.build > index 6cd04567b0d..cd51ad308f6 100644 > --- a/src/egl/meson.build > +++ b/src/egl/meson.build > @@ -58,20 +58,6 @@ files_egl = files( >'drivers/dri2/egl_dri2_fallbacks.h', > ) > > -linux_dmabuf_unstable_v1_protocol_c = custom_target( > - 'linux-dmabuf-unstable-v1-protocol.c', > - input : wayland_dmabuf_xml, > - output : 'linux-dmabuf-unstable-v1-protocol.c', > - command : [prog_wl_scanner, 'code', '@INPUT@', '@OUTPUT@'], > -) > - > -linux_dmabuf_unstable_v1_client_protocol_h = custom_target( > - 'linux-dmabuf-unstable-v1-client-protocol.h', > - input : wayland_dmabuf_xml, > - output : 'linux-dmabuf-unstable-v1-client-protocol.h', > - command : [prog_wl_scanner, 'client-header', '@INPUT@', '@OUTPUT@'], > -) > - > g_egldispatchstubs_c = custom_target( >'g_egldispatchstubs.c', >input : [ > diff --git a/src/egl/wayland/wayland-drm/meson.build > b/src/egl/wayland/wayland-drm/meson.build > index fa334880530..c627deaa1c3 100644 > --- a/src/egl/wayland/wayland-drm/meson.build > +++ b/src/egl/wayland/wayland-drm/meson.build > @@ -48,3 +48,25 @@ libwayland_drm = static_library( >dependencies : [dep_wayland_server], >build_by_default : false, > ) > + > +# linux-dmabuf isn't part of wayland-drm, but this happens to be the only > +# place which is a) guaranteed to be built when building either or both > +# of EGL and Vulkan WSI, and b) guaranteed to be included before both, > +# so the targets are actually defined by the time the files come to be > +# used. > +# > +# Moving these to a src/wsi/ was suggested but shot down, so put these > +# here for now as the maybe-least-bad solution. > +linux_dmabuf_unstable_v1_protocol_c = custom_target( > + 'linux-dmabuf-unstable-v1-protocol.c', > + input : wayland_dmabuf_xml, > + output : 'linux-dmabuf-unstable-v1-protocol.c', > + command : [prog_wl_scanner, 'code', '@INPUT@', '@OUTPUT@'], > +) > + > +linux_dmabuf_unstable_v1_client_protocol_h = custom_target( > + 'linux-dmabuf-unstable-v1-client-protocol.h', > + input : wayland_dmabuf_xml, > + output : 'linux-dmabuf-unstable-v1-client-protocol.h', > + command : [prog_wl_scanner, 'client-header', '@INPUT@', '@OUTPUT@'], > +) > -- > 2.14.3 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev Reviewed-by: Dylan Baker 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 07/11] vulkan/wsi/wayland: Add support for zwp_dmabuf
On Thu, Feb 15, 2018 at 7:57 AM, Daniel Stone wrote:
> zwp_linux_dmabuf_v1 lets us use multi-planar images and buffer
> modifiers.
>
> Signed-off-by: Daniel Stone
> ---
> src/vulkan/Makefile.am | 10 +++
> src/vulkan/Makefile.sources | 4 +-
> src/vulkan/wsi/meson.build | 2 +
> src/vulkan/wsi/wsi_common_wayland.c | 138 ++
> ++
> 4 files changed, 139 insertions(+), 15 deletions(-)
>
> diff --git a/src/vulkan/Makefile.am b/src/vulkan/Makefile.am
> index 4fdaedf38c1..c7813ce05e3 100644
> --- a/src/vulkan/Makefile.am
> +++ b/src/vulkan/Makefile.am
> @@ -71,6 +71,16 @@ wsi/wayland-drm-client-protocol.h : $(WL_DRM_XML)
> $(MKDIR_GEN)
> $(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
>
> +WL_DMABUF_XML = $(WAYLAND_PROTOCOLS_DATADIR)/unstable/linux-dmabuf/linux-
> dmabuf-unstable-v1.xml
> +
> +wsi/linux-dmabuf-unstable-v1-protocol.c : $(WL_DMABUF_XML)
> + $(MKDIR_GEN)
> + $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
> +
> +wsi/linux-dmabuf-unstable-v1-client-protocol.h : $(WL_DMABUF_XML)
> + $(MKDIR_GEN)
> + $(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
> +
> if HAVE_PLATFORM_WAYLAND
> AM_CPPFLAGS += \
> -I$(top_builddir)/src/vulkan/wsi \
> diff --git a/src/vulkan/Makefile.sources b/src/vulkan/Makefile.sources
> index a0a24ce7de8..101a94349c6 100644
> --- a/src/vulkan/Makefile.sources
> +++ b/src/vulkan/Makefile.sources
> @@ -11,7 +11,9 @@ VULKAN_WSI_WAYLAND_FILES := \
>
> VULKAN_WSI_WAYLAND_GENERATED_FILES := \
> wsi/wayland-drm-protocol.c \
> - wsi/wayland-drm-client-protocol.h
> + wsi/wayland-drm-client-protocol.h \
> + wsi/linux-dmabuf-unstable-v1-protocol.c \
> + wsi/linux-dmabuf-unstable-v1-client-protocol.h
>
> VULKAN_WSI_X11_FILES := \
> wsi/wsi_common_x11.c \
> diff --git a/src/vulkan/wsi/meson.build b/src/vulkan/wsi/meson.build
> index 66ccc8316ec..223c8ca357e 100644
> --- a/src/vulkan/wsi/meson.build
> +++ b/src/vulkan/wsi/meson.build
> @@ -54,6 +54,8 @@ if with_platform_wayland
>files_vulkan_wsi += [
> wayland_drm_client_protocol_h,
> wayland_drm_protocol_c,
> +linux_dmabuf_unstable_v1_client_protocol_h,
> +linux_dmabuf_unstable_v1_protocol_c,
>]
> endif
>
> diff --git a/src/vulkan/wsi/wsi_common_wayland.c
> b/src/vulkan/wsi/wsi_common_wayland.c
> index 1162b92c35f..26acde194d6 100644
> --- a/src/vulkan/wsi/wsi_common_wayland.c
> +++ b/src/vulkan/wsi/wsi_common_wayland.c
> @@ -31,10 +31,13 @@
> #include
> #include
>
> +#include
> +
> #include "vk_util.h"
> #include "wsi_common_private.h"
> #include "wsi_common_wayland.h"
> #include "wayland-drm-client-protocol.h"
> +#include "linux-dmabuf-unstable-v1-client-protocol.h"
>
> #include
> #include
> @@ -53,11 +56,17 @@ struct wsi_wl_display {
> struct wl_display * wl_display_wrapper;
> struct wl_event_queue * queue;
> struct wl_drm * drm;
> + struct zwp_linux_dmabuf_v1 * dmabuf;
>
> struct wsi_wayland *wsi_wl;
> /* Vector of VkFormats supported */
> struct u_vectorformats;
>
> + struct {
> + struct u_vector argb;
> + struct u_vector xrgb;
> + } modifiers;
> +
> uint32_t capabilities;
>
> /* Only used for displays created by wsi_wl_display_create */
> @@ -223,6 +232,53 @@ static const struct wl_drm_listener drm_listener = {
> drm_handle_capabilities,
> };
>
> +static void
> +dmabuf_handle_format(void *data, struct zwp_linux_dmabuf_v1 *dmabuf,
> + uint32_t format)
> +{
> + /* Formats are implicitly advertised by the modifier event, so we
> ignore
> +* them here. */
> +}
> +
> +static void
> +dmabuf_handle_modifier(void *data, struct zwp_linux_dmabuf_v1 *dmabuf,
> + uint32_t format, uint32_t modifier_hi,
> + uint32_t modifier_lo)
> +{
> + struct wsi_wl_display *display = data;
> + uint64_t *mod = NULL;
> +
> + /* If we're not fetching formats, don't fetch modifiers either. */
> + if (display->formats.element_size == 0)
> + return;
> +
> + if (modifier_hi == (DRM_FORMAT_MOD_INVALID >> 32) &&
> + modifier_lo == (DRM_FORMAT_MOD_INVALID & 0x))
> + return;
> +
> + switch (format) {
> + case WL_DRM_FORMAT_ARGB:
> + mod = u_vector_add(&display->modifiers.argb);
> + break;
> + case WL_DRM_FORMAT_XRGB:
> + mod = u_vector_add(&display->modifiers.xrgb);
> + break;
> + default:
> + break;
> + }
> +
> + if (!mod)
> + return;
> +
> + *mod = (uint64_t) modifier_hi << 32;
> + *mod |= (uint64_t) (modifier_lo & 0x);
> +}
> +
> +static const struct zwp_linux_dmabuf_v1_listener dmabuf_listener = {
> + dmabuf_handle_format,
> +
[Mesa-dev] [PATCH V2 16/16] i965/icl: Add render target flush after uploading binding table
From PIPE_CONTROL command description in gfxspecs:
"Whenever a Binding Table Index (BTI) used by a Render Taget Message
points to a different RENDER_SURFACE_STATE, SW must issue a Render
Target Cache Flush by enabling this bit. When render target flush
is set due to new association of BTI, PS Scoreboard Stall bit must
be set in this packet."
V2: Move the PIPE_CONTROL to update_renderbuffer_surfaces() in
brw_wm_surface_state.c (Ken).
Fixes a fulsim error and a GPU hang described in below JIRA.
JIRA: MD5-322
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 14 ++
1 file changed, 14 insertions(+)
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 44c87df17d..84c5a81227 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -971,6 +971,20 @@ update_renderbuffer_surfaces(struct brw_context *brw)
emit_null_surface_state(brw, fb, &surf_offsets[rt_start]);
}
+ /* From PIPE_CONTROL command description in gfxspecs:
+
+ "Whenever a Binding Table Index (BTI) used by a Render Taget Message
+ points to a different RENDER_SURFACE_STATE, SW must issue a Render
+ Target Cache Flush by enabling this bit. When render target flush
+ is set due to new association of BTI, PS Scoreboard Stall bit must
+ be set in this packet."
+ */
+ if (devinfo->gen >= 11) {
+ brw_emit_pipe_control_flush(brw,
+ PIPE_CONTROL_RENDER_TARGET_FLUSH |
+ PIPE_CONTROL_STALL_AT_SCOREBOARD);
+ }
+
brw->ctx.NewDriverState |= BRW_NEW_SURFACES;
}
--
2.13.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/16] intel/common/icl: Add has_sample_with_hiz flag in gen_device_info
Sampling from hiz is enabled in i965 for GEN9+ but this feature has
been removed from gen11. So, this new flag will be useful to turn
the feature on/off for different gen h/w. It will be used later
in a patch adding device info for gen11.
Suggested-by: Kenneth Graunke
Signed-off-by: Anuj Phogat
Cc: Kenneth Graunke
---
src/intel/common/gen_device_info.c| 7 +++
src/intel/common/gen_device_info.h| 2 +-
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 +
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/intel/common/gen_device_info.c
b/src/intel/common/gen_device_info.c
index c0eb7c3c35..a08a13a32a 100644
--- a/src/intel/common/gen_device_info.c
+++ b/src/intel/common/gen_device_info.c
@@ -311,12 +311,16 @@ static const struct gen_device_info
gen_device_info_hsw_gt3 = {
},
};
+/* It's unclear how well supported sampling from the hiz buffer is on GEN8,
+ * so keep things conservative for now and set has_sample_with_hiz = false.
+ */
#define GEN8_FEATURES \
.gen = 8,\
.has_hiz_and_separate_stencil = true,\
.has_resource_streamer = true, \
.must_use_separate_stencil = true, \
.has_llc = true, \
+ .has_sample_with_hiz = false,\
.has_pln = true, \
.supports_simd16_3src = true,\
.has_surface_tile_offset = true, \
@@ -451,6 +455,7 @@ static const struct gen_device_info gen_device_info_chv = {
GEN9_HW_INFO, \
.gt = 1,\
.has_llc = false, \
+ .has_sample_with_hiz = true,\
.num_slices = 1,\
.num_thread_per_eu = 6, \
.max_vs_threads = 112, \
@@ -502,6 +507,7 @@ static const struct gen_device_info gen_device_info_chv = {
#define GEN9_FEATURES \
GEN8_FEATURES, \
GEN9_HW_INFO,\
+ .has_sample_with_hiz = true, \
.num_thread_per_eu = 7
static const struct gen_device_info gen_device_info_skl_gt1 = {
@@ -695,6 +701,7 @@ static const struct gen_device_info gen_device_info_cfl_gt3
= {
#define GEN10_FEATURES(_gt, _slices, _subslices, _l3) \
GEN8_FEATURES, \
GEN10_HW_INFO, \
+ .has_sample_with_hiz = true, \
.gt = _gt, \
.num_slices = _slices, \
.num_subslices = _subslices, \
diff --git a/src/intel/common/gen_device_info.h
b/src/intel/common/gen_device_info.h
index 30ddd905be..fd9c17531d 100644
--- a/src/intel/common/gen_device_info.h
+++ b/src/intel/common/gen_device_info.h
@@ -55,7 +55,7 @@ struct gen_device_info
bool has_hiz_and_separate_stencil;
bool must_use_separate_stencil;
-
+ bool has_sample_with_hiz;
bool has_llc;
bool has_pln;
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index da5e3b0989..6d35c9d392 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1911,10 +1911,7 @@ intel_miptree_sample_with_hiz(struct brw_context *brw,
{
const struct gen_device_info *devinfo = &brw->screen->devinfo;
- /* It's unclear how well supported sampling from the hiz buffer is on GEN8,
-* so keep things conservative for now and never enable it unless we're
SKL+.
-*/
- if (devinfo->gen < 9) {
+ if (!devinfo->has_sample_with_hiz) {
return false;
}
--
2.13.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/16] intel/genxml/icl: Generate packing headers
On Thu, Feb 15, 2018 at 9:49 AM, Emil Velikov wrote: > On 13 February 2018 at 19:15, Anuj Phogat wrote: >> Signed-off-by: Anuj Phogat >> --- >> src/intel/Android.genxml.mk | 5 + >> src/intel/Makefile.sources| 3 ++- >> src/intel/genxml/genX_pack.h | 2 ++ >> src/intel/genxml/gen_macros.h | 3 +++ >> 4 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/src/intel/Android.genxml.mk b/src/intel/Android.genxml.mk >> index e4d8dd8b94..8b867920c3 100644 >> --- a/src/intel/Android.genxml.mk >> +++ b/src/intel/Android.genxml.mk >> @@ -101,6 +101,11 @@ $(intermediates)/genxml/gen10_pack.h: PRIVATE_XML := >> $(LOCAL_PATH)/genxml/gen10. >> $(intermediates)/genxml/gen10_pack.h: $(LOCAL_PATH)/genxml/gen10.xml >> $(LOCAL_PATH)/genxml/gen_pack_header.py >> $(call header-gen) >> >> +$(intermediates)/genxml/gen11_pack.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) >> $(LOCAL_PATH)/genxml/gen_pack_header.py >> +$(intermediates)/genxml/gen11_pack.h: PRIVATE_XML := >> $(LOCAL_PATH)/genxml/gen11.xml >> +$(intermediates)/genxml/gen11_pack.h: $(LOCAL_PATH)/genxml/gen11.xml >> $(LOCAL_PATH)/genxml/gen_pack_header.py >> + $(call header-gen) >> + > ... and here it is. > > I second Kenneth - please keep the build bits in one patch. > Be that squashing 1+2 or keeping git add gen10.xml in patch 01 and the > build in 02. > > Thanks > Emil I'll move the build changes in patch 2. Thanks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 02/12] meson: add libswdri and libswkmsdri to link_with unconditionally
Quoting Emil Velikov (2018-02-15 09:37:01)
> On 12 February 2018 at 19:27, Dylan Baker wrote:
> > Fixes: 6b4c7047d571 ("meson: build gallium nine state_tracker")
> > Signed-off-by: Dylan Baker
> > ---
> > src/gallium/targets/d3dadapter9/meson.build | 13 +++--
> > 1 file changed, 3 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/gallium/targets/d3dadapter9/meson.build
> > b/src/gallium/targets/d3dadapter9/meson.build
> > index 5476e80..f1b68fd 100644
> > --- a/src/gallium/targets/d3dadapter9/meson.build
> > +++ b/src/gallium/targets/d3dadapter9/meson.build
> > @@ -1,4 +1,5 @@
> > # Copyright © 2017 Dylan Baker
> > +# 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
> > @@ -31,20 +32,12 @@ gallium_nine_c_args = [
> > ]
> > gallium_nine_ld_args = []
> > gallium_nine_link_depends = []
> > -gallium_nine_link_with = []
> >
> > if with_ld_version_script
> >gallium_nine_ld_args += ['-Wl,--version-script',
> > join_paths(meson.current_source_dir(), 'd3dadapter9.sym')]
> >gallium_nine_link_depends += files('d3dadapter9.sym')
> > endif
> >
> > -if with_dri
> > - gallium_nine_link_with += libswdri
> > -endif
> > -if with_gallium_drisw_kms
> > - gallium_nine_link_with += libswkmsdri
> > -endif
> > -
> > libgallium_nine = shared_library(
> >'d3dadapter9',
> >[files('description.c', 'getproc.c', 'drm.c'), xmlpool_options_h],
> > @@ -60,8 +53,8 @@ libgallium_nine = shared_library(
> >link_depends : gallium_nine_link_depends,
> >link_with : [
> > libgalliumvl_stub, libgallium, libnine_st, libmesa_util, libddebug,
> > -librbug, libtrace, libpipe_loader_static, libws_null, libwsw,
> > -gallium_nine_link_with,
> > +librbug, libtrace, libpipe_loader_static, libws_null, libwsw, libswdi,
> > +libswkmsdri,
> I hope you build tested the series with and w/o gallium swrast - that
> should cover most of the cases.
>
> With the s/swdi/swdri/ typo fixed the series is
> Reviewed-by: Emil Velikov
>
> For the future - one could even fold the link_with libraries into a
> list and reuse across targets.
> There's two instances vl stubbed and full blown ones.
>
> -Emil
Thanks!
I did test this (before pushing) with
-Dgallium-drivers=swrast -Ddri-drivers= -Dvulkan-drivers= -Dglx=gallium-xlib
and an error in the real swdri case.
I looked into putting the libs into lists of some kind, I still think that would
be worth looking into.
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 07/15] util/bitset: Add C++ wrapper for static-size bitsets.
Eric Engestrom writes:
> On Wednesday, 2018-02-14 13:18:29 -0800, Francisco Jerez wrote:
>> ---
>> src/util/bitset.h | 114
>> ++
>> 1 file changed, 114 insertions(+)
>>
>> diff --git a/src/util/bitset.h b/src/util/bitset.h
>> index 2404ce7f630..7bb5f3c83cf 100644
>> --- a/src/util/bitset.h
>> +++ b/src/util/bitset.h
>> @@ -132,4 +132,118 @@ __bitset_next_set(unsigned i, BITSET_WORD *tmp,
>> for (__tmp = *(__set), __i = 0; \
>> (__i = __bitset_next_set(__i, &__tmp, __set, __size)) < __size;)
>>
>> +#ifdef __cplusplus
>> +
>> +/**
>> + * Simple C++ wrapper of a bitset type of static size, with value semantics
>> + * and basic bitwise arithmetic operators. The operators defined below are
>> + * expected to have the same semantics as the same operator applied to other
>> + * fundamental integer types. T is the name of the struct to instantiate
>> + * it as, and N is the number of bits in the bitset.
>> + */
>
> Any reason not to use std::bitset for this?
> http://en.cppreference.com/w/cpp/utility/bitset
>
It would be nice, but I don't think std::bitset is guaranteed to be a
standard layout type which the next patch relies on.
>> +#define DECLARE_BITSET_T(T, N) struct T { \
>> + /* XXX - Replace this with an implicitly-defined \
>> + * constructor when support for C++11 defaulted \
>> + * constructors can be assumed (available on GCC 4.4 and \
>> + * later) in order to make the object trivially \
>> + * constructible like a fundamental integer type for \
>> + * convenience. \
>> + */ \
>> + T() \
>> + { \
>> + } \
>> +\
>> + T(BITSET_WORD x) \
>> + { \
>> + for (unsigned i = 0; i < BITSET_WORDS(N); i++, x = 0) \
>> +words[i] = x; \
>> + } \
>> +\
>> + EXPLICIT_CONVERSION \
>> + operator bool() const \
>> + { \
>> + for (unsigned i = 0; i < BITSET_WORDS(N); i++) \
>> +if (words[i]) \
>> + return true; \
>> + return false; \
>> + } \
>> +\
>> + friend bool \
>> + operator==(const T &b, const T &c)\
>> + { \
>> + return BITSET_EQUAL(b.words, c.words); \
>> + } \
>> +\
>> + friend bool \
>> + operator!=(const T &b, const T &c)\
>> + { \
>> + return !(b == c); \
>> + } \
>> +\
>> + friend T \
>> + operator~(const T &b) \
>> + { \
>> + T c; \
>> + for (unsigned i = 0; i < BITSET_WORDS(N); i++) \
>> +c.words[i] = ~b.words[i]; \
>> + return c; \
>> + } \
>> +\
>> + T & \
>> + operator|=(const T &b)\
>> + { \
>> + for (unsigned i = 0; i < BITSET_WORDS(N); i++) \
>> +words[i] |= b.words[i]; \
>> + return *this; \
>>
Re: [Mesa-dev] [PATCH 0/6] OpenGL 3.1 + ARB_compatibility and related stuff (v2)
FYI, these GLSL 1.40 tests pass: https://cgit.freedesktop.org/~mareko/piglit/commit/?h=deqp&id=eeccd7b98e74e7dfefd02611563b0edbf2358327 glslparsertest dependency: https://cgit.freedesktop.org/~mareko/piglit/commit/?h=deqp&id=e3f6d5fc68b61c23c7327083bed6c90333119d75 I plan to send out those piglit patches after I know that the GLSL 1.50 tests are also correct. Marek On Thu, Feb 15, 2018 at 1:11 AM, Marek Olšák wrote: > Hi, > > This is the second version of GL 3.1 compatibility support patches. > There is also ARB_enhanced_layouts for the compatibility context and > other related changes. > > Please review. > > Thanks, > Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/29] blorp: Handle the RGB workaround more like other workarounds
On Fri, Jan 26, 2018 at 05:59:30PM -0800, Jason Ekstrand wrote:
> The previous version was sort-of strapped on in that it just adjusted
> the blit rectangle and trusted in the fact that we would use texelFetch
> and round to the nearest integer to ensure that the component positions
> matched. This new version, while slightly more complicated, is more
> accurate because all three components end up with exactly the same
> dst_pos and so they will get interpolated and sampled at the same
> texture coordinate. This makes the workaround suitable for using with
> scaled blits.
This can be also seen as being more simple. It is (as you said yourself) now
like the other workarounds.
Reviewed-by: Topi Pohjolainen
> ---
> src/intel/blorp/blorp_blit.c | 60
> ++--
> 1 file changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> index 0757db0..7d717da 100644
> --- a/src/intel/blorp/blorp_blit.c
> +++ b/src/intel/blorp/blorp_blit.c
> @@ -1155,6 +1155,20 @@ brw_blorp_build_nir_shader(struct blorp_context
> *blorp, void *mem_ctx,
>key->dst_layout);
> }
>
> + nir_ssa_def *comp = NULL;
> + if (key->dst_rgb) {
> + /* The destination image is bound as a red texture three times as wide
> + * as the actual image. Our shader is effectively running one color
> + * component at a time. We need to save off the component and adjust
> + * the destination position.
> + */
> + assert(dst_pos->num_components == 2);
> + nir_ssa_def *dst_x = nir_channel(&b, dst_pos, 0);
> + comp = nir_umod(&b, dst_x, nir_imm_int(&b, 3));
> + dst_pos = nir_vec2(&b, nir_idiv(&b, dst_x, nir_imm_int(&b, 3)),
> + nir_channel(&b, dst_pos, 1));
> + }
> +
> /* Now (X, Y, S) = decode_msaa(dst_samples, detile(dst_tiling, offset)).
> *
> * That is: X, Y and S now contain the true coordinates and sample index
> of
> @@ -1285,8 +1299,6 @@ brw_blorp_build_nir_shader(struct blorp_context *blorp,
> void *mem_ctx,
> * from the source color and write that to destination red.
> */
>assert(dst_pos->num_components == 2);
> - nir_ssa_def *comp =
> - nir_umod(&b, nir_channel(&b, dst_pos, 0), nir_imm_int(&b, 3));
>
>nir_ssa_def *color_component =
> nir_bcsel(&b, nir_ieq(&b, comp, nir_imm_int(&b, 0)),
> @@ -1549,16 +1561,13 @@ struct blt_coords {
>
> static void
> surf_fake_rgb_with_red(const struct isl_device *isl_dev,
> - struct brw_blorp_surface_info *info,
> - uint32_t *x, uint32_t *width)
> + struct brw_blorp_surface_info *info)
> {
> blorp_surf_convert_to_single_slice(isl_dev, info);
>
> info->surf.logical_level0_px.width *= 3;
> info->surf.phys_level0_sa.width *= 3;
> info->tile_x_sa *= 3;
> - *x *= 3;
> - *width *= 3;
>
> enum isl_format red_format;
> switch (info->view.format) {
> @@ -1588,28 +1597,6 @@ surf_fake_rgb_with_red(const struct isl_device
> *isl_dev,
> info->surf.format = info->view.format = red_format;
> }
>
> -static void
> -fake_dest_rgb_with_red(const struct isl_device *dev,
> - struct blorp_params *params,
> - struct brw_blorp_blit_prog_key *wm_prog_key,
> - struct blt_coords *coords)
> -{
> - /* Handle RGB destinations for blorp_copy */
> - const struct isl_format_layout *dst_fmtl =
> - isl_format_get_layout(params->dst.surf.format);
> -
> - if (dst_fmtl->bpb % 3 == 0) {
> - uint32_t dst_x = coords->x.dst0;
> - uint32_t dst_width = coords->x.dst1 - dst_x;
> - surf_fake_rgb_with_red(dev, ¶ms->dst,
> - &dst_x, &dst_width);
> - coords->x.dst0 = dst_x;
> - coords->x.dst1 = dst_x + dst_width;
> - wm_prog_key->dst_rgb = true;
> - wm_prog_key->need_dst_offset = true;
> - }
> -}
> -
> enum blit_shrink_status {
> BLIT_NO_SHRINK = 0,
> BLIT_WIDTH_SHRINK = 1,
> @@ -1628,8 +1615,6 @@ try_blorp_blit(struct blorp_batch *batch,
> {
> const struct gen_device_info *devinfo = batch->blorp->isl_dev->info;
>
> - fake_dest_rgb_with_red(batch->blorp->isl_dev, params, wm_prog_key,
> coords);
> -
> if (isl_format_has_sint_channel(params->src.view.format)) {
>wm_prog_key->texture_data_type = nir_type_int;
> } else if (isl_format_has_uint_channel(params->src.view.format)) {
> @@ -1835,6 +1820,21 @@ try_blorp_blit(struct blorp_batch *batch,
> params->src.view.base_level);
> }
>
> + if (isl_format_get_layout(params->dst.view.format)->bpb % 3 == 0) {
> + /* We can't render to RGB formats natively because they aren't a
> + * power-of-two size. Instead, we fake them by using a red format
> + * with the same channel type and size and emit
Re: [Mesa-dev] [PATCH 06/11] meson: Move Wayland dmabuf to wayland-drm
On 15 February 2018 at 15:57, Daniel Stone wrote: > As the comment notes: linux-dmabuf has nothing to do with wayland-drm, > but we need a single place to build these files we can use from both EGL > and Vulkan, which is guaranteed to be included before both EGL and > Vulkan WSI. > > Signed-off-by: Daniel Stone > Cc: Emil Velikov Thanks Dan, Reviewed-by: Emil Velikov -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/16] intel/isl/icl: Build and use gen11 surface state emit functions
On 13 February 2018 at 19:15, Anuj Phogat wrote: > Signed-off-by: Anuj Phogat > --- > src/intel/Android.isl.mk | 20 > src/intel/Makefile.isl.am | 4 > src/intel/Makefile.sources | 4 > src/intel/isl/isl.c| 3 +++ > src/intel/isl/isl_priv.h | 3 +++ > src/intel/isl/meson.build | 2 +- > 6 files changed, 35 insertions(+), 1 deletion(-) > Patch looks spot on. Patches 01, 02 and 05 are Reviewed-by: Emil Velikov -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/16] intel/genxml/icl: Generate packing headers
On 13 February 2018 at 19:15, Anuj Phogat wrote: > Signed-off-by: Anuj Phogat > --- > src/intel/Android.genxml.mk | 5 + > src/intel/Makefile.sources| 3 ++- > src/intel/genxml/genX_pack.h | 2 ++ > src/intel/genxml/gen_macros.h | 3 +++ > 4 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/src/intel/Android.genxml.mk b/src/intel/Android.genxml.mk > index e4d8dd8b94..8b867920c3 100644 > --- a/src/intel/Android.genxml.mk > +++ b/src/intel/Android.genxml.mk > @@ -101,6 +101,11 @@ $(intermediates)/genxml/gen10_pack.h: PRIVATE_XML := > $(LOCAL_PATH)/genxml/gen10. > $(intermediates)/genxml/gen10_pack.h: $(LOCAL_PATH)/genxml/gen10.xml > $(LOCAL_PATH)/genxml/gen_pack_header.py > $(call header-gen) > > +$(intermediates)/genxml/gen11_pack.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) > $(LOCAL_PATH)/genxml/gen_pack_header.py > +$(intermediates)/genxml/gen11_pack.h: PRIVATE_XML := > $(LOCAL_PATH)/genxml/gen11.xml > +$(intermediates)/genxml/gen11_pack.h: $(LOCAL_PATH)/genxml/gen11.xml > $(LOCAL_PATH)/genxml/gen_pack_header.py > + $(call header-gen) > + ... and here it is. I second Kenneth - please keep the build bits in one patch. Be that squashing 1+2 or keeping git add gen10.xml in patch 01 and the build in 02. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM
Jason Ekstrand writes: > It seems a little odd to me to default to opening the master node and then > fall back to the render node if it doesn't work. I suppose that's probably > ok so long as we ensure that vkGetPhysicalDeviceDisplayPropertiesKHR > returns no displays if we're on the render node. > > We could always go back to the DRM fd extension idea but I'm not coming up > with something nice and clean in the 60 seconds I've thought about it. As I said in the last comments about this section, Dave Airlie and I added this code only recently so that we could test this extension without also needing the kernel and X leasing changes. I think we should decide how to enable this functionality "for real", and I have two easy options: 1) Use my KEITHP_kms_display extension (presumably renamed MESA), which exposes a way to pass the DRM fd from the application into the driver. This makes it possible for the application to get the FD through any mechanism at all (including RandR or the new Wayland extension) and leave that out of the Vulkan code entirely. 2) Add a new extension which passes a new data structure that directs the driver to open either the Render or Primary nodes. When this is done, we can switch from the current code which tries to open the Primary node whenever the KHR_display extension is requested. > Would it make anything easier if we just storred the DRM struct here? "No" > is a perfectly valid answer. Nope -- once we add the acquire_xlib extension, we get modes through either X or DRM, depending on whether we're pre-lease or post-lease. > Any particular reason why the list of modes is global and not in the > connector? It seems like it would be a tiny bit more efficient and > convenient to put the list in the connector. I think you're right. I have some vague memory of a lifetime issue with connectors, but can't think of what it might be, even after reviewing the relevant parts of the Vulkan spec. I've gone ahead and changed it; seems to work fine. >> + LIST_FOR_EACH_ENTRY(display_mode, &wsi->display_modes, list) >> + if (display_mode->connector == connector) >> + display_mode->valid = false; >> > > Please use braces for loops containing more than one line. Well, that was easy to fix -- the condition is now gone :-) > Since we're allocating these in a physical device query, we need to use the > INSTANCE scope. the OBJECT scope is intended for vkCreate functions to > allocated data that will live no longer than the associated vkDestroy > function. Thanks! The whole Vulkan memory model remains a mystery to me. I've changed allocation of wsi_display_mode and wsi_display_connector to use SCOPE_INSTANCE. VkIceSurfaceDisplay, wsi_display_fence and wsi_display_swapchain remain using SCOPE_OBJECT. I've also changed *all* instances of vk_alloc to use vk_zalloc. These are all small data structures allocated only during application startup, so I think the benefit of known memory contents is worth the cost of memset. > Hooray for obviously false fixed constants! > > I know the answer to this will be "EDIDs lie, never trust them!" but can we > get the real value somehow? As someone who has a 13" laptop with a > 3200x1800 display, I know that number isn't always right. :-) Yes, we could dig the real value out of the EDID, but we'd have to parse the entire EDID to manage that. I don't want to stick an EDID parser directly in Mesa, so I'm kinda waiting for someone to create a separate EDID parsing library that the X server, Mesa and others can share. Until then, I'd prefer to just lie here. > double-;; Thx. I remember seeing this while reviewing patches and forgot all about it... > From the Vulkan spec: > > Note: > For devices which have no natural value to return here, implementations > *should* return the maximum resolution supported. > > We should walk the list and pick the biggest one. I did this intentionally -- most monitors have a preferred resolution, which is their native pixel size. And, we want to tell applications to use that size, even if the monitor offers a larger (presumabl scaled) resolution in their mode list. > See question about MM_PER_PIXEL above Yeah, see response about not boiling the EDID ocean above ;-) > I know i915 can do better at least in some cases. Is there a practical way > to expose this? If not, I'm fine with just exposing IDENTITY. I'm not seeing this exposed through the common DRM mode interfaces yet. We should probably consider adding this to the kernel and then adding it here. > This error is not allowed for this function. We should just write 0 to > property_count and return VK_SUCCESS. Maybe add some asserts for debug > builds if you really think this shouldn't ever happen. I bet it will happen if you VT switch away and then try this function. I've added this at the end of the function: bail: *property_count = 0; return VK_SUCCESS; > This could be made a
Re: [Mesa-dev] [PATCH 01/16] intel/genxml/icl: Add gen11.xml
Hi Anuj, On 13 February 2018 at 22:41, Anuj Phogat wrote: > Signed-off-by: Anuj Phogat > --- > This patch adds a big xml file. So I couldn't send the patch > to the list. Clamping down the patch so that reviewers can > actually see what i'm doing in [PATCH 01/16 ]. The whole > patch can be found in my 'review' branch on github. > > src/intel/Makefile.sources |3 +- > src/intel/genxml/gen11.xml | 3787 > ++ > src/intel/genxml/meson.build |1 + Can you please add an Android blurb in src/intel/Android.genxml.mk Just copy the 4 lines of gen10_pack.h + sed s/gen10/gen11/ Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 02/12] meson: add libswdri and libswkmsdri to link_with unconditionally
On 12 February 2018 at 19:27, Dylan Baker wrote:
> Fixes: 6b4c7047d571 ("meson: build gallium nine state_tracker")
> Signed-off-by: Dylan Baker
> ---
> src/gallium/targets/d3dadapter9/meson.build | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/targets/d3dadapter9/meson.build
> b/src/gallium/targets/d3dadapter9/meson.build
> index 5476e80..f1b68fd 100644
> --- a/src/gallium/targets/d3dadapter9/meson.build
> +++ b/src/gallium/targets/d3dadapter9/meson.build
> @@ -1,4 +1,5 @@
> # Copyright © 2017 Dylan Baker
> +# 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
> @@ -31,20 +32,12 @@ gallium_nine_c_args = [
> ]
> gallium_nine_ld_args = []
> gallium_nine_link_depends = []
> -gallium_nine_link_with = []
>
> if with_ld_version_script
>gallium_nine_ld_args += ['-Wl,--version-script',
> join_paths(meson.current_source_dir(), 'd3dadapter9.sym')]
>gallium_nine_link_depends += files('d3dadapter9.sym')
> endif
>
> -if with_dri
> - gallium_nine_link_with += libswdri
> -endif
> -if with_gallium_drisw_kms
> - gallium_nine_link_with += libswkmsdri
> -endif
> -
> libgallium_nine = shared_library(
>'d3dadapter9',
>[files('description.c', 'getproc.c', 'drm.c'), xmlpool_options_h],
> @@ -60,8 +53,8 @@ libgallium_nine = shared_library(
>link_depends : gallium_nine_link_depends,
>link_with : [
> libgalliumvl_stub, libgallium, libnine_st, libmesa_util, libddebug,
> -librbug, libtrace, libpipe_loader_static, libws_null, libwsw,
> -gallium_nine_link_with,
> +librbug, libtrace, libpipe_loader_static, libws_null, libwsw, libswdi,
> +libswkmsdri,
I hope you build tested the series with and w/o gallium swrast - that
should cover most of the cases.
With the s/swdi/swdri/ typo fixed the series is
Reviewed-by: Emil Velikov
For the future - one could even fold the link_with libraries into a
list and reuse across targets.
There's two instances vl stubbed and full blown ones.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] loader_dri3/glx/egl: Reinstate the loader_dri3_vtable get_dri_screen callback
I'm not too familiar with this code, but your changes look OK to me.
Reviewed-by: Brian Paul
On 02/09/2018 01:37 AM, Thomas Hellstrom wrote:
Removing this callback caused rendering corruption in some multi-screen cases,
so it is reinstated but without the drawable argument which was never used
by implementations and was confusing since the drawable could have been
created with another screen.
Cc: "17.3" mesa-sta...@lists.freedesktop.org
Fixes: 5198e48a0d (loader_dri3/glx/egl: Remove the loader_dri3_vtable
get_dri_screen callback)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105013
Reported-by: Daniel van Vugt
Signed-off-by: Thomas Hellstrom
---
src/egl/drivers/dri2/platform_x11_dri3.c | 12
src/glx/dri3_glx.c | 11 +++
src/loader/loader_dri3_helper.c | 12 +++-
src/loader/loader_dri3_helper.h | 1 +
4 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c
b/src/egl/drivers/dri2/platform_x11_dri3.c
index 6e40eaa596..060b5f83a3 100644
--- a/src/egl/drivers/dri2/platform_x11_dri3.c
+++ b/src/egl/drivers/dri2/platform_x11_dri3.c
@@ -75,6 +75,17 @@ egl_dri3_get_dri_context(struct loader_dri3_drawable *draw)
return dri2_ctx->dri_context;
}
+static __DRIscreen *
+egl_dri3_get_dri_screen(void)
+{
+ _EGLContext *ctx = _eglGetCurrentContext();
+ struct dri2_egl_context *dri2_ctx;
+ if (!ctx)
+ return NULL;
+ dri2_ctx = dri2_egl_context(ctx);
+ return dri2_egl_display(dri2_ctx->base.Resource.Display)->dri_screen;
+}
+
static void
egl_dri3_flush_drawable(struct loader_dri3_drawable *draw, unsigned flags)
{
@@ -88,6 +99,7 @@ static const struct loader_dri3_vtable egl_dri3_vtable = {
.set_drawable_size = egl_dri3_set_drawable_size,
.in_current_context = egl_dri3_in_current_context,
.get_dri_context = egl_dri3_get_dri_context,
+ .get_dri_screen = egl_dri3_get_dri_screen,
.flush_drawable = egl_dri3_flush_drawable,
.show_fps = NULL,
};
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index f280a8cef7..016f91b196 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -116,6 +116,16 @@ glx_dri3_get_dri_context(struct loader_dri3_drawable *draw)
return (gc != &dummyContext) ? dri3Ctx->driContext : NULL;
}
+static __DRIscreen *
+glx_dri3_get_dri_screen(void)
+{
+ struct glx_context *gc = __glXGetCurrentContext();
+ struct dri3_context *pcp = (struct dri3_context *) gc;
+ struct dri3_screen *psc = (struct dri3_screen *) pcp->base.psc;
+
+ return (gc != &dummyContext && psc) ? psc->driScreen : NULL;
+}
+
static void
glx_dri3_flush_drawable(struct loader_dri3_drawable *draw, unsigned flags)
{
@@ -150,6 +160,7 @@ static const struct loader_dri3_vtable glx_dri3_vtable = {
.set_drawable_size = glx_dri3_set_drawable_size,
.in_current_context = glx_dri3_in_current_context,
.get_dri_context = glx_dri3_get_dri_context,
+ .get_dri_screen = glx_dri3_get_dri_screen,
.flush_drawable = glx_dri3_flush_drawable,
.show_fps = glx_dri3_show_fps,
};
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index fbda3d635c..2e3b6c619e 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -1311,6 +1311,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
unsigned int format,
xcb_sync_fence_t sync_fence;
struct xshmfence *shm_fence;
int fence_fd;
+ __DRIscreen *cur_screen;
if (buffer)
return buffer;
@@ -1341,8 +1342,17 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
unsigned int format,
if (!bp_reply)
goto no_image;
+ /* Get the currently-bound screen or revert to using the drawable's screen if
+* no contexts are currently bound. The latter case is at least necessary
for
+* obs-studio, when using Window Capture (Xcomposite) as a Source.
+*/
+ cur_screen = draw->vtable->get_dri_screen();
+ if (!cur_screen) {
+ cur_screen = draw->dri_screen;
+ }
+
buffer->image = loader_dri3_create_image(draw->conn, bp_reply, format,
-draw->dri_screen, draw->ext->image,
+cur_screen, draw->ext->image,
buffer);
if (!buffer->image)
goto no_image;
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 4ce98b8c59..839cba30df 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -99,6 +99,7 @@ struct loader_dri3_vtable {
void (*set_drawable_size)(struct loader_dri3_drawable *, int, int);
bool (*in_current_context)(struct loader_dri3_drawable *);
__DRIcontext *(*get_dri_context)(struct loader_dri3_drawable *);
+ __DRIscreen *(*get_dri_screen)(void);
Re: [Mesa-dev] [PATCH] svga: replace gotos with else clauses
Looks good.
Reviewed-by: Charmaine Lee
From: Brian Paul
Sent: Thursday, February 15, 2018 8:31:12 AM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH] svga: replace gotos with else clauses
Simple clean-up.
---
src/gallium/drivers/svga/svga_state_fs.c | 19 +--
src/gallium/drivers/svga/svga_state_gs.c | 9 -
src/gallium/drivers/svga/svga_state_vs.c | 15 +++
3 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index eeb1ba6..5190542 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -383,18 +383,17 @@ svga_reemit_fs_bindings(struct svga_context *svga)
ret = svga->swc->resource_rebind(svga->swc, NULL,
svga->state.hw_draw.fs->gb_shader,
SVGA_RELOC_READ);
- goto out;
+ }
+ else {
+ if (svga_have_vgpu10(svga))
+ ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_PS,
+ svga->state.hw_draw.fs->gb_shader,
+ svga->state.hw_draw.fs->id);
+ else
+ ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_PS,
+ svga->state.hw_draw.fs->gb_shader);
}
- if (svga_have_vgpu10(svga))
- ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_PS,
-svga->state.hw_draw.fs->gb_shader,
-svga->state.hw_draw.fs->id);
- else
- ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_PS,
- svga->state.hw_draw.fs->gb_shader);
-
- out:
if (ret != PIPE_OK)
return ret;
diff --git a/src/gallium/drivers/svga/svga_state_gs.c
b/src/gallium/drivers/svga/svga_state_gs.c
index 19f0887..38d85f0 100644
--- a/src/gallium/drivers/svga/svga_state_gs.c
+++ b/src/gallium/drivers/svga/svga_state_gs.c
@@ -153,13 +153,12 @@ svga_reemit_gs_bindings(struct svga_context *svga)
if (!svga_need_to_rebind_resources(svga)) {
ret = svga->swc->resource_rebind(svga->swc, NULL, gbshader,
SVGA_RELOC_READ);
- goto out;
+ }
+ else {
+ ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_GS,
+gbshader, shaderId);
}
- ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_GS,
- gbshader, shaderId);
-
- out:
if (ret != PIPE_OK)
return ret;
diff --git a/src/gallium/drivers/svga/svga_state_vs.c
b/src/gallium/drivers/svga/svga_state_vs.c
index 3dfc9f4..ad93f60 100644
--- a/src/gallium/drivers/svga/svga_state_vs.c
+++ b/src/gallium/drivers/svga/svga_state_vs.c
@@ -227,16 +227,15 @@ svga_reemit_vs_bindings(struct svga_context *svga)
if (!svga_need_to_rebind_resources(svga)) {
ret = svga->swc->resource_rebind(svga->swc, NULL, gbshader,
SVGA_RELOC_READ);
- goto out;
+ }
+ else {
+ if (svga_have_vgpu10(svga))
+ ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_VS,
+ gbshader, shaderId);
+ else
+ ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_VS, gbshader);
}
- if (svga_have_vgpu10(svga))
- ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_VS,
-gbshader, shaderId);
- else
- ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_VS, gbshader);
-
- out:
if (ret != PIPE_OK)
return ret;
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] svga: replace gotos with else clauses
Simple clean-up.
---
src/gallium/drivers/svga/svga_state_fs.c | 19 +--
src/gallium/drivers/svga/svga_state_gs.c | 9 -
src/gallium/drivers/svga/svga_state_vs.c | 15 +++
3 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index eeb1ba6..5190542 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -383,18 +383,17 @@ svga_reemit_fs_bindings(struct svga_context *svga)
ret = svga->swc->resource_rebind(svga->swc, NULL,
svga->state.hw_draw.fs->gb_shader,
SVGA_RELOC_READ);
- goto out;
+ }
+ else {
+ if (svga_have_vgpu10(svga))
+ ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_PS,
+ svga->state.hw_draw.fs->gb_shader,
+ svga->state.hw_draw.fs->id);
+ else
+ ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_PS,
+ svga->state.hw_draw.fs->gb_shader);
}
- if (svga_have_vgpu10(svga))
- ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_PS,
-svga->state.hw_draw.fs->gb_shader,
-svga->state.hw_draw.fs->id);
- else
- ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_PS,
- svga->state.hw_draw.fs->gb_shader);
-
- out:
if (ret != PIPE_OK)
return ret;
diff --git a/src/gallium/drivers/svga/svga_state_gs.c
b/src/gallium/drivers/svga/svga_state_gs.c
index 19f0887..38d85f0 100644
--- a/src/gallium/drivers/svga/svga_state_gs.c
+++ b/src/gallium/drivers/svga/svga_state_gs.c
@@ -153,13 +153,12 @@ svga_reemit_gs_bindings(struct svga_context *svga)
if (!svga_need_to_rebind_resources(svga)) {
ret = svga->swc->resource_rebind(svga->swc, NULL, gbshader,
SVGA_RELOC_READ);
- goto out;
+ }
+ else {
+ ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_GS,
+gbshader, shaderId);
}
- ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_GS,
- gbshader, shaderId);
-
- out:
if (ret != PIPE_OK)
return ret;
diff --git a/src/gallium/drivers/svga/svga_state_vs.c
b/src/gallium/drivers/svga/svga_state_vs.c
index 3dfc9f4..ad93f60 100644
--- a/src/gallium/drivers/svga/svga_state_vs.c
+++ b/src/gallium/drivers/svga/svga_state_vs.c
@@ -227,16 +227,15 @@ svga_reemit_vs_bindings(struct svga_context *svga)
if (!svga_need_to_rebind_resources(svga)) {
ret = svga->swc->resource_rebind(svga->swc, NULL, gbshader,
SVGA_RELOC_READ);
- goto out;
+ }
+ else {
+ if (svga_have_vgpu10(svga))
+ ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_VS,
+ gbshader, shaderId);
+ else
+ ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_VS, gbshader);
}
- if (svga_have_vgpu10(svga))
- ret = SVGA3D_vgpu10_SetShader(svga->swc, SVGA3D_SHADERTYPE_VS,
-gbshader, shaderId);
- else
- ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_VS, gbshader);
-
- out:
if (ret != PIPE_OK)
return ret;
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/11] egl/x11: Re-allocate buffers if format is suboptimal
On 2018-02-15 05:17 PM, Daniel Stone wrote: > Hi Michel, > > On 15 February 2018 at 16:14, Michel Dänzer wrote: >> On 2018-02-15 04:57 PM, Daniel Stone wrote: >>> @@ -885,6 +901,11 @@ loader_dri3_swap_buffers_msc(struct >>> loader_dri3_drawable *draw, >>>if (!loader_dri3_have_image_blit(draw) && draw->cur_blit_source != >>> -1) >>> options |= XCB_PRESENT_OPTION_COPY; >>> >>> +#if XCB_PRESENT_MAJOR_VERSION > 1 || (XCB_PRESENT_MAJOR_VERSION == 1 && >>> XCB_PRESENT_MINOR_VERSION >= 1) >>> + if (draw->multiplanes_available) >>> + options |= XCB_PRESENT_OPTION_SUBOPTIMAL; >>> +#endif >> >> This should check directly that the Present extension supports >> PresentOptionSuboptimal, rather than checking the DRI3 extension >> capabilities (what draw->multiplanes_available reflects). > > True, but it does: > dri2_dpy->multibuffers_available = >(dri2_dpy->dri3_major_version > 1 || > (dri2_dpy->dri3_major_version == 1 && > > dri2_dpy->dri3_minor_version >= 1)) && > + (dri2_dpy->present_major_version > 1 || > (dri2_dpy->present_major_version == 1 && > + > dri2_dpy->present_minor_version >= 1)) && >(dri2_dpy->image && dri2_dpy->image->base.version >= 15); Oh, I missed that. > If you'd prefer a present_suboptimal_available rather than lumping the > two together, that would be pretty easy to do. I don't care. -- 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 11/11] egl/x11: Re-allocate buffers if format is suboptimal
Hi Michel, On 15 February 2018 at 16:14, Michel Dänzer wrote: > On 2018-02-15 04:57 PM, Daniel Stone wrote: >> @@ -885,6 +901,11 @@ loader_dri3_swap_buffers_msc(struct >> loader_dri3_drawable *draw, >>if (!loader_dri3_have_image_blit(draw) && draw->cur_blit_source != -1) >> options |= XCB_PRESENT_OPTION_COPY; >> >> +#if XCB_PRESENT_MAJOR_VERSION > 1 || (XCB_PRESENT_MAJOR_VERSION == 1 && >> XCB_PRESENT_MINOR_VERSION >= 1) >> + if (draw->multiplanes_available) >> + options |= XCB_PRESENT_OPTION_SUBOPTIMAL; >> +#endif > > This should check directly that the Present extension supports > PresentOptionSuboptimal, rather than checking the DRI3 extension > capabilities (what draw->multiplanes_available reflects). True, but it does: dri2_dpy->multibuffers_available = (dri2_dpy->dri3_major_version > 1 || (dri2_dpy->dri3_major_version == 1 && dri2_dpy->dri3_minor_version >= 1)) && + (dri2_dpy->present_major_version > 1 || (dri2_dpy->present_major_version == 1 && + dri2_dpy->present_minor_version >= 1)) && (dri2_dpy->image && dri2_dpy->image->base.version >= 15); If you'd prefer a present_suboptimal_available rather than lumping the two together, that would be pretty easy to do. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/11] egl/x11: Re-allocate buffers if format is suboptimal
On 2018-02-15 04:57 PM, Daniel Stone wrote: > From: Louis-Francis Ratté-Boulianne > > If PresentCompleteNotify event says the pixmap was presented > with mode PresentCompleteModeSuboptimalCopy, it means the pixmap > could possibly have been flipped instead if allocated with a > different format/modifier. > > Signed-off-by: Louis-Francis Ratté-Boulianne > Reviewed-by: Daniel Stone > Signed-off-by: Daniel Stone [...] > @@ -885,6 +901,11 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable > *draw, >if (!loader_dri3_have_image_blit(draw) && draw->cur_blit_source != -1) > options |= XCB_PRESENT_OPTION_COPY; > > +#if XCB_PRESENT_MAJOR_VERSION > 1 || (XCB_PRESENT_MAJOR_VERSION == 1 && > XCB_PRESENT_MINOR_VERSION >= 1) > + if (draw->multiplanes_available) > + options |= XCB_PRESENT_OPTION_SUBOPTIMAL; > +#endif This should check directly that the Present extension supports PresentOptionSuboptimal, rather than checking the DRI3 extension capabilities (what draw->multiplanes_available reflects). -- 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] svga: call tgsi_scan_shader() for dummy shaders
Looks good. Reviewed-by: Charmaine Lee From: Brian Paul Sent: Wednesday, February 14, 2018 6:57:21 PM To: mesa-dev@lists.freedesktop.org Cc: Charmaine Lee; Neha Bhende Subject: [PATCH] svga: call tgsi_scan_shader() for dummy shaders If we fail to compile the normal VS or FS we fall back to a simple/ dummy shader. We need to rescan the the shader to update the shader info. Otherwise, this can lead to further translations failures because the shader info doesn't match the actual shader. Found by adding some extra debug assertions in the state-update code while debugging something else. v2: also update shader generic_inputs/outputs, etc. per Charmaine --- src/gallium/drivers/svga/svga_state_fs.c | 4 src/gallium/drivers/svga/svga_state_vs.c | 3 +++ 2 files changed, 7 insertions(+) diff --git a/src/gallium/drivers/svga/svga_state_fs.c b/src/gallium/drivers/svga/svga_state_fs.c index 5e56899..eeb1ba6 100644 --- a/src/gallium/drivers/svga/svga_state_fs.c +++ b/src/gallium/drivers/svga/svga_state_fs.c @@ -115,6 +115,10 @@ get_compiled_dummy_shader(struct svga_context *svga, FREE((void *) fs->base.tokens); fs->base.tokens = dummy; + tgsi_scan_shader(fs->base.tokens, &fs->base.info); + fs->generic_inputs = svga_get_generic_inputs_mask(&fs->base.info); + svga_remap_generics(fs->generic_inputs, fs->generic_remap_table); + variant = translate_fragment_program(svga, fs, key); return variant; } diff --git a/src/gallium/drivers/svga/svga_state_vs.c b/src/gallium/drivers/svga/svga_state_vs.c index a0ab868..3dfc9f4 100644 --- a/src/gallium/drivers/svga/svga_state_vs.c +++ b/src/gallium/drivers/svga/svga_state_vs.c @@ -105,6 +105,9 @@ get_compiled_dummy_vertex_shader(struct svga_context *svga, FREE((void *) vs->base.tokens); vs->base.tokens = dummy; + tgsi_scan_shader(vs->base.tokens, &vs->base.info); + vs->generic_outputs = svga_get_generic_outputs_mask(&vs->base.info); + variant = translate_vertex_program(svga, vs, key); return variant; } -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
