Re: [Mesa-dev] [PATCH] glsl: don't flatten if-blocks with dynamic array indices
On 18.11.2016 02:35, Dylan Baker wrote:
Are you sure this is correct? Marek mentions in the referenced commit message
that these pass on softpipe, and they work on i965 and i915 just fine.
GLSL states very clearly that out-of-bounds array accesses lead to
undefined behavior. Without this patch, we effectively turn:
if (cond)
array[i] = x;
into
tmp = array[i];
tmp = cond ? x : tmp;
array[i] = tmp;
This is the code that radeonsi hands off to LLVM, and LLVM takes that
code literally. This implies the assumption that i is within array
bounds. Combined with the optimizations that LLVM does (in particular
instruction scheduling), an out-of-bounds i will lead to an unrelated
register being overwritten by the original value of tmp when cond if
false. For example, array is stored in hardware registers v0 .. v3 and i
== 4. Due to instruction scheduling, v4 corresponds to a different value
when it is read than when it is written.
softpipe interprets the resulting TGSI literally and without instruction
scheduling, so even if it ignores the ArrayID annotations, it will end
up _not_ clobbering other values. I suspect i9?5 are similar.
Cheers,
Nicolai
Dylan
Quoting Nicolai Hähnle (2016-11-17 13:59:26)
From: Nicolai Hähnle
This fixes the regression of radeonsi in
glsl-1.10/execution/variable-indexing/vs-output-array-vec3-index-wr
caused by commit 74e39de9324d2d2333cda6adca50ae2a3fc36de2.
---
src/compiler/glsl/lower_if_to_cond_assign.cpp | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/compiler/glsl/lower_if_to_cond_assign.cpp
b/src/compiler/glsl/lower_if_to_cond_assign.cpp
index ae048be..37f1ec8 100644
--- a/src/compiler/glsl/lower_if_to_cond_assign.cpp
+++ b/src/compiler/glsl/lower_if_to_cond_assign.cpp
@@ -79,20 +79,21 @@ public:
~ir_if_to_cond_assign_visitor()
{
_mesa_set_destroy(this->condition_variables, NULL);
}
ir_visitor_status visit_enter(ir_if *);
ir_visitor_status visit_leave(ir_if *);
bool found_unsupported_op;
bool found_expensive_op;
+ bool found_dynamic_arrayref;
bool is_then;
bool progress;
gl_shader_stage stage;
unsigned then_cost;
unsigned else_cost;
unsigned min_branch_cost;
unsigned max_depth;
unsigned depth;
struct set *condition_variables;
@@ -141,22 +142,27 @@ check_ir_node(ir_instruction *ir, void *data)
var->data.mode == ir_var_shader_out)
v->found_unsupported_op = true;
break;
}
/* SSBO, images, atomic counters are handled by ir_type_call */
case ir_type_texture:
v->found_expensive_op = true;
break;
+ case ir_type_dereference_array: {
+ ir_dereference_array *deref = ir->as_dereference_array();
+
+ if (deref->array_index->ir_type != ir_type_constant)
+ v->found_dynamic_arrayref = true;
+ } /* fall-through */
case ir_type_expression:
- case ir_type_dereference_array:
case ir_type_dereference_record:
if (v->is_then)
v->then_cost++;
else
v->else_cost++;
break;
default:
break;
}
@@ -222,42 +228,51 @@ ir_visitor_status
ir_if_to_cond_assign_visitor::visit_leave(ir_if *ir)
{
bool must_lower = this->depth-- > this->max_depth;
/* Only flatten when beyond the GPU's maximum supported nesting depth. */
if (!must_lower && this->min_branch_cost == 0)
return visit_continue;
this->found_unsupported_op = false;
this->found_expensive_op = false;
+ this->found_dynamic_arrayref = false;
this->then_cost = 0;
this->else_cost = 0;
ir_assignment *assign;
/* Check that both blocks don't contain anything we can't support. */
this->is_then = true;
foreach_in_list(ir_instruction, then_ir, &ir->then_instructions) {
visit_tree(then_ir, check_ir_node, this);
}
this->is_then = false;
foreach_in_list(ir_instruction, else_ir, &ir->else_instructions) {
visit_tree(else_ir, check_ir_node, this);
}
if (this->found_unsupported_op)
return visit_continue; /* can't handle inner unsupported opcodes */
- /* Skip if the branch cost is high enough or if there's an expensive op. */
+ /* Skip if the branch cost is high enough or if there's an expensive op.
+*
+* Also skip if non-constant array indices were encountered, since those
+* can be out-of-bounds for a not-taken branch, and so generating an
+* assignment would be incorrect. In the case of must_lower, it's up to the
+* backend to deal with any potential fall-out (perhaps by translating the
+* assignments to hardware-predicated moves).
+*/
if (!must_lower &&
(this->found_expensive_op ||
+this->found_dynamic_arrayref ||
MAX2(this->then_cost, this->else_cost) >= this->min_branch_cost))
return visit_continue;
void *mem_ctx = ralloc_parent(ir);
/* Store the condition to a variable. Move all of the instructions f
Re: [Mesa-dev] [PATCH 1/2] gbm: automake: remove unused defines
Series is: Reviewed-by: Eduardo Lima Mitev Thanks! On 11/17/2016 04:45 PM, Emil Velikov wrote: From: Emil Velikov Signed-off-by: Emil Velikov --- src/gbm/Makefile.am | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/gbm/Makefile.am b/src/gbm/Makefile.am index aba8d1e..e34c1d4 100644 --- a/src/gbm/Makefile.am +++ b/src/gbm/Makefile.am @@ -4,8 +4,6 @@ pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = main/gbm.pc AM_CFLAGS = \ - -D_OS_UNIX=1 \ - -DMODULEDIR='"$(libdir)/gbm"' \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src/loader \ -I$(top_srcdir)/src/gbm/main \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Determinism in the results of llvmpipe?
On 17/11/16 07:37, Andrew A. wrote: Hello, I'm using Mesa's software renderer for the purposes of regression testing in our graphics software. We render various scenes, save a screencap of the framebuffer for each scene, then compare those framebuffer captures to previously known-good captures. Across runs of these tests on the same hardware, the results seem to be 100% identical. When running the same tests on a different machine, results are *slightly* different. It's very similar within a small tolerance, so this is still usable. However, I was hoping for fully deterministic behavior, even if the hardware is slightly different. Are there some compile time settings or some code that I can change to get Mesa's llvmpipe renderer/rasterizer to be fully deterministic in its output? I'm using llvmpipe, and these are the two different CPUs I'm using to run the tests: Intel(R) Xeon(R) CPU E3-1275 v3 Intel(R) Xeon(R) CPU X5650 Thanks, Andrew ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev llvmpipe changes its behavior in _runtime_ based on the CPU features (like SSE AVX, AVX2, etc.) You could hack u_cpu_detect.c and LLVM source code to mask away CPU extra features ans reduce the perceived CPUID flags to the common denominator. In fact, for the two CPUs you mention above, the differences probably go away if you set this environment variable: LP_NATIVE_VECTOR_WIDTH=128 as it will force llvmpipe to ignore AVX/AVX2/FMA/F16C. But probably the best is to use x86 virtualization to clamp CPUID and do that. Having a virtual machine image will also solve the problem of ensuring all runtime is the same, etc. https://software.intel.com/en-us/articles/intel-software-development-emulator can also do the same without virtualization (via bianry translation), but it might impact performance. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 06/10] swr: Windows-related changes
On 17 November 2016 at 20:51, Kyriazis, George wrote: > > >> -Original Message- >> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On >> Behalf Of Emil Velikov >> Sent: Thursday, November 17, 2016 11:12 AM >> To: Kyriazis, George >> Cc: ML mesa-dev >> Subject: Re: [Mesa-dev] [PATCH v3 06/10] swr: Windows-related changes >> >> Hi George, >> >> Seems I was unclear as a few suggestions got missed. >> >> On 16 November 2016 at 02:26, George Kyriazis >> wrote: >> > - Handle dynamic library loading for windows >> > - Implement swap for gdi >> > - fix prototypes >> > - update include paths on configure-based build for swr_loader.cpp >> > --- >> > src/gallium/drivers/swr/Makefile.am| 7 +++ >> > src/gallium/drivers/swr/swr_loader.cpp | 28 >> +--- >> > src/gallium/drivers/swr/swr_public.h | 11 +++ >> > 3 files changed, 39 insertions(+), 7 deletions(-) >> > >> > diff --git a/src/gallium/drivers/swr/Makefile.am >> > b/src/gallium/drivers/swr/Makefile.am >> > index dd1c2e6..305154f 100644 >> > --- a/src/gallium/drivers/swr/Makefile.am >> > +++ b/src/gallium/drivers/swr/Makefile.am >> > @@ -217,6 +217,12 @@ libswrAVX2_la_CXXFLAGS = \ >> libswrAVX2_la_SOURCES >> > = \ >> > $(COMMON_SOURCES) >> > >> > +# XXX: $(SWR_AVX_CXXFLAGS) should not be included, but we end up >> > +including # simdintrin.h, which throws a warning if AVX is not >> > +enabled libmesaswr_la_CXXFLAGS = \ >> > + $(COMMON_CXXFLAGS) \ >> > + $(SWR_AVX_CXXFLAGS) >> > + >> Drop this. >> > This is needed for linux configure-based build. > As you can see per your v4 this don't fold true. I would kindly ask you to compile test (2 minute job) - saves a lot of confusing moments on each end. >> > --- a/src/gallium/drivers/swr/swr_loader.cpp >> > +++ b/src/gallium/drivers/swr/swr_loader.cpp >> >> > +#include "swr_screen.h" >> > +#include "swr_resource.h" >> > + >> You only need p_screen.h here. Adding the swr ones is wrong (afaict). >> > Ok, replaced. > Same goes here - these wrong includes were the reason for extra includes above. Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for windows
On 18 November 2016 at 04:27, George Kyriazis wrote: > Also, modify gen_knobs.py so that each invocation creates a single generated > file. This is more similar to how the other generators behave. > --- > src/gallium/SConscript | 1 + > src/gallium/drivers/swr/Makefile.am| 15 +- > src/gallium/drivers/swr/SConscript | 216 > + > .../drivers/swr/rasterizer/scripts/gen_knobs.py| 51 ++--- > 4 files changed, 257 insertions(+), 26 deletions(-) > create mode 100644 src/gallium/drivers/swr/SConscript > This is getting tiresome :'-( I've mentioned on multiple occasions to keep separate logical changes into individual patches. In my previous sounds I've _explicitly_ left only the ones (SConscript fixes) that should be squashed here. Please read review comments more carefully ? When sending version X of patch series, adding r-b/ack-b/t-b/other tags (where applicable) and brief version history is highly recommended. If in doubt on the latter - skim through git log + grep v2. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stable release process
On 17 November 2016 at 23:42, Marek Olšák wrote:
> On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov
> wrote:
>> On 15 November 2016 at 16:57, Marek Olšák wrote:
>>> On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov
>>> wrote:
On 15 November 2016 at 16:13, Marek Olšák wrote:
> I think that if people add the Cc stable tag to patches that are going
> to land in master first, they shouldn't send it to the stable ML,
> because that is redundant. Yet, many people do that. I would go even
> further and say that any unreviewed patches shouldn't be sent to the
> stable ML. At least that would be my policy I were the release
> manager.
>
Since I'm no longer tracking nominated-but-not-merged-in-master
patches things are noticeably better.
>>>
>>> What about patches in mesa-stable that can't be merged to master,
>>> because master needs to be fixed differently? Will you then apply the
>>> patches from mesa-stable or ignore them?
>>>
>>> Based on experience, it looks like you ignore them completely, which
>>> is why many fixes that I sent for inclusion to stable branches only
>>> (not master) have never been applied. This process needs to be fixed.
>>>
>> Trivial patches are addressed, others are pinged. Trivial dependencies
>> are picked, non-trivial ones invalidate the nominated patch.
>> Backports are always appreciated - there's been a few from yourself,
>> Ilia and others.
>>
>> One example/snippet from the 12.0.x pre-release announcement.
>> "
>> f240ad9 st/mesa: unduplicate st_check_sync code
>> b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync
>>
>> Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
>> fence_finish") which is gallium API change.
>> "
>> Here the original nominations are invalidated, and from a quick look
>> even if we do pick the dependency things won't work [as expected]
>> since zero drivers hadnle the pipe_ctx this will need to add support
>> (read: not bugfix, but implement).
>>
>> In all fairness if sounds like things are unclear rather than anything
>> else. I believe with the documentation (and above) things are better
>> now ?
>
> That's all nice, but it's mostly irrelevant to what I was saying.
>
> We need Patchwork for mesa-stable, so that patches don't get lost.
>
Ok let me be perfectly clear.
Nearly all the missed patches (many of those sent by you) do _not_
follow the -stable submission rules. I've been polite and picked those
_despite_ that fact and yes some have been missed.
Regardless of patchwork I would _strongly_ suggest that you stay
consistent (you do it right most of the time) and nominate patches
properly!
Speaking of patchwork, mostly I'm fine with it. There are some
"drawbacks" though:
- some duplicated time will be spent tagging "self-rejected" patches.
I already track these based from the mailing list.
- it doesn't parse "Pick commit $sha, it addresses $issue"
nominations, so it cannot substitute/replace the mailing list.
In case my first point brought some "don't bother with the ML" type of thoughts.
- you don't seem to be using it [1] so I'm not sure of the sudden interest.
Thanks
Emil
[1] The following shows ~800 "New" patches for yours ranging back to 2014.
https://patchwork.freedesktop.org/project/mesa/patches/?submitter=11032&state=&q=&archive=&delegate=
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stable release process
On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov wrote:
> On 17 November 2016 at 23:42, Marek Olšák wrote:
>> On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov
>> wrote:
>>> On 15 November 2016 at 16:57, Marek Olšák wrote:
On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov
wrote:
> On 15 November 2016 at 16:13, Marek Olšák wrote:
>> I think that if people add the Cc stable tag to patches that are going
>> to land in master first, they shouldn't send it to the stable ML,
>> because that is redundant. Yet, many people do that. I would go even
>> further and say that any unreviewed patches shouldn't be sent to the
>> stable ML. At least that would be my policy I were the release
>> manager.
>>
> Since I'm no longer tracking nominated-but-not-merged-in-master
> patches things are noticeably better.
What about patches in mesa-stable that can't be merged to master,
because master needs to be fixed differently? Will you then apply the
patches from mesa-stable or ignore them?
Based on experience, it looks like you ignore them completely, which
is why many fixes that I sent for inclusion to stable branches only
(not master) have never been applied. This process needs to be fixed.
>>> Trivial patches are addressed, others are pinged. Trivial dependencies
>>> are picked, non-trivial ones invalidate the nominated patch.
>>> Backports are always appreciated - there's been a few from yourself,
>>> Ilia and others.
>>>
>>> One example/snippet from the 12.0.x pre-release announcement.
>>> "
>>> f240ad9 st/mesa: unduplicate st_check_sync code
>>> b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync
>>>
>>> Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
>>> fence_finish") which is gallium API change.
>>> "
>>> Here the original nominations are invalidated, and from a quick look
>>> even if we do pick the dependency things won't work [as expected]
>>> since zero drivers hadnle the pipe_ctx this will need to add support
>>> (read: not bugfix, but implement).
>>>
>>> In all fairness if sounds like things are unclear rather than anything
>>> else. I believe with the documentation (and above) things are better
>>> now ?
>>
>> That's all nice, but it's mostly irrelevant to what I was saying.
>>
>> We need Patchwork for mesa-stable, so that patches don't get lost.
>>
> Ok let me be perfectly clear.
>
> Nearly all the missed patches (many of those sent by you) do _not_
> follow the -stable submission rules. I've been polite and picked those
> _despite_ that fact and yes some have been missed.
> Regardless of patchwork I would _strongly_ suggest that you stay
> consistent (you do it right most of the time) and nominate patches
> properly!
The last one was nominated properly, and ignored. It didn't mention
anything about the app it was fixing, but I couldn't tell you that
anyway - it was for an app that hadn't even been released for Linux.
So yeah, nominations not mentioning fixed apps or bugzilla should be
expected and accepted.
>
> Speaking of patchwork, mostly I'm fine with it. There are some
> "drawbacks" though:
> - some duplicated time will be spent tagging "self-rejected" patches.
> I already track these based from the mailing list.
> - it doesn't parse "Pick commit $sha, it addresses $issue"
> nominations, so it cannot substitute/replace the mailing list.
> In case my first point brought some "don't bother with the ML" type of
> thoughts.
> - you don't seem to be using it [1] so I'm not sure of the sudden interest.
Patchwork can't clear any of my patches on git push. That's normal. I
do use Patchwork for reviewing patches though.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 98767] [swrast] ralloc.c:84: get_header: Assertion `info->canary == CANARY' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=98767 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Timothy Arceri --- Should be fixed by: commit 88fe2c308ec0902b8f3980f9ce6ab6241ba74c14 Author: Timothy Arceri Date: Fri Nov 18 11:51:59 2016 +1100 mesa: fix old classic drivers to use ralloc for ARB asm programs These changes were missed in 0ad69e6b5. Acked-by: Edward O'Callaghan Reviewed-by: Kenneth Graunke Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98767 -- 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] glsl: don't flatten if-blocks with dynamic array indices
Thanks!
Reviewed-by: Marek Olšák
Marek
On Thu, Nov 17, 2016 at 10:59 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This fixes the regression of radeonsi in
> glsl-1.10/execution/variable-indexing/vs-output-array-vec3-index-wr
> caused by commit 74e39de9324d2d2333cda6adca50ae2a3fc36de2.
> ---
> src/compiler/glsl/lower_if_to_cond_assign.cpp | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/glsl/lower_if_to_cond_assign.cpp
> b/src/compiler/glsl/lower_if_to_cond_assign.cpp
> index ae048be..37f1ec8 100644
> --- a/src/compiler/glsl/lower_if_to_cond_assign.cpp
> +++ b/src/compiler/glsl/lower_if_to_cond_assign.cpp
> @@ -79,20 +79,21 @@ public:
> ~ir_if_to_cond_assign_visitor()
> {
>_mesa_set_destroy(this->condition_variables, NULL);
> }
>
> ir_visitor_status visit_enter(ir_if *);
> ir_visitor_status visit_leave(ir_if *);
>
> bool found_unsupported_op;
> bool found_expensive_op;
> + bool found_dynamic_arrayref;
> bool is_then;
> bool progress;
> gl_shader_stage stage;
> unsigned then_cost;
> unsigned else_cost;
> unsigned min_branch_cost;
> unsigned max_depth;
> unsigned depth;
>
> struct set *condition_variables;
> @@ -141,22 +142,27 @@ check_ir_node(ir_instruction *ir, void *data)
>var->data.mode == ir_var_shader_out)
> v->found_unsupported_op = true;
>break;
> }
>
> /* SSBO, images, atomic counters are handled by ir_type_call */
> case ir_type_texture:
>v->found_expensive_op = true;
>break;
>
> + case ir_type_dereference_array: {
> + ir_dereference_array *deref = ir->as_dereference_array();
> +
> + if (deref->array_index->ir_type != ir_type_constant)
> + v->found_dynamic_arrayref = true;
> + } /* fall-through */
> case ir_type_expression:
> - case ir_type_dereference_array:
> case ir_type_dereference_record:
>if (v->is_then)
> v->then_cost++;
>else
> v->else_cost++;
>break;
>
> default:
>break;
> }
> @@ -222,42 +228,51 @@ ir_visitor_status
> ir_if_to_cond_assign_visitor::visit_leave(ir_if *ir)
> {
> bool must_lower = this->depth-- > this->max_depth;
>
> /* Only flatten when beyond the GPU's maximum supported nesting depth. */
> if (!must_lower && this->min_branch_cost == 0)
>return visit_continue;
>
> this->found_unsupported_op = false;
> this->found_expensive_op = false;
> + this->found_dynamic_arrayref = false;
> this->then_cost = 0;
> this->else_cost = 0;
>
> ir_assignment *assign;
>
> /* Check that both blocks don't contain anything we can't support. */
> this->is_then = true;
> foreach_in_list(ir_instruction, then_ir, &ir->then_instructions) {
>visit_tree(then_ir, check_ir_node, this);
> }
>
> this->is_then = false;
> foreach_in_list(ir_instruction, else_ir, &ir->else_instructions) {
>visit_tree(else_ir, check_ir_node, this);
> }
>
> if (this->found_unsupported_op)
>return visit_continue; /* can't handle inner unsupported opcodes */
>
> - /* Skip if the branch cost is high enough or if there's an expensive op.
> */
> + /* Skip if the branch cost is high enough or if there's an expensive op.
> +*
> +* Also skip if non-constant array indices were encountered, since those
> +* can be out-of-bounds for a not-taken branch, and so generating an
> +* assignment would be incorrect. In the case of must_lower, it's up to
> the
> +* backend to deal with any potential fall-out (perhaps by translating the
> +* assignments to hardware-predicated moves).
> +*/
> if (!must_lower &&
> (this->found_expensive_op ||
> +this->found_dynamic_arrayref ||
> MAX2(this->then_cost, this->else_cost) >= this->min_branch_cost))
>return visit_continue;
>
> void *mem_ctx = ralloc_parent(ir);
>
> /* Store the condition to a variable. Move all of the instructions from
> * the then-clause of the if-statement. Use the condition variable as a
> * condition for all assignments.
> */
> ir_variable *const then_var =
> --
> 2.7.4
>
> ___
> 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] anv/state: enable coordinate address rounding for Min/Mag filters
This patch improves pass rate of dEQP-VK.texture.explicit_lod.2d.sizes.*
from 68.0% (98/144) to 83.3% (120/144) by enabling sampler address
rounding mode when the selected filter is not nearest, which is the same
thing we do for OpenGL.
These tests check texture filtering for various texture sizes and mipmap
levels. The failures (without this patch) affect cases where the target
texture has odd dimensions (like 57x35) and either the Min or the Mag filter
is not nearest.
---
I think this patch should fix all the failed tests, but for some reason it
only fixes the subset where the MagFilter is not linear.
src/intel/vulkan/genX_state.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
index be1bd78..4122395 100644
--- a/src/intel/vulkan/genX_state.c
+++ b/src/intel/vulkan/genX_state.c
@@ -167,6 +167,11 @@ VkResult genX(CreateSampler)(
uint32_t border_color_offset = device->border_colors.offset +
pCreateInfo->borderColor * 64;
+ bool enable_min_filter_addr_rounding =
+ pCreateInfo->minFilter != VK_FILTER_NEAREST;
+ bool enable_mag_filter_addr_rounding =
+ pCreateInfo->magFilter != VK_FILTER_NEAREST;
+
struct GENX(SAMPLER_STATE) sampler_state = {
.SamplerDisable = false,
.TextureBorderColorMode = DX10OGL,
@@ -202,12 +207,12 @@ VkResult genX(CreateSampler)(
#endif
.MaximumAnisotropy =
vk_to_gen_max_anisotropy(pCreateInfo->maxAnisotropy),
- .RAddressMinFilterRoundingEnable = 0,
- .RAddressMagFilterRoundingEnable = 0,
- .VAddressMinFilterRoundingEnable = 0,
- .VAddressMagFilterRoundingEnable = 0,
- .UAddressMinFilterRoundingEnable = 0,
- .UAddressMagFilterRoundingEnable = 0,
+ .RAddressMinFilterRoundingEnable = enable_min_filter_addr_rounding,
+ .RAddressMagFilterRoundingEnable = enable_mag_filter_addr_rounding,
+ .VAddressMinFilterRoundingEnable = enable_min_filter_addr_rounding,
+ .VAddressMagFilterRoundingEnable = enable_mag_filter_addr_rounding,
+ .UAddressMinFilterRoundingEnable = enable_min_filter_addr_rounding,
+ .UAddressMagFilterRoundingEnable = enable_mag_filter_addr_rounding,
.TrilinearFilterQuality = 0,
.NonnormalizedCoordinateEnable = pCreateInfo->unnormalizedCoordinates,
.TCXAddressControlMode =
vk_to_gen_tex_address[pCreateInfo->addressModeU],
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/10] mesa: support for EGL_ANDROID_native_fence_sync (vN+1)
This patchset implements support for EGL_ANDROID_native_fence_sync[1] for egl and gallium. This extension provides support for native fence fd's (file descriptors) for the GPU. In a similar way to dma-buf fd's, which provide a reference-counted userspace handle to buffers which can be shared across drivers and across processes, native fence fd's provide a reference-counted userspace handle to fences which can be shared across drivers and across processes. This extension is already in use on android, and should be useful in other environments. Patch 04/10 has some fixes from Chad squashed in, as well as a couple fixes for issues that Rafael found while writing piglit tests. The kernel patches for freedreno (drm/msm) are upstream (v4.9) and the libdrm patches are in v2.4.72. Kernel patches for drm/virtio are in flight (so corresponding gallium patch is not ready to push). Kernel plus libdrm plus mesa patches for i965 are in flight. This has been tested on piglit[2] (i965, freedreno), kmscube[3] (virgl, freedreno), and drm-hwc2[4] (virgl, freedreno). [1] https://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_native_fence_sync.txt [2] https://patchwork.freedesktop.org/series/14498/ [3] https://github.com/robclark/kmscube/commits/atomic-fence [4] https://git.collabora.com/cgit/user/robertfoss/drm_hwcomposer.git/log/?h=hwc2_fence_v2 Gustavo Padovan (1): RFC: virgl: native fence fd support Rob Clark (9): egl: initialize SyncCondition after attr parsing egl: un-fallthrough sync attr parsing dri: extend fence extension to support native fd fences egl: add EGL_ANDROID_native_fence_sync gallium: wire up server_wait_sync gallium: support for native fence fd's freedreno: some fence cleanup freedreno: native fence fd support freedreno: no-op render when we need a fence configure.ac | 2 +- include/GL/internal/dri_interface.h| 44 +++- src/egl/drivers/dri2/egl_dri2.c| 58 +++- src/egl/main/eglapi.c | 38 ++- src/egl/main/eglapi.h | 2 + src/egl/main/egldisplay.h | 1 + src/egl/main/eglfallbacks.c| 1 + src/egl/main/eglsync.c | 31 +++-- src/egl/main/eglsync.h | 1 + src/gallium/drivers/freedreno/freedreno_batch.c| 7 +- src/gallium/drivers/freedreno/freedreno_batch.h| 3 + .../drivers/freedreno/freedreno_batch_cache.c | 4 +- .../drivers/freedreno/freedreno_batch_cache.h | 2 +- src/gallium/drivers/freedreno/freedreno_context.c | 27 +--- src/gallium/drivers/freedreno/freedreno_context.h | 2 +- src/gallium/drivers/freedreno/freedreno_fence.c| 51 -- src/gallium/drivers/freedreno/freedreno_fence.h| 16 +++-- src/gallium/drivers/freedreno/freedreno_gmem.c | 32 - src/gallium/drivers/freedreno/freedreno_gmem.h | 1 + src/gallium/drivers/freedreno/freedreno_screen.c | 7 +- src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_pipe.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/drivers/virgl/virgl_context.c | 47 +++-- src/gallium/drivers/virgl/virgl_screen.c | 12 src/gallium/drivers/virgl/virgl_winsys.h | 16 - src/gallium/include/pipe/p_context.h | 19 ++ src/gallium/include/pipe/p_defines.h | 2 + src/gallium/include/pipe/p_screen.h| 10 +++ src/gallium/state_trackers/dri/dri2.c | 58 +++- src/gallium/winsys/virgl/drm/virgl_drm_winsys.c| 78 +- src/gallium/winsys/virgl/drm/virgl_drm_winsys.h| 2 + src/gallium/winsys/virgl/drm/virtgpu_drm.h | 16 - .../winsys/virgl/vtest/virgl_vtest_winsys.c| 8 ++- 43 files changed, 549 insertions(+), 61 deletions(-) -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/10] egl: initialize SyncCondition after attr parsing
From: Rob Clark
Reduce the noise in the next patch. For EGL_SYNC_NATIVE_FENCE_ANDROID
the sync condition is conditional on EGL_SYNC_NATIVE_FENCE_FD_ANDROID
attribute.
Signed-off-by: Rob Clark
---
src/egl/main/eglsync.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c
index dea324b..005cb31 100644
--- a/src/egl/main/eglsync.c
+++ b/src/egl/main/eglsync.c
@@ -84,6 +84,8 @@ _eglInitSync(_EGLSync *sync, _EGLDisplay *dpy, EGLenum type,
sync->Type = type;
sync->SyncStatus = EGL_UNSIGNALED_KHR;
+ err = _eglParseSyncAttribList(sync, attrib_list);
+
switch (type) {
case EGL_SYNC_CL_EVENT_KHR:
sync->SyncCondition = EGL_SYNC_CL_EVENT_COMPLETE_KHR;
@@ -92,7 +94,6 @@ _eglInitSync(_EGLSync *sync, _EGLDisplay *dpy, EGLenum type,
sync->SyncCondition = EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR;
}
- err = _eglParseSyncAttribList(sync, attrib_list);
if (err != EGL_SUCCESS)
return _eglError(err, "eglCreateSyncKHR");
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] dri: extend fence extension to support native fd fences
From: Rob Clark
Required to implement EGL_ANDROID_native_fence_sync.
Signed-off-by: Rob Clark
---
include/GL/internal/dri_interface.h | 44 -
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index d0b1bc6..c6ea464 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -340,12 +340,19 @@ struct __DRI2throttleExtensionRec {
*/
#define __DRI2_FENCE "DRI2_Fence"
-#define __DRI2_FENCE_VERSION 1
+#define __DRI2_FENCE_VERSION 2
#define __DRI2_FENCE_TIMEOUT_INFINITE 0xllu
#define __DRI2_FENCE_FLAG_FLUSH_COMMANDS (1 << 0)
+/**
+ * \name Capabilities that might be returned by
__DRI2fenceExtensionRec::get_capabilities
+ */
+/*@{*/
+#define __DRI_FENCE_CAP_NATIVE_FD 1
+/*@}*/
+
struct __DRI2fenceExtensionRec {
__DRIextension base;
@@ -390,6 +397,41 @@ struct __DRI2fenceExtensionRec {
*sense with this function (right now there are none)
*/
void (*server_wait_sync)(__DRIcontext *ctx, void *fence, unsigned flags);
+
+ /**
+* Query for general capabilities of the driver that concern fences.
+* Returns a bitmask of __DRI_FENCE_CAP_x
+*
+* \since 2
+*/
+ unsigned (*get_capabilities)(__DRIscreen *screen);
+
+ /**
+* Create an fd (file descriptor) associated fence. If the fence fd
+* is -1, this behaves similarly to create_fence() except that when
+* rendering is flushed the driver creates a fence fd. Otherwise,
+* the driver wraps an existing fence fd.
+*
+* This is used to implement the EGL_ANDROID_native_fence_sync extension.
+*
+* \since 2
+*
+* \param ctx the context associated with the fence
+* \param fd the fence fd or -1
+*/
+ void *(*create_fence_fd)(__DRIcontext *ctx, int fd);
+
+ /**
+* For fences created with create_fence_fd(), after rendering is flushed,
+* this retrieves the native fence fd. Caller takes ownership of the
+* fd and will close() it when it is no longer needed.
+*
+* \since 2
+*
+* \param screen the screen associated with the fence
+* \param fence the fence
+*/
+ int (*get_fence_fd)(__DRIscreen *screen, void *fence);
};
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] egl: un-fallthrough sync attr parsing
Doesn't work so well when you start having more than one possible
attrib. Prep-work for next patch.
Signed-off-by: Rob Clark
---
src/egl/main/eglsync.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c
index 005cb31..7b2c882 100644
--- a/src/egl/main/eglsync.c
+++ b/src/egl/main/eglsync.c
@@ -55,11 +55,11 @@ _eglParseSyncAttribList(_EGLSync *sync, const EGLAttrib
*attrib_list)
case EGL_CL_EVENT_HANDLE_KHR:
if (sync->Type == EGL_SYNC_CL_EVENT_KHR) {
sync->CLEvent = val;
-break;
+ } else {
+err = EGL_BAD_ATTRIBUTE;
}
- /* fall through */
+ break;
default:
- (void) val;
err = EGL_BAD_ATTRIBUTE;
break;
}
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/10] egl: add EGL_ANDROID_native_fence_sync
From: Rob Clark
With fixes from Chad squashed in, plus fixes for issues that Rafael
found while writing piglit tests.
Cc: Chad Versace
Cc: Rafael Antognolli
Signed-off-by: Rob Clark
---
src/egl/drivers/dri2/egl_dri2.c | 58 -
src/egl/main/eglapi.c | 38 ---
src/egl/main/eglapi.h | 2 ++
src/egl/main/egldisplay.h | 1 +
src/egl/main/eglfallbacks.c | 1 +
src/egl/main/eglsync.c | 22 ++--
src/egl/main/eglsync.h | 1 +
7 files changed, 117 insertions(+), 6 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index f18e9fb..52fbdff 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -658,6 +658,12 @@ dri2_setup_screen(_EGLDisplay *disp)
disp->Extensions.KHR_wait_sync = EGL_TRUE;
if (dri2_dpy->fence->get_fence_from_cl_event)
disp->Extensions.KHR_cl_event2 = EGL_TRUE;
+ if (dri2_dpy->fence->base.version >= 2) {
+ unsigned capabilities =
+dri2_dpy->fence->get_capabilities(dri2_dpy->dri_screen);
+ disp->Extensions.ANDROID_native_fence_sync =
+(capabilities & __DRI_FENCE_CAP_NATIVE_FD) != 0;
+ }
}
disp->Extensions.KHR_reusable_sync = EGL_TRUE;
@@ -2511,8 +2517,17 @@ dri2_egl_unref_sync(struct dri2_egl_display *dri2_dpy,
struct dri2_egl_sync *dri2_sync)
{
if (p_atomic_dec_zero(&dri2_sync->refcount)) {
- if (dri2_sync->base.Type == EGL_SYNC_REUSABLE_KHR)
+ switch (dri2_sync->base.Type) {
+ case EGL_SYNC_REUSABLE_KHR:
cnd_destroy(&dri2_sync->cond);
+ break;
+ case EGL_SYNC_NATIVE_FENCE_ANDROID:
+ if (dri2_sync->base.SyncFd != EGL_NO_NATIVE_FENCE_FD_ANDROID)
+close(dri2_sync->base.SyncFd);
+ break;
+ default:
+ break;
+ }
if (dri2_sync->fence)
dri2_dpy->fence->destroy_fence(dri2_dpy->dri_screen,
dri2_sync->fence);
@@ -2603,6 +2618,19 @@ dri2_create_sync(_EGLDriver *drv, _EGLDisplay *dpy,
/* initial status of reusable sync must be "unsignaled" */
dri2_sync->base.SyncStatus = EGL_UNSIGNALED_KHR;
break;
+
+ case EGL_SYNC_NATIVE_FENCE_ANDROID:
+ if (dri2_dpy->fence->create_fence_fd) {
+ dri2_sync->fence = dri2_dpy->fence->create_fence_fd(
+dri2_ctx->dri_context,
+dri2_sync->base.SyncFd);
+ }
+ if (!dri2_sync->fence) {
+ _eglError(EGL_BAD_ATTRIBUTE, "eglCreateSyncKHR");
+ free(dri2_sync);
+ return NULL;
+ }
+ break;
}
p_atomic_set(&dri2_sync->refcount, 1);
@@ -2632,12 +2660,38 @@ dri2_destroy_sync(_EGLDriver *drv, _EGLDisplay *dpy,
_EGLSync *sync)
ret = EGL_FALSE;
}
}
+
dri2_egl_unref_sync(dri2_dpy, dri2_sync);
return ret;
}
static EGLint
+dri2_dup_native_fence_fd(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSync *sync)
+{
+ struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
+ struct dri2_egl_sync *dri2_sync = dri2_egl_sync(sync);
+
+ assert(sync->Type == EGL_SYNC_NATIVE_FENCE_ANDROID);
+
+ if (sync->SyncFd == EGL_NO_NATIVE_FENCE_FD_ANDROID) {
+ /* try to retrieve the actual native fence fd.. if rendering is
+ * not flushed this will just return -1, aka NO_NATIVE_FENCE_FD:
+ */
+ sync->SyncFd = dri2_dpy->fence->get_fence_fd(dri2_dpy->dri_screen,
+ dri2_sync->fence);
+ }
+
+ if (sync->SyncFd == EGL_NO_NATIVE_FENCE_FD_ANDROID) {
+ /* if native fence fd still not created, return an error: */
+ _eglError(EGL_BAD_PARAMETER, "eglDupNativeFenceFDANDROID");
+ return EGL_NO_NATIVE_FENCE_FD_ANDROID;
+ }
+
+ return dup(sync->SyncFd);
+}
+
+static EGLint
dri2_client_wait_sync(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSync *sync,
EGLint flags, EGLTime timeout)
{
@@ -2667,6 +2721,7 @@ dri2_client_wait_sync(_EGLDriver *drv, _EGLDisplay *dpy,
_EGLSync *sync,
switch (sync->Type) {
case EGL_SYNC_FENCE_KHR:
+ case EGL_SYNC_NATIVE_FENCE_ANDROID:
case EGL_SYNC_CL_EVENT_KHR:
if (dri2_dpy->fence->client_wait_sync(dri2_ctx ? dri2_ctx->dri_context :
NULL,
dri2_sync->fence, wait_flags,
@@ -2922,6 +2977,7 @@ _eglBuiltInDriverDRI2(const char *args)
dri2_drv->base.API.DestroySyncKHR = dri2_destroy_sync;
dri2_drv->base.API.GLInteropQueryDeviceInfo =
dri2_interop_query_device_info;
dri2_drv->base.API.GLInteropExportObject = dri2_interop_export_object;
+ dri2_drv->base.API.DupNativeFenceFDANDROID = dri2_dup_native_fence_fd;
dri2_drv->base.Name = "DRI2";
dri2_drv->base.Unload = dri2_unload;
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 4a44315..a13130f 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
[Mesa-dev] [PATCH 05/10] gallium: wire up server_wait_sync
From: Rob Clark
This will be needed for explicit synchronization with devices outside
the gpu, ie. EGL_ANDROID_native_fence_sync.
Signed-off-by: Rob Clark
Reviewed-by: Marek Olšák
---
src/gallium/include/pipe/p_context.h | 6 ++
src/gallium/state_trackers/dri/dri2.c | 6 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index b97aad5..ee8a511 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -475,6 +475,12 @@ struct pipe_context {
unsigned flags);
/**
+* Insert commands to have GPU wait for fence to be signaled.
+*/
+ void (*fence_server_sync)(struct pipe_context *pipe,
+ struct pipe_fence_handle *fence);
+
+ /**
* Create a view on a texture to be used by a shader stage.
*/
struct pipe_sampler_view * (*create_sampler_view)(struct pipe_context *ctx,
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index 9ec069b..1a44bcb 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1548,7 +1548,11 @@ dri2_client_wait_sync(__DRIcontext *_ctx, void *_fence,
unsigned flags,
static void
dri2_server_wait_sync(__DRIcontext *_ctx, void *_fence, unsigned flags)
{
- /* AFAIK, no driver currently supports parallel context execution. */
+ struct pipe_context *ctx = dri_context(_ctx)->st->pipe;
+ struct dri2_fence *fence = (struct dri2_fence*)_fence;
+
+ if (ctx->fence_server_sync)
+ ctx->fence_server_sync(ctx, fence->pipe_fence);
}
static __DRI2fenceExtension dri2FenceExtension = {
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/10] freedreno: some fence cleanup
Prep-work for next patch, mostly move to tracking last_fence as a
pipe_fence_handle (created now only in fd_gmem_render_tiles()), and a
bit of superficial renaming.
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_batch.c | 2 --
src/gallium/drivers/freedreno/freedreno_batch_cache.c | 4 +---
src/gallium/drivers/freedreno/freedreno_batch_cache.h | 2 +-
src/gallium/drivers/freedreno/freedreno_context.c | 17 ++---
src/gallium/drivers/freedreno/freedreno_context.h | 2 +-
src/gallium/drivers/freedreno/freedreno_fence.c | 7 +++
src/gallium/drivers/freedreno/freedreno_fence.h | 8 +---
src/gallium/drivers/freedreno/freedreno_gmem.c| 4
src/gallium/drivers/freedreno/freedreno_screen.c | 4 ++--
9 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/src/gallium/drivers/freedreno/freedreno_batch.c
b/src/gallium/drivers/freedreno/freedreno_batch.c
index 276f6be..176a31c 100644
--- a/src/gallium/drivers/freedreno/freedreno_batch.c
+++ b/src/gallium/drivers/freedreno/freedreno_batch.c
@@ -234,7 +234,6 @@ batch_flush_func(void *job, int id)
fd_gmem_render_tiles(batch);
batch_reset_resources(batch);
- batch->ctx->last_fence = fd_ringbuffer_timestamp(batch->gmem);
}
static void
@@ -275,7 +274,6 @@ batch_flush(struct fd_batch *batch)
} else {
fd_gmem_render_tiles(batch);
batch_reset_resources(batch);
- batch->ctx->last_fence = fd_ringbuffer_timestamp(batch->gmem);
}
debug_assert(batch->reference.count > 0);
diff --git a/src/gallium/drivers/freedreno/freedreno_batch_cache.c
b/src/gallium/drivers/freedreno/freedreno_batch_cache.c
index df11eab..f3d5078 100644
--- a/src/gallium/drivers/freedreno/freedreno_batch_cache.c
+++ b/src/gallium/drivers/freedreno/freedreno_batch_cache.c
@@ -124,7 +124,7 @@ fd_bc_fini(struct fd_batch_cache *cache)
_mesa_hash_table_destroy(cache->ht, NULL);
}
-uint32_t
+void
fd_bc_flush(struct fd_batch_cache *cache, struct fd_context *ctx)
{
struct hash_entry *entry;
@@ -150,8 +150,6 @@ fd_bc_flush(struct fd_batch_cache *cache, struct fd_context
*ctx)
fd_batch_sync(last_batch);
fd_batch_reference(&last_batch, NULL);
}
-
- return ctx->last_fence;
}
void
diff --git a/src/gallium/drivers/freedreno/freedreno_batch_cache.h
b/src/gallium/drivers/freedreno/freedreno_batch_cache.h
index 1790e5c..44c66b5 100644
--- a/src/gallium/drivers/freedreno/freedreno_batch_cache.h
+++ b/src/gallium/drivers/freedreno/freedreno_batch_cache.h
@@ -62,7 +62,7 @@ struct fd_batch_cache {
void fd_bc_init(struct fd_batch_cache *cache);
void fd_bc_fini(struct fd_batch_cache *cache);
-uint32_t fd_bc_flush(struct fd_batch_cache *cache, struct fd_context *ctx);
+void fd_bc_flush(struct fd_batch_cache *cache, struct fd_context *ctx);
void fd_bc_invalidate_context(struct fd_context *ctx);
void fd_bc_invalidate_batch(struct fd_batch *batch, bool destroy);
diff --git a/src/gallium/drivers/freedreno/freedreno_context.c
b/src/gallium/drivers/freedreno/freedreno_context.c
index 0b12409..70220f8 100644
--- a/src/gallium/drivers/freedreno/freedreno_context.c
+++ b/src/gallium/drivers/freedreno/freedreno_context.c
@@ -43,22 +43,15 @@ fd_context_flush(struct pipe_context *pctx, struct
pipe_fence_handle **fence,
unsigned flags)
{
struct fd_context *ctx = fd_context(pctx);
- uint32_t timestamp;
if (!ctx->screen->reorder) {
- struct fd_batch *batch = NULL;
- fd_batch_reference(&batch, ctx->batch);
- fd_batch_flush(batch, true);
- timestamp = fd_ringbuffer_timestamp(batch->gmem);
- fd_batch_reference(&batch, NULL);
+ fd_batch_flush(ctx->batch, true);
} else {
- timestamp = fd_bc_flush(&ctx->screen->batch_cache, ctx);
+ fd_bc_flush(&ctx->screen->batch_cache, ctx);
}
- if (fence) {
- fd_screen_fence_ref(pctx->screen, fence, NULL);
- *fence = fd_fence_create(pctx, timestamp);
- }
+ if (fence)
+ fd_fence_ref(pctx->screen, fence, ctx->last_fence);
}
/**
@@ -109,6 +102,8 @@ fd_context_destroy(struct pipe_context *pctx)
fd_batch_reference(&ctx->batch, NULL); /* unref current batch */
fd_bc_invalidate_context(ctx);
+ fd_fence_ref(pctx->screen, &ctx->last_fence, NULL);
+
fd_prog_fini(pctx);
fd_hw_query_fini(pctx);
diff --git a/src/gallium/drivers/freedreno/freedreno_context.h
b/src/gallium/drivers/freedreno/freedreno_context.h
index c4c08a6..4a766f5 100644
--- a/src/gallium/drivers/freedreno/freedreno_context.h
+++ b/src/gallium/drivers/freedreno/freedreno_context.h
@@ -164,7 +164,7 @@ struct fd_context {
*/
struct fd_batch *batch;
- uint32_t last_fence;
+ struct pi
[Mesa-dev] [PATCH 06/10] gallium: support for native fence fd's
From: Rob Clark
This enables gallium support for EGL_ANDROID_native_fence_sync, for
drivers which support PIPE_CAP_NATIVE_FENCE_FD.
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_screen.c | 2 +
src/gallium/drivers/i915/i915_screen.c | 1 +
src/gallium/drivers/ilo/ilo_screen.c | 1 +
src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 +
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 +
src/gallium/drivers/r300/r300_screen.c | 1 +
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/radeonsi/si_pipe.c | 1 +
src/gallium/drivers/softpipe/sp_screen.c | 1 +
src/gallium/drivers/svga/svga_screen.c | 1 +
src/gallium/drivers/vc4/vc4_screen.c | 1 +
src/gallium/drivers/virgl/virgl_screen.c | 2 +
src/gallium/include/pipe/p_context.h | 13 ++
src/gallium/include/pipe/p_defines.h | 2 +
src/gallium/include/pipe/p_screen.h | 10 +
src/gallium/state_trackers/dri/dri2.c| 52 +++-
18 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
index 4fe9a36..be1dbfb 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -377,6 +377,8 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
return 10;
case PIPE_CAP_UMA:
return 1;
+ case PIPE_CAP_NATIVE_FENCE_FD:
+ return 0;
}
debug_printf("unknown param %d\n", param);
return 0;
diff --git a/src/gallium/drivers/i915/i915_screen.c
b/src/gallium/drivers/i915/i915_screen.c
index bfadca3..98b6978 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -294,6 +294,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap
cap)
case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
case PIPE_CAP_SAMPLER_VIEW_TARGET:
case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS:
+ case PIPE_CAP_NATIVE_FENCE_FD:
return 0;
case PIPE_CAP_MAX_VIEWPORTS:
diff --git a/src/gallium/drivers/ilo/ilo_screen.c
b/src/gallium/drivers/ilo/ilo_screen.c
index f3f182c..0f9c3d2 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_screen.c
@@ -517,6 +517,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap
param)
case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED:
case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS:
case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
+ case PIPE_CAP_NATIVE_FENCE_FD:
return 0;
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 4b502f0..fd1a91c 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -338,6 +338,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
pipe_cap param)
case PIPE_CAP_MAX_WINDOW_RECTANGLES:
case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED:
case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS:
+ case PIPE_CAP_NATIVE_FENCE_FD:
return 0;
}
/* should only get here on unhandled cases */
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 126c207..422205e 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -203,6 +203,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS:
case PIPE_CAP_MIXED_COLOR_DEPTH_BITS:
case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
+ case PIPE_CAP_NATIVE_FENCE_FD:
return 0;
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 4cf4d2a..56100cb 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -255,6 +255,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED:
case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS:
case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
+ case PIPE_CAP_NATIVE_FENCE_FD:
return 0;
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 68e3ab6..8c70c98 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -274,6 +274,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_PCI_DEVICE:
case PIPE_CAP_PCI_FUNCTION:
case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS:
+ case PIPE_CAP_NATIVE_FENCE_FD:
[Mesa-dev] [PATCH 09/10] freedreno: no-op render when we need a fence
If app tries to create a fence but there is no rendering to submit, we
need a dummy/no-op submit. Use a string-marker for the purpose.. mostly
since it avoids needing to realize that the packet format changes in
later gen's (so one less place to fixup for a5xx).
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_context.c | 11 ++-
src/gallium/drivers/freedreno/freedreno_gmem.c| 35 +++
src/gallium/drivers/freedreno/freedreno_gmem.h| 1 +
3 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/freedreno/freedreno_context.c
b/src/gallium/drivers/freedreno/freedreno_context.c
index 0364507..1128d91 100644
--- a/src/gallium/drivers/freedreno/freedreno_context.c
+++ b/src/gallium/drivers/freedreno/freedreno_context.c
@@ -53,8 +53,17 @@ fd_context_flush(struct pipe_context *pctx, struct
pipe_fence_handle **fence,
fd_bc_flush(&ctx->screen->batch_cache, ctx);
}
- if (fence)
+ if (fence) {
+ /* if there hasn't been any rendering submitted yet, we might
not
+* have actually created a fence
+*/
+ if (!ctx->last_fence || ctx->batch->needs_out_fence_fd) {
+ ctx->batch->needs_flush = true;
+ fd_gmem_render_noop(ctx->batch);
+ fd_batch_reset(ctx->batch);
+ }
fd_fence_ref(pctx->screen, fence, ctx->last_fence);
+ }
}
/**
diff --git a/src/gallium/drivers/freedreno/freedreno_gmem.c
b/src/gallium/drivers/freedreno/freedreno_gmem.c
index 0aacb64..ed1b33a 100644
--- a/src/gallium/drivers/freedreno/freedreno_gmem.c
+++ b/src/gallium/drivers/freedreno/freedreno_gmem.c
@@ -354,6 +354,20 @@ render_sysmem(struct fd_batch *batch)
fd_reset_wfi(batch);
}
+static void
+flush_ring(struct fd_batch *batch)
+{
+ struct fd_context *ctx = batch->ctx;
+ int out_fence_fd = -1;
+
+ fd_ringbuffer_flush2(batch->gmem, batch->in_fence_fd,
+ batch->needs_out_fence_fd ? &out_fence_fd : NULL);
+
+ fd_fence_ref(&ctx->screen->base, &ctx->last_fence, NULL);
+ ctx->last_fence = fd_fence_create(ctx,
+ fd_ringbuffer_timestamp(batch->gmem), out_fence_fd);
+}
+
void
fd_gmem_render_tiles(struct fd_batch *batch)
{
@@ -394,13 +408,22 @@ fd_gmem_render_tiles(struct fd_batch *batch)
ctx->stats.batch_gmem++;
}
- int out_fence_fd = -1;
- fd_ringbuffer_flush2(batch->gmem, batch->in_fence_fd,
- batch->needs_out_fence_fd ? &out_fence_fd : NULL);
+ flush_ring(batch);
+}
- fd_fence_ref(&ctx->screen->base, &ctx->last_fence, NULL);
- ctx->last_fence = fd_fence_create(ctx,
- fd_ringbuffer_timestamp(batch->gmem), out_fence_fd);
+/* special case for when we need to create a fence but have no rendering
+ * to flush.. just emit a no-op string-marker packet.
+ */
+void
+fd_gmem_render_noop(struct fd_batch *batch)
+{
+ struct fd_context *ctx = batch->ctx;
+ struct pipe_context *pctx = &ctx->base;
+
+ pctx->emit_string_marker(pctx, "noop", 4);
+ /* emit IB to drawcmds (which contain the string marker): */
+ ctx->emit_ib(batch->gmem, batch->draw);
+ flush_ring(batch);
}
/* tile needs restore if it isn't completely contained within the
diff --git a/src/gallium/drivers/freedreno/freedreno_gmem.h
b/src/gallium/drivers/freedreno/freedreno_gmem.h
index 116423a..6598ea9 100644
--- a/src/gallium/drivers/freedreno/freedreno_gmem.h
+++ b/src/gallium/drivers/freedreno/freedreno_gmem.h
@@ -62,6 +62,7 @@ struct fd_gmem_stateobj {
struct fd_batch;
void fd_gmem_render_tiles(struct fd_batch *batch);
+void fd_gmem_render_noop(struct fd_batch *batch);
bool fd_gmem_needs_restore(struct fd_batch *batch, struct fd_tile *tile,
uint32_t buffers);
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 10/10] virgl: native fence fd support
From: Gustavo Padovan
---
src/gallium/drivers/virgl/virgl_context.c | 47 +++--
src/gallium/drivers/virgl/virgl_screen.c | 12 +++-
src/gallium/drivers/virgl/virgl_winsys.h | 16 -
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c| 78 +-
src/gallium/winsys/virgl/drm/virgl_drm_winsys.h| 2 +
src/gallium/winsys/virgl/drm/virtgpu_drm.h | 16 -
.../winsys/virgl/vtest/virgl_vtest_winsys.c| 8 ++-
7 files changed, 162 insertions(+), 17 deletions(-)
diff --git a/src/gallium/drivers/virgl/virgl_context.c
b/src/gallium/drivers/virgl/virgl_context.c
index bda9515..66bd4e8 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -21,6 +21,8 @@
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
+
#include "pipe/p_shader_tokens.h"
#include "pipe/p_context.h"
@@ -623,13 +625,20 @@ static void virgl_draw_vbo(struct pipe_context *ctx,
}
-static void virgl_flush_eq(struct virgl_context *ctx, void *closure)
+static void virgl_flush_eq(struct virgl_context *ctx, void *closure,
+ struct pipe_fence_handle **fence)
{
struct virgl_screen *rs = virgl_screen(ctx->base.screen);
+ int out_fence_fd = -1;
/* send the buffer to the remote side for decoding */
ctx->num_transfers = ctx->num_draws = 0;
- rs->vws->submit_cmd(rs->vws, ctx->cbuf);
+
+ rs->vws->submit_cmd(rs->vws, ctx->cbuf, ctx->cbuf->in_fence_fd,
+ ctx->cbuf->needs_out_fence_fd ? &out_fence_fd : NULL);
+
+ if (fence)
+ *fence = rs->vws->cs_create_fence(rs->vws, out_fence_fd);
virgl_encoder_set_sub_ctx(ctx, ctx->hw_sub_ctx_id);
@@ -642,11 +651,10 @@ static void virgl_flush_from_st(struct pipe_context *ctx,
enum pipe_flush_flags flags)
{
struct virgl_context *vctx = virgl_context(ctx);
- struct virgl_screen *rs = virgl_screen(ctx->screen);
struct virgl_buffer *buf, *tmp;
- if (fence)
- *fence = rs->vws->cs_create_fence(rs->vws);
+ if (flags & PIPE_FLUSH_FENCE_FD)
+ vctx->cbuf->needs_out_fence_fd = true;
LIST_FOR_EACH_ENTRY_SAFE(buf, tmp, &vctx->to_flush_bufs, flush_list) {
struct pipe_resource *res = &buf->base.u.b;
@@ -656,7 +664,13 @@ static void virgl_flush_from_st(struct pipe_context *ctx,
pipe_resource_reference(&res, NULL);
}
- virgl_flush_eq(vctx, vctx);
+ virgl_flush_eq(vctx, vctx, fence);
+
+ if (vctx->cbuf->in_fence_fd != -1) {
+ close(vctx->cbuf->in_fence_fd);
+ vctx->cbuf->in_fence_fd = -1;
+ }
+ vctx->cbuf->needs_out_fence_fd = false;
}
static struct pipe_sampler_view *virgl_create_sampler_view(struct pipe_context
*ctx,
@@ -846,6 +860,23 @@ static void virgl_blit(struct pipe_context *ctx,
blit);
}
+static void virgl_create_fence_fd(struct pipe_context *ctx,
+ struct pipe_fence_handle **fence, int fd)
+{
+ struct virgl_screen *rs = virgl_screen(ctx->screen);
+
+ *fence = rs->vws->cs_create_fence(rs->vws, fd);
+}
+
+static void virgl_fence_server_sync(struct pipe_context *ctx,
+ struct pipe_fence_handle *fence)
+{
+ struct virgl_context *vctx = virgl_context(ctx);
+ struct virgl_screen *rs = virgl_screen(ctx->screen);
+
+ rs->vws->fence_server_sync(rs->vws, vctx->cbuf, fence);
+}
+
static void
virgl_context_destroy( struct pipe_context *ctx )
{
@@ -855,7 +886,7 @@ virgl_context_destroy( struct pipe_context *ctx )
vctx->framebuffer.zsbuf = NULL;
vctx->framebuffer.nr_cbufs = 0;
virgl_encoder_destroy_sub_ctx(vctx, vctx->hw_sub_ctx_id);
- virgl_flush_eq(vctx, vctx);
+ virgl_flush_eq(vctx, vctx, NULL);
rs->vws->cmd_buf_destroy(vctx->cbuf);
if (vctx->uploader)
@@ -937,6 +968,8 @@ struct pipe_context *virgl_context_create(struct
pipe_screen *pscreen,
vctx->base.resource_copy_region = virgl_resource_copy_region;
vctx->base.flush_resource = virgl_flush_resource;
vctx->base.blit = virgl_blit;
+ vctx->base.create_fence_fd = virgl_create_fence_fd;
+ vctx->base.fence_server_sync = virgl_fence_server_sync;
virgl_init_context_resource_functions(&vctx->base);
virgl_init_query_functions(vctx);
diff --git a/src/gallium/drivers/virgl/virgl_screen.c
b/src/gallium/drivers/virgl/virgl_screen.c
index 0edaa22..aa8a336 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -261,7 +261,7 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap
param)
case PIPE_CAP_VIDEO_MEMORY:
return 0;
case PIPE_CAP_NATIVE_FENCE_FD:
- return 0;
+ return vscreen->vws->driver_version(vscreen->vws) >= 1;
}
/* should only get here on unhandled cases */
debug_printf("Unexpected PIPE_CAP %d query\n", param);
@@ -540,6 +540,15 @@ static boolean virgl_fence_finish(struct pipe_screen
*screen,
return vws->fence_wait(v
[Mesa-dev] [PATCH 08/10] freedreno: native fence fd support
Requires newer libdrm, and the support only is advertised with a
sufficiently new kernel (v4.9 and later) as it depends on fence fd
support in the submit ioctl.
Signed-off-by: Rob Clark
---
configure.ac | 2 +-
src/gallium/drivers/freedreno/freedreno_batch.c | 5 +++
src/gallium/drivers/freedreno/freedreno_batch.h | 3 ++
src/gallium/drivers/freedreno/freedreno_context.c | 5 +++
src/gallium/drivers/freedreno/freedreno_fence.c | 46 +--
src/gallium/drivers/freedreno/freedreno_fence.h | 8 +++-
src/gallium/drivers/freedreno/freedreno_gmem.c| 7 +++-
src/gallium/drivers/freedreno/freedreno_screen.c | 3 +-
8 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5f30ae8..ec5bf43 100644
--- a/configure.ac
+++ b/configure.ac
@@ -74,7 +74,7 @@ LIBDRM_AMDGPU_REQUIRED=2.4.63
LIBDRM_INTEL_REQUIRED=2.4.61
LIBDRM_NVVIEUX_REQUIRED=2.4.66
LIBDRM_NOUVEAU_REQUIRED=2.4.66
-LIBDRM_FREEDRENO_REQUIRED=2.4.68
+LIBDRM_FREEDRENO_REQUIRED=2.4.72
LIBDRM_VC4_REQUIRED=2.4.69
DRI2PROTO_REQUIRED=2.6
DRI3PROTO_REQUIRED=1.0
diff --git a/src/gallium/drivers/freedreno/freedreno_batch.c
b/src/gallium/drivers/freedreno/freedreno_batch.c
index 176a31c..f7b8201 100644
--- a/src/gallium/drivers/freedreno/freedreno_batch.c
+++ b/src/gallium/drivers/freedreno/freedreno_batch.c
@@ -60,6 +60,8 @@ batch_init(struct fd_batch *batch)
fd_ringbuffer_set_parent(batch->draw, batch->gmem);
fd_ringbuffer_set_parent(batch->binning, batch->gmem);
+ batch->in_fence_fd = -1;
+
batch->cleared = batch->partial_cleared = 0;
batch->restore = batch->resolve = 0;
batch->needs_flush = false;
@@ -109,6 +111,9 @@ batch_fini(struct fd_batch *batch)
{
pipe_resource_reference(&batch->query_buf, NULL);
+ if (batch->in_fence_fd != -1)
+ close(batch->in_fence_fd);
+
fd_ringbuffer_del(batch->draw);
fd_ringbuffer_del(batch->binning);
fd_ringbuffer_del(batch->gmem);
diff --git a/src/gallium/drivers/freedreno/freedreno_batch.h
b/src/gallium/drivers/freedreno/freedreno_batch.h
index aeeb9c5..289f36e 100644
--- a/src/gallium/drivers/freedreno/freedreno_batch.h
+++ b/src/gallium/drivers/freedreno/freedreno_batch.h
@@ -68,6 +68,9 @@ struct fd_batch {
unsigned seqno;
unsigned idx;
+ int in_fence_fd;
+ bool needs_out_fence_fd;
+
struct fd_context *ctx;
struct util_queue_fence flush_fence;
diff --git a/src/gallium/drivers/freedreno/freedreno_context.c
b/src/gallium/drivers/freedreno/freedreno_context.c
index 70220f8..0364507 100644
--- a/src/gallium/drivers/freedreno/freedreno_context.c
+++ b/src/gallium/drivers/freedreno/freedreno_context.c
@@ -44,6 +44,9 @@ fd_context_flush(struct pipe_context *pctx, struct
pipe_fence_handle **fence,
{
struct fd_context *ctx = fd_context(pctx);
+ if (flags & PIPE_FLUSH_FENCE_FD)
+ ctx->batch->needs_out_fence_fd = true;
+
if (!ctx->screen->reorder) {
fd_batch_flush(ctx->batch, true);
} else {
@@ -251,6 +254,8 @@ fd_context_init(struct fd_context *ctx, struct pipe_screen
*pscreen,
pctx->flush = fd_context_flush;
pctx->emit_string_marker = fd_emit_string_marker;
pctx->set_debug_callback = fd_set_debug_callback;
+ pctx->create_fence_fd = fd_create_fence_fd;
+ pctx->fence_server_sync = fd_fence_server_sync;
/* TODO what about compute? Ideally it creates it's own independent
* batches per compute job (since it isn't using tiling, so no point
diff --git a/src/gallium/drivers/freedreno/freedreno_fence.c
b/src/gallium/drivers/freedreno/freedreno_fence.c
index a5f7171..f20c6ac 100644
--- a/src/gallium/drivers/freedreno/freedreno_fence.c
+++ b/src/gallium/drivers/freedreno/freedreno_fence.c
@@ -26,6 +26,8 @@
*Rob Clark
*/
+#include
+
#include "util/u_inlines.h"
#include "freedreno_fence.h"
@@ -36,16 +38,23 @@ struct pipe_fence_handle {
struct pipe_reference reference;
struct fd_context *ctx;
struct fd_screen *screen;
+ int fence_fd;
uint32_t timestamp;
};
-void
-fd_fence_ref(struct pipe_screen *pscreen,
+static void fd_fence_destroy(struct pipe_fence_handle *fence)
+{
+ if (fence->fence_fd != -1)
+ close(fence->fence_fd);
+ FREE(fence);
+}
+
+void fd_fence_ref(struct pipe_screen *pscreen,
struct pipe_fence_handle **ptr,
struct pipe_fence_handle *pfence)
{
if (pipe_reference(&(*ptr)->reference, &pfence->reference))
- FREE(*ptr);
+ fd_fence_destroy(*ptr);
*ptr = pfence;
}
@@ -55,14 +64,42 @@ boolean fd_fence_finish(struct pipe_screen *pscreen,
struct pipe_fence_handle *fence,
uint64_t timeout)
{
+ if (fence->fence_fd != -1) {
+ int ret = sync_wait(fence-
Re: [Mesa-dev] UDL & Modeset with Mesa 13.0.1 - Segmentation fault
On 17 November 2016 at 20:15, poma wrote: > > Airlie solved everything concerning the kernel, > so it seems, now it's user space turn. > > = mesa-libgbm-12.0.3 - works OK > ... > [ 714.429] (II) Loading sub module "glamoregl" > [ 714.429] (II) LoadModule: "glamoregl" > [ 714.430] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so > [ 714.480] (II) Module glamoregl: vendor="X.Org Foundation" > [ 714.481]compiled for 1.19.0, module version = 1.0.0 > [ 714.481]ABI class: X.Org ANSI C Emulation, version 0.4 > ... > [ 714.481] (II) glamor: OpenGL accelerated X.org driver based. > [ 714.633] (II) glamor: EGL version 1.4 (DRI2): > [ 714.633] EGL_MESA_drm_image required. > [ 714.634] (EE) modeset(0): glamor initialization failed > [ 714.634] (II) modeset(0): ShadowFB: preferred NO, enabled NO > ... > [ 714.643] (==) Depth 24 pixmap format is 32 bpp > [ 714.645] (==) modeset(0): Backing store enabled > [ 714.645] (==) modeset(0): Silken mouse enabled > [ 714.645] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR > disabled message. > [ 714.646] (==) modeset(0): DPMS enabled > [ 714.646] (--) RandR disabled > [ 714.669] (II) AIGLX: Screen 0 is not DRI2 capable > [ 714.669] (EE) AIGLX: reverting to software rendering > [ 714.683] (II) IGLX: enabled GLX_MESA_copy_sub_buffer > [ 714.686] (II) IGLX: Loaded and initialized swrast > [ 714.686] (II) GLX: Initialized DRISWRAST GL provider for screen 0 > [ 714.691] (II) modeset(0): Damage tracking initialized > ... > > = mesa-libgbm-13.0.1 - not quite > ... > [ 2324.953] (II) Loading sub module "glamoregl" > [ 2324.953] (II) LoadModule: "glamoregl" > [ 2324.953] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so > [ 2325.000] (II) Module glamoregl: vendor="X.Org Foundation" > [ 2325.000]compiled for 1.19.0, module version = 1.0.0 > [ 2325.000]ABI class: X.Org ANSI C Emulation, version 0.4 > ... > [ 2325.001] (II) glamor: OpenGL accelerated X.org driver based. > [ 2325.002] (EE) > [ 2325.002] (EE) Backtrace: > [ 2325.006] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x59e389] > [ 2325.008] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) > [0x7f69d836ac2f] > [ 2325.009] (EE) 2: /lib64/libgbm.so.1 (gbm_surface_has_free_buffers+0x1505) > [0x7f69d2b64685] > [ 2325.010] (EE) 3: /lib64/libgbm.so.1 (gbm_surface_has_free_buffers+0x1b98) > [0x7f69d2b653b8] > [ 2325.011] (EE) 4: /lib64/libgbm.so.1 (gbm_surface_has_free_buffers+0x1498) > [0x7f69d2b644c8] > [ 2325.012] (EE) 5: /lib64/libgbm.so.1 (gbm_create_device+0x4c) > [0x7f69d2b61a4c] > [ 2325.014] (EE) 6: /usr/lib64/xorg/modules/libglamoregl.so > (glamor_egl_init+0x83) [0x7f69d2d73fb3] > [ 2325.015] (EE) 7: /usr/lib64/xorg/modules/drivers/modesetting_drv.so > (_init+0x4d21) [0x7f69d2facfd1] > [ 2325.016] (EE) 8: /usr/libexec/Xorg (InitOutput+0xa82) [0x47d6c2] > [ 2325.017] (EE) 9: /usr/libexec/Xorg (InitFonts+0x216) [0x43ae36] > [ 2325.020] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf1) > [0x7f69d7fb8731] > [ 2325.022] (EE) 11: /usr/libexec/Xorg (_start+0x29) [0x424d29] > [ 2325.024] (EE) 12: ? (?+0x29) [0x29] > [ 2325.025] (EE) > [ 2325.025] (EE) Segmentation fault at address 0xc > [ 2325.025] (EE) > Fatal server error: > [ 2325.025] (EE) Caught signal 11 (Segmentation fault). Server aborting > [ 2325.026] (EE) > [ 2325.026] (EE) > ... > [ 2325.027] (EE) Server terminated with error (1). Closing log file. > > > A call to not load the module(s) is not at all useful: > Section "Module" > Disable "glx" > Disable "glamoregl" > EndSection > > ... > (WW) "glx" will not be loaded unless you've specified it to be loaded > elsewhere. > (WW) "glamoregl" will not be loaded unless you've specified it to be loaded > elsewhere. > (II) "glx" will be loaded even though the default is to disable it. > ... > (II) Loading sub module "glamoregl" > (II) LoadModule: "glamoregl" > (II) Loading /usr/lib64/xorg/modules/libglamoregl.so > (II) Module glamoregl: vendor="X.Org Foundation" > compiled for 1.19.0, module version = 1.0.0 > ABI class: X.Org ANSI C Emulation, version 0.4 > (II) glamor: OpenGL accelerated X.org driver based. > (EE) > (EE) Backtrace: > ... > > Therefore, until the issue resolved, there remain two workarounds: > downgrade mesa to 12.0.3, what works > OR > leave mesa 13.0.1 and: > # rm /usr/lib64/xorg/modules/libglamoregl.so > Is that with libdrm 2.4.72 or later ? Older ones are known to be broken with non-pci devices. Additionally ensure that your pthread-stubs package does _not_ have the following commit/patch [1]. Thanks Emil [1] https://cgit.freedesktop.org/xcb/pthread-stubs/commit/?id=fa6db2f9c018c54a47e94c0175450303d700aa92 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/13] anv/pipeline: Move gather_info further down the compilation process
On Thu, 2016-11-17 at 08:56 -0800, Jason Ekstrand wrote: > On Thu, Nov 17, 2016 at 4:43 AM, Iago Toral > wrote: > > Ah, I had missed this, ignore my comment then :) > > > I just sent out a v2 of patch 7 and force-pushed my review branch if > you want to test things out. Yep, that fixes the problems. Thanks! Iago > > On Wed, 2016-11-16 at 21:18 -0800, Jason Ekstrand wrote: > > > Forget this patch. It's bogus. The computation of prog_data- > > > >nr_params requires gathered info so the earliest we could put it > > > is at the top of this function. Instead, we'll just call > > > anv_nir_lower_input_attachments earlier. > > > > > > On Wed, Nov 16, 2016 at 11:31 AM, Jason Ekstrand > > d.net> wrote: > > > > The lower_input_attachments pass that we're about to add will > > > > generate > > > > additional uses of system values and we want those to be > > > > reflected in > > > > gather_info. > > > > --- > > > > src/intel/vulkan/anv_pipeline.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/src/intel/vulkan/anv_pipeline.c > > > > b/src/intel/vulkan/anv_pipeline.c > > > > index bdac404..c251463 100644 > > > > --- a/src/intel/vulkan/anv_pipeline.c > > > > +++ b/src/intel/vulkan/anv_pipeline.c > > > > @@ -166,8 +166,6 @@ anv_shader_compile_to_nir(struct anv_device > > > > *device, > > > > > > > > nir = brw_preprocess_nir(compiler, nir); > > > > > > > > - nir_shader_gather_info(nir, entry_point->impl); > > > > - > > > > nir_variable_mode indirect_mask = 0; > > > > if (compiler- > > > > >glsl_compiler_options[stage].EmitNoIndirectInput) > > > > indirect_mask |= nir_var_shader_in; > > > > @@ -369,6 +367,8 @@ anv_pipeline_compile(struct anv_pipeline > > > > *pipeline, > > > > */ > > > > nir->num_uniforms = prog_data->nr_params * 4; > > > > > > > > + nir_shader_gather_info(nir, > > > > nir_shader_get_entrypoint(nir)); > > > > + > > > > return nir; > > > > } > > > > > > > > -- > > > > 2.5.0.400.gff86faf > > > > > > > > > > > ___ > > > mesa-dev mailing list > > > mesa-dev@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] implement EGL_EXT_image_dma_buf_import_modifiers
[Pardon for dropping in uninvited] On 15 November 2016 at 18:04, Marek Olšák wrote: > Immutable metadata (modifiers) stored in the kernel is the only > scalable (and thus usable) solution here. There was an argument > against _mutable_ metadata attached to BOs and the synchronization > hell it can cause, but I've not seen any argument against _immutable_ > metadata. Trying to push the metadata (modifiers) through window > system protocols seems like a horrible idea to me, not just because of > that fact that window system protocols shouldn't care about > driver-specific stuff, but also because of the immense burden once you > realize that you have to fix all window system protocols and KMS apps > because 64 bits of metadata is not enough to support your hardware. > It's clearly not economically sustainable. > Wasn't this one of the things that were [supposed to be] discussed at XDC as part of the gbm2/liballoc ? Not too sure on the topic, so a simple yes/no would be appreciated. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/13] egl: update eglext.h
On 15 November 2016 at 14:24, Varad Gautam wrote: > +#ifndef EGL_MESA_platform_surfaceless > +#define EGL_MESA_platform_surfaceless 1 > +#define EGL_PLATFORM_SURFACELESS_MESA 0x31DD > +#endif /* EGL_MESA_platform_surfaceless */ > + Thinking out loud: is dropping the similar hunk from include/EGL/eglmesaext.h a wise move ? Either way - not something that should be addressed here/now. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/13] egl/main: add support for fourth plane tokens
On 15 November 2016 at 14:24, Varad Gautam wrote:
> From: Pekka Paalanen
>
> The EGL_EXT_dma_buf_import_modifiers extension adds support for a
> fourth plane, just like DRM KMS API does.
>
> Bump maximum dma_buf plane count to four.
>
> Signed-off-by: Pekka Paalanen
> Signed-off-by: Varad Gautam
> ---
> src/egl/drivers/dri2/egl_dri2.c | 2 +-
> src/egl/main/eglimage.c | 12
> src/egl/main/eglimage.h | 2 +-
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 9a41ad0..58d16e1 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -2038,7 +2038,7 @@ dri2_check_dma_buf_format(const _EGLImageAttribs *attrs)
> * "If is EGL_LINUX_DMA_BUF_EXT, and the EGL_LINUX_DRM_FOURCC_EXT
> * attribute indicates a single-plane format, EGL_BAD_ATTRIBUTE is
> * generated if any of the EGL_DMA_BUF_PLANE1_* or EGL_DMA_BUF_PLANE2_*
> -* attributes are specified."
> +* or EGL_DMA_BUF_PLANE3_* attributes are specified."
> */
> for (i = plane_n; i < DMA_BUF_MAX_PLANES; ++i) {
>if (attrs->DMABufPlaneFds[i].IsPresent ||
> diff --git a/src/egl/main/eglimage.c b/src/egl/main/eglimage.c
> index 411d1ca..cd170c6 100644
> --- a/src/egl/main/eglimage.c
> +++ b/src/egl/main/eglimage.c
> @@ -133,6 +133,18 @@ _eglParseImageAttribList(_EGLImageAttribs *attrs,
> _EGLDisplay *dpy,
> attrs->DMABufPlanePitches[2].Value = val;
> attrs->DMABufPlanePitches[2].IsPresent = EGL_TRUE;
> break;
> + case EGL_DMA_BUF_PLANE3_FD_EXT:
> + attrs->DMABufPlaneFds[3].Value = val;
> + attrs->DMABufPlaneFds[3].IsPresent = EGL_TRUE;
> + break;
> + case EGL_DMA_BUF_PLANE3_OFFSET_EXT:
> + attrs->DMABufPlaneOffsets[3].Value = val;
> + attrs->DMABufPlaneOffsets[3].IsPresent = EGL_TRUE;
> + break;
> + case EGL_DMA_BUF_PLANE3_PITCH_EXT:
> + attrs->DMABufPlanePitches[3].Value = val;
> + attrs->DMABufPlanePitches[3].IsPresent = EGL_TRUE;
> + break;
These should be within an extension guard. Otherwise we'll parse them
(and try to push down) even if we don't support them.
Something line the following should do it. Either squashed here or
separate patch is fine.
src/egl/main/egldisplay.h
+ EGLBoolean EGL_EXT_dma_buf_import_modifiers;
src/egl/main/eglapi.c
+ _EGL_CHECK_EXTENSION(EGL_EXT_dma_buf_import_modifiers);
src/egl/main/eglimage.h
- /* EGL_EXT_image_dma_buf_import */
+ /* EGL_EXT_image_dma_buf_import and EGL_EXT_dma_buf_import_modifiers */
src/egl/main/eglimage.c
+ case EGL_DMA_BUF_PLANE3_FD_EXT:
+ if (!disp->Extensions.EXT_dma_buf_import_modifiers) {
+ err = EGL_BAD_ATTRIBUTE;
+ break;
+ }
+ attrs->DMABufPlaneFds[3].Value = val;
+ attrs->DMABufPlaneFds[3].IsPresent = EGL_TRUE;
+ break;
and same for OFFSET and PITCH.
IMHO we want to keep the new code relatively bug free, so it's better
to address those irrespective of the bugs/extra work mentioned below.
Afaict none of the existing attribs honour their respective extension
(bool). Some of them are kind of ok like EGL_EXT_image_dma_buf_import
were we don't have the API/vfunc so even if we parse the values we
cannot push them further down. Either way correct extensions' attrib
parsing can be addressed, as independent work at a later point in
time.
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/10] freedreno: native fence fd support
On Fri, Nov 18, 2016 at 08:39:37AM -0500, Rob Clark wrote:
> +void fd_fence_server_sync(struct pipe_context *pctx,
> + struct pipe_fence_handle *fence)
> +{
> + struct fd_context *ctx = fd_context(pctx);
> + struct fd_batch *batch = ctx->batch;
> +
> + if (sync_accumulate("freedreno", &batch->in_fence_fd, fence->fence_fd))
> {
> + /* error */
On error, the choice is either to cause corruption or convert it into a
CPU (client) wait. I would suggest:
perf_debug("Failed to add fence to command stream,"
" stalling in the client instead!\n");
sync_wait(fence->fence_fd, -1);
> + }
> +}
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/13] st/dri: implement DRIimage creation from dmabufs with modifiers
On 15 November 2016 at 14:24, Varad Gautam wrote: > From: Varad Gautam > > support importing dmabufs into DRIimage taking format modifiers in > account, as per DRIimage extension version 14. > With the following discussion in mind [1] I'm wondering if we don't want to rework things to pass/store a single modifier. I'm leaning that implementation good as-is. One small catch though - we would need a check at the EGL API level to check if the modifier provided is identical across the board. -Emil [1] https://lists.freedesktop.org/archives/dri-devel/2016-November/123922.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/10] freedreno: native fence fd support
On Fri, Nov 18, 2016 at 9:20 AM, Chris Wilson wrote:
> On Fri, Nov 18, 2016 at 08:39:37AM -0500, Rob Clark wrote:
>> +void fd_fence_server_sync(struct pipe_context *pctx,
>> + struct pipe_fence_handle *fence)
>> +{
>> + struct fd_context *ctx = fd_context(pctx);
>> + struct fd_batch *batch = ctx->batch;
>> +
>> + if (sync_accumulate("freedreno", &batch->in_fence_fd,
>> fence->fence_fd)) {
>> + /* error */
>
> On error, the choice is either to cause corruption or convert it into a
> CPU (client) wait. I would suggest:
> perf_debug("Failed to add fence to command stream,"
>" stalling in the client instead!\n");
> sync_wait(fence->fence_fd, -1);
hmm, that is a good idea.. I was wondering what to do in case of error
since there isn't currently (without changing dri fence extension,
iirc) a way to propagate that back to the user. I was assuming
corruption would be the best we could do (and anyways, if you hit this
case, it is likely that a lot of other things are going to be going
badly..)
BR,
-R
>> + }
>> +}
>
> --
> Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl_dri2: add support for using modifier attributes in eglCreateImageKHR
On 16 November 2016 at 09:28, Varad Gautam wrote:
> From: Pekka Paalanen
>
> allow creating EGLImages with dmabuf format modifiers when target is
> EGL_LINUX_DMA_BUF_EXT for EGL_EXT_image_dma_buf_import_modifiers.
>
> v2: clear modifier assembling and error label name (Eric Engestrom)
>
> Signed-off-by: Pekka Paalanen
> Signed-off-by: Varad Gautam
> Reviewed-by: Eric Engestrom
> ---
> + int nonzero_modifier_found = 0;
> unsigned error;
>
> /**
> @@ -2106,18 +2125,44 @@ dri2_create_image_dma_buf(_EGLDisplay *disp,
> _EGLContext *ctx,
>fds[i] = attrs.DMABufPlaneFds[i].Value;
>pitches[i] = attrs.DMABufPlanePitches[i].Value;
>offsets[i] = attrs.DMABufPlaneOffsets[i].Value;
> + if (attrs.DMABufPlaneModifiersLo[i].IsPresent) {
> + modifiers[i] = (attrs.DMABufPlaneModifiersHi[i].Value << 32) |
> +attrs.DMABufPlaneModifiersLo[i].Value;
> + if (modifiers[i] != 0)
> +nonzero_modifier_found = EGL_TRUE;
integer storage and EGL_TRUE -> bool and true/false ?
> + if (nonzero_modifier_found && dri2_dpy->image->createImageFromDmaBufs2) {
> + dri_image =
> + dri2_dpy->image->createImageFromDmaBufs2(dri2_dpy->dri_screen,
> +attrs.Width, attrs.Height, attrs.DMABufFourCC.Value,
> +fds, num_fds, pitches, offsets, modifiers,
> +attrs.DMABufYuvColorSpaceHint.Value,
> +attrs.DMABufSampleRangeHint.Value,
> +attrs.DMABufChromaHorizontalSiting.Value,
> +attrs.DMABufChromaVerticalSiting.Value,
> +&error,
> +NULL);
> + } else {
> + if (nonzero_modifier_found) {
> + _eglError(EGL_BAD_MATCH, "unsupported dma_buf format modifier");
> + return EGL_NO_IMAGE_KHR;
> + }
> +
Using something like the following might be better?
if (nonzero_modifier_found) {
if (!dri2_dpy->image->createImageFromDmaBufs2)
# assert should never reach here, since the extension should be
advertised only if the API is available.
use new API
else
use old API
> + case EGL_DMA_BUF_PLANE3_MODIFIER_LO_EXT:
> + if (!dpy->Extensions.EXT_image_dma_buf_import_modifiers)
> +goto bad_param;
> + attrs->DMABufPlaneModifiersLo[3].Value = val;
> + attrs->DMABufPlaneModifiersLo[3].IsPresent = EGL_TRUE;
> + break;
> + case EGL_DMA_BUF_PLANE3_MODIFIER_HI_EXT:
> + if (!dpy->Extensions.EXT_image_dma_buf_import_modifiers)
> +goto bad_param;
> + attrs->DMABufPlaneModifiersHi[3].Value = val;
> + attrs->DMABufPlaneModifiersHi[3].IsPresent = EGL_TRUE;
> + break;
>case EGL_YUV_COLOR_SPACE_HINT_EXT:
> if (val != EGL_ITU_REC601_EXT && val != EGL_ITU_REC709_EXT &&
> val != EGL_ITU_REC2020_EXT) {
> @@ -181,6 +229,7 @@ _eglParseImageAttribList(_EGLImageAttribs *attrs,
> _EGLDisplay *dpy,
> }
> break;
>
> +bad_param:
Using goto to jump to another case statement is "evil". Please don't use them.
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/13] egl: implement eglQueryDmaBufFormatsEXT
On 15 November 2016 at 14:24, Varad Gautam wrote:
> From: Varad Gautam
>
> allow egl clients to query the dmabuf formats supported on this platform.
>
> Signed-off-by: Louis-Francis Ratté-Boulianne
> Signed-off-by: Varad Gautam
> ---
> src/egl/drivers/dri2/egl_dri2.c | 87
> +
> src/egl/main/eglapi.c | 19 +
> src/egl/main/eglapi.h | 4 ++
> 3 files changed, 110 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 4eb1861..de2d4df 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -78,6 +78,68 @@ const __DRIuseInvalidateExtension use_invalidate = {
> .base = { __DRI_USE_INVALIDATE, 1 }
> };
>
> +static const EGLint dma_buf_formats[] = {
> + DRM_FORMAT_R8,
> + DRM_FORMAT_RG88,
> + DRM_FORMAT_GR88,
> + DRM_FORMAT_RGB332,
> + DRM_FORMAT_BGR233,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_RGBX,
> + DRM_FORMAT_BGRX,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_RGBA,
> + DRM_FORMAT_BGRA,
> + DRM_FORMAT_XRGB1555,
> + DRM_FORMAT_XBGR1555,
> + DRM_FORMAT_RGBX5551,
> + DRM_FORMAT_BGRX5551,
> + DRM_FORMAT_ARGB1555,
> + DRM_FORMAT_ABGR1555,
> + DRM_FORMAT_RGBA5551,
> + DRM_FORMAT_BGRA5551,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGR888,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_RGBX,
> + DRM_FORMAT_BGRX,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_RGBA,
> + DRM_FORMAT_BGRA,
> + DRM_FORMAT_XRGB2101010,
> + DRM_FORMAT_XBGR2101010,
> + DRM_FORMAT_RGBX1010102,
> + DRM_FORMAT_BGRX1010102,
> + DRM_FORMAT_ARGB2101010,
> + DRM_FORMAT_ABGR2101010,
> + DRM_FORMAT_RGBA1010102,
> + DRM_FORMAT_BGRA1010102,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_YVYU,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_VYUY,
> + DRM_FORMAT_NV12,
> + DRM_FORMAT_NV21,
> + DRM_FORMAT_NV16,
> + DRM_FORMAT_NV61,
> + DRM_FORMAT_YUV410,
> + DRM_FORMAT_YVU410,
> + DRM_FORMAT_YUV411,
> + DRM_FORMAT_YVU411,
> + DRM_FORMAT_YUV420,
> + DRM_FORMAT_YVU420,
> + DRM_FORMAT_YUV422,
> + DRM_FORMAT_YVU422,
> + DRM_FORMAT_YUV444,
> + DRM_FORMAT_YVU444
> +};
> +
> EGLint dri2_to_egl_attribute_map[] = {
> 0,
> EGL_BUFFER_SIZE,/* __DRI_ATTRIB_BUFFER_SIZE */
> @@ -2069,6 +2131,30 @@ dri2_check_dma_buf_format(const _EGLImageAttribs
> *attrs)
> return plane_n;
> }
>
> +static EGLBoolean
> +dri2_query_dma_buf_formats(_EGLDriver *drv, _EGLDisplay *disp,
> +EGLint max, EGLint *formats, EGLint *count)
> +{
> + EGLint i;
> +
> + if (max < 0 || (max > 0 && formats == NULL)) {
> + _eglError(EGL_BAD_PARAMETER, "invalid value for max count of formats");
> + return EGL_FALSE;
> + }
> +
> + if (max == 0) {
> + *count = ARRAY_SIZE(dma_buf_formats);
> + return EGL_TRUE;
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(dma_buf_formats) && i < max; i++) {
> + formats[i] = dma_buf_formats[i];
> + }
Returning every format imaginable as supported then most drivers
(currently) support up-to half of them is very misleading.
Worth adding another DRIimage callback, reuse existing one(s) and/or
add some other heuristics ?
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl_dri2: add support for using modifier attributes in eglCreateImageKHR
Hi,
On 18 November 2016 at 14:50, Emil Velikov wrote:
> On 16 November 2016 at 09:28, Varad Gautam wrote:
>> + if (nonzero_modifier_found && dri2_dpy->image->createImageFromDmaBufs2) {
>> + dri_image =
>> + dri2_dpy->image->createImageFromDmaBufs2(dri2_dpy->dri_screen,
>> +attrs.Width, attrs.Height, attrs.DMABufFourCC.Value,
>> +fds, num_fds, pitches, offsets, modifiers,
>> +attrs.DMABufYuvColorSpaceHint.Value,
>> +attrs.DMABufSampleRangeHint.Value,
>> +attrs.DMABufChromaHorizontalSiting.Value,
>> +attrs.DMABufChromaVerticalSiting.Value,
>> +&error,
>> +NULL);
>> + } else {
>> + if (nonzero_modifier_found) {
>> + _eglError(EGL_BAD_MATCH, "unsupported dma_buf format modifier");
>> + return EGL_NO_IMAGE_KHR;
>> + }
>> +
> Using something like the following might be better?
>
> if (nonzero_modifier_found) {
>if (!dri2_dpy->image->createImageFromDmaBufs2)
> # assert should never reach here, since the extension should be
> advertised only if the API is available.
>use new API
> else
>use old API
Actually, present-and-zero modifier has a very well-defined meaning:
it _forces_ linear interpretation of the buffer, whereas a non-present
modifier may cause a kernel query (e.g. i915_gem_get_tiling) to
discover a hidden tiling mode. So, if present, the modifier should be
passed.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: invert order for wayland-scanner check
Hi Gustavo, On 17 November 2016 at 18:57, Gustavo Zacarias wrote: > When cross-compiling the .pc file might point to the wrong > wayland-scanner binary (target rather than host) resulting in a > non-executable and wrong scanner. > Try searching the PATH first, and if that fails fall back into > pkg-config. > Not sure I exactly follow what's happening there. As we cross-compile wayland - the wayland-scanner binary (and thus .pc) should follow --build arch/triplet - the wayland libraries the host/target ones. Are you saying that despite the different arch/triplet everything is installed in the same place ? I'm not a cross-compilation expert but the latter doesn't sound right. There was a related discussion on the wayland mailing list, but I'm not sure the proposed solution (there) is correct either. Thanks Emil [1] https://lists.freedesktop.org/archives/wayland-devel/2016-September/031073.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl_dri2: add support for using modifier attributes in eglCreateImageKHR
On 18 November 2016 at 15:17, Daniel Stone wrote:
> Hi,
>
> On 18 November 2016 at 14:50, Emil Velikov wrote:
>> On 16 November 2016 at 09:28, Varad Gautam wrote:
>>> + if (nonzero_modifier_found && dri2_dpy->image->createImageFromDmaBufs2)
>>> {
>>> + dri_image =
>>> + dri2_dpy->image->createImageFromDmaBufs2(dri2_dpy->dri_screen,
>>> +attrs.Width, attrs.Height, attrs.DMABufFourCC.Value,
>>> +fds, num_fds, pitches, offsets, modifiers,
>>> +attrs.DMABufYuvColorSpaceHint.Value,
>>> +attrs.DMABufSampleRangeHint.Value,
>>> +attrs.DMABufChromaHorizontalSiting.Value,
>>> +attrs.DMABufChromaVerticalSiting.Value,
>>> +&error,
>>> +NULL);
>>> + } else {
>>> + if (nonzero_modifier_found) {
>>> + _eglError(EGL_BAD_MATCH, "unsupported dma_buf format modifier");
>>> + return EGL_NO_IMAGE_KHR;
>>> + }
>>> +
>> Using something like the following might be better?
>>
>> if (nonzero_modifier_found) {
>>if (!dri2_dpy->image->createImageFromDmaBufs2)
>> # assert should never reach here, since the extension should be
>> advertised only if the API is available.
>>use new API
>> else
>>use old API
>
> Actually, present-and-zero modifier has a very well-defined meaning:
> it _forces_ linear interpretation of the buffer, whereas a non-present
> modifier may cause a kernel query (e.g. i915_gem_get_tiling) to
> discover a hidden tiling mode. So, if present, the modifier should be
> passed.
>
You are suggesting that we should track "has_modifier" (as opposed to
nonzero_modifier_found) and pass it to DmaBuf2 regardless of the
contents, right ?
Just double-checking.
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] implement EGL_EXT_image_dma_buf_import_modifiers
On Nov 18, 2016 2:55 PM, "Emil Velikov" wrote: > > [Pardon for dropping in uninvited] > > On 15 November 2016 at 18:04, Marek Olšák wrote: > > > Immutable metadata (modifiers) stored in the kernel is the only > > scalable (and thus usable) solution here. There was an argument > > against _mutable_ metadata attached to BOs and the synchronization > > hell it can cause, but I've not seen any argument against _immutable_ > > metadata. Trying to push the metadata (modifiers) through window > > system protocols seems like a horrible idea to me, not just because of > > that fact that window system protocols shouldn't care about > > driver-specific stuff, but also because of the immense burden once you > > realize that you have to fix all window system protocols and KMS apps > > because 64 bits of metadata is not enough to support your hardware. > > It's clearly not economically sustainable. > > > Wasn't this one of the things that were [supposed to be] discussed at > XDC as part of the gbm2/liballoc ? > Not too sure on the topic, so a simple yes/no would be appreciated. Yes. There is also a thread on dri-devel About it. Marek > > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl_dri2: add support for using modifier attributes in eglCreateImageKHR
Hi Emil, On 18 November 2016 at 15:24, Emil Velikov wrote: > On 18 November 2016 at 15:17, Daniel Stone wrote: >> Actually, present-and-zero modifier has a very well-defined meaning: >> it _forces_ linear interpretation of the buffer, whereas a non-present >> modifier may cause a kernel query (e.g. i915_gem_get_tiling) to >> discover a hidden tiling mode. So, if present, the modifier should be >> passed. >> > You are suggesting that we should track "has_modifier" (as opposed to > nonzero_modifier_found) and pass it to DmaBuf2 regardless of the > contents, right ? Yep, exactly that. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] implement EGL_EXT_image_dma_buf_import_modifiers
On 18 November 2016 at 15:26, Marek Olšák wrote: > On Nov 18, 2016 2:55 PM, "Emil Velikov" wrote: >> >> [Pardon for dropping in uninvited] >> >> On 15 November 2016 at 18:04, Marek Olšák wrote: >> >> > Immutable metadata (modifiers) stored in the kernel is the only >> > scalable (and thus usable) solution here. There was an argument >> > against _mutable_ metadata attached to BOs and the synchronization >> > hell it can cause, but I've not seen any argument against _immutable_ >> > metadata. Trying to push the metadata (modifiers) through window >> > system protocols seems like a horrible idea to me, not just because of >> > that fact that window system protocols shouldn't care about >> > driver-specific stuff, but also because of the immense burden once you >> > realize that you have to fix all window system protocols and KMS apps >> > because 64 bits of metadata is not enough to support your hardware. >> > It's clearly not economically sustainable. >> > >> Wasn't this one of the things that were [supposed to be] discussed at >> XDC as part of the gbm2/liballoc ? >> Not too sure on the topic, so a simple yes/no would be appreciated. > > Yes. There is also a thread on dri-devel About it. > Afaict the dri-devel thread started after XDC. Seemingly you/others did not had the chance to have a productive brainstorming discussion and/or reach a consensus ? Either way, I won't deviate the thread any more. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 10/10] virgl: native fence fd support
Thanks for upstreaming this, this patch has been tested and confirmed
working on a qemu setup.
Tested-by: Robert Foss
On Fri, 2016-11-18 at 08:39 -0500, Rob Clark wrote:
> From: Gustavo Padovan
>
> ---
> src/gallium/drivers/virgl/virgl_context.c | 47 +++-
> -
> src/gallium/drivers/virgl/virgl_screen.c | 12 +++-
> src/gallium/drivers/virgl/virgl_winsys.h | 16 -
> src/gallium/winsys/virgl/drm/virgl_drm_winsys.c| 78
> +-
> src/gallium/winsys/virgl/drm/virgl_drm_winsys.h| 2 +
> src/gallium/winsys/virgl/drm/virtgpu_drm.h | 16 -
> .../winsys/virgl/vtest/virgl_vtest_winsys.c| 8 ++-
> 7 files changed, 162 insertions(+), 17 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.c
> b/src/gallium/drivers/virgl/virgl_context.c
> index bda9515..66bd4e8 100644
> --- a/src/gallium/drivers/virgl/virgl_context.c
> +++ b/src/gallium/drivers/virgl/virgl_context.c
> @@ -21,6 +21,8 @@
> * USE OR OTHER DEALINGS IN THE SOFTWARE.
> */
>
> +#include
> +
> #include "pipe/p_shader_tokens.h"
>
> #include "pipe/p_context.h"
> @@ -623,13 +625,20 @@ static void virgl_draw_vbo(struct pipe_context
> *ctx,
>
> }
>
> -static void virgl_flush_eq(struct virgl_context *ctx, void *closure)
> +static void virgl_flush_eq(struct virgl_context *ctx, void *closure,
> + struct pipe_fence_handle **fence)
> {
> struct virgl_screen *rs = virgl_screen(ctx->base.screen);
> + int out_fence_fd = -1;
>
> /* send the buffer to the remote side for decoding */
> ctx->num_transfers = ctx->num_draws = 0;
> - rs->vws->submit_cmd(rs->vws, ctx->cbuf);
> +
> + rs->vws->submit_cmd(rs->vws, ctx->cbuf, ctx->cbuf->in_fence_fd,
> + ctx->cbuf->needs_out_fence_fd ? &out_fence_fd
> : NULL);
> +
> + if (fence)
> + *fence = rs->vws->cs_create_fence(rs->vws, out_fence_fd);
>
> virgl_encoder_set_sub_ctx(ctx, ctx->hw_sub_ctx_id);
>
> @@ -642,11 +651,10 @@ static void virgl_flush_from_st(struct
> pipe_context *ctx,
> enum pipe_flush_flags flags)
> {
> struct virgl_context *vctx = virgl_context(ctx);
> - struct virgl_screen *rs = virgl_screen(ctx->screen);
> struct virgl_buffer *buf, *tmp;
>
> - if (fence)
> - *fence = rs->vws->cs_create_fence(rs->vws);
> + if (flags & PIPE_FLUSH_FENCE_FD)
> + vctx->cbuf->needs_out_fence_fd = true;
>
> LIST_FOR_EACH_ENTRY_SAFE(buf, tmp, &vctx->to_flush_bufs,
> flush_list) {
> struct pipe_resource *res = &buf->base.u.b;
> @@ -656,7 +664,13 @@ static void virgl_flush_from_st(struct
> pipe_context *ctx,
> pipe_resource_reference(&res, NULL);
>
> }
> - virgl_flush_eq(vctx, vctx);
> + virgl_flush_eq(vctx, vctx, fence);
> +
> + if (vctx->cbuf->in_fence_fd != -1) {
> + close(vctx->cbuf->in_fence_fd);
> + vctx->cbuf->in_fence_fd = -1;
> + }
> + vctx->cbuf->needs_out_fence_fd = false;
> }
>
> static struct pipe_sampler_view *virgl_create_sampler_view(struct
> pipe_context *ctx,
> @@ -846,6 +860,23 @@ static void virgl_blit(struct pipe_context *ctx,
> blit);
> }
>
> +static void virgl_create_fence_fd(struct pipe_context *ctx,
> + struct pipe_fence_handle **fence,
> int fd)
> +{
> + struct virgl_screen *rs = virgl_screen(ctx->screen);
> +
> + *fence = rs->vws->cs_create_fence(rs->vws, fd);
> +}
> +
> +static void virgl_fence_server_sync(struct pipe_context *ctx,
> + struct pipe_fence_handle *fence)
> +{
> + struct virgl_context *vctx = virgl_context(ctx);
> + struct virgl_screen *rs = virgl_screen(ctx->screen);
> +
> + rs->vws->fence_server_sync(rs->vws, vctx->cbuf, fence);
> +}
> +
> static void
> virgl_context_destroy( struct pipe_context *ctx )
> {
> @@ -855,7 +886,7 @@ virgl_context_destroy( struct pipe_context *ctx )
> vctx->framebuffer.zsbuf = NULL;
> vctx->framebuffer.nr_cbufs = 0;
> virgl_encoder_destroy_sub_ctx(vctx, vctx->hw_sub_ctx_id);
> - virgl_flush_eq(vctx, vctx);
> + virgl_flush_eq(vctx, vctx, NULL);
>
> rs->vws->cmd_buf_destroy(vctx->cbuf);
> if (vctx->uploader)
> @@ -937,6 +968,8 @@ struct pipe_context *virgl_context_create(struct
> pipe_screen *pscreen,
> vctx->base.resource_copy_region = virgl_resource_copy_region;
> vctx->base.flush_resource = virgl_flush_resource;
> vctx->base.blit = virgl_blit;
> + vctx->base.create_fence_fd = virgl_create_fence_fd;
> + vctx->base.fence_server_sync = virgl_fence_server_sync;
>
> virgl_init_context_resource_functions(&vctx->base);
> virgl_init_query_functions(vctx);
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c
> b/src/gallium/drivers/virgl/virgl_screen.c
> index 0edaa22..aa8a336 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -261,7 +261,7 @@ virgl_get_param(struc
Re: [Mesa-dev] Stable release process
On 18 November 2016 at 12:34, Marek Olšák wrote:
> On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov
> wrote:
>> On 17 November 2016 at 23:42, Marek Olšák wrote:
>>> On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov
>>> wrote:
On 15 November 2016 at 16:57, Marek Olšák wrote:
> On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov
> wrote:
>> On 15 November 2016 at 16:13, Marek Olšák wrote:
>>> I think that if people add the Cc stable tag to patches that are going
>>> to land in master first, they shouldn't send it to the stable ML,
>>> because that is redundant. Yet, many people do that. I would go even
>>> further and say that any unreviewed patches shouldn't be sent to the
>>> stable ML. At least that would be my policy I were the release
>>> manager.
>>>
>> Since I'm no longer tracking nominated-but-not-merged-in-master
>> patches things are noticeably better.
>
> What about patches in mesa-stable that can't be merged to master,
> because master needs to be fixed differently? Will you then apply the
> patches from mesa-stable or ignore them?
>
> Based on experience, it looks like you ignore them completely, which
> is why many fixes that I sent for inclusion to stable branches only
> (not master) have never been applied. This process needs to be fixed.
>
Trivial patches are addressed, others are pinged. Trivial dependencies
are picked, non-trivial ones invalidate the nominated patch.
Backports are always appreciated - there's been a few from yourself,
Ilia and others.
One example/snippet from the 12.0.x pre-release announcement.
"
f240ad9 st/mesa: unduplicate st_check_sync code
b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync
Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
fence_finish") which is gallium API change.
"
Here the original nominations are invalidated, and from a quick look
even if we do pick the dependency things won't work [as expected]
since zero drivers hadnle the pipe_ctx this will need to add support
(read: not bugfix, but implement).
In all fairness if sounds like things are unclear rather than anything
else. I believe with the documentation (and above) things are better
now ?
>>>
>>> That's all nice, but it's mostly irrelevant to what I was saying.
>>>
>>> We need Patchwork for mesa-stable, so that patches don't get lost.
>>>
>> Ok let me be perfectly clear.
>>
>> Nearly all the missed patches (many of those sent by you) do _not_
>> follow the -stable submission rules. I've been polite and picked those
>> _despite_ that fact and yes some have been missed.
>> Regardless of patchwork I would _strongly_ suggest that you stay
>> consistent (you do it right most of the time) and nominate patches
>> properly!
>
> The last one was nominated properly, and ignored.
As mentioned in private that was due to bug on my end as I was working
on improving the workflow.
Please don't everything under the same nominator.
>>
>> Speaking of patchwork, mostly I'm fine with it. There are some
>> "drawbacks" though:
>> - some duplicated time will be spent tagging "self-rejected" patches.
>> I already track these based from the mailing list.
>> - it doesn't parse "Pick commit $sha, it addresses $issue"
>> nominations, so it cannot substitute/replace the mailing list.
>> In case my first point brought some "don't bother with the ML" type of
>> thoughts.
>> - you don't seem to be using it [1] so I'm not sure of the sudden interest.
>
> Patchwork can't clear any of my patches on git push. That's normal. I
> do use Patchwork for reviewing patches though.
>
Seems to work fairly well here. Admittedly I have way less (and
smaller) patches...
Please elaborate a bit on "We need Patchwork for mesa-stable, so that
patches don't get lost."
How you plan to use it to track/other. Can we get a clear
idea/understanding your workflow/expectations so that things work
better for all of us ?
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stable release process
On 18.11.2016 16:56, Emil Velikov wrote:
On 18 November 2016 at 12:34, Marek Olšák wrote:
On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov wrote:
On 17 November 2016 at 23:42, Marek Olšák wrote:
On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov wrote:
On 15 November 2016 at 16:57, Marek Olšák wrote:
On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov wrote:
On 15 November 2016 at 16:13, Marek Olšák wrote:
I think that if people add the Cc stable tag to patches that are going
to land in master first, they shouldn't send it to the stable ML,
because that is redundant. Yet, many people do that. I would go even
further and say that any unreviewed patches shouldn't be sent to the
stable ML. At least that would be my policy I were the release
manager.
Since I'm no longer tracking nominated-but-not-merged-in-master
patches things are noticeably better.
What about patches in mesa-stable that can't be merged to master,
because master needs to be fixed differently? Will you then apply the
patches from mesa-stable or ignore them?
Based on experience, it looks like you ignore them completely, which
is why many fixes that I sent for inclusion to stable branches only
(not master) have never been applied. This process needs to be fixed.
Trivial patches are addressed, others are pinged. Trivial dependencies
are picked, non-trivial ones invalidate the nominated patch.
Backports are always appreciated - there's been a few from yourself,
Ilia and others.
One example/snippet from the 12.0.x pre-release announcement.
"
f240ad9 st/mesa: unduplicate st_check_sync code
b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync
Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
fence_finish") which is gallium API change.
"
Here the original nominations are invalidated, and from a quick look
even if we do pick the dependency things won't work [as expected]
since zero drivers hadnle the pipe_ctx this will need to add support
(read: not bugfix, but implement).
In all fairness if sounds like things are unclear rather than anything
else. I believe with the documentation (and above) things are better
now ?
That's all nice, but it's mostly irrelevant to what I was saying.
We need Patchwork for mesa-stable, so that patches don't get lost.
Ok let me be perfectly clear.
Nearly all the missed patches (many of those sent by you) do _not_
follow the -stable submission rules. I've been polite and picked those
_despite_ that fact and yes some have been missed.
Regardless of patchwork I would _strongly_ suggest that you stay
consistent (you do it right most of the time) and nominate patches
properly!
The last one was nominated properly, and ignored.
As mentioned in private that was due to bug on my end as I was working
on improving the workflow.
Please don't everything under the same nominator.
Speaking of patchwork, mostly I'm fine with it. There are some
"drawbacks" though:
- some duplicated time will be spent tagging "self-rejected" patches.
I already track these based from the mailing list.
- it doesn't parse "Pick commit $sha, it addresses $issue"
nominations, so it cannot substitute/replace the mailing list.
In case my first point brought some "don't bother with the ML" type of thoughts.
- you don't seem to be using it [1] so I'm not sure of the sudden interest.
Patchwork can't clear any of my patches on git push. That's normal. I
do use Patchwork for reviewing patches though.
Seems to work fairly well here. Admittedly I have way less (and
smaller) patches...
Patchwork is pretty dumb about how it compares patches. If you have
non-standard git diff settings (e.g. more lines of context), it will
never recognize a patch.
Nicolai
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/10] egl: add EGL_ANDROID_native_fence_sync
The first 4 patches of this series at least (including this one) work
well on i915 when combined with the pending i915 patches for mesa,
libdrm and kernel.
Tested-by: Rafael Antognolli
On Fri, Nov 18, 2016 at 08:39:33AM -0500, Rob Clark wrote:
> From: Rob Clark
>
> With fixes from Chad squashed in, plus fixes for issues that Rafael
> found while writing piglit tests.
>
> Cc: Chad Versace
> Cc: Rafael Antognolli
> Signed-off-by: Rob Clark
> ---
> src/egl/drivers/dri2/egl_dri2.c | 58
> -
> src/egl/main/eglapi.c | 38 ---
> src/egl/main/eglapi.h | 2 ++
> src/egl/main/egldisplay.h | 1 +
> src/egl/main/eglfallbacks.c | 1 +
> src/egl/main/eglsync.c | 22 ++--
> src/egl/main/eglsync.h | 1 +
> 7 files changed, 117 insertions(+), 6 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index f18e9fb..52fbdff 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -658,6 +658,12 @@ dri2_setup_screen(_EGLDisplay *disp)
>disp->Extensions.KHR_wait_sync = EGL_TRUE;
>if (dri2_dpy->fence->get_fence_from_cl_event)
> disp->Extensions.KHR_cl_event2 = EGL_TRUE;
> + if (dri2_dpy->fence->base.version >= 2) {
> + unsigned capabilities =
> +dri2_dpy->fence->get_capabilities(dri2_dpy->dri_screen);
> + disp->Extensions.ANDROID_native_fence_sync =
> +(capabilities & __DRI_FENCE_CAP_NATIVE_FD) != 0;
> + }
> }
>
> disp->Extensions.KHR_reusable_sync = EGL_TRUE;
> @@ -2511,8 +2517,17 @@ dri2_egl_unref_sync(struct dri2_egl_display *dri2_dpy,
> struct dri2_egl_sync *dri2_sync)
> {
> if (p_atomic_dec_zero(&dri2_sync->refcount)) {
> - if (dri2_sync->base.Type == EGL_SYNC_REUSABLE_KHR)
> + switch (dri2_sync->base.Type) {
> + case EGL_SYNC_REUSABLE_KHR:
> cnd_destroy(&dri2_sync->cond);
> + break;
> + case EGL_SYNC_NATIVE_FENCE_ANDROID:
> + if (dri2_sync->base.SyncFd != EGL_NO_NATIVE_FENCE_FD_ANDROID)
> +close(dri2_sync->base.SyncFd);
> + break;
> + default:
> + break;
> + }
>
>if (dri2_sync->fence)
> dri2_dpy->fence->destroy_fence(dri2_dpy->dri_screen,
> dri2_sync->fence);
> @@ -2603,6 +2618,19 @@ dri2_create_sync(_EGLDriver *drv, _EGLDisplay *dpy,
>/* initial status of reusable sync must be "unsignaled" */
>dri2_sync->base.SyncStatus = EGL_UNSIGNALED_KHR;
>break;
> +
> + case EGL_SYNC_NATIVE_FENCE_ANDROID:
> + if (dri2_dpy->fence->create_fence_fd) {
> + dri2_sync->fence = dri2_dpy->fence->create_fence_fd(
> +dri2_ctx->dri_context,
> +dri2_sync->base.SyncFd);
> + }
> + if (!dri2_sync->fence) {
> + _eglError(EGL_BAD_ATTRIBUTE, "eglCreateSyncKHR");
> + free(dri2_sync);
> + return NULL;
> + }
> + break;
> }
>
> p_atomic_set(&dri2_sync->refcount, 1);
> @@ -2632,12 +2660,38 @@ dri2_destroy_sync(_EGLDriver *drv, _EGLDisplay *dpy,
> _EGLSync *sync)
> ret = EGL_FALSE;
>}
> }
> +
> dri2_egl_unref_sync(dri2_dpy, dri2_sync);
>
> return ret;
> }
>
> static EGLint
> +dri2_dup_native_fence_fd(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSync *sync)
> +{
> + struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
> + struct dri2_egl_sync *dri2_sync = dri2_egl_sync(sync);
> +
> + assert(sync->Type == EGL_SYNC_NATIVE_FENCE_ANDROID);
> +
> + if (sync->SyncFd == EGL_NO_NATIVE_FENCE_FD_ANDROID) {
> + /* try to retrieve the actual native fence fd.. if rendering is
> + * not flushed this will just return -1, aka NO_NATIVE_FENCE_FD:
> + */
> + sync->SyncFd = dri2_dpy->fence->get_fence_fd(dri2_dpy->dri_screen,
> + dri2_sync->fence);
> + }
> +
> + if (sync->SyncFd == EGL_NO_NATIVE_FENCE_FD_ANDROID) {
> + /* if native fence fd still not created, return an error: */
> + _eglError(EGL_BAD_PARAMETER, "eglDupNativeFenceFDANDROID");
> + return EGL_NO_NATIVE_FENCE_FD_ANDROID;
> + }
> +
> + return dup(sync->SyncFd);
> +}
> +
> +static EGLint
> dri2_client_wait_sync(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSync *sync,
>EGLint flags, EGLTime timeout)
> {
> @@ -2667,6 +2721,7 @@ dri2_client_wait_sync(_EGLDriver *drv, _EGLDisplay
> *dpy, _EGLSync *sync,
>
> switch (sync->Type) {
> case EGL_SYNC_FENCE_KHR:
> + case EGL_SYNC_NATIVE_FENCE_ANDROID:
> case EGL_SYNC_CL_EVENT_KHR:
>if (dri2_dpy->fence->client_wait_sync(dri2_ctx ? dri2_ctx->dri_context
> : NULL,
> dri2_sync->fence, wait_flags,
> @@ -2922,6 +2977,7 @@ _eglBuiltInDriverDRI2(const char *args)
> dri2_
Re: [Mesa-dev] Stable release process
Hi everybody, Nicolai Hähnle wrote on 18.11.2016 17:48: > On 18.11.2016 16:56, Emil Velikov wrote: >> On 18 November 2016 at 12:34, Marek Olšák wrote: >>> On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov >>> wrote: >>> [...] Speaking of patchwork, mostly I'm fine with it. There are some "drawbacks" though: - some duplicated time will be spent tagging "self-rejected" patches. I already track these based from the mailing list. - it doesn't parse "Pick commit $sha, it addresses $issue" nominations, so it cannot substitute/replace the mailing list. In case my first point brought some "don't bother with the ML" type of thoughts. - you don't seem to be using it [1] so I'm not sure of the sudden interest. >>> >>> Patchwork can't clear any of my patches on git push. That's normal. I >>> do use Patchwork for reviewing patches though. >>> >> Seems to work fairly well here. Admittedly I have way less (and >> smaller) patches... > > Patchwork is pretty dumb about how it compares patches. If you have > non-standard > git diff settings (e.g. more lines of context), it will never recognize a > patch. wouldn't a tool like Phabricator be much better for reviewing and reliably tracking whether a patch has landed or not? Especially if you use it in combination with Arcanist? While I'm certainly not a core developer, I find patchwork clunky. Sometimes it doesn't pick up R-bs or doesn't recognise series, which makes seeing the actual state of a patch a bit tricky from time to time. In addition you would get things like automatically closure of bugs, nice referencing features and lots of other nice features. And AFAIK freedesktop.org already has a Phabricator instance, which could be used. Just my outside opinion, though. ;-) Cheers, Kai signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv/state: enable coordinate address rounding for Min/Mag filters
Thanks!
Reviewed-by: Jason Ekstrand
On Fri, Nov 18, 2016 at 4:44 AM, Iago Toral Quiroga
wrote:
> This patch improves pass rate of dEQP-VK.texture.explicit_lod.2d.sizes.*
> from 68.0% (98/144) to 83.3% (120/144) by enabling sampler address
> rounding mode when the selected filter is not nearest, which is the same
> thing we do for OpenGL.
>
> These tests check texture filtering for various texture sizes and mipmap
> levels. The failures (without this patch) affect cases where the target
> texture has odd dimensions (like 57x35) and either the Min or the Mag
> filter
> is not nearest.
>
> ---
>
> I think this patch should fix all the failed tests, but for some reason it
> only fixes the subset where the MagFilter is not linear.
>
> src/intel/vulkan/genX_state.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
> index be1bd78..4122395 100644
> --- a/src/intel/vulkan/genX_state.c
> +++ b/src/intel/vulkan/genX_state.c
> @@ -167,6 +167,11 @@ VkResult genX(CreateSampler)(
> uint32_t border_color_offset = device->border_colors.offset +
>pCreateInfo->borderColor * 64;
>
> + bool enable_min_filter_addr_rounding =
> + pCreateInfo->minFilter != VK_FILTER_NEAREST;
> + bool enable_mag_filter_addr_rounding =
> + pCreateInfo->magFilter != VK_FILTER_NEAREST;
> +
> struct GENX(SAMPLER_STATE) sampler_state = {
>.SamplerDisable = false,
>.TextureBorderColorMode = DX10OGL,
> @@ -202,12 +207,12 @@ VkResult genX(CreateSampler)(
> #endif
>
>.MaximumAnisotropy = vk_to_gen_max_anisotropy(
> pCreateInfo->maxAnisotropy),
> - .RAddressMinFilterRoundingEnable = 0,
> - .RAddressMagFilterRoundingEnable = 0,
> - .VAddressMinFilterRoundingEnable = 0,
> - .VAddressMagFilterRoundingEnable = 0,
> - .UAddressMinFilterRoundingEnable = 0,
> - .UAddressMagFilterRoundingEnable = 0,
> + .RAddressMinFilterRoundingEnable = enable_min_filter_addr_rounding,
> + .RAddressMagFilterRoundingEnable = enable_mag_filter_addr_rounding,
> + .VAddressMinFilterRoundingEnable = enable_min_filter_addr_rounding,
> + .VAddressMagFilterRoundingEnable = enable_mag_filter_addr_rounding,
> + .UAddressMinFilterRoundingEnable = enable_min_filter_addr_rounding,
> + .UAddressMagFilterRoundingEnable = enable_mag_filter_addr_rounding,
>.TrilinearFilterQuality = 0,
>.NonnormalizedCoordinateEnable = pCreateInfo->
> unnormalizedCoordinates,
>.TCXAddressControlMode = vk_to_gen_tex_address[
> pCreateInfo->addressModeU],
> --
> 2.7.4
>
> ___
> 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 v3] clover: restore support for LLVM <= 3.9
The commit 8e430ff8b060b4e8e922bae24b3c57837da6ea77 support for LLVM
3.9 and older versionsin Clover. This patch restores it and refactors
the support using Clover compatibility layer for LLVM.
Signed-off-by: Vedran Miletić
---
.../state_trackers/clover/llvm/codegen/bitcode.cpp | 9 ++
src/gallium/state_trackers/clover/llvm/compat.hpp | 33 ++
2 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
index 5dcc4f8..4b4ae41 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
@@ -32,6 +32,7 @@
///
#include "llvm/codegen.hpp"
+#include "llvm/compat.hpp"
#include "llvm/metadata.hpp"
#include "core/error.hpp"
#include "util/algorithm.hpp"
@@ -99,13 +100,7 @@ clover::llvm::parse_module_library(const module &m,
::llvm::LLVMContext &ctx,
auto mod = ::llvm::parseBitcodeFile(::llvm::MemoryBufferRef(
as_string(m.secs[0].data), " "), ctx);
- if (::llvm::Error err = mod.takeError()) {
- std::string msg;
- ::llvm::handleAllErrors(std::move(err), [&](::llvm::ErrorInfoBase &EIB) {
- msg = EIB.message();
- fail(r_log, error(CL_INVALID_PROGRAM), msg.c_str());
- });
- }
+ compat::handle_module_error(mod, r_log);
return std::unique_ptr<::llvm::Module>(std::move(*mod));
}
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index a963cff..431aeae 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -39,6 +39,11 @@
#include
#include
#include
+#if HAVE_LLVM >= 0x0400
+#include
+#else
+#include
+#endif
#if HAVE_LLVM >= 0x0307
#include
@@ -53,6 +58,12 @@
#include
#include
+#include
+
+namespace llvm {
+ class Module;
+}
+
namespace clover {
namespace llvm {
namespace compat {
@@ -158,6 +169,28 @@ namespace clover {
#else
const auto default_reloc_model = ::llvm::Reloc::Default;
#endif
+
+#if HAVE_LLVM >= 0x0400
+ typedef ::llvm::Expected>
bitcode_module;
+#elif HAVE_LLVM >= 0x0307
+ typedef ::llvm::ErrorOr>
bitcode_module;
+#else
+ typedef ::llvm::ErrorOr<::llvm::Module *> bitcode_module;
+#endif
+
+ inline void
+ handle_module_error(bitcode_module &mod, std::string &r_log) {
+#if HAVE_LLVM >= 0x0400
+if (::llvm::Error err = mod.takeError()) {
+ ::llvm::handleAllErrors(std::move(err),
[&](::llvm::ErrorInfoBase &EIB) {
+ fail(r_log, error(CL_INVALID_PROGRAM),
EIB.message().c_str());
+ });
+}
+#else
+if (!mod)
+ fail(r_log, error(CL_INVALID_PROGRAM),
mod.getError().message());
+#endif
+ }
}
}
}
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4] clover: restore support for LLVM <= 3.9
The commit 8e430ff8b060b4e8e922bae24b3c57837da6ea77 support for LLVM
3.9 and older versionsin Clover. This patch restores it and refactors
the support using Clover compatibility layer for LLVM.
Signed-off-by: Vedran Miletić
---
.../state_trackers/clover/llvm/codegen/bitcode.cpp | 9 ++
src/gallium/state_trackers/clover/llvm/compat.hpp | 35 ++
2 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
index 5dcc4f8..4b4ae41 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
@@ -32,6 +32,7 @@
///
#include "llvm/codegen.hpp"
+#include "llvm/compat.hpp"
#include "llvm/metadata.hpp"
#include "core/error.hpp"
#include "util/algorithm.hpp"
@@ -99,13 +100,7 @@ clover::llvm::parse_module_library(const module &m,
::llvm::LLVMContext &ctx,
auto mod = ::llvm::parseBitcodeFile(::llvm::MemoryBufferRef(
as_string(m.secs[0].data), " "), ctx);
- if (::llvm::Error err = mod.takeError()) {
- std::string msg;
- ::llvm::handleAllErrors(std::move(err), [&](::llvm::ErrorInfoBase &EIB) {
- msg = EIB.message();
- fail(r_log, error(CL_INVALID_PROGRAM), msg.c_str());
- });
- }
+ compat::handle_module_error(mod, r_log);
return std::unique_ptr<::llvm::Module>(std::move(*mod));
}
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index a963cff..b29100f 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -39,6 +39,11 @@
#include
#include
#include
+#if HAVE_LLVM >= 0x0400
+#include
+#else
+#include
+#endif
#if HAVE_LLVM >= 0x0307
#include
@@ -53,6 +58,14 @@
#include
#include
+#if HAVE_LLVM >= 0x0307
+#include
+#endif
+
+namespace llvm {
+ class Module;
+}
+
namespace clover {
namespace llvm {
namespace compat {
@@ -158,6 +171,28 @@ namespace clover {
#else
const auto default_reloc_model = ::llvm::Reloc::Default;
#endif
+
+#if HAVE_LLVM >= 0x0400
+ typedef ::llvm::Expected>
bitcode_module;
+#elif HAVE_LLVM >= 0x0307
+ typedef ::llvm::ErrorOr>
bitcode_module;
+#else
+ typedef ::llvm::ErrorOr<::llvm::Module *> bitcode_module;
+#endif
+
+ inline void
+ handle_module_error(bitcode_module &mod, std::string &r_log) {
+#if HAVE_LLVM >= 0x0400
+if (::llvm::Error err = mod.takeError()) {
+ ::llvm::handleAllErrors(std::move(err),
[&](::llvm::ErrorInfoBase &EIB) {
+ fail(r_log, error(CL_INVALID_PROGRAM),
EIB.message().c_str());
+ });
+}
+#else
+if (!mod)
+ fail(r_log, error(CL_INVALID_PROGRAM),
mod.getError().message());
+#endif
+ }
}
}
}
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stable release process
On Fri, Nov 18, 2016 at 4:56 PM, Emil Velikov wrote:
> On 18 November 2016 at 12:34, Marek Olšák wrote:
>> On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov
>> wrote:
>>> On 17 November 2016 at 23:42, Marek Olšák wrote:
On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov
wrote:
> On 15 November 2016 at 16:57, Marek Olšák wrote:
>> On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov
>> wrote:
>>> On 15 November 2016 at 16:13, Marek Olšák wrote:
I think that if people add the Cc stable tag to patches that are going
to land in master first, they shouldn't send it to the stable ML,
because that is redundant. Yet, many people do that. I would go even
further and say that any unreviewed patches shouldn't be sent to the
stable ML. At least that would be my policy I were the release
manager.
>>> Since I'm no longer tracking nominated-but-not-merged-in-master
>>> patches things are noticeably better.
>>
>> What about patches in mesa-stable that can't be merged to master,
>> because master needs to be fixed differently? Will you then apply the
>> patches from mesa-stable or ignore them?
>>
>> Based on experience, it looks like you ignore them completely, which
>> is why many fixes that I sent for inclusion to stable branches only
>> (not master) have never been applied. This process needs to be fixed.
>>
> Trivial patches are addressed, others are pinged. Trivial dependencies
> are picked, non-trivial ones invalidate the nominated patch.
> Backports are always appreciated - there's been a few from yourself,
> Ilia and others.
>
> One example/snippet from the 12.0.x pre-release announcement.
> "
> f240ad9 st/mesa: unduplicate st_check_sync code
> b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync
>
> Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
> fence_finish") which is gallium API change.
> "
> Here the original nominations are invalidated, and from a quick look
> even if we do pick the dependency things won't work [as expected]
> since zero drivers hadnle the pipe_ctx this will need to add support
> (read: not bugfix, but implement).
>
> In all fairness if sounds like things are unclear rather than anything
> else. I believe with the documentation (and above) things are better
> now ?
That's all nice, but it's mostly irrelevant to what I was saying.
We need Patchwork for mesa-stable, so that patches don't get lost.
>>> Ok let me be perfectly clear.
>>>
>>> Nearly all the missed patches (many of those sent by you) do _not_
>>> follow the -stable submission rules. I've been polite and picked those
>>> _despite_ that fact and yes some have been missed.
>>> Regardless of patchwork I would _strongly_ suggest that you stay
>>> consistent (you do it right most of the time) and nominate patches
>>> properly!
>>
>> The last one was nominated properly, and ignored.
> As mentioned in private that was due to bug on my end as I was working
> on improving the workflow.
> Please don't everything under the same nominator.
OK.
>
>>>
>>> Speaking of patchwork, mostly I'm fine with it. There are some
>>> "drawbacks" though:
>>> - some duplicated time will be spent tagging "self-rejected" patches.
>>> I already track these based from the mailing list.
>>> - it doesn't parse "Pick commit $sha, it addresses $issue"
>>> nominations, so it cannot substitute/replace the mailing list.
>>> In case my first point brought some "don't bother with the ML" type of
>>> thoughts.
>>> - you don't seem to be using it [1] so I'm not sure of the sudden interest.
>>
>> Patchwork can't clear any of my patches on git push. That's normal. I
>> do use Patchwork for reviewing patches though.
>>
> Seems to work fairly well here. Admittedly I have way less (and
> smaller) patches...
>
> Please elaborate a bit on "We need Patchwork for mesa-stable, so that
> patches don't get lost."
I thought Patchwork would help us to prevent losing patches. If you
have a different (just as good) process in place already, Patchwork is
not necessary.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stable release process
On Fri, Nov 18, 2016 at 7:45 PM, Kai Wasserbäch wrote: > Hi everybody, > Nicolai Hähnle wrote on 18.11.2016 17:48: >> On 18.11.2016 16:56, Emil Velikov wrote: >>> On 18 November 2016 at 12:34, Marek Olšák wrote: On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov wrote: [...] > Speaking of patchwork, mostly I'm fine with it. There are some > "drawbacks" though: > - some duplicated time will be spent tagging "self-rejected" patches. > I already track these based from the mailing list. > - it doesn't parse "Pick commit $sha, it addresses $issue" > nominations, so it cannot substitute/replace the mailing list. > In case my first point brought some "don't bother with the ML" type of > thoughts. > - you don't seem to be using it [1] so I'm not sure of the sudden > interest. Patchwork can't clear any of my patches on git push. That's normal. I do use Patchwork for reviewing patches though. >>> Seems to work fairly well here. Admittedly I have way less (and >>> smaller) patches... >> >> Patchwork is pretty dumb about how it compares patches. If you have >> non-standard >> git diff settings (e.g. more lines of context), it will never recognize a >> patch. > > wouldn't a tool like Phabricator be much better for reviewing and reliably > tracking whether a patch has landed or not? Especially if you use it in > combination with Arcanist? While I'm certainly not a core developer, I find > patchwork clunky. Sometimes it doesn't pick up R-bs or doesn't recognise > series, > which makes seeing the actual state of a patch a bit tricky from time to time. > > In addition you would get things like automatically closure of bugs, nice > referencing features and lots of other nice features. And AFAIK > freedesktop.org > already has a Phabricator instance, which could be used. OK, off topic we go. I have some experience with Phabricator and Arcanist from LLVM and it's not very good. Phabricator (or Arcanist) doesn't support patch series. You can only submit one patch, or a range of commits as one patch (which is pretty bad - why would anyone on Earth want to do that). It also doesn't support downloading patches in the mbox format (only plain diffs). Based on that, I don't recommend it. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: store group_size_variable in struct si_compute
From: Nicolai Hähnle
For compute shaders, we free the selector after the shader has been
compiled, so we need to save this bit somewhere else. Also, make sure that
this type of bug cannot re-appear, by NULL-ing the selector pointer after
we're done with it.
This bug has been there since the feature was added, but was only exposed
in piglit arb_compute_variable_group_size-local-size by commit
9bfee7047b70cb0aa026ca9536465762f96cb2b1 (which is totally unrelated).
Cc: 13.0
---
src/gallium/drivers/radeonsi/si_compute.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index f1887bb..69d57b9 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -35,21 +35,22 @@
#define MAX_GLOBAL_BUFFERS 20
struct si_compute {
unsigned ir_type;
unsigned local_size;
unsigned private_size;
unsigned input_size;
struct si_shader shader;
struct pipe_resource *global_buffers[MAX_GLOBAL_BUFFERS];
- bool use_code_object_v2;
+ unsigned use_code_object_v2 : 1;
+ unsigned variable_group_size : 1;
};
struct dispatch_packet {
uint16_t header;
uint16_t setup;
uint16_t workgroup_size_x;
uint16_t workgroup_size_y;
uint16_t workgroup_size_z;
uint16_t reserved0;
uint32_t grid_size_x;
@@ -140,21 +141,25 @@ static void *si_create_compute_state(
S_00B848_SGPRS((shader->config.num_sgprs - 1) / 8) |
S_00B848_DX10_CLAMP(1) |
S_00B848_FLOAT_MODE(shader->config.float_mode);
shader->config.rsrc2 = S_00B84C_USER_SGPR(SI_CS_NUM_USER_SGPR) |
S_00B84C_SCRATCH_EN(scratch_enabled) |
S_00B84C_TGID_X_EN(1) | S_00B84C_TGID_Y_EN(1) |
S_00B84C_TGID_Z_EN(1) | S_00B84C_TIDIG_COMP_CNT(2) |
S_00B84C_LDS_SIZE(shader->config.lds_size);
+ program->variable_group_size =
+ sel.info.properties[TGSI_PROPERTY_CS_FIXED_BLOCK_WIDTH]
== 0;
+
FREE(sel.tokens);
+ program->shader.selector = NULL;
} else {
const struct pipe_llvm_program_header *header;
const char *code;
header = cso->prog;
code = cso->prog + sizeof(struct pipe_llvm_program_header);
radeon_elf_read(code, header->num_bytes,
&program->shader.binary);
if (program->use_code_object_v2) {
const amd_kernel_code_t *code_object =
si_compute_get_code_object(program, 0);
@@ -600,28 +605,26 @@ static void si_setup_tgsi_grid(struct si_context *sctx,
radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_MEM) |
COPY_DATA_DST_SEL(COPY_DATA_REG));
radeon_emit(cs, (va + 4 * i));
radeon_emit(cs, (va + 4 * i) >> 32);
radeon_emit(cs, (grid_size_reg >> 2) + i);
radeon_emit(cs, 0);
}
} else {
struct si_compute *program = sctx->cs_shader_state.program;
- bool variable_group_size =
-
program->shader.selector->info.properties[TGSI_PROPERTY_CS_FIXED_BLOCK_WIDTH]
== 0;
- radeon_set_sh_reg_seq(cs, grid_size_reg, variable_group_size ?
6 : 3);
+ radeon_set_sh_reg_seq(cs, grid_size_reg,
program->variable_group_size ? 6 : 3);
radeon_emit(cs, info->grid[0]);
radeon_emit(cs, info->grid[1]);
radeon_emit(cs, info->grid[2]);
- if (variable_group_size) {
+ if (program->variable_group_size) {
radeon_emit(cs, info->block[0]);
radeon_emit(cs, info->block[1]);
radeon_emit(cs, info->block[2]);
}
}
}
static void si_emit_dispatch_packets(struct si_context *sctx,
const struct pipe_grid_info *info)
{
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for windows
> -Original Message- > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On > Behalf Of Emil Velikov > Sent: Friday, November 18, 2016 5:24 AM > To: Kyriazis, George > Cc: ML mesa-dev > Subject: Re: [Mesa-dev] [PATCH v4 09/10] gallium: swr: Added swr build for > windows > > On 18 November 2016 at 04:27, George Kyriazis > wrote: > > Also, modify gen_knobs.py so that each invocation creates a single > > generated file. This is more similar to how the other generators behave. > > --- > > src/gallium/SConscript | 1 + > > src/gallium/drivers/swr/Makefile.am| 15 +- > > src/gallium/drivers/swr/SConscript | 216 > + > > .../drivers/swr/rasterizer/scripts/gen_knobs.py| 51 ++--- > > 4 files changed, 257 insertions(+), 26 deletions(-) create mode > > 100644 src/gallium/drivers/swr/SConscript > > > This is getting tiresome :'-( > > I've mentioned on multiple occasions to keep separate logical changes into > individual patches. > In my previous sounds I've _explicitly_ left only the ones (SConscript > fixes) that should be squashed here. > Please read review comments more carefully ? > I hope we can go past the confusion. Hopefully last set of patches will be posted in a bit. > When sending version X of patch series, adding r-b/ack-b/t-b/other tags > (where applicable) and brief version history is highly recommended. > If in doubt on the latter - skim through git log + grep v2. > Appreciate the pointer; I am new to mesa check-in practices, and I didn't know. I think it's a good idea to add this info in the Mesa Development notes webpage, to make it more obvious (http://www.mesa3d.org/devinfo.html). Thanks, George > Thanks > Emil > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/70] glsl: create gl_program at the start of linking rather than the end
On 16 November 2016 at 21:47, Timothy Arceri
wrote:
> On Wed, 2016-11-16 at 21:17 +, Emil Velikov wrote:
>> On 11 November 2016 at 00:45, Timothy Arceri
>> wrote:
>> >
>> > This will allow us to directly store metadata we want to retain in
>> > gl_program this metadata is currently stored in gl_linked_shader
>> > and
>> > will be lost if relinking fails even though the program will remain
>> > in use and is still valid according to the spec.
>> >
>> > "If a program object that is active for any shader stage is re-
>> > linked
>> > unsuccessfully, the link status will be set to FALSE, but any
>> > existing
>> > executables and associated state will remain part of the current
>> > rendering state until a subsequent call to UseProgram,
>> > UseProgramStages, or BindProgramPipeline removes them from use."
>> >
>> > This change will also help avoid the double handing that happens in
>> > _mesa_copy_linked_program_data().
>> > ---
>> > src/compiler/glsl/linker.cpp | 15 +++
>> > src/mesa/drivers/dri/i965/brw_link.cpp | 9 +
>> > src/mesa/program/ir_to_mesa.cpp| 6 +-
>> > src/mesa/state_tracker/st_glsl_to_nir.cpp | 7 +--
>> > src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 8 ++--
>> > 5 files changed, 20 insertions(+), 25 deletions(-)
>> >
>> > diff --git a/src/compiler/glsl/linker.cpp
>> > b/src/compiler/glsl/linker.cpp
>> > index 693a50b..f63c025 100644
>> > --- a/src/compiler/glsl/linker.cpp
>> > +++ b/src/compiler/glsl/linker.cpp
>> > @@ -72,6 +72,7 @@
>> > #include "ir.h"
>> > #include "program.h"
>> > #include "program/prog_instruction.h"
>> > +#include "program/program.h"
>> > #include "util/set.h"
>> > #include "util/string_to_uint_map.h"
>> > #include "linker.h"
>> > @@ -2183,6 +2184,20 @@ link_intrastage_shaders(void *mem_ctx,
>> > }
>> >
>> > gl_linked_shader *linked = ctx-
>> > >Driver.NewShader(shader_list[0]->Stage);
>> > +
>> > + /* Create program and attach it to the linked shader */
>> > + struct gl_program *gl_prog =
>> > + ctx->Driver.NewProgram(ctx,
>> > + _mesa_shader_stage_to_program(shader_
>> > list[0]->Stage),
>> > + prog->Name);
>> > + if (!prog) {
>> > + prog->LinkStatus = false;
>> > + _mesa_delete_linked_shader(ctx, linked);
>> > + return NULL;
>> > + }
>> > +
>> > + _mesa_reference_program(ctx, &linked->Program, gl_prog);
>> > +
>> I'm not too sure referencing seems right in this patch.
>> All the error paths seem to be missing the deref, is that intentional
>> or a bug ? I'm leaning toward the latter.
>
> It's intentional, _mesa_delete_linked_shader() will remove the
> reference ... although we might just what to have gl_linked_shader take
> ownership of gl_program here and not use _mesa_reference_program() at
> all otherwise your right the ref count will still be at 1. I think all
> link_shader paths currently have what looks like a hack where they
> call _mesa_reference_program(ctx, &prog, NULL); at the end of linking I
> think the correct way to do it is not use _mesa_reference_program() and
> just assign the pointer directly taking ownership of it.
>
> I think I'll make a fix that goes before this patch to tidy that up,
> and update this patch also.
>
After a long and careful look I believe you're spot on. The new
patches v2 11a and v2 11 are
Reviewed-by: Emil Velikov
> st_nir_get_mesa_program() never checks for a linking error (I'm not
> 100% sure why it is different in that respect)
>
Ack. We can unravel this at some other time.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] intel/aubinator: Fix the kernel start pointer for 3DSTATE_HS
---
src/intel/tools/aubinator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 0da01f4..f5e5167 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -442,9 +442,9 @@ handle_3dstate_hs(struct gen_spec *spec, uint32_t *p)
int hs_enable;
if (gen_spec_get_gen(spec) >= gen_make_gen(8, 0)) {
- start = get_qword(&p[4]);
+ start = get_qword(&p[3]);
} else {
- start = p[4];
+ start = p[3];
}
hs_enable = p[2] & 0x8000;
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] intel/aubinator: Properly handle batch buffer chaining
From: Jason Ekstrand
The original aubinator that Kristian wrote had a bug in the handling of
MI_BATCH_BUFFER_START that propagated into the version in upstream mesa.
In particular, it ignored the "2nd level" bit which tells you whether this
MI_BATCH_BUFFER_START is a subroutine call (2nd level) or a goto. Since
the Vulkan driver uses batch chaining, this can lead to a very confusing
interpretation of the batches. In some cases, depending on how things are
laid out in the virtual GTT, you can even end up with infinite loops in
batch processing.
Signed-off-by: Jason Ekstrand
---
src/intel/tools/aubinator.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 0d4b3f9..78682c5 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -790,7 +790,25 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int
size, int engine)
else
start = p[1];
- parse_commands(spec, gtt + start, 1 << 20, engine);
+ if (p[0] & (1 << 22)) {
+/* MI_BATCH_BUFFER_START with "2nd Level Batch Buffer" set acts
+ * like a subroutine call. Commands that come afterwards get
+ * processed once the 2nd level batch buffer returns with
+ * MI_BATCH_BUFFER_END.
+ */
+parse_commands(spec, gtt + start, gtt_end - start, engine);
+ } else {
+/* MI_BATCH_BUFFER_START with "2nd Level Batch Buffer" unset acts
+ * like a goto. Nothing after it will ever get processed. In
+ * order to prevent the recursion from growing, we just reset the
+ * loop and continue;
+ */
+p = gtt + start;
+/* We don't know where secondaries end so use the GTT end */
+end = gtt + gtt_end;
+length = 0;
+continue;
+ }
} else if ((p[0] & 0x) == AUB_MI_BATCH_BUFFER_END) {
break;
}
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] intel/aubinator: Add a get_address helper
This new helper is automatically handles 32 vs. 48-bit GTT issues. It also
handles 48-bit canonical addresses on Broadwell and above.
---
src/intel/tools/aubinator.c | 47 ++---
1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 78682c5..0da01f4 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -238,31 +238,50 @@ get_qword(uint32_t *p)
return ((uint64_t) p[1] << 32) | p[0];
}
+static inline uint64_t
+get_address(struct gen_spec *spec, uint32_t *p)
+{
+ /* Addresses are always guaranteed to be page-aligned and sometimes
+* hardware packets have extra stuff stuffed in the bottom 12 bits.
+*/
+ uint64_t addr = p[0] & ~0xfffu;
+
+ if (gen_spec_get_gen(spec) >= gen_make_gen(8,0)) {
+ /* On Broadwell and above, we have 48-bit addresses which consume two
+ * dwords. Some packets require that these get stored in a "canonical
+ * form" which means that bit 47 is sign-extended through the upper
+ * bits. In order to correctly handle those aub dumps, we need to mask
+ * off the top 16 bits.
+ */
+ addr |= ((uint64_t)p[1] & 0x) << 32;
+ }
+
+ return addr;
+}
+
static void
handle_state_base_address(struct gen_spec *spec, uint32_t *p)
{
- uint64_t mask = ~((1 << 12) - 1);
-
if (gen_spec_get_gen(spec) >= gen_make_gen(8,0)) {
if (p[1] & 1)
- general_state_base = get_qword(&p[1]) & mask;
+ general_state_base = get_address(spec, &p[1]);
if (p[4] & 1)
- surface_state_base = get_qword(&p[4]) & mask;
+ surface_state_base = get_address(spec, &p[4]);
if (p[6] & 1)
- dynamic_state_base = get_qword(&p[6]) & mask;
+ dynamic_state_base = get_address(spec, &p[6]);
if (p[10] & 1)
- instruction_base = get_qword(&p[10]) & mask;
+ instruction_base = get_address(spec, &p[10]);
if (p[15] & 1)
- instruction_bound = p[15] & mask;
+ instruction_bound = p[15] & 0xfff;
} else {
if (p[2] & 1)
- surface_state_base = p[2] & mask;
+ surface_state_base = get_address(spec, &p[2]);
if (p[3] & 1)
- dynamic_state_base = p[3] & mask;
+ dynamic_state_base = get_address(spec, &p[3]);
if (p[5] & 1)
- instruction_base = p[5] & mask;
+ instruction_base = get_address(spec, &p[5]);
if (p[9] & 1)
- instruction_bound = p[9] & mask;
+ instruction_bound = get_address(spec, &p[9]);
}
}
@@ -784,11 +803,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int
size, int engine)
}
if ((p[0] & 0x) == AUB_MI_BATCH_BUFFER_START) {
- uint64_t start;
- if (gen_spec_get_gen(spec) >= gen_make_gen(8,0))
-start = get_qword(&p[1]);
- else
-start = p[1];
+ uint64_t start = get_address(spec, &p[1]);
if (p[0] & (1 << 22)) {
/* MI_BATCH_BUFFER_START with "2nd Level Batch Buffer" set acts
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] intel/aubinator: Add a get_offset helper
The helper automatically handles masking for us so we don't have to worry
about whether or not something is in the bottom bits.
---
src/intel/tools/aubinator.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index f5e5167..fbd8721 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -233,12 +233,6 @@ handle_3dstate_index_buffer(struct gen_spec *spec,
uint32_t *p)
}
static inline uint64_t
-get_qword(uint32_t *p)
-{
- return ((uint64_t) p[1] << 32) | p[0];
-}
-
-static inline uint64_t
get_address(struct gen_spec *spec, uint32_t *p)
{
/* Addresses are always guaranteed to be page-aligned and sometimes
@@ -259,6 +253,21 @@ get_address(struct gen_spec *spec, uint32_t *p)
return addr;
}
+static inline uint64_t
+get_offset(uint32_t *p, uint32_t start, uint32_t end)
+{
+ assert(start <= end);
+ assert(end < 64);
+
+ uint64_t mask = (~0ull >> (64 - (end - start + 1))) << start;
+
+ uint64_t offset = p[0];
+ if (end >= 32)
+ offset |= (uint64_t) p[1] << 32;
+
+ return offset & mask;
+}
+
static void
handle_state_base_address(struct gen_spec *spec, uint32_t *p)
{
@@ -418,10 +427,10 @@ handle_3dstate_vs(struct gen_spec *spec, uint32_t *p)
int vs_enable;
if (gen_spec_get_gen(spec) >= gen_make_gen(8, 0)) {
- start = get_qword(&p[1]);
+ start = get_offset(&p[1], 6, 63);
vs_enable = p[7] & 1;
} else {
- start = p[1];
+ start = get_offset(&p[1], 6, 31);
vs_enable = p[5] & 1;
}
@@ -442,9 +451,9 @@ handle_3dstate_hs(struct gen_spec *spec, uint32_t *p)
int hs_enable;
if (gen_spec_get_gen(spec) >= gen_make_gen(8, 0)) {
- start = get_qword(&p[3]);
+ start = get_offset(&p[3], 6, 63);
} else {
- start = p[3];
+ start = get_offset(&p[3], 6, 31);
}
hs_enable = p[2] & 0x8000;
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77662] Fail to render to different faces of depth-stencil cube map
https://bugs.freedesktop.org/show_bug.cgi?id=77662 Nanley Chery changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nanley Chery --- Thank you for this bug report. This bug has recently been fixed by the following commit in the master branch of the Mesa git repo: commit 63318d34acd4a5edb271d57adf3b01e2e52552f8 Author: Nanley Chery Date: Tue Nov 15 16:42:23 2016 -0800 mesa/fbobject: Update CubeMapFace when reusing textures Framebuffer attachments can be specified through FramebufferTexture* calls. Upon specifying a depth (or stencil) framebuffer attachment that internally reuses a texture, the cube map face of the new attachment would not be updated (defaulting to TEXTURE_CUBE_MAP_POSITIVE_X). Fix this issue by actually updating the CubeMapFace field. This bug manifested itself in BindFramebuffer calls performed on framebuffers whose stencil attachments internally reused a depth texture. When binding a framebuffer, we walk through the framebuffer's attachments and update each one's corresponding gl_renderbuffer. Since the framebuffer's depth and stencil attachments may share a gl_renderbuffer and the walk visits the stencil attachment after the depth attachment, the uninitialized CubeMapFace forced rendering to TEXTURE_CUBE_MAP_POSITIVE_X. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77662 Signed-off-by: Nanley Chery Reviewed-by: Brian Paul -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] anv/cmd_buffer: Enable stencil-only HZ clears
On Thu, Nov 17, 2016 at 10:06:12PM -0800, Jason Ekstrand wrote:
> On Wed, Oct 19, 2016 at 10:47 AM, Nanley Chery
> wrote:
>
> > The HZ sequence modifies less state than the blorp path and requires
> > less CPU time to generate the necessary packets.
> >
> > Signed-off-by: Nanley Chery
> > ---
> >
> > v2: Don't combine the depth alignment if statements
> >
> > src/intel/vulkan/gen8_cmd_buffer.c | 46 +++---
> >
> > 1 file changed, 33 insertions(+), 13 deletions(-)
> >
> > diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
> > b/src/intel/vulkan/gen8_cmd_buffer.c
> > index 204542e..d4410d4 100644
> > --- a/src/intel/vulkan/gen8_cmd_buffer.c
> > +++ b/src/intel/vulkan/gen8_cmd_buffer.c
> > @@ -350,15 +350,19 @@ genX(cmd_buffer_emit_hz_op)(struct anv_cmd_buffer
> > *cmd_buffer,
> >assert(cmd_state->render_area.offset.x == 0 &&
> > cmd_state->render_area.offset.y == 0);
> >
> > + bool depth_clear;
> > + bool stc_clear;
> >
>
> Mind calling this stencil_clear instead of the abbreviation. While stc is
> fairly obvious, it's not an abbreviation we usually use. Yes, it's used in
> the PRM in the docs for WM_HZ_OP, but this is the first time I'd seen it.
That sounds good. I actually wasn't very fond of using "stc" either.
> With that changed, all three are
>
> Reviewed-by: Jason Ekstrand
>
Thanks for the review.
> Sorry it took so long. :-/
It's okay.
>
> Feel free to ignore the comment below for now. I'm mostly just pointing it
> out. (Sorry if I've pointed it out before.)
>
> --Jason
>
>
> > +
> > /* This variable corresponds to the Pixel Dim column in the table
> > below */
> > struct isl_extent2d px_dim;
> >
>
> Pedanticism: I'd really rather we call this align_px or something because
> that's really what it is. Yes, it comes from the size of a HiZ block but
> the way we use it is as an alignment. We could split the difference and
> call it block_size_px or something.
>
>
align_px is a fine variable name. I don't mind us renaming it.
-Nanley
> > /* Validate that we can perform the HZ operation and that it's
> > necessary. */
> > switch (op) {
> > case BLORP_HIZ_OP_DEPTH_CLEAR:
> > - if (cmd_buffer->state.pass->attachments[ds].load_op !=
> > - VK_ATTACHMENT_LOAD_OP_CLEAR)
> > - return;
> > + stc_clear = VK_IMAGE_ASPECT_STENCIL_BIT &
> > + cmd_state->attachments[ds].pending_clear_aspects;
> > + depth_clear = VK_IMAGE_ASPECT_DEPTH_BIT &
> > +cmd_state->attachments[ds].pending_clear_aspects;
> >
> >/* Apply alignment restrictions. Despite the BDW PRM mentioning
> > this is
> > * only needed for a depth buffer surface type of D16_UNORM, testing
> > @@ -396,7 +400,7 @@ genX(cmd_buffer_emit_hz_op)(struct anv_cmd_buffer
> > *cmd_buffer,
> >px_dim = (struct isl_extent2d) { .w = 8, .h = 4};
> > #endif
> >
> > - if (!full_surface_op) {
> > + if (depth_clear && !full_surface_op) {
> > /* Fast depth clears clear an entire sample block at a time. As a
> >* result, the rectangle must be aligned to the pixel dimensions
> > of
> >* a sample block for a successful operation.
> > @@ -409,15 +413,25 @@ genX(cmd_buffer_emit_hz_op)(struct anv_cmd_buffer
> > *cmd_buffer,
> >*/
> > if (cmd_state->render_area.offset.x % px_dim.w ||
> > cmd_state->render_area.offset.y % px_dim.h)
> > -return;
> > +depth_clear = false;
> > if (cmd_state->render_area.offset.x +
> > cmd_state->render_area.extent.width != iview->extent.width
> > &&
> > cmd_state->render_area.extent.width % px_dim.w)
> > -return;
> > +depth_clear = false;
> > if (cmd_state->render_area.offset.y +
> > cmd_state->render_area.extent.height !=
> > iview->extent.height &&
> > cmd_state->render_area.extent.height % px_dim.h)
> > +depth_clear = false;
> > + }
> > +
> > + if (!depth_clear) {
> > + if (stc_clear) {
> > +/* Stencil has no alignment requirements */
> > +px_dim = (struct isl_extent2d) { .w = 1, .h = 1};
> > + } else {
> > +/* Nothing to clear */
> > return;
> > + }
> >
>}
> >break;
> > case BLORP_HIZ_OP_DEPTH_RESOLVE:
> > @@ -448,10 +462,8 @@ genX(cmd_buffer_emit_hz_op)(struct anv_cmd_buffer
> > *cmd_buffer,
> > anv_batch_emit(&cmd_buffer->batch, GENX(3DSTATE_WM_HZ_OP), hzp) {
> >switch (op) {
> >case BLORP_HIZ_OP_DEPTH_CLEAR:
> > - hzp.StencilBufferClearEnable = VK_IMAGE_ASPECT_STENCIL_BIT &
> > -cmd_state->attachments[ds].
> > pending_clear_aspects;
> > - hzp.DepthBufferClearEnable = VK_IMAGE_ASPECT_DEPTH_BIT &
> > -cmd_state->attachments[ds].
> > pending_clear_aspects;
Re: [Mesa-dev] [PATCH 14/70] mesa: create new gl_shader_program_data struct
On 11 November 2016 at 00:45, Timothy Arceri
wrote:
> This will be used to share data between gl_program and gl_shader_program
> allowing for greater code simplification as we can remove a number of
> awkward uses of gl_shader_program.
> ---
> src/mesa/main/mtypes.h| 25 +
> src/mesa/main/shaderobj.c | 41 +
> src/mesa/main/shaderobj.h | 5 +
> 3 files changed, 71 insertions(+)
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 600b1da..9500ec9 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -2625,6 +2625,31 @@ struct gl_program_resource
> };
>
> /**
> + * A data structure to be shared by gl_shader_program and gl_program.
> + */
> +struct gl_shader_program_data
> +{
> + GLint RefCount; /**< Reference count */
> +
> + unsigned NumUniformStorage;
> + unsigned NumHiddenUniforms;
> + struct gl_uniform_storage *UniformStorage;
> +
> + unsigned NumUniformBlocks;
> + struct gl_uniform_block *UniformBlocks;
> +
> + unsigned NumShaderStorageBlocks;
> + struct gl_uniform_block *ShaderStorageBlocks;
> +
> + struct gl_active_atomic_buffer *AtomicBuffers;
> + unsigned NumAtomicBuffers;
> +
> + GLboolean LinkStatus; /**< GL_LINK_STATUS */
> + GLboolean Validated;
> + GLchar *InfoLog;
> +};
> +
> +/**
> * A GLSL program object.
> * Basically a linked collection of vertex and fragment shaders.
> */
> diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
> index 8fd574e..a753a1b 100644
> --- a/src/mesa/main/shaderobj.c
> +++ b/src/mesa/main/shaderobj.c
> @@ -41,6 +41,7 @@
> #include "program/prog_parameter.h"
> #include "util/ralloc.h"
> #include "util/string_to_uint_map.h"
> +#include "util/u_atomic.h"
>
> /**/
> /*** Shader object functions***/
> @@ -208,6 +209,35 @@ _mesa_lookup_shader_err(struct gl_context *ctx, GLuint
> name, const char *caller)
> /**/
>
>
> +void
> +_mesa_reference_shader_program_data(struct gl_context *ctx,
> +struct gl_shader_program_data **ptr,
> +struct gl_shader_program_data *data)
> +{
> + if (*ptr == data)
> + return;
> +
> + if (*ptr) {
> + struct gl_shader_program_data *oldData = *ptr;
> +
> + assert(oldData->RefCount > 0);
> +
> + if (p_atomic_dec_zero(&oldData->RefCount)) {
Yay for atomics and good bye locking ;-)
> + assert(ctx);
> + ralloc_free(oldData);
> + }
> +
> + *ptr = NULL;
> + }
> +
> + assert(!*ptr);
Dull moment, when can this trigger ? We seems to have this in a fair
few places in mesa, yet nothing obvious comes up.
> + if (data) {
> + p_atomic_inc(&data->RefCount);
> + }
> +
Please drop the extra parenthesis.
> + *ptr = data;
> +}
> +
> /**
> * Set ptr to point to shProg.
> * If ptr is pointing to another object, decrement its refcount (and delete
> @@ -249,6 +279,17 @@ _mesa_reference_shader_program_(struct gl_context *ctx,
> }
> }
>
> +static struct gl_shader_program_data *
> +create_shader_program_data()
> +{
> + struct gl_shader_program_data *data;
> + data = rzalloc(NULL, struct gl_shader_program_data);
Worth passing in a ctx, (gl_shader_program *) as opposed to using NULL ?
> + if (data) {
> + data->RefCount = 1;
> + }
Drop the parenthesis ?
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 04/11] gallium: Added SWR support for gdi
Added hooks for screen creation and swap. Still keep llvmpipe the default
software renderer.
v2: split from bigger patch
v3: reword commit message
Reviewed-by: Emil Velikov
---
src/gallium/targets/libgl-gdi/libgl_gdi.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/src/gallium/targets/libgl-gdi/libgl_gdi.c
b/src/gallium/targets/libgl-gdi/libgl_gdi.c
index 922c186..12576db 100644
--- a/src/gallium/targets/libgl-gdi/libgl_gdi.c
+++ b/src/gallium/targets/libgl-gdi/libgl_gdi.c
@@ -51,9 +51,12 @@
#include "llvmpipe/lp_public.h"
#endif
+#ifdef HAVE_SWR
+#include "swr/swr_public.h"
+#endif
static boolean use_llvmpipe = FALSE;
-
+static boolean use_swr = FALSE;
static struct pipe_screen *
gdi_screen_create(void)
@@ -69,6 +72,8 @@ gdi_screen_create(void)
#ifdef HAVE_LLVMPIPE
default_driver = "llvmpipe";
+#elif HAVE_SWR
+ default_driver = "swr";
#else
default_driver = "softpipe";
#endif
@@ -78,15 +83,21 @@ gdi_screen_create(void)
#ifdef HAVE_LLVMPIPE
if (strcmp(driver, "llvmpipe") == 0) {
screen = llvmpipe_create_screen( winsys );
+ if (screen)
+ use_llvmpipe = TRUE;
+ }
+#endif
+#ifdef HAVE_SWR
+ if (strcmp(driver, "swr") == 0) {
+ screen = swr_create_screen( winsys );
+ if (screen)
+ use_swr = TRUE;
}
-#else
- (void) driver;
#endif
+ (void) driver;
if (screen == NULL) {
screen = softpipe_create_screen( winsys );
- } else {
- use_llvmpipe = TRUE;
}
if(!screen)
@@ -128,6 +139,13 @@ gdi_present(struct pipe_screen *screen,
}
#endif
+#ifdef HAVE_SWR
+ if (use_swr) {
+ swr_gdi_swap(screen, res, hDC);
+ return;
+ }
+#endif
+
winsys = softpipe_screen(screen)->winsys,
dt = softpipe_resource(res)->dt,
gdi_sw_display(winsys, dt, hDC);
--
2.10.0.windows.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 05/11] swr: Handle windows.h and NOMINMAX
Reorder header files so that we have a chance to defined NOMINMAX before
mesa include files include windows.h
v3: split from bigger patch
Reviewed-by: Emil Velikov
---
src/gallium/drivers/swr/swr_context.cpp | 16
src/gallium/drivers/swr/swr_context.h | 2 ++
src/gallium/drivers/swr/swr_screen.cpp | 25 +++--
3 files changed, 17 insertions(+), 26 deletions(-)
diff --git a/src/gallium/drivers/swr/swr_context.cpp
b/src/gallium/drivers/swr/swr_context.cpp
index a5ab236..3f57712 100644
--- a/src/gallium/drivers/swr/swr_context.cpp
+++ b/src/gallium/drivers/swr/swr_context.cpp
@@ -21,6 +21,14 @@
* IN THE SOFTWARE.
***/
+#include "swr_context.h"
+#include "swr_memory.h"
+#include "swr_screen.h"
+#include "swr_resource.h"
+#include "swr_scratch.h"
+#include "swr_query.h"
+#include "swr_fence.h"
+
#include "util/u_memory.h"
#include "util/u_inlines.h"
#include "util/u_format.h"
@@ -31,14 +39,6 @@ extern "C" {
#include "util/u_surface.h"
}
-#include "swr_context.h"
-#include "swr_memory.h"
-#include "swr_screen.h"
-#include "swr_resource.h"
-#include "swr_scratch.h"
-#include "swr_query.h"
-#include "swr_fence.h"
-
#include "api.h"
#include "backend.h"
diff --git a/src/gallium/drivers/swr/swr_context.h
b/src/gallium/drivers/swr/swr_context.h
index eecfe0d..04e11fe 100644
--- a/src/gallium/drivers/swr/swr_context.h
+++ b/src/gallium/drivers/swr/swr_context.h
@@ -24,6 +24,8 @@
#ifndef SWR_CONTEXT_H
#define SWR_CONTEXT_H
+#include "common/os.h"
+
#include "pipe/p_context.h"
#include "pipe/p_state.h"
#include "util/u_blitter.h"
diff --git a/src/gallium/drivers/swr/swr_screen.cpp
b/src/gallium/drivers/swr/swr_screen.cpp
index 0c8f5db..cc79f28 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -21,6 +21,13 @@
* IN THE SOFTWARE.
***/
+#include "swr_context.h"
+#include "swr_public.h"
+#include "swr_screen.h"
+#include "swr_resource.h"
+#include "swr_fence.h"
+#include "gen_knobs.h"
+
#include "pipe/p_screen.h"
#include "pipe/p_defines.h"
#include "util/u_memory.h"
@@ -35,13 +42,6 @@ extern "C" {
#include "gallivm/lp_bld_limits.h"
}
-#include "swr_public.h"
-#include "swr_screen.h"
-#include "swr_context.h"
-#include "swr_resource.h"
-#include "swr_fence.h"
-#include "gen_knobs.h"
-
#include "jit_api.h"
#include
@@ -1023,14 +1023,3 @@ swr_create_screen(struct sw_winsys *winsys)
return &screen->base;
}
-struct sw_winsys *
-swr_get_winsys(struct pipe_screen *pipe)
-{
- return ((struct swr_screen *)pipe)->winsys;
-}
-
-struct sw_displaytarget *
-swr_get_displaytarget(struct pipe_resource *resource)
-{
- return ((struct swr_resource *)resource)->display_target;
-}
--
2.10.0.windows.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 06/11] swr: renamed duplicate swr_create_screen()
There are 2 swr_create_screen() functions. One in swr_loader.cpp, which
is used during driver init, and the other is hiding in swr_screen.cpp,
which ends up in the arch-specific .dll/.so.
Rename the second one to swr_create_screen_internal(), to avoid confusion
in header files.
---
src/gallium/drivers/swr/swr_loader.cpp | 2 +-
src/gallium/drivers/swr/swr_public.h | 4
src/gallium/drivers/swr/swr_screen.cpp | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/swr/swr_loader.cpp
b/src/gallium/drivers/swr/swr_loader.cpp
index 2113c37..9d79fa5 100644
--- a/src/gallium/drivers/swr/swr_loader.cpp
+++ b/src/gallium/drivers/swr/swr_loader.cpp
@@ -54,7 +54,7 @@ swr_create_screen(struct sw_winsys *winsys)
exit(-1);
}
- util_dl_proc pScreenProc = util_dl_get_proc_address(pLibrary,
"swr_create_screen");
+ util_dl_proc pScreenProc = util_dl_get_proc_address(pLibrary,
"swr_create_screen_internal");
if (!pScreenProc) {
fprintf(stderr, "SWR library search failure: %s\n", util_dl_error());
diff --git a/src/gallium/drivers/swr/swr_public.h
b/src/gallium/drivers/swr/swr_public.h
index 0814c3b..7ef81bf 100644
--- a/src/gallium/drivers/swr/swr_public.h
+++ b/src/gallium/drivers/swr/swr_public.h
@@ -32,8 +32,12 @@ struct sw_displaytarget;
extern "C" {
#endif
+// driver entry point
struct pipe_screen *swr_create_screen(struct sw_winsys *winsys);
+// arch-specific dll entry point
+PUBLIC struct pipe_screen *swr_create_screen_internal(struct sw_winsys
*winsys);
+
struct sw_winsys *swr_get_winsys(struct pipe_screen *pipe);
struct sw_displaytarget *swr_get_displaytarget(struct pipe_resource *resource);
diff --git a/src/gallium/drivers/swr/swr_screen.cpp
b/src/gallium/drivers/swr/swr_screen.cpp
index cc79f28..8a85128 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -986,7 +986,7 @@ swr_destroy_screen(struct pipe_screen *p_screen)
PUBLIC
struct pipe_screen *
-swr_create_screen(struct sw_winsys *winsys)
+swr_create_screen_internal(struct sw_winsys *winsys)
{
struct swr_screen *screen = CALLOC_STRUCT(swr_screen);
--
2.10.0.windows.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 00/11] Support windows builds for OpenSWR
Changes to support Windows scons builds for OpenSWR driver, since scons
is the only supported build system for windows.
Scons swr build will not work at this point. Also, windows scons swr build
requires llvm version 3.9 (and above).
Build on windows using the following command line:
scons swr=1 libgl-gdi
Make sure you have the LLVM environment variable set, per build instructions.
This will produce 3 .dlls. The (main) opengl32.dll, and 2 swr-specific
dlls that are loaded dynamically at runtime depending on the underlying
CPU architecture (swrAVX.dll and swrAVX2.dll).
The default software renderer is still llvmpipe, and, like on linux,
you enable SWR by setting the GALLIUM_DRIVER variable to "swr".
George Kyriazis (11):
mesa: removed redundant #else
scons: ignore .hpp files in parse_source_list()
scons: add llvm 3.9 support.
gallium: Added SWR support for gdi
swr: Handle windows.h and NOMINMAX
swr: renamed duplicate swr_create_screen()
swr: Windows-related changes
scons: Add swr compile option
swr: Modify gen_knobs.{cpp|h} creation script
gallium: swr: Added swr build for windows
gallium: Add support for SWR compilation
common.py | 1 +
scons/custom.py| 2 +-
scons/llvm.py | 21 +-
src/gallium/SConscript | 1 +
src/gallium/drivers/swr/Makefile.am| 15 +-
src/gallium/drivers/swr/SConscript | 216 +
.../drivers/swr/rasterizer/scripts/gen_knobs.py| 51 ++---
src/gallium/drivers/swr/swr_context.cpp| 16 +-
src/gallium/drivers/swr/swr_context.h | 2 +
src/gallium/drivers/swr/swr_loader.cpp | 29 ++-
src/gallium/drivers/swr/swr_public.h | 11 +-
src/gallium/drivers/swr/swr_screen.cpp | 27 +--
src/gallium/targets/libgl-gdi/SConscript | 4 +
src/gallium/targets/libgl-gdi/libgl_gdi.c | 28 ++-
src/gallium/targets/libgl-xlib/SConscript | 4 +
src/gallium/targets/osmesa/SConscript | 4 +
src/util/macros.h | 1 -
17 files changed, 364 insertions(+), 69 deletions(-)
create mode 100644 src/gallium/drivers/swr/SConscript
--
2.10.0.windows.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 10/11] gallium: swr: Added swr build for windows
v4: Add windows-specific gen_knobs.{cpp|h} changes
v5: remove aggresive squashing of gen_knobs.py to this commit
Reviewed-by: Emil Velikov
---
src/gallium/SConscript | 1 +
src/gallium/drivers/swr/SConscript | 216 +
2 files changed, 217 insertions(+)
create mode 100644 src/gallium/drivers/swr/SConscript
diff --git a/src/gallium/SConscript b/src/gallium/SConscript
index f98268f..9273db7 100644
--- a/src/gallium/SConscript
+++ b/src/gallium/SConscript
@@ -18,6 +18,7 @@ SConscript([
'drivers/softpipe/SConscript',
'drivers/svga/SConscript',
'drivers/trace/SConscript',
+'drivers/swr/SConscript',
])
#
diff --git a/src/gallium/drivers/swr/SConscript
b/src/gallium/drivers/swr/SConscript
new file mode 100644
index 000..0de51a7
--- /dev/null
+++ b/src/gallium/drivers/swr/SConscript
@@ -0,0 +1,216 @@
+Import('*')
+
+from sys import executable as python_cmd
+import os.path
+import distutils.version
+
+if not env['swr']:
+Return()
+
+if not env['llvm']:
+print 'warning: LLVM disabled: not building swr'
+env['swr'] = False
+Return()
+
+if env['LLVM_VERSION'] < distutils.version.LooseVersion('3.9'):
+print "warning: swr requires LLVM >= 3.9: not building swr"
+env['swr'] = False
+Return()
+
+if env['platform'] != 'windows':
+print "warning: swr scons build only supports windows: not building swr"
+env['swr'] = False
+Return()
+
+env.MSVC2013Compat()
+
+env = env.Clone()
+
+# construct llvm include dir
+if env['platform'] == 'windows':
+# on windows there is no llvm-config, so LLVM is defined
+llvm_includedir = os.path.join(os.environ['LLVM'], 'include')
+else:
+llvm_includedir = env.backtick('llvm-config --includedir').rstrip()
+print "llvm include dir %s" % llvm_includedir
+
+# the loader is included in the mesa lib itself
+# All the remaining files are in loadable modules
+loadersource = env.ParseSourceList('Makefile.sources', [
+'LOADER_SOURCES'
+])
+
+env.Append(CPPDEFINES = [
+'__STDC_CONSTANT_MACROS',
+'__STDC_LIMIT_MACROS'
+])
+
+if not env['msvc'] :
+env.Append(CCFLAGS = [
+'-std=c++11',
+])
+
+swrroot = '#src/gallium/drivers/swr/'
+
+env.CodeGenerate(
+target = 'rasterizer/scripts/gen_knobs.cpp',
+script = swrroot + 'rasterizer/scripts/gen_knobs.py',
+source = 'rasterizer/scripts/templates/knobs.template',
+command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET
--gen_cpp'
+)
+
+env.CodeGenerate(
+target = 'rasterizer/scripts/gen_knobs.h',
+script = swrroot + 'rasterizer/scripts/gen_knobs.py',
+source = 'rasterizer/scripts/templates/knobs.template',
+command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET --gen_h'
+)
+
+env.CodeGenerate(
+target = 'rasterizer/jitter/state_llvm.h',
+script = swrroot + 'rasterizer/jitter/scripts/gen_llvm_types.py',
+source = 'rasterizer/core/state.h',
+command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET'
+)
+
+env.CodeGenerate(
+target = 'rasterizer/jitter/builder_gen.h',
+script = swrroot + 'rasterizer/jitter/scripts/gen_llvm_ir_macros.py',
+source = os.path.join(llvm_includedir, 'llvm/IR/IRBuilder.h'),
+command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET --gen_h'
+)
+
+env.CodeGenerate(
+target = 'rasterizer/jitter/builder_gen.cpp',
+script = swrroot + 'rasterizer/jitter/scripts/gen_llvm_ir_macros.py',
+source = os.path.join(llvm_includedir, 'llvm/IR/IRBuilder.h'),
+command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET
--gen_cpp'
+)
+
+env.CodeGenerate(
+target = 'rasterizer/jitter/builder_x86.h',
+script = swrroot + 'rasterizer/jitter/scripts/gen_llvm_ir_macros.py',
+source = '',
+command = python_cmd + ' $SCRIPT --output $TARGET --gen_x86_h'
+)
+
+env.CodeGenerate(
+target = 'rasterizer/jitter/builder_x86.cpp',
+script = swrroot + 'rasterizer/jitter/scripts/gen_llvm_ir_macros.py',
+source = '',
+command = python_cmd + ' $SCRIPT --output $TARGET --gen_x86_cpp'
+)
+
+env.CodeGenerate(
+target = 'swr_context_llvm.h',
+script = swrroot + 'rasterizer/jitter/scripts/gen_llvm_types.py',
+source = 'swr_context.h',
+command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET'
+)
+
+env.CodeGenerate(
+target = 'rasterizer/archrast/gen_ar_event.h',
+script = swrroot + 'rasterizer/scripts/gen_archrast.py',
+source = 'rasterizer/archrast/events.proto',
+command = python_cmd + ' $SCRIPT --proto $SOURCE --output $TARGET
--gen_event_h'
+)
+
+env.CodeGenerate(
+target = 'rasterizer/archrast/gen_ar_event.cpp',
+script = swrroot + 'rasterizer/scripts/gen_archrast.py',
+source = 'rasterizer/archrast/events.proto',
+command = python_cmd + ' $SCRIPT --proto $SOURCE --output $TARGET
--gen_event_cpp'
+)
+
+env.CodeGenerate(
+target = 'rasterizer/archrast/gen_ar_eventhandler.h',
+script = swrroot +
[Mesa-dev] [PATCH v5 08/11] scons: Add swr compile option
To buils The SWR driver (currently optional, not compiled by default)
v3: add option as opposed to target
Reviewed-by: Emil Velikov
---
common.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/common.py b/common.py
index fb0884e..704ad2e 100644
--- a/common.py
+++ b/common.py
@@ -110,5 +110,6 @@ def AddOptions(opts):
opts.Add(BoolOption('texture_float',
'enable floating-point textures and renderbuffers',
'no'))
+opts.Add(BoolOption('swr', 'Build OpenSWR', 'no'))
if host_platform == 'windows':
opts.Add('MSVC_VERSION', 'Microsoft Visual C/C++ version')
--
2.10.0.windows.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 02/11] scons: ignore .hpp files in parse_source_list()
Drivers that contain C++ .hpp files need to ignore them too, along
with .h files, when building source file lists.
Reviewed-by: Emil Velikov
---
scons/custom.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scons/custom.py b/scons/custom.py
index bdb4039..544b15d 100644
--- a/scons/custom.py
+++ b/scons/custom.py
@@ -281,7 +281,7 @@ def parse_source_list(env, filename, names=None):
# cause duplicate actions.
f = f[len(cur_srcdir + '/'):]
# do not include any headers
-if f.endswith('.h'):
+if f.endswith(tuple(['.h','.hpp'])):
continue
srcs.append(f)
--
2.10.0.windows.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 03/11] scons: add llvm 3.9 support.
v2: reworded commit message
Reviewed-by: Emil Velikov
---
scons/llvm.py | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index 1fc8a3f..977e47a 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -106,7 +106,24 @@ def generate(env):
])
env.Prepend(LIBPATH = [os.path.join(llvm_dir, 'lib')])
# LIBS should match the output of `llvm-config --libs engine mcjit
bitwriter x86asmprinter`
-if llvm_version >= distutils.version.LooseVersion('3.7'):
+if llvm_version >= distutils.version.LooseVersion('3.9'):
+env.Prepend(LIBS = [
+'LLVMX86Disassembler', 'LLVMX86AsmParser',
+'LLVMX86CodeGen', 'LLVMSelectionDAG', 'LLVMAsmPrinter',
+'LLVMDebugInfoCodeView', 'LLVMCodeGen',
+'LLVMScalarOpts', 'LLVMInstCombine',
+'LLVMInstrumentation', 'LLVMTransformUtils',
+'LLVMBitWriter', 'LLVMX86Desc',
+'LLVMMCDisassembler', 'LLVMX86Info',
+'LLVMX86AsmPrinter', 'LLVMX86Utils',
+'LLVMMCJIT', 'LLVMExecutionEngine', 'LLVMTarget',
+'LLVMAnalysis', 'LLVMProfileData',
+'LLVMRuntimeDyld', 'LLVMObject', 'LLVMMCParser',
+'LLVMBitReader', 'LLVMMC', 'LLVMCore',
+'LLVMSupport',
+'LLVMIRReader', 'LLVMASMParser'
+])
+elif llvm_version >= distutils.version.LooseVersion('3.7'):
env.Prepend(LIBS = [
'LLVMBitWriter', 'LLVMX86Disassembler', 'LLVMX86AsmParser',
'LLVMX86CodeGen', 'LLVMSelectionDAG', 'LLVMAsmPrinter',
@@ -203,7 +220,7 @@ def generate(env):
if '-fno-rtti' in cxxflags:
env.Append(CXXFLAGS = ['-fno-rtti'])
-components = ['engine', 'mcjit', 'bitwriter', 'x86asmprinter',
'mcdisassembler']
+components = ['engine', 'mcjit', 'bitwriter', 'x86asmprinter',
'mcdisassembler', 'irreader']
env.ParseConfig('llvm-config --libs ' + ' '.join(components))
env.ParseConfig('llvm-config --ldflags')
--
2.10.0.windows.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 07/11] swr: Windows-related changes
- Handle dynamic library loading for windows
- Implement swap for gdi
- fix prototypes
- update include paths on configure-based build for swr_loader.cpp
v2: split to multiple patches
v3: split and reshuffle some more; renamed title
v4: move Makefile.am changes to other commit. Modify header files
---
src/gallium/drivers/swr/swr_loader.cpp | 27 ---
src/gallium/drivers/swr/swr_public.h | 9 +
2 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/swr/swr_loader.cpp
b/src/gallium/drivers/swr/swr_loader.cpp
index 9d79fa5..4d71a67 100644
--- a/src/gallium/drivers/swr/swr_loader.cpp
+++ b/src/gallium/drivers/swr/swr_loader.cpp
@@ -25,14 +25,16 @@
#include "util/u_dl.h"
#include "swr_public.h"
+#include "pipe/p_screen.h"
+
#include
-#include
typedef pipe_screen *(*screen_create_proc)(struct sw_winsys *winsys);
struct pipe_screen *
swr_create_screen(struct sw_winsys *winsys)
{
+ char filename[256];
fprintf(stderr, "SWR detected ");
util_dl_library *pLibrary = nullptr;
@@ -40,14 +42,15 @@ swr_create_screen(struct sw_winsys *winsys)
util_cpu_detect();
if (util_cpu_caps.has_avx2) {
fprintf(stderr, "AVX2\n");
- pLibrary = util_dl_open("libswrAVX2.so");
+ sprintf(filename, "%s%s%s", UTIL_DL_PREFIX, "swrAVX2", UTIL_DL_EXT);
} else if (util_cpu_caps.has_avx) {
fprintf(stderr, "AVX\n");
- pLibrary = util_dl_open("libswrAVX.so");
+ sprintf(filename, "%s%s%s", UTIL_DL_PREFIX, "swrAVX", UTIL_DL_EXT);
} else {
fprintf(stderr, "no AVX/AVX2 support. Aborting!\n");
exit(-1);
}
+ pLibrary = util_dl_open(filename);
if (!pLibrary) {
fprintf(stderr, "SWR library load failure: %s\n", util_dl_error());
@@ -65,3 +68,21 @@ swr_create_screen(struct sw_winsys *winsys)
return pScreenCreate(winsys);
}
+
+
+#ifdef _WIN32
+// swap function called from libl_gdi.c
+
+void
+swr_gdi_swap(struct pipe_screen *screen,
+ struct pipe_resource *res,
+ void *hDC)
+{
+ screen->flush_frontbuffer(screen,
+ res,
+ 0, 0,
+ hDC,
+ NULL);
+}
+
+#endif /* _WIN32 */
diff --git a/src/gallium/drivers/swr/swr_public.h
b/src/gallium/drivers/swr/swr_public.h
index 7ef81bf..4b15070 100644
--- a/src/gallium/drivers/swr/swr_public.h
+++ b/src/gallium/drivers/swr/swr_public.h
@@ -38,10 +38,11 @@ struct pipe_screen *swr_create_screen(struct sw_winsys
*winsys);
// arch-specific dll entry point
PUBLIC struct pipe_screen *swr_create_screen_internal(struct sw_winsys
*winsys);
-struct sw_winsys *swr_get_winsys(struct pipe_screen *pipe);
-
-struct sw_displaytarget *swr_get_displaytarget(struct pipe_resource *resource);
-
+#ifdef _WIN32
+void swr_gdi_swap(struct pipe_screen *screen,
+ struct pipe_resource *res,
+ void *hDC);
+#endif /* _WIN32 */
#ifdef __cplusplus
}
--
2.10.0.windows.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 09/11] swr: Modify gen_knobs.{cpp|h} creation script
Modify gen_knobs.py so that each invocation creates a single generated
file. This is more similar to how the other generators behave.
v5: remove Scoscript edits from this commit; moved to commit that first
adds SConscript
Acked-by: Emil Velikov
---
src/gallium/drivers/swr/Makefile.am| 15 ++-
.../drivers/swr/rasterizer/scripts/gen_knobs.py| 51 --
2 files changed, 40 insertions(+), 26 deletions(-)
diff --git a/src/gallium/drivers/swr/Makefile.am
b/src/gallium/drivers/swr/Makefile.am
index dd1c2e6..b22ded0 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -71,11 +71,21 @@ swr_context_llvm.h:
rasterizer/jitter/scripts/gen_llvm_types.py swr_context.h
--input $(srcdir)/swr_context.h \
--output swr_context_llvm.h
-rasterizer/scripts/gen_knobs.cpp rasterizer/scripts/gen_knobs.h:
rasterizer/scripts/gen_knobs.py rasterizer/scripts/knob_defs.py
rasterizer/scripts/templates/knobs.template
+rasterizer/scripts/gen_knobs.cpp: rasterizer/scripts/gen_knobs.py
rasterizer/scripts/knob_defs.py rasterizer/scripts/templates/knobs.template
$(MKDIR_GEN)
$(PYTHON_GEN) \
$(srcdir)/rasterizer/scripts/gen_knobs.py \
- rasterizer/scripts
+ --input $(srcdir)/rasterizer/scripts/templates/knobs.template \
+ --output rasterizer/scripts/gen_knobs.cpp \
+ --gen_cpp
+
+rasterizer/scripts/gen_knobs.h: rasterizer/scripts/gen_knobs.py
rasterizer/scripts/knob_defs.py rasterizer/scripts/templates/knobs.template
+ $(MKDIR_GEN)
+ $(PYTHON_GEN) \
+ $(srcdir)/rasterizer/scripts/gen_knobs.py \
+ --input $(srcdir)/rasterizer/scripts/templates/knobs.template \
+ --output rasterizer/scripts/gen_knobs.h \
+ --gen_h
rasterizer/jitter/state_llvm.h: rasterizer/jitter/scripts/gen_llvm_types.py
rasterizer/core/state.h
$(MKDIR_GEN)
@@ -235,6 +245,7 @@ libswrAVX2_la_LDFLAGS = \
include $(top_srcdir)/install-gallium-links.mk
EXTRA_DIST = \
+ SConscript \
rasterizer/archrast/events.proto \
rasterizer/jitter/scripts/gen_llvm_ir_macros.py \
rasterizer/jitter/scripts/gen_llvm_types.py \
diff --git a/src/gallium/drivers/swr/rasterizer/scripts/gen_knobs.py
b/src/gallium/drivers/swr/rasterizer/scripts/gen_knobs.py
index 3d003fb..225082e 100644
--- a/src/gallium/drivers/swr/rasterizer/scripts/gen_knobs.py
+++ b/src/gallium/drivers/swr/rasterizer/scripts/gen_knobs.py
@@ -23,13 +23,14 @@
from __future__ import print_function
import os
import sys
+import argparse
import knob_defs
from mako.template import Template
from mako.exceptions import RichTraceback
def write_template_to_string(template_filename, **kwargs):
try:
-template = Template(filename=template_filename)
+template = Template(filename=os.path.abspath(template_filename))
# Split + Join fixes line-endings for whatever platform you are using
return '\n'.join(template.render(**kwargs).splitlines())
except:
@@ -40,37 +41,39 @@ def write_template_to_string(template_filename, **kwargs):
print("%s: %s" % (str(traceback.error.__class__.__name__),
traceback.error))
def write_template_to_file(template_filename, output_filename, **kwargs):
+output_dirname = os.path.dirname(output_filename)
+if not os.path.exists(output_dirname):
+os.makedirs(output_dirname)
with open(output_filename, "w") as outfile:
print(write_template_to_string(template_filename, **kwargs),
file=outfile)
def main(args=sys.argv[1:]):
-if len(args) != 1:
-print('Usage:', sys.argv[0], '', file=sys.stderr)
-return 1
-output_dir = args[0]
-if not os.path.isdir(output_dir):
-if os.path.exists(output_dir):
-print('ERROR: Invalid output directory:', output_dir,
file=sys.stderr)
-return 1
+# parse args
+parser = argparse.ArgumentParser()
+parser.add_argument("--input", "-i", help="Path to knobs.template",
required=True)
+parser.add_argument("--output", "-o", help="Path to output file",
required=True)
+parser.add_argument("--gen_h", "-gen_h", help="Generate gen_knobs.h",
action="store_true", default=False)
+parser.add_argument("--gen_cpp", "-gen_cpp", help="Generate
gen_knobs.cpp", action="store_true", required=False)
-try:
-os.makedirs(output_dir)
-except:
-print('ERROR: Could not create output directory:', output_dir,
file=sys.stderr)
-return 1
+args = parser.parse_args()
-# Output path exists, now just run the template
-template_file = os.sep.join([sys.path[0], 'templates', 'knobs.template'])
-output_file = os.sep.join([output_dir, 'gen_knobs.cpp'])
-output_header = os.sep.join([output_dir, 'gen_knobs.h'])
+if args.input:
+if args.gen_h:
+writ
[Mesa-dev] [PATCH v5 01/11] mesa: removed redundant #else
Reviewed-by: Emil Velikov
---
src/util/macros.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/util/macros.h b/src/util/macros.h
index 733bf42..6f55ac6 100644
--- a/src/util/macros.h
+++ b/src/util/macros.h
@@ -178,7 +178,6 @@ do { \
# elif defined(_MSC_VER) && !defined(__INTEL_COMPILER)
# if _MSC_VER >= 1800
# define HAS_TRIVIAL_DESTRUCTOR(T) __has_trivial_destructor(T)
-# else
# endif
# endif
# ifndef HAS_TRIVIAL_DESTRUCTOR
--
2.10.0.windows.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 11/11] gallium: Add support for SWR compilation
Include swr library and include -DHAVE_SWR in the compile line. v3: split to a separate commit Reviewed-by: Emil Velikov --- src/gallium/targets/libgl-gdi/SConscript | 4 src/gallium/targets/libgl-xlib/SConscript | 4 src/gallium/targets/osmesa/SConscript | 4 3 files changed, 12 insertions(+) diff --git a/src/gallium/targets/libgl-gdi/SConscript b/src/gallium/targets/libgl-gdi/SConscript index 2a52363..d3251ca 100644 --- a/src/gallium/targets/libgl-gdi/SConscript +++ b/src/gallium/targets/libgl-gdi/SConscript @@ -30,6 +30,10 @@ if env['llvm']: env.Append(CPPDEFINES = 'HAVE_LLVMPIPE') drivers += [llvmpipe] +if env['swr']: +env.Append(CPPDEFINES = 'HAVE_SWR') +drivers += [swr] + if env['gcc'] and env['machine'] != 'x86_64': # DEF parser in certain versions of MinGW is busted, as does not behave as # MSVC. mingw-w64 works fine. diff --git a/src/gallium/targets/libgl-xlib/SConscript b/src/gallium/targets/libgl-xlib/SConscript index 0a4f31b..d01bb3c 100644 --- a/src/gallium/targets/libgl-xlib/SConscript +++ b/src/gallium/targets/libgl-xlib/SConscript @@ -48,6 +48,10 @@ if env['llvm']: env.Append(CPPDEFINES = ['GALLIUM_LLVMPIPE']) env.Prepend(LIBS = [llvmpipe]) +if env['swr']: +env.Append(CPPDEFINES = 'HAVE_SWR') +env.Prepend(LIBS = [swr]) + if env['platform'] != 'darwin': # Disallow undefined symbols, except with Address Sanitizer, since libasan # is not linked on shared libs, as it should be LD_PRELOAD'ed instead diff --git a/src/gallium/targets/osmesa/SConscript b/src/gallium/targets/osmesa/SConscript index 7a2a00c..47937a2 100644 --- a/src/gallium/targets/osmesa/SConscript +++ b/src/gallium/targets/osmesa/SConscript @@ -30,6 +30,10 @@ if env['llvm']: env.Append(CPPDEFINES = 'GALLIUM_LLVMPIPE') env.Prepend(LIBS = [llvmpipe]) +if env['swr']: +env.Append(CPPDEFINES = 'HAVE_SWR') +env.Prepend(LIBS = [swr]) + if env['platform'] == 'windows': if env['gcc'] and env['machine'] != 'x86_64': sources += ['osmesa.mingw.def'] -- 2.10.0.windows.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/70] st/mesa/glsl/nir/i965: make use of new gl_shader_program_data in gl_shader_program
Hi Tim, In general we could use the odd local variable to make things shorter (and cut down the number of derefs). That can (should?) be done once we're finished with the big churn. On 11 November 2016 at 00:45, Timothy Arceri wrote: > @@ -296,6 +296,8 @@ init_shader_program(struct gl_shader_program *prog) > prog->Type = GL_SHADER_PROGRAM_MESA; > prog->RefCount = 1; > > + prog->data = create_shader_program_data(); > + This can fail. Please move it a level up (such that it's symmetric to the dtor) and call ralloc_free(shProg) on failure. > prog->AttributeBindings = string_to_uint_map_ctor(); > prog->FragDataBindings = string_to_uint_map_ctor(); > prog->FragDataIndexBindings = string_to_uint_map_ctor(); > @@ -309,7 +311,7 @@ init_shader_program(struct gl_shader_program *prog) > > exec_list_make_empty(&prog->EmptyUniformLocations); > > - prog->InfoLog = ralloc_strdup(prog, ""); > + prog->data->InfoLog = ralloc_strdup(prog->data, ""); IMHO it's fine keeping this piece here (despite the above suggestion). > + _mesa_uniform_detach_all_driver_storage(&shProg->data-> > +UniformStorage[i]); Hmm had no idea this is legal. Wondering how many compilers will be happy with it - worth keeping on single line ? Please check if we leak due to the missing ctx in create_shader_program_data() and if we're fine _do_ ignore my suggestion. With the small nitpicks patches 12-15 incl. are Reviewed-by: Emil Velikov -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] st/va: fix gop size for rate control
From: Boyuan Zhang
The gop_size in rate control is the budget window for internal rate
control calculation, and shouldn't always equal to idr period. Define
a coefficient to let budget window contains a number of idr period for
proper rate control calculation. Adjust the number of i/p frame remaining
accordingly.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98005
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/picture.c| 18 --
src/gallium/state_trackers/va/va_private.h | 2 ++
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index 592cdef..b5b9a83 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -351,7 +351,11 @@ handleVAEncSequenceParameterBufferType(vlVaDriver *drv,
vlVaContext *context, vl
if (!context->decoder)
return VA_STATUS_ERROR_ALLOCATION_FAILED;
}
- context->desc.h264enc.gop_size = h264->intra_idr_period;
+
+ context->gop_coeff = ((1024 + h264->intra_idr_period - 1) /
h264->intra_idr_period + 1) / 2 * 2;
+ if (context->gop_coeff > VL_VA_ENC_GOP_COEFF)
+ context->gop_coeff = VL_VA_ENC_GOP_COEFF;
+ context->desc.h264enc.gop_size = h264->intra_idr_period *
context->gop_coeff;
context->desc.h264enc.rate_ctrl.frame_rate_num = h264->time_scale / 2;
context->desc.h264enc.rate_ctrl.frame_rate_den = 1;
return VA_STATUS_SUCCESS;
@@ -391,10 +395,10 @@ handleVAEncPictureParameterBufferType(vlVaDriver *drv,
vlVaContext *context, vlV
context->desc.h264enc.not_referenced = false;
context->desc.h264enc.is_idr = (h264->pic_fields.bits.idr_pic_flag == 1);
context->desc.h264enc.pic_order_cnt = h264->CurrPic.TopFieldOrderCnt;
- if (context->desc.h264enc.is_idr)
- context->desc.h264enc.i_remain = 1;
- else
- context->desc.h264enc.i_remain = 0;
+ if (context->desc.h264enc.gop_cnt == 0)
+ context->desc.h264enc.i_remain = context->gop_coeff;
+ else if (context->desc.h264enc.frame_num == 1)
+ context->desc.h264enc.i_remain--;
context->desc.h264enc.p_remain = context->desc.h264enc.gop_size -
context->desc.h264enc.gop_cnt - context->desc.h264enc.i_remain;
@@ -578,6 +582,8 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
context->decoder->end_frame(context->decoder, context->target,
&context->desc.base);
if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
+ int idr_period = context->desc.h264enc.gop_size / context->gop_coeff;
+ int p_remain_in_idr = idr_period - context->desc.h264enc.frame_num;
surf->frame_num_cnt = context->desc.h264enc.frame_num_cnt;
surf->force_flushed = false;
if (context->first_single_submitted) {
@@ -585,7 +591,7 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
context->first_single_submitted = false;
surf->force_flushed = true;
}
- if (context->desc.h264enc.p_remain == 1) {
+ if (p_remain_in_idr == 1) {
if ((context->desc.h264enc.frame_num_cnt % 2) != 0) {
context->decoder->flush(context->decoder);
context->first_single_submitted = true;
diff --git a/src/gallium/state_trackers/va/va_private.h
b/src/gallium/state_trackers/va/va_private.h
index 9e3ba03..900abbc 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -50,6 +50,7 @@
#define VL_VA_PSCREEN(ctx) (VL_VA_DRIVER(ctx)->vscreen->pscreen)
#define VL_VA_MAX_IMAGE_FORMATS 9
+#define VL_VA_ENC_GOP_COEFF 16
static inline enum pipe_video_chroma_format
ChromaToPipe(int format)
@@ -245,6 +246,7 @@ typedef struct {
struct vlVaBuffer *coded_buf;
int target_id;
bool first_single_submitted;
+ int gop_coeff;
} vlVaContext;
typedef struct {
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] intel/aubinator: Properly handle batch buffer chaining
On Fri, Nov 18, 2016 at 11:54 AM Jason Ekstrand
wrote:
> From: Jason Ekstrand
>
> The original aubinator that Kristian wrote had a bug in the handling of
> MI_BATCH_BUFFER_START that propagated into the version in upstream mesa.
> In particular, it ignored the "2nd level" bit which tells you whether this
> MI_BATCH_BUFFER_START is a subroutine call (2nd level) or a goto. Since
> the Vulkan driver uses batch chaining, this can lead to a very confusing
> interpretation of the batches. In some cases, depending on how things are
> laid out in the virtual GTT, you can even end up with infinite loops in
> batch processing.
>
>
All four:
Reviewed-by: Kristian H. Kristensen
> Signed-off-by: Jason Ekstrand
> ---
> src/intel/tools/aubinator.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> index 0d4b3f9..78682c5 100644
> --- a/src/intel/tools/aubinator.c
> +++ b/src/intel/tools/aubinator.c
> @@ -790,7 +790,25 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds,
> int size, int engine)
> else
> start = p[1];
>
> - parse_commands(spec, gtt + start, 1 << 20, engine);
> + if (p[0] & (1 << 22)) {
> +/* MI_BATCH_BUFFER_START with "2nd Level Batch Buffer" set
> acts
> + * like a subroutine call. Commands that come afterwards get
> + * processed once the 2nd level batch buffer returns with
> + * MI_BATCH_BUFFER_END.
> + */
> +parse_commands(spec, gtt + start, gtt_end - start, engine);
> + } else {
> +/* MI_BATCH_BUFFER_START with "2nd Level Batch Buffer" unset
> acts
> + * like a goto. Nothing after it will ever get processed. In
> + * order to prevent the recursion from growing, we just reset
> the
> + * loop and continue;
> + */
> +p = gtt + start;
> +/* We don't know where secondaries end so use the GTT end */
> +end = gtt + gtt_end;
> +length = 0;
> +continue;
> + }
>} else if ((p[0] & 0x) == AUB_MI_BATCH_BUFFER_END) {
> break;
>}
> --
> 2.5.0.400.gff86faf
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/va: force to submit two consecutive single jobs
From: Boyuan Zhang
When using dual instance and rate control, driver needs to submit jobs either
in dual submissions or 2 consecutive single submissions to keep the pattern
constant for rate control
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98005
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/picture.c| 24 +++-
src/gallium/state_trackers/va/surface.c| 8 ++--
src/gallium/state_trackers/va/va_private.h | 2 ++
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index a8102a4..592cdef 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -413,7 +413,6 @@ handleVAEncPictureParameterBufferType(vlVaDriver *drv,
vlVaContext *context, vlV
context->desc.h264enc.quant_i_frames = h264->pic_init_qp;
context->desc.h264enc.quant_b_frames = h264->pic_init_qp;
context->desc.h264enc.quant_p_frames = h264->pic_init_qp;
- context->desc.h264enc.frame_num_cnt++;
context->desc.h264enc.gop_cnt++;
if (context->desc.h264enc.gop_cnt == context->desc.h264enc.gop_size)
context->desc.h264enc.gop_cnt = 0;
@@ -569,18 +568,33 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID
context_id)
if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
coded_buf = context->coded_buf;
getEncParamPreset(context);
+ context->desc.h264enc.frame_num_cnt++;
context->decoder->begin_frame(context->decoder, context->target,
&context->desc.base);
context->decoder->encode_bitstream(context->decoder, context->target,
coded_buf->derived_surface.resource,
&feedback);
- surf->frame_num_cnt = context->desc.h264enc.frame_num_cnt;
surf->feedback = feedback;
surf->coded_buf = coded_buf;
}
context->decoder->end_frame(context->decoder, context->target,
&context->desc.base);
- if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE &&
- context->desc.h264enc.p_remain == 1)
- context->decoder->flush(context->decoder);
+ if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
+ surf->frame_num_cnt = context->desc.h264enc.frame_num_cnt;
+ surf->force_flushed = false;
+ if (context->first_single_submitted) {
+ context->decoder->flush(context->decoder);
+ context->first_single_submitted = false;
+ surf->force_flushed = true;
+ }
+ if (context->desc.h264enc.p_remain == 1) {
+ if ((context->desc.h264enc.frame_num_cnt % 2) != 0) {
+context->decoder->flush(context->decoder);
+context->first_single_submitted = true;
+ }
+ else
+context->first_single_submitted = false;
+ surf->force_flushed = true;
+ }
+ }
pipe_mutex_unlock(drv->mutex);
return VA_STATUS_SUCCESS;
}
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
index f8513d9..78342a1 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -125,12 +125,16 @@ vlVaSyncSurface(VADriverContextP ctx, VASurfaceID
render_target)
if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
int frame_diff;
- if (context->desc.h264enc.frame_num_cnt > surf->frame_num_cnt)
+ if (context->desc.h264enc.frame_num_cnt >= surf->frame_num_cnt)
frame_diff = context->desc.h264enc.frame_num_cnt -
surf->frame_num_cnt;
else
frame_diff = 0x - surf->frame_num_cnt + 1 +
context->desc.h264enc.frame_num_cnt;
- if (frame_diff < 2)
+ if (frame_diff == 0 && surf->force_flushed == false) {
context->decoder->flush(context->decoder);
+ if (context->desc.h264enc.rate_ctrl.rate_ctrl_method ==
+PIPE_H264_ENC_RATE_CONTROL_METHOD_VARIABLE)
+context->first_single_submitted = true;
+ }
context->decoder->get_feedback(context->decoder, surf->feedback,
&(surf->coded_buf->coded_size));
surf->feedback = NULL;
}
diff --git a/src/gallium/state_trackers/va/va_private.h
b/src/gallium/state_trackers/va/va_private.h
index c9a6a41..9e3ba03 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -244,6 +244,7 @@ typedef struct {
struct vl_deint_filter *deint;
struct vlVaBuffer *coded_buf;
int target_id;
+ bool first_single_submitted;
} vlVaContext;
typedef struct {
@@ -274,6 +275,7 @@ typedef struct {
vlVaBuffer *coded_buf;
void *feedback;
unsigned int frame_num_cnt;
+ bool force_flushed;
} vlVaSurface;
// Public functions:
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4] clover: restore support for LLVM <= 3.9
On Fri, Nov 18, 2016 at 10:57 AM, Vedran Miletić wrote:
> The commit 8e430ff8b060b4e8e922bae24b3c57837da6ea77 support for LLVM
> 3.9 and older versionsin Clover. This patch restores it and refactors
> the support using Clover compatibility layer for LLVM.
>
> Signed-off-by: Vedran Miletić
> ---
> .../state_trackers/clover/llvm/codegen/bitcode.cpp | 9 ++
> src/gallium/state_trackers/clover/llvm/compat.hpp | 35
> ++
> 2 files changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> index 5dcc4f8..4b4ae41 100644
> --- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> @@ -32,6 +32,7 @@
> ///
>
> #include "llvm/codegen.hpp"
> +#include "llvm/compat.hpp"
> #include "llvm/metadata.hpp"
> #include "core/error.hpp"
> #include "util/algorithm.hpp"
> @@ -99,13 +100,7 @@ clover::llvm::parse_module_library(const module &m,
> ::llvm::LLVMContext &ctx,
> auto mod = ::llvm::parseBitcodeFile(::llvm::MemoryBufferRef(
> as_string(m.secs[0].data), " "),
> ctx);
>
> - if (::llvm::Error err = mod.takeError()) {
> - std::string msg;
> - ::llvm::handleAllErrors(std::move(err), [&](::llvm::ErrorInfoBase
> &EIB) {
> - msg = EIB.message();
> - fail(r_log, error(CL_INVALID_PROGRAM), msg.c_str());
> - });
> - }
> + compat::handle_module_error(mod, r_log);
>
> return std::unique_ptr<::llvm::Module>(std::move(*mod));
> }
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index a963cff..b29100f 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -39,6 +39,11 @@
> #include
> #include
> #include
> +#if HAVE_LLVM >= 0x0400
> +#include
> +#else
> +#include
> +#endif
>
> #if HAVE_LLVM >= 0x0307
> #include
> @@ -53,6 +58,14 @@
> #include
> #include
>
> +#if HAVE_LLVM >= 0x0307
> +#include
> +#endif
> +
> +namespace llvm {
> + class Module;
> +}
> +
> namespace clover {
> namespace llvm {
>namespace compat {
> @@ -158,6 +171,28 @@ namespace clover {
> #else
> const auto default_reloc_model = ::llvm::Reloc::Default;
> #endif
> +
> +#if HAVE_LLVM >= 0x0400
> + typedef ::llvm::Expected>
> bitcode_module;
> +#elif HAVE_LLVM >= 0x0307
> + typedef ::llvm::ErrorOr>
> bitcode_module;
> +#else
> + typedef ::llvm::ErrorOr<::llvm::Module *> bitcode_module;
> +#endif
> +
> + inline void
> + handle_module_error(bitcode_module &mod, std::string &r_log) {
> +#if HAVE_LLVM >= 0x0400
> +if (::llvm::Error err = mod.takeError()) {
> + ::llvm::handleAllErrors(std::move(err),
> [&](::llvm::ErrorInfoBase &EIB) {
> + fail(r_log, error(CL_INVALID_PROGRAM),
> EIB.message().c_str());
> + });
> +}
> +#else
> +if (!mod)
> + fail(r_log, error(CL_INVALID_PROGRAM),
> mod.getError().message());
> +#endif
> + }
>}
> }
> }
> --
> 2.7.4
>
This patch fixes builds with llvm-3.8.
Tested-by: Vinson Lee
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 14/70] mesa: create new gl_shader_program_data struct
On Fri, 2016-11-18 at 20:35 +, Emil Velikov wrote:
> On 11 November 2016 at 00:45, Timothy Arceri
> wrote:
> >
> > This will be used to share data between gl_program and
> > gl_shader_program
> > allowing for greater code simplification as we can remove a number
> > of
> > awkward uses of gl_shader_program.
> > ---
> > src/mesa/main/mtypes.h| 25 +
> > src/mesa/main/shaderobj.c | 41
> > +
> > src/mesa/main/shaderobj.h | 5 +
> > 3 files changed, 71 insertions(+)
> >
> > diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> > index 600b1da..9500ec9 100644
> > --- a/src/mesa/main/mtypes.h
> > +++ b/src/mesa/main/mtypes.h
> > @@ -2625,6 +2625,31 @@ struct gl_program_resource
> > };
> >
> > /**
> > + * A data structure to be shared by gl_shader_program and
> > gl_program.
> > + */
> > +struct gl_shader_program_data
> > +{
> > + GLint RefCount; /**< Reference count */
> > +
> > + unsigned NumUniformStorage;
> > + unsigned NumHiddenUniforms;
> > + struct gl_uniform_storage *UniformStorage;
> > +
> > + unsigned NumUniformBlocks;
> > + struct gl_uniform_block *UniformBlocks;
> > +
> > + unsigned NumShaderStorageBlocks;
> > + struct gl_uniform_block *ShaderStorageBlocks;
> > +
> > + struct gl_active_atomic_buffer *AtomicBuffers;
> > + unsigned NumAtomicBuffers;
> > +
> > + GLboolean LinkStatus; /**< GL_LINK_STATUS */
> > + GLboolean Validated;
> > + GLchar *InfoLog;
> > +};
> > +
> > +/**
> > * A GLSL program object.
> > * Basically a linked collection of vertex and fragment shaders.
> > */
> > diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
> > index 8fd574e..a753a1b 100644
> > --- a/src/mesa/main/shaderobj.c
> > +++ b/src/mesa/main/shaderobj.c
> > @@ -41,6 +41,7 @@
> > #include "program/prog_parameter.h"
> > #include "util/ralloc.h"
> > #include "util/string_to_uint_map.h"
> > +#include "util/u_atomic.h"
> >
> > /*
> > */
> > /*** Shader object
> > functions***/
> > @@ -208,6 +209,35 @@ _mesa_lookup_shader_err(struct gl_context
> > *ctx, GLuint name, const char *caller)
> > /*
> > */
> >
> >
> > +void
> > +_mesa_reference_shader_program_data(struct gl_context *ctx,
> > +struct gl_shader_program_data
> > **ptr,
> > +struct gl_shader_program_data
> > *data)
> > +{
> > + if (*ptr == data)
> > + return;
> > +
> > + if (*ptr) {
> > + struct gl_shader_program_data *oldData = *ptr;
> > +
> > + assert(oldData->RefCount > 0);
> > +
> > + if (p_atomic_dec_zero(&oldData->RefCount)) {
> Yay for atomics and good bye locking ;-)
>
> >
> > + assert(ctx);
> > + ralloc_free(oldData);
> > + }
> > +
> > + *ptr = NULL;
> > + }
> > +
> > + assert(!*ptr);
> Dull moment, when can this trigger ? We seems to have this in a fair
> few places in mesa, yet nothing obvious comes up.
Yeah I think I copied this from the other functions it looks safe to
remove, probably left over from a previous change.
>
> >
> > + if (data) {
> > + p_atomic_inc(&data->RefCount);
> > + }
> > +
> Please drop the extra parenthesis.
>
> >
> > + *ptr = data;
> > +}
> > +
> > /**
> > * Set ptr to point to shProg.
> > * If ptr is pointing to another object, decrement its refcount
> > (and delete
> > @@ -249,6 +279,17 @@ _mesa_reference_shader_program_(struct
> > gl_context *ctx,
> > }
> > }
> >
> > +static struct gl_shader_program_data *
> > +create_shader_program_data()
> > +{
> > + struct gl_shader_program_data *data;
> > + data = rzalloc(NULL, struct gl_shader_program_data);
> Worth passing in a ctx, (gl_shader_program *) as opposed to using
> NULL ?
No. The ref counting is designed to clean this up because by the end of
this series it will be possible for the user to have freed the program
(which will free gl_shader_program) but the program can still be active
if a new program hasn't been pushed into the pipeline which means
gl_program still needs access to this data.
>
> >
> > + if (data) {
> > + data->RefCount = 1;
> > + }
> Drop the parenthesis ?
I don't really mind. I can drop them however I don't think this is a
rule, it's even been suggested at some point we always use them to
avoid silly bugs being introduced.
>
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/10] gallium: wire up server_wait_sync
On Fri, Nov 18, 2016 at 2:39 PM, Rob Clark wrote:
> From: Rob Clark
>
> This will be needed for explicit synchronization with devices outside
> the gpu, ie. EGL_ANDROID_native_fence_sync.
>
> Signed-off-by: Rob Clark
> Reviewed-by: Marek Olšák
> ---
> src/gallium/include/pipe/p_context.h | 6 ++
> src/gallium/state_trackers/dri/dri2.c | 6 +-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/include/pipe/p_context.h
> b/src/gallium/include/pipe/p_context.h
> index b97aad5..ee8a511 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -475,6 +475,12 @@ struct pipe_context {
> unsigned flags);
>
> /**
> +* Insert commands to have GPU wait for fence to be signaled.
> +*/
> + void (*fence_server_sync)(struct pipe_context *pipe,
> + struct pipe_fence_handle *fence);
BTW, why is it called "server_sync"? Do we have a server in gallium?
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 98774] glsl/tests/warnings-test regression
https://bugs.freedesktop.org/show_bug.cgi?id=98774 Bug ID: 98774 Summary: glsl/tests/warnings-test regression Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: All Status: NEW Keywords: bisected, have-backtrace, regression Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: v...@freedesktop.org QA Contact: mesa-dev@lists.freedesktop.org CC: emil.l.veli...@gmail.com, t_arc...@yahoo.com.au $ make check [...] PASS: glsl/glcpp/tests/glcpp-test PASS: glsl/glcpp/tests/glcpp-test-cr-lf PASS: glsl/tests/blob-test PASS: glsl/tests/cache-test PASS: glsl/tests/general-ir-test PASS: glsl/tests/optimization-test PASS: glsl/tests/sampler-types-test PASS: glsl/tests/uniform-initializer-test FAIL: glsl/tests/warnings-test PASS: nir/tests/control_flow_tests Testsuite summary for Mesa 13.1.0-devel # TOTAL: 10 # PASS: 9 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 $ ./glsl_compiler --just-log --version 150 ./glsl/tests/warnings/000-basic-test.vert 0:8(8): warning: `undefined' used uninitialized Segmentation fault (core dumped) (gdb) bt #0 0x in ?? () #1 0x0044a11e in link_intrastage_shaders (mem_ctx=mem_ctx@entry=0x1391320, ctx=ctx@entry=0x717a40 , prog=prog@entry=0x1391320, shader_list=0x1391920, num_shaders=num_shaders@entry=1, allow_missing_main=allow_missing_main@entry=true) at glsl/linker.cpp:2196 #2 0x00406c02 in standalone_compile_shader (_options=_options@entry=0x717a10 , num_files=num_files@entry=1, files=) at glsl/standalone.cpp:494 #3 0x0040346b in main (argc=, argv=0x7ffe4b919888) at glsl/main.cpp:92 (gdb) frame 1 #1 0x0044a11e in link_intrastage_shaders (mem_ctx=mem_ctx@entry=0x1391320, ctx=ctx@entry=0x717a40 , prog=prog@entry=0x1391320, shader_list=0x1391920, num_shaders=num_shaders@entry=1, allow_missing_main=allow_missing_main@entry=true) at glsl/linker.cpp:2196 2196 prog->Name); (gdb) print prog->Name $1 = 0 9d96d3803ab5dc896d4844ac785db57bb1717f91 is the first bad commit commit 9d96d3803ab5dc896d4844ac785db57bb1717f91 Author: Timothy Arceri Date: Mon Oct 31 23:54:03 2016 +1100 glsl: create gl_program at the start of linking rather than the end This will allow us to directly store metadata we want to retain in gl_program this metadata is currently stored in gl_linked_shader and will be lost if relinking fails even though the program will remain in use and is still valid according to the spec. "If a program object that is active for any shader stage is re-linked unsuccessfully, the link status will be set to FALSE, but any existing executables and associated state will remain part of the current rendering state until a subsequent call to UseProgram, UseProgramStages, or BindProgramPipeline removes them from use." This change will also help avoid the double handing that happens in _mesa_copy_linked_program_data(). Reviewed-by: Emil Velikov :04 04 97d2bb36e78083ac49ae2858d9d710b755d02941 2aa728acfaf8bc58a74f6ea379023f95c42139bf M src bisect run success -- 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] gallium: wire up server_wait_sync
On Fri, Nov 18, 2016 at 5:07 PM, Marek Olšák wrote:
> On Fri, Nov 18, 2016 at 2:39 PM, Rob Clark wrote:
>> From: Rob Clark
>>
>> This will be needed for explicit synchronization with devices outside
>> the gpu, ie. EGL_ANDROID_native_fence_sync.
>>
>> Signed-off-by: Rob Clark
>> Reviewed-by: Marek Olšák
>> ---
>> src/gallium/include/pipe/p_context.h | 6 ++
>> src/gallium/state_trackers/dri/dri2.c | 6 +-
>> 2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> index b97aad5..ee8a511 100644
>> --- a/src/gallium/include/pipe/p_context.h
>> +++ b/src/gallium/include/pipe/p_context.h
>> @@ -475,6 +475,12 @@ struct pipe_context {
>> unsigned flags);
>>
>> /**
>> +* Insert commands to have GPU wait for fence to be signaled.
>> +*/
>> + void (*fence_server_sync)(struct pipe_context *pipe,
>> + struct pipe_fence_handle *fence);
>
> BTW, why is it called "server_sync"? Do we have a server in gallium?
only to differentiate from client-wait.. and because it is called from
dri2_server_wait_sync() (which is called via
__DRI2fenceExtension::server_wait_sync()).. it's telling the "server"
(which is actually the CP) to wait. I guess the terminology probably
made sense about 15+ years ago before dri.. I find it kind of
confusing, but figured it was better to stick w/ what the rest of the
codebase (and gl specs) used..
BR,
-R
> Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/10] gallium: wire up server_wait_sync
On Fri, Nov 18, 2016 at 11:17 PM, Rob Clark wrote:
> On Fri, Nov 18, 2016 at 5:07 PM, Marek Olšák wrote:
>> On Fri, Nov 18, 2016 at 2:39 PM, Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> This will be needed for explicit synchronization with devices outside
>>> the gpu, ie. EGL_ANDROID_native_fence_sync.
>>>
>>> Signed-off-by: Rob Clark
>>> Reviewed-by: Marek Olšák
>>> ---
>>> src/gallium/include/pipe/p_context.h | 6 ++
>>> src/gallium/state_trackers/dri/dri2.c | 6 +-
>>> 2 files changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/include/pipe/p_context.h
>>> b/src/gallium/include/pipe/p_context.h
>>> index b97aad5..ee8a511 100644
>>> --- a/src/gallium/include/pipe/p_context.h
>>> +++ b/src/gallium/include/pipe/p_context.h
>>> @@ -475,6 +475,12 @@ struct pipe_context {
>>> unsigned flags);
>>>
>>> /**
>>> +* Insert commands to have GPU wait for fence to be signaled.
>>> +*/
>>> + void (*fence_server_sync)(struct pipe_context *pipe,
>>> + struct pipe_fence_handle *fence);
>>
>> BTW, why is it called "server_sync"? Do we have a server in gallium?
>
> only to differentiate from client-wait.. and because it is called from
> dri2_server_wait_sync() (which is called via
> __DRI2fenceExtension::server_wait_sync()).. it's telling the "server"
> (which is actually the CP) to wait. I guess the terminology probably
> made sense about 15+ years ago before dri.. I find it kind of
> confusing, but figured it was better to stick w/ what the rest of the
> codebase (and gl specs) used..
OK, we can rename it later.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4] clover: restore support for LLVM <= 3.9
Mesa master builds again against LLVM 3.6.
Tested-by: Pierre Moreau
On 07:57 pm - Nov 18 2016, Vedran Miletić wrote:
> The commit 8e430ff8b060b4e8e922bae24b3c57837da6ea77 support for LLVM
> 3.9 and older versionsin Clover. This patch restores it and refactors
> the support using Clover compatibility layer for LLVM.
>
> Signed-off-by: Vedran Miletić
> ---
> .../state_trackers/clover/llvm/codegen/bitcode.cpp | 9 ++
> src/gallium/state_trackers/clover/llvm/compat.hpp | 35
> ++
> 2 files changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> index 5dcc4f8..4b4ae41 100644
> --- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> @@ -32,6 +32,7 @@
> ///
>
> #include "llvm/codegen.hpp"
> +#include "llvm/compat.hpp"
> #include "llvm/metadata.hpp"
> #include "core/error.hpp"
> #include "util/algorithm.hpp"
> @@ -99,13 +100,7 @@ clover::llvm::parse_module_library(const module &m,
> ::llvm::LLVMContext &ctx,
> auto mod = ::llvm::parseBitcodeFile(::llvm::MemoryBufferRef(
> as_string(m.secs[0].data), " "),
> ctx);
>
> - if (::llvm::Error err = mod.takeError()) {
> - std::string msg;
> - ::llvm::handleAllErrors(std::move(err), [&](::llvm::ErrorInfoBase
> &EIB) {
> - msg = EIB.message();
> - fail(r_log, error(CL_INVALID_PROGRAM), msg.c_str());
> - });
> - }
> + compat::handle_module_error(mod, r_log);
>
> return std::unique_ptr<::llvm::Module>(std::move(*mod));
> }
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index a963cff..b29100f 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -39,6 +39,11 @@
> #include
> #include
> #include
> +#if HAVE_LLVM >= 0x0400
> +#include
> +#else
> +#include
> +#endif
>
> #if HAVE_LLVM >= 0x0307
> #include
> @@ -53,6 +58,14 @@
> #include
> #include
>
> +#if HAVE_LLVM >= 0x0307
> +#include
> +#endif
> +
> +namespace llvm {
> + class Module;
> +}
> +
> namespace clover {
> namespace llvm {
>namespace compat {
> @@ -158,6 +171,28 @@ namespace clover {
> #else
> const auto default_reloc_model = ::llvm::Reloc::Default;
> #endif
> +
> +#if HAVE_LLVM >= 0x0400
> + typedef ::llvm::Expected>
> bitcode_module;
> +#elif HAVE_LLVM >= 0x0307
> + typedef ::llvm::ErrorOr>
> bitcode_module;
> +#else
> + typedef ::llvm::ErrorOr<::llvm::Module *> bitcode_module;
> +#endif
> +
> + inline void
> + handle_module_error(bitcode_module &mod, std::string &r_log) {
> +#if HAVE_LLVM >= 0x0400
> +if (::llvm::Error err = mod.takeError()) {
> + ::llvm::handleAllErrors(std::move(err),
> [&](::llvm::ErrorInfoBase &EIB) {
> + fail(r_log, error(CL_INVALID_PROGRAM),
> EIB.message().c_str());
> + });
> +}
> +#else
> +if (!mod)
> + fail(r_log, error(CL_INVALID_PROGRAM),
> mod.getError().message());
> +#endif
> + }
>}
> }
> }
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/12] docs/submittingpatches: flesh out "how to nominate" methods
Reviewed-by: Marek Olšák Marek On Wed, Nov 16, 2016 at 7:46 PM, Emil Velikov wrote: > From: Emil Velikov > > Currently things are a bit buried within the text, making it harder to > find out. Move at the top and be clear what is _not_ a good idea. > > We had some people consistently using the "bad" way and then being > unhappy that their patches were missed/delayed. > > Cc: Marek Olšák > Signed-off-by: Emil Velikov > --- > docs/submittingpatches.html | 30 -- > 1 file changed, 20 insertions(+), 10 deletions(-) > > diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html > index 77b870a..0ab 100644 > --- a/docs/submittingpatches.html > +++ b/docs/submittingpatches.html > @@ -184,6 +184,24 @@ as the issues are resolved first. > Nominating a commit for a stable branch > > > +There are three ways to nominate patch for inclusion of the stable branch and > +release. > + > + > + By adding the Cc: mesa-stable@ tag as described below. > + Sending the commit ID (as seen in master branch) to the mesa-stable@ > mailing list. > + Forwarding the patch from the mesa-dev@ mailing list. > + > + > + > +Note: sending [re]sending patch identical to one on mesa-dev@ or one that > +differs only by the extra mesa-stable@ tag is not > recommended. > + > + > + > +The stable tag > + > + > If you want a commit to be applied to a stable branch, > you should add an appropriate note to the commit message. > > @@ -207,16 +225,8 @@ exclusively for the older branch. > > This "CC" syntax for patch nomination will cause patches to automatically be > copied to the mesa-stable@ mailing list when you use "git send-email" to send > -patches to the mesa-dev@ mailing list. Also, if you realize that a commit > -should be nominated for the stable branch after it has already been > committed, > -you can send a note directly to the mesa-sta...@lists.freedesktop.org where > -the Mesa stable-branch maintainers will receive it. Be sure to mention the > -commit ID of the commit of interest (as it appears in the mesa master > branch). > - > -The latest set of patches that have been nominated, accepted, or rejected for > -the upcoming stable release can always be seen on the > -http://cworth.org/~cworth/mesa-stable-queue/";>Mesa Stable Queue > -page. > +patches to the mesa-dev@ mailing list. If you prefer using --suppress-cc that > +won't have any effect negative effect on the patch nomination. > > Criteria for accepting patches to the stable branch > > -- > 2.9.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] radeonsi: store group_size_variable in struct si_compute
Reviewed-by: Marek Olšák
Marek
On Fri, Nov 18, 2016 at 8:22 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> For compute shaders, we free the selector after the shader has been
> compiled, so we need to save this bit somewhere else. Also, make sure that
> this type of bug cannot re-appear, by NULL-ing the selector pointer after
> we're done with it.
>
> This bug has been there since the feature was added, but was only exposed
> in piglit arb_compute_variable_group_size-local-size by commit
> 9bfee7047b70cb0aa026ca9536465762f96cb2b1 (which is totally unrelated).
>
> Cc: 13.0
> ---
> src/gallium/drivers/radeonsi/si_compute.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> index f1887bb..69d57b9 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -35,21 +35,22 @@
> #define MAX_GLOBAL_BUFFERS 20
>
> struct si_compute {
> unsigned ir_type;
> unsigned local_size;
> unsigned private_size;
> unsigned input_size;
> struct si_shader shader;
>
> struct pipe_resource *global_buffers[MAX_GLOBAL_BUFFERS];
> - bool use_code_object_v2;
> + unsigned use_code_object_v2 : 1;
> + unsigned variable_group_size : 1;
> };
>
> struct dispatch_packet {
> uint16_t header;
> uint16_t setup;
> uint16_t workgroup_size_x;
> uint16_t workgroup_size_y;
> uint16_t workgroup_size_z;
> uint16_t reserved0;
> uint32_t grid_size_x;
> @@ -140,21 +141,25 @@ static void *si_create_compute_state(
>S_00B848_SGPRS((shader->config.num_sgprs - 1) / 8)
> |
>S_00B848_DX10_CLAMP(1) |
>S_00B848_FLOAT_MODE(shader->config.float_mode);
>
> shader->config.rsrc2 =
> S_00B84C_USER_SGPR(SI_CS_NUM_USER_SGPR) |
>S_00B84C_SCRATCH_EN(scratch_enabled) |
>S_00B84C_TGID_X_EN(1) | S_00B84C_TGID_Y_EN(1) |
>S_00B84C_TGID_Z_EN(1) | S_00B84C_TIDIG_COMP_CNT(2)
> |
>S_00B84C_LDS_SIZE(shader->config.lds_size);
>
> + program->variable_group_size =
> +
> sel.info.properties[TGSI_PROPERTY_CS_FIXED_BLOCK_WIDTH] == 0;
> +
> FREE(sel.tokens);
> + program->shader.selector = NULL;
> } else {
> const struct pipe_llvm_program_header *header;
> const char *code;
> header = cso->prog;
> code = cso->prog + sizeof(struct pipe_llvm_program_header);
>
> radeon_elf_read(code, header->num_bytes,
> &program->shader.binary);
> if (program->use_code_object_v2) {
> const amd_kernel_code_t *code_object =
> si_compute_get_code_object(program, 0);
> @@ -600,28 +605,26 @@ static void si_setup_tgsi_grid(struct si_context *sctx,
> radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
> radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_MEM) |
> COPY_DATA_DST_SEL(COPY_DATA_REG));
> radeon_emit(cs, (va + 4 * i));
> radeon_emit(cs, (va + 4 * i) >> 32);
> radeon_emit(cs, (grid_size_reg >> 2) + i);
> radeon_emit(cs, 0);
> }
> } else {
> struct si_compute *program = sctx->cs_shader_state.program;
> - bool variable_group_size =
> -
> program->shader.selector->info.properties[TGSI_PROPERTY_CS_FIXED_BLOCK_WIDTH]
> == 0;
>
> - radeon_set_sh_reg_seq(cs, grid_size_reg, variable_group_size
> ? 6 : 3);
> + radeon_set_sh_reg_seq(cs, grid_size_reg,
> program->variable_group_size ? 6 : 3);
> radeon_emit(cs, info->grid[0]);
> radeon_emit(cs, info->grid[1]);
> radeon_emit(cs, info->grid[2]);
> - if (variable_group_size) {
> + if (program->variable_group_size) {
> radeon_emit(cs, info->block[0]);
> radeon_emit(cs, info->block[1]);
> radeon_emit(cs, info->block[2]);
> }
> }
> }
>
> static void si_emit_dispatch_packets(struct si_context *sctx,
> const struct pipe_grid_info *info)
> {
> --
> 2.7.4
>
> ___
> 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/m
Re: [Mesa-dev] [PATCH] st/mesa: silence warnings in optimized builds
Reviewed-by: Marek Olšák
Marek
On Thu, Nov 17, 2016 at 11:00 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Mark variables and static functions that only occur in assert()s as
> MAYBE_UNUSED.
> ---
> src/mesa/state_tracker/st_sampler_view.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_sampler_view.c
> b/src/mesa/state_tracker/st_sampler_view.c
> index 2b2fa8b..88d5d1a 100644
> --- a/src/mesa/state_tracker/st_sampler_view.c
> +++ b/src/mesa/state_tracker/st_sampler_view.c
> @@ -310,21 +310,21 @@ get_texture_format_swizzle(const struct st_context *st,
> return swizzle_swizzle(stObj->base._Swizzle, tex_swizzle);
> }
>
>
> /**
> * Return TRUE if the texture's sampler view swizzle is not equal to
> * the texture's swizzle.
> *
> * \param stObj the st texture object,
> */
> -static boolean
> +MAYBE_UNUSED static boolean
> check_sampler_swizzle(const struct st_context *st,
>const struct st_texture_object *stObj,
> const struct pipe_sampler_view *sv, unsigned
> glsl_version)
> {
> unsigned swizzle = get_texture_format_swizzle(st, stObj, glsl_version);
>
> return ((sv->swizzle_r != GET_SWZ(swizzle, 0)) ||
> (sv->swizzle_g != GET_SWZ(swizzle, 1)) ||
> (sv->swizzle_b != GET_SWZ(swizzle, 2)) ||
> (sv->swizzle_a != GET_SWZ(swizzle, 3)));
> @@ -466,21 +466,21 @@ st_get_texture_sampler_view_from_stobj(struct
> st_context *st,
> if (*sv) {
>/* Debug check: make sure that the sampler view's parameters are
> * what they're supposed to be.
> */
>MAYBE_UNUSED struct pipe_sampler_view *view = *sv;
>assert(!check_sampler_swizzle(st, stObj, view, glsl_version));
>assert(get_sampler_view_format(st, stObj, samp) == view->format);
>assert(gl_target_to_pipe(stObj->base.Target) == view->target);
>if (stObj->base.Target == GL_TEXTURE_BUFFER) {
> unsigned base = stObj->base.BufferOffset;
> - unsigned size = MIN2(stObj->pt->width0 - base,
> + MAYBE_UNUSED unsigned size = MIN2(stObj->pt->width0 - base,
>(unsigned) stObj->base.BufferSize);
> assert(view->u.buf.offset == base);
> assert(view->u.buf.size == size);
>}
>else {
> assert(stObj->base.MinLevel + stObj->base.BaseLevel ==
> view->u.tex.first_level);
> assert(last_level(stObj) == view->u.tex.last_level);
> assert(stObj->layer_override || stObj->base.MinLayer ==
> view->u.tex.first_layer);
> assert(stObj->layer_override || last_layer(stObj) ==
> view->u.tex.last_layer);
> --
> 2.7.4
>
> ___
> 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] mesa: Add missing call to _mesa_unlock_debug_state(ctx);
On Wed, Nov 16, 2016 at 10:23 PM, Tom Stellard wrote:
> cd724208d3e1e3307f84a794f2c1fc83b69ccf8a added a call to
> _mesa_lock_debug_state(ctx) but wasn't unlocking the debug state.
>
> This fixes a hang in glsl-fs-loop piglit test with MESA_DEBUG=context.
> ---
> src/gallium/drivers/radeonsi/si_pipe.c | 8 +---
> src/mesa/main/debug_output.c | 5 +++--
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 1737e23..b086f0e 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -128,9 +128,11 @@ si_create_llvm_target_machine(struct si_screen *sscreen)
> {
> const char *triple = "amdgcn--";
>
> - if (sscreen->b.debug_flags & DBG_GLOBAL_ISEL) {
> - const char *options[1] = {"-global-isel"};
> - LLVMParseCommandLineOptions(1, options, NULL);
> + static bool cl_set = false;
> + if (!cl_set && sscreen->b.debug_flags & DBG_GLOBAL_ISEL) {
> + const char *options[4] = {"radeonsi",
> "-global-isel","-global-isel-abort=2", "-debug-only=instruction-select"};
> + LLVMParseCommandLineOptions(3, options, NULL);
> + cl_set = true;
Unrelated change.
> }
>
> return LLVMCreateTargetMachine(si_llvm_get_amdgpu_target(triple),
> triple,
> diff --git a/src/mesa/main/debug_output.c b/src/mesa/main/debug_output.c
> index 4e9209b..b3d9398 100644
> --- a/src/mesa/main/debug_output.c
> +++ b/src/mesa/main/debug_output.c
> @@ -1282,15 +1282,16 @@ _mesa_init_debug_output(struct gl_context *ctx)
> */
>struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
>if (!debug) {
> - return;
> + goto done;
>}
>debug->DebugOutput = GL_TRUE;
>debug->LogToStderr = GL_TRUE;
>ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_DEBUG_BIT;
> }
> +done:
> + _mesa_unlock_debug_state(ctx);
> }
This part is:
Reviewed-by: Marek Olšák
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 98740] bitcode.cpp:102:8: error: ‘Error’ is not a member of ‘llvm’
https://bugs.freedesktop.org/show_bug.cgi?id=98740 Alejandro Vilicic changed: What|Removed |Added CC||alejandro.vilicich@inacapma ||il.cl QA Contact|mesa-dev@lists.freedesktop. |alejandro.vilicich@inacapma |org |il.cl Assignee|mesa-dev@lists.freedesktop. |sebastian.sanchez33@inacapm |org |ail.cl --- Comment #3 from Alejandro Vilicic --- revisar error detectado en apliac -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radeonsi: Use buffer_load intrinsics instead of llvm.SI.vs.load.input
On Wed, Nov 16, 2016 at 4:38 PM, Tom Stellard wrote: > On Wed, Nov 16, 2016 at 11:13:45AM +0100, Nicolai Hähnle wrote: >> Have you looked at the shader-db impact? >> > > shader-db is mostly unchanged. There are a few decreases in SGPR usage and > code size, and a 4 byte increase in code size for one shader. > >> I do think we should eventually do this, but llvm.SI.vs.load.input is >> ReadNone while llvm.amdgcn.buffer.load.* is only ReadOnly, so as long as we >> can't teach LLVM properly about no-aliasing and speculability, there may be >> performance regressions. >> > > Ideally llvm.amdgcn.buffer.load.* would be ReadOnly and ArgMemOnly, but I > think > as long as it has non-pointer arguments this combination behaves the same as > ReadNone, which would be incorrect. Why would it be incorrect? Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: add new program driver function to standalone compiler
This fixes a regression with the standalone compiler caused by
9d96d3803ab5dc
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98774
---
src/compiler/glsl/standalone.cpp | 61
1 file changed, 43 insertions(+), 18 deletions(-)
diff --git a/src/compiler/glsl/standalone.cpp b/src/compiler/glsl/standalone.cpp
index 6aecd22..41f122a 100644
--- a/src/compiler/glsl/standalone.cpp
+++ b/src/compiler/glsl/standalone.cpp
@@ -99,6 +99,39 @@ private:
set *variables;
};
+void
+init_gl_program(struct gl_program *prog, GLenum target)
+{
+ mtx_init(&prog->Mutex, mtx_plain);
+
+ prog->RefCount = 1;
+ prog->Format = GL_PROGRAM_FORMAT_ASCII_ARB;
+
+ /* default mapping from samplers to texture units */
+ for (int i = 0; i < MAX_SAMPLERS; i++)
+ prog->SamplerUnits[i] = i;
+}
+
+struct gl_program *
+new_program(struct gl_context *ctx, GLenum target, GLuint id)
+{
+ switch (target) {
+ case GL_VERTEX_PROGRAM_ARB: /* == GL_VERTEX_PROGRAM_NV */
+ case GL_GEOMETRY_PROGRAM_NV:
+ case GL_TESS_CONTROL_PROGRAM_NV:
+ case GL_TESS_EVALUATION_PROGRAM_NV:
+ case GL_FRAGMENT_PROGRAM_ARB:
+ case GL_COMPUTE_PROGRAM_NV: {
+ struct gl_program *prog = rzalloc(NULL, struct gl_program);
+ init_gl_program(prog, target);
+ return prog;
+ }
+ default:
+ printf("bad target in new_program\n");
+ return NULL;
+ }
+}
+
static const struct standalone_options *options;
static void
@@ -298,6 +331,7 @@ initialize_context(struct gl_context *ctx, gl_api api)
4 * MESA_SHADER_STAGES * MAX_UNIFORMS;
ctx->Driver.NewShader = _mesa_new_linked_shader;
+ ctx->Driver.NewProgram = new_program;
}
/* Returned string will have 'ctx' as its ralloc owner. */
@@ -360,19 +394,6 @@ compile_shader(struct gl_context *ctx, struct gl_shader
*shader)
return;
}
-void
-init_gl_program(struct gl_program *prog, GLenum target)
-{
- mtx_init(&prog->Mutex, mtx_plain);
-
- prog->RefCount = 1;
- prog->Format = GL_PROGRAM_FORMAT_ASCII_ARB;
-
- /* default mapping from samplers to texture units */
- for (int i = 0; i < MAX_SAMPLERS; i++)
- prog->SamplerUnits[i] = i;
-}
-
extern "C" struct gl_shader_program *
standalone_compile_shader(const struct standalone_options *_options,
unsigned num_files, char* const* files)
@@ -547,9 +568,6 @@ standalone_compile_shader(const struct standalone_options
*_options,
dead_variable_visitor dv;
visit_list_elements(&dv, shader->ir);
dv.remove_dead_variables();
-
- shader->Program = rzalloc(shader, gl_program);
- init_gl_program(shader->Program, shader->Stage);
}
if (options->dump_builder) {
@@ -567,6 +585,11 @@ standalone_compile_shader(const struct standalone_options
*_options,
return whole_program;
fail:
+ for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
+ if (whole_program->_LinkedShaders[i])
+ ralloc_free(whole_program->_LinkedShaders[i]->Program);
+ }
+
ralloc_free(whole_program);
return NULL;
}
@@ -574,8 +597,10 @@ fail:
extern "C" void
standalone_compiler_cleanup(struct gl_shader_program *whole_program)
{
- for (unsigned i = 0; i < MESA_SHADER_STAGES; i++)
- ralloc_free(whole_program->_LinkedShaders[i]);
+ for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
+ if (whole_program->_LinkedShaders[i])
+ ralloc_free(whole_program->_LinkedShaders[i]->Program);
+ }
delete whole_program->AttributeBindings;
delete whole_program->FragDataBindings;
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radeonsi: Use buffer_load intrinsics instead of llvm.SI.vs.load.input
On Sat, Nov 19, 2016 at 01:09:00AM +0100, Marek Olšák wrote: > On Wed, Nov 16, 2016 at 4:38 PM, Tom Stellard wrote: > > On Wed, Nov 16, 2016 at 11:13:45AM +0100, Nicolai Hähnle wrote: > >> Have you looked at the shader-db impact? > >> > > > > shader-db is mostly unchanged. There are a few decreases in SGPR usage and > > code size, and a 4 byte increase in code size for one shader. > > > >> I do think we should eventually do this, but llvm.SI.vs.load.input is > >> ReadNone while llvm.amdgcn.buffer.load.* is only ReadOnly, so as long as we > >> can't teach LLVM properly about no-aliasing and speculability, there may be > >> performance regressions. > >> > > > > Ideally llvm.amdgcn.buffer.load.* would be ReadOnly and ArgMemOnly, but I > > think > > as long as it has non-pointer arguments this combination behaves the same as > > ReadNone, which would be incorrect. > > Why would it be incorrect? > Because llvm.amdgcn.buffer.load.* can be used in a lot of different ways, so it is possible that the memory it is reading from has been modified by the shader. -Tom > Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 98774] glsl/tests/warnings-test regression
https://bugs.freedesktop.org/show_bug.cgi?id=98774 --- Comment #1 from Timothy Arceri --- Thanks, fix sent for review: https://lists.freedesktop.org/archives/mesa-dev/2016-November/135829.html -- 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] glsl: add new program driver function to standalone compiler
On Sat, 2016-11-19 at 11:14 +1100, Timothy Arceri wrote:
> This fixes a regression with the standalone compiler caused by
> 9d96d3803ab5dc
I forgot to add this:
Note that we change standalone_compiler_cleanup() to no longer
explicitly free the linked shaders as the will be freed when
we free the parent ctx whole_program.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98774
> ---
> src/compiler/glsl/standalone.cpp | 61
>
> 1 file changed, 43 insertions(+), 18 deletions(-)
>
> diff --git a/src/compiler/glsl/standalone.cpp
> b/src/compiler/glsl/standalone.cpp
> index 6aecd22..41f122a 100644
> --- a/src/compiler/glsl/standalone.cpp
> +++ b/src/compiler/glsl/standalone.cpp
> @@ -99,6 +99,39 @@ private:
> set *variables;
> };
>
> +void
> +init_gl_program(struct gl_program *prog, GLenum target)
> +{
> + mtx_init(&prog->Mutex, mtx_plain);
> +
> + prog->RefCount = 1;
> + prog->Format = GL_PROGRAM_FORMAT_ASCII_ARB;
> +
> + /* default mapping from samplers to texture units */
> + for (int i = 0; i < MAX_SAMPLERS; i++)
> + prog->SamplerUnits[i] = i;
> +}
> +
> +struct gl_program *
> +new_program(struct gl_context *ctx, GLenum target, GLuint id)
> +{
> + switch (target) {
> + case GL_VERTEX_PROGRAM_ARB: /* == GL_VERTEX_PROGRAM_NV */
> + case GL_GEOMETRY_PROGRAM_NV:
> + case GL_TESS_CONTROL_PROGRAM_NV:
> + case GL_TESS_EVALUATION_PROGRAM_NV:
> + case GL_FRAGMENT_PROGRAM_ARB:
> + case GL_COMPUTE_PROGRAM_NV: {
> + struct gl_program *prog = rzalloc(NULL, struct gl_program);
> + init_gl_program(prog, target);
> + return prog;
> + }
> + default:
> + printf("bad target in new_program\n");
> + return NULL;
> + }
> +}
> +
> static const struct standalone_options *options;
>
> static void
> @@ -298,6 +331,7 @@ initialize_context(struct gl_context *ctx, gl_api
> api)
> 4 * MESA_SHADER_STAGES * MAX_UNIFORMS;
>
> ctx->Driver.NewShader = _mesa_new_linked_shader;
> + ctx->Driver.NewProgram = new_program;
> }
>
> /* Returned string will have 'ctx' as its ralloc owner. */
> @@ -360,19 +394,6 @@ compile_shader(struct gl_context *ctx, struct
> gl_shader *shader)
> return;
> }
>
> -void
> -init_gl_program(struct gl_program *prog, GLenum target)
> -{
> - mtx_init(&prog->Mutex, mtx_plain);
> -
> - prog->RefCount = 1;
> - prog->Format = GL_PROGRAM_FORMAT_ASCII_ARB;
> -
> - /* default mapping from samplers to texture units */
> - for (int i = 0; i < MAX_SAMPLERS; i++)
> - prog->SamplerUnits[i] = i;
> -}
> -
> extern "C" struct gl_shader_program *
> standalone_compile_shader(const struct standalone_options *_options,
> unsigned num_files, char* const* files)
> @@ -547,9 +568,6 @@ standalone_compile_shader(const struct
> standalone_options *_options,
> dead_variable_visitor dv;
> visit_list_elements(&dv, shader->ir);
> dv.remove_dead_variables();
> -
> - shader->Program = rzalloc(shader, gl_program);
> - init_gl_program(shader->Program, shader->Stage);
> }
>
> if (options->dump_builder) {
> @@ -567,6 +585,11 @@ standalone_compile_shader(const struct
> standalone_options *_options,
> return whole_program;
>
> fail:
> + for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
> + if (whole_program->_LinkedShaders[i])
> + ralloc_free(whole_program->_LinkedShaders[i]->Program);
> + }
> +
> ralloc_free(whole_program);
> return NULL;
> }
> @@ -574,8 +597,10 @@ fail:
> extern "C" void
> standalone_compiler_cleanup(struct gl_shader_program *whole_program)
> {
> - for (unsigned i = 0; i < MESA_SHADER_STAGES; i++)
> - ralloc_free(whole_program->_LinkedShaders[i]);
> + for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
> + if (whole_program->_LinkedShaders[i])
> + ralloc_free(whole_program->_LinkedShaders[i]->Program);
> + }
>
> delete whole_program->AttributeBindings;
> delete whole_program->FragDataBindings;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radeonsi: Use buffer_load intrinsics instead of llvm.SI.vs.load.input
On Sat, Nov 19, 2016 at 1:13 AM, Tom Stellard wrote: > On Sat, Nov 19, 2016 at 01:09:00AM +0100, Marek Olšák wrote: >> On Wed, Nov 16, 2016 at 4:38 PM, Tom Stellard wrote: >> > On Wed, Nov 16, 2016 at 11:13:45AM +0100, Nicolai Hähnle wrote: >> >> Have you looked at the shader-db impact? >> >> >> > >> > shader-db is mostly unchanged. There are a few decreases in SGPR usage and >> > code size, and a 4 byte increase in code size for one shader. >> > >> >> I do think we should eventually do this, but llvm.SI.vs.load.input is >> >> ReadNone while llvm.amdgcn.buffer.load.* is only ReadOnly, so as long as >> >> we >> >> can't teach LLVM properly about no-aliasing and speculability, there may >> >> be >> >> performance regressions. >> >> >> > >> > Ideally llvm.amdgcn.buffer.load.* would be ReadOnly and ArgMemOnly, but I >> > think >> > as long as it has non-pointer arguments this combination behaves the same >> > as >> > ReadNone, which would be incorrect. >> >> Why would it be incorrect? >> > > Because llvm.amdgcn.buffer.load.* can be used in a lot of different > ways, so it is possible that the memory it is reading from has been > modified by the shader. OpenGL tells us which buffers read from invariant memory and which aren't. We have most of the information from OpenGL or GLSL to tell whether a load or store affects any other buffers or not. E.g. a shader buffer or image with the "restrict" modifier means that its memory doesn't overlap with any other buffer. Read-only buffers such as vertex buffers and uniform buffers have this property naturally. If you see only loads with that modifier, you can set ReadNone. If you see only stores with that modifer, you can set InaccessibleMemOnly I think. I would say that it would be more common in OpenGL to see llvm.amdgcn.buffer.load.* with ReadNone than ReadOnly if we used the LLVM attributes more aggressively. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 03/20] configure.ac: Use new llvm_add_default_components
Signed-off-by: Tobias Droste
Reviewed-by: Emil Velikov
---
configure.ac | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0c955bf..4f98c19 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2242,11 +2242,7 @@ if test "x$enable_gallium_llvm" = xyes || test
"x$HAVE_RADEON_VULKAN" = xyes; th
AC_MSG_ERROR([LLVM
$LLVM_REQUIRED_VERSION_MAJOR.$LLVM_REQUIRED_VERSION_MINOR or newer is required])
fi
-LLVM_COMPONENTS="engine bitwriter mcjit mcdisassembler"
-
-if $LLVM_CONFIG --components | grep -q inteljitevents ; then
-LLVM_COMPONENTS="${LLVM_COMPONENTS} inteljitevents"
-fi
+llvm_add_default_components "gallium"
if test "x$enable_opencl" = xyes; then
llvm_check_version_for "3" "6" "0" "opencl"
--
2.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 04/20] configure.ac: Use new helper function for LLVM
Use the new helper function to add LLVM targets and components.
The components are added one by one to later find out which component
is missing in case there is one.
Signed-off-by: Tobias Droste
Reviewed-by: Emil Velikov
---
configure.ac | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4f98c19..b544507 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2247,8 +2247,14 @@ if test "x$enable_gallium_llvm" = xyes || test
"x$HAVE_RADEON_VULKAN" = xyes; th
if test "x$enable_opencl" = xyes; then
llvm_check_version_for "3" "6" "0" "opencl"
-LLVM_COMPONENTS="${LLVM_COMPONENTS} all-targets ipo linker
instrumentation"
-LLVM_COMPONENTS="${LLVM_COMPONENTS} irreader option objcarcopts
profiledata"
+llvm_add_component "all-targets" "opencl"
+llvm_add_component "ipos" "opencl"
+llvm_add_component "linker" "opencl"
+llvm_add_component "instrumentation" "opencl"
+llvm_add_component "irreader" "yes" "opencl"
+llvm_add_component "option" "yes" "opencl"
+llvm_add_component "objcarcopts" "opencl"
+llvm_add_component "profiledata" "opencl"
fi
DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT
-DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
MESA_LLVM=1
@@ -2356,11 +2362,14 @@ radeon_llvm_check() {
else
amdgpu_llvm_target_name='amdgpu'
fi
+
llvm_check_version_for $2 $3 $4 $1
-if test true && $LLVM_CONFIG --targets-built | grep -iqvw
$amdgpu_llvm_target_name ; then
-AC_MSG_ERROR([LLVM $amdgpu_llvm_target_name not enabled in your LLVM
build.])
-fi
-LLVM_COMPONENTS="${LLVM_COMPONENTS} $amdgpu_llvm_target_name bitreader ipo"
+
+llvm_add_target $amdgpu_llvm_target_name $1
+
+llvm_add_component "bitreader" $1
+llvm_add_component "ipo" $1
+
NEED_RADEON_LLVM=yes
if test "x$have_libelf" != xyes; then
AC_MSG_ERROR([$1 requires libelf when using llvm])
@@ -2454,7 +2463,9 @@ if test -n "$with_gallium_drivers"; then
require_libdrm "Gallium R600"
if test "x$enable_opencl" = xyes; then
radeon_gallium_llvm_check "r600g" "3" "6" "0"
-LLVM_COMPONENTS="${LLVM_COMPONENTS} bitreader asmparser"
+
+llvm_add_component "asmparser" "r600"
+llvm_add_component "bitreader" "r600"
fi
;;
xradeonsi)
--
2.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 06/20] configure.ac: Move LLVM functions to the top
This just moves code around so that all LLVM related stuff is at the
top of the file in the correct order.
No functional change.
Signed-off-by: Tobias Droste
Reviewed-by: Emil Velikov
---
configure.ac | 151 +--
1 file changed, 74 insertions(+), 77 deletions(-)
diff --git a/configure.ac b/configure.ac
index c12d9b0..65b604e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -866,6 +866,27 @@ AC_SUBST([SELINUX_LIBS])
dnl
dnl LLVM
dnl
+AC_ARG_ENABLE([llvm-shared-libs],
+[AS_HELP_STRING([--enable-llvm-shared-libs],
+[link with LLVM shared libraries @<:@default=enabled@:>@])],
+[enable_llvm_shared_libs="$enableval"],
+[enable_llvm_shared_libs=yes])
+
+AC_ARG_WITH([llvm-prefix],
+[AS_HELP_STRING([--with-llvm-prefix],
+[Prefix for LLVM installations in non-standard locations])],
+[llvm_prefix="$withval"],
+[llvm_prefix=''])
+
+PKG_CHECK_MODULES([LIBELF], [libelf], [have_libelf=yes], [have_libelf=no])
+if test "x$have_libelf" = xno; then
+ LIBELF_LIBS=''
+ LIBELF_CFLAGS=''
+ AC_CHECK_LIB([elf], [elf_memory], [have_libelf=yes;LIBELF_LIBS=-lelf],
[have_libelf=no])
+ AC_SUBST([LIBELF_LIBS])
+ AC_SUBST([LIBELF_CFLAGS])
+fi
+
llvm_add_component() {
new_llvm_component=$1
driver_name=$2
@@ -899,6 +920,33 @@ llvm_add_target() {
fi
}
+# Call this inside ` ` to get the return value.
+# $1 is the llvm-config command with arguments.
+strip_unwanted_llvm_flags() {
+# Use \> (marks the end of the word)
+echo `$1` | sed \
+-e 's/-march=\S*//g' \
+-e 's/-mtune=\S*//g' \
+-e 's/-mcpu=\S*//g' \
+-e 's/-DNDEBUG\>//g' \
+-e 's/-D_GNU_SOURCE\>//g' \
+-e 's/-pedantic\>//g' \
+-e 's/-Wcovered-switch-default\>//g' \
+-e 's/-O.\>//g' \
+-e 's/-g\>//g' \
+-e 's/-Wall\>//g' \
+-e 's/-Wcast-qual\>//g' \
+-e 's/-Woverloaded-virtual\>//g' \
+-e 's/-fcolor-diagnostics\>//g' \
+-e 's/-fdata-sections\>//g' \
+-e 's/-ffunction-sections\>//g' \
+-e 's/-fno-exceptions\>//g' \
+-e 's/-fomit-frame-pointer\>//g' \
+-e 's/-fvisibility-inlines-hidden\>//g' \
+-e 's/-fPIC\>//g' \
+-e 's/-fstack-protector-strong\>//g'
+}
+
llvm_set_environment_variables() {
if test -z "$LLVM_CONFIG"; then
if test -n "$llvm_prefix"; then
@@ -972,6 +1020,32 @@ llvm_set_environment_variables() {
fi
}
+llvm_check_version_for() {
+if test "${LLVM_VERSION_INT}${LLVM_VERSION_PATCH}" -lt "${1}0${2}${3}";
then
+AC_MSG_ERROR([LLVM $1.$2.$3 or newer is required for $4])
+fi
+}
+
+radeon_llvm_check() {
+if test ${LLVM_VERSION_INT} -lt 307; then
+amdgpu_llvm_target_name='r600'
+else
+amdgpu_llvm_target_name='amdgpu'
+fi
+
+llvm_check_version_for $2 $3 $4 $1
+
+llvm_add_target $amdgpu_llvm_target_name $1
+
+llvm_add_component "bitreader" $1
+llvm_add_component "ipo" $1
+
+NEED_RADEON_LLVM=yes
+if test "x$have_libelf" != xyes; then
+ AC_MSG_ERROR([$1 requires libelf when using llvm])
+fi
+}
+
dnl Options for APIs
AC_ARG_ENABLE([opengl],
[AS_HELP_STRING([--disable-opengl],
@@ -2040,15 +2114,6 @@ AC_ARG_WITH([clang-libdir],
[CLANG_LIBDIR=''])
PKG_CHECK_EXISTS([libclc], [have_libclc=yes], [have_libclc=no])
-PKG_CHECK_MODULES([LIBELF], [libelf], [have_libelf=yes], [have_libelf=no])
-
-if test "x$have_libelf" = xno; then
- LIBELF_LIBS=''
- LIBELF_CFLAGS=''
- AC_CHECK_LIB([elf], [elf_memory], [have_libelf=yes;LIBELF_LIBS=-lelf],
[have_libelf=no])
- AC_SUBST([LIBELF_LIBS])
- AC_SUBST([LIBELF_CFLAGS])
-fi
if test "x$enable_opencl" = xyes; then
if test -z "$with_gallium_drivers"; then
@@ -2218,54 +2283,6 @@ AC_ARG_ENABLE([gallium-llvm],
[enable_gallium_llvm="$enableval"],
[enable_gallium_llvm=auto])
-AC_ARG_ENABLE([llvm-shared-libs],
-[AS_HELP_STRING([--enable-llvm-shared-libs],
-[link with LLVM shared libraries @<:@default=enabled@:>@])],
-[enable_llvm_shared_libs="$enableval"],
-[enable_llvm_shared_libs=yes])
-
-AC_ARG_WITH([llvm-prefix],
-[AS_HELP_STRING([--with-llvm-prefix],
-[Prefix for LLVM installations in non-standard locations])],
-[llvm_prefix="$withval"],
-[llvm_prefix=''])
-
-
-# Call this inside ` ` to get the return value.
-# $1 is the llvm-config command with arguments.
-strip_unwanted_llvm_flags() {
-# Use \> (marks the end of the word)
-echo `$1` | sed \
- -e 's/-march=\S*//g' \
- -e 's/-mtune=\S*//g' \
- -e 's/-mcpu=\S*//g' \
- -e 's/-DNDEBUG\>//g' \
- -e 's/-D_GNU_SOURCE\>//g' \
- -e 's/-pedantic\>//g' \
- -e 's/-Wcovered-switch-default\>//g' \
- -e 's/-O.\>//g' \
- -e 's/-g\>//g' \
- -e 's/-Wall\>//g' \
- -e 's/-Wcast-qual\>//g' \
- -e 's/-Woverloaded-virtual\>//g' \
- -e 's/-fcolor-diagnostics\>//g' \
- -e '
[Mesa-dev] [PATCH v5 18/20] configure.ac: Add required LLVM versions to the top
Consolidate the required LLVM versions at the top where the other
versions for dependencies are listed.
v5:
Splitted out separate changes (see patch 19 and 20)
Signed-off-by: Tobias Droste
---
configure.ac | 68 +++-
1 file changed, 54 insertions(+), 14 deletions(-)
diff --git a/configure.ac b/configure.ac
index 2cd7f16..c92aa82 100644
--- a/configure.ac
+++ b/configure.ac
@@ -92,6 +92,14 @@ XVMC_REQUIRED=1.0.6
PYTHON_MAKO_REQUIRED=0.8.0
LIBSENSORS_REQUIRED=4.0.0
+dnl LLVM versions
+LLVM_REQUIRED_GALLIUM=3.3.0
+LLVM_REQUIRED_OPENCL=3.6.0
+LLVM_REQUIRED_R600=3.6.0
+LLVM_REQUIRED_RADEONSI=3.6.0
+LLVM_REQUIRED_RADV=3.9.0
+LLVM_REQUIRED_SWR=3.6.0
+
dnl Check for progs
AC_PROG_CPP
AC_PROG_CC
@@ -995,9 +1003,41 @@ llvm_set_environment_variables() {
}
llvm_check_version_for() {
-if test "${LLVM_VERSION_INT}${LLVM_VERSION_PATCH}" -lt "${1}0${2}${3}";
then
-AC_MSG_ERROR([LLVM $1.$2.$3 or newer is required for $4])
+if test "x$MESA_LLVM" = x0; then
+AC_MSG_ERROR([LLVM $1 or newer is required for $2])
+return
+fi
+
+llvm_target_version_major=`echo $1 | cut -d. -f1 | egrep -o '^[[0-9]]+'`
+llvm_target_version_minor=`echo $1 | cut -d. -f2 | egrep -o '^[[0-9]]+'`
+llvm_target_version_patch=`echo $1 | cut -d. -f3 | egrep -o '^[[0-9]]+'`
+
+if test "$LLVM_VERSION_MAJOR" -gt "$llvm_target_version_major"; then
+# major > required major
+# --> OK
+return
fi
+
+if test "$LLVM_VERSION_MAJOR" -eq "$llvm_target_version_major"; then
+if test "$LLVM_VERSION_MINOR" -gt "$llvm_target_version_minor"; then
+# major = required major and
+# minor > required minor
+# --> OK
+return
+else
+if test "$LLVM_VERSION_MINOR" -eq "$llvm_target_version_minor";
then
+if test "$LLVM_VERSION_PATCH" -ge
"$llvm_target_version_patch"; then
+# major = required major and
+# minor = required minor and
+# patch >= required patch
+# --> OK
+return
+fi
+fi
+fi
+fi
+
+AC_MSG_ERROR([LLVM $1 or newer is required for $2])
}
radeon_llvm_check() {
@@ -1009,11 +1049,11 @@ radeon_llvm_check() {
llvm_check_version_for $*
-llvm_add_target $amdgpu_llvm_target_name $4
+llvm_add_target $amdgpu_llvm_target_name $2
-llvm_add_default_components $4
-llvm_add_component "bitreader" $4
-llvm_add_component "ipo" $4
+llvm_add_default_components $2
+llvm_add_component "bitreader" $2
+llvm_add_component "ipo" $2
NEED_RADEON_LLVM=yes
if test "x$have_libelf" != xyes; then
@@ -1861,7 +1901,7 @@ if test -n "$with_vulkan_drivers"; then
;;
xradeon)
PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >=
$LIBDRM_AMDGPU_REQUIRED])
-radeon_llvm_check "3" "9" "0" "radv"
+radeon_llvm_check $LLVM_REQUIRED_RADV "radv"
HAVE_RADEON_VULKAN=yes;
if test "x$with_sha1" == "x"; then
AC_MSG_ERROR([radv vulkan driver requires SHA1])
@@ -2135,7 +2175,7 @@ if test "x$enable_opencl" = xyes; then
AC_MSG_ERROR([Clover requires libelf])
fi
-llvm_check_version_for "3" "6" "0" "opencl"
+llvm_check_version_for $LLVM_REQUIRED_OPENCL "opencl"
llvm_add_default_components "opencl"
llvm_add_component "all-targets" "opencl"
@@ -2340,7 +2380,7 @@ dnl Gallium helper functions
dnl
gallium_require_llvm() {
if test "x$enable_gallium_llvm" == "xyes"; then
-llvm_check_version_for "3" "3" "0" "gallium"
+llvm_check_version_for $LLVM_REQUIRED_GALLIUM "gallium"
else
AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
fi
@@ -2365,7 +2405,7 @@ require_basic_egl() {
radeon_gallium_llvm_check() {
if test "x$enable_gallium_llvm" != "xyes"; then
-AC_MSG_ERROR([--enable-gallium-llvm is required when building $4])
+AC_MSG_ERROR([--enable-gallium-llvm is required when building $2])
fi
radeon_llvm_check $*
}
@@ -2439,7 +2479,7 @@ if test -n "$with_gallium_drivers"; then
PKG_CHECK_MODULES([RADEON], [libdrm_radeon >=
$LIBDRM_RADEON_REQUIRED])
require_libdrm "r600"
if test "x$enable_opencl" = xyes; then
-radeon_gallium_llvm_check "3" "6" "0" "r600"
+radeon_gallium_llvm_check $LLVM_REQUIRED_R600 "r600"
llvm_add_component "asmparser" "r600"
llvm_add_component "bitreader" "r600"
@@ -2450,7 +2490,7 @@ if test -n "$with_gallium_drivers"; then
PKG_CHECK_MODULES([RADEON], [libdrm_radeon >=
$LIBDRM_RADEON_REQUIRED])
PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >=
$LIBDRM_AMDGPU_REQUIRED])
require_libdrm "radeonsi"
-radeon_galliu
[Mesa-dev] [PATCH v5 09/20] configure.ac: Use short names for r600 und r300
There are no non gallium r300 and r600 drivers anymore. No need to explicilty mention gallium here. Just cosmetics, no functional change. Signed-off-by: Tobias Droste Reviewed-by: Emil Velikov --- configure.ac | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index a511c68..1a50699 100644 --- a/configure.ac +++ b/configure.ac @@ -2451,15 +2451,15 @@ if test -n "$with_gallium_drivers"; then xr300) HAVE_GALLIUM_R300=yes PKG_CHECK_MODULES([RADEON], [libdrm_radeon >= $LIBDRM_RADEON_REQUIRED]) -require_libdrm "Gallium R300" -gallium_require_llvm "Gallium R300" +require_libdrm "r300" +gallium_require_llvm "r300" ;; xr600) HAVE_GALLIUM_R600=yes PKG_CHECK_MODULES([RADEON], [libdrm_radeon >= $LIBDRM_RADEON_REQUIRED]) -require_libdrm "Gallium R600" +require_libdrm "r600" if test "x$enable_opencl" = xyes; then -radeon_gallium_llvm_check "r600g" "3" "6" "0" +radeon_gallium_llvm_check "r600" "3" "6" "0" llvm_add_component "asmparser" "r600" llvm_add_component "bitreader" "r600" -- 2.10.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 01/20] configure.ac: Don't search llvm-config if it's known
This way LLVM_CONFIG can bet set from an env variable if it's outside the $llvm_prefix. This is not a must, but it helps testing. Signed-off-by: Tobias Droste Reviewed-by: Emil Velikov --- configure.ac | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 5f30ae8..5a11798 100644 --- a/configure.ac +++ b/configure.ac @@ -2166,10 +2166,12 @@ if test "x$enable_gallium_llvm" = xauto; then esac fi if test "x$enable_gallium_llvm" = xyes || test "x$HAVE_RADEON_VULKAN" = xyes; then -if test -n "$llvm_prefix"; then -AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no], ["$llvm_prefix/bin"]) -else -AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no]) +if test -z "$LLVM_CONFIG"; then +if test -n "$llvm_prefix"; then +AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no], ["$llvm_prefix/bin"]) +else +AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no]) +fi fi if test "x$LLVM_CONFIG" != xno; then -- 2.10.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 10/20] configure.ac: Check gallium LLVM version in gallium_require_llvm
This moves the LLVM version check to the helper function
gallium_require_llvm() and uses the llvm_check_version_for() helper
instead of open conding the LLVM version check.
gallium_require_llvm is functionally the same as before, because
"enable_gallium_llvm" is only set to "yes" if the host cpu is x86:
if test "x$enable_gallium_llvm" = xauto; then
case "$host_cpu" in
i*86|x86_64|amd64) enable_gallium_llvm=yes;;
esac
fi
This function is also only called now when needed.
Before this patch llvmpipe would call this as soon as LLVM is
installed. Now it only gets called by llvmpipe if gallium
LLVM is actually enabled (i.e. only on x86).
Both reasons mentioned above remove the need to check host cpu
in the gallium_require_llvm function.
Signed-off-by: Tobias Droste
Reviewed-by: Emil Velikov
---
configure.ac | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1a50699..da107b7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -982,12 +982,6 @@ llvm_set_environment_variables() {
LLVM_VERSION_INT=`echo $LLVM_VERSION | sed -e
's/\([[0-9]]\)\.\([[0-9]]\)/\10\2/g'`
fi
-LLVM_REQUIRED_VERSION_MAJOR="3"
-LLVM_REQUIRED_VERSION_MINOR="3"
-if test "$LLVM_VERSION_INT" -lt
"${LLVM_REQUIRED_VERSION_MAJOR}0${LLVM_REQUIRED_VERSION_MINOR}"; then
-AC_MSG_ERROR([LLVM
$LLVM_REQUIRED_VERSION_MAJOR.$LLVM_REQUIRED_VERSION_MINOR or newer is required])
-fi
-
llvm_add_default_components "gallium"
if test "x$enable_opencl" = xyes; then
@@ -2348,11 +2342,10 @@ dnl
dnl Gallium helper functions
dnl
gallium_require_llvm() {
-if test "x$MESA_LLVM" = x0; then
-case "$host" in *gnux32) return;; esac
-case "$host_cpu" in
-i*86|x86_64|amd64) AC_MSG_ERROR([LLVM is required to build $1 on x86
and x86_64]);;
-esac
+if test "x$enable_gallium_llvm" == "xyes"; then
+llvm_check_version_for "3" "3" "0" "gallium"
+else
+AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
fi
}
@@ -2485,7 +2478,7 @@ if test -n "$with_gallium_drivers"; then
;;
xswrast)
HAVE_GALLIUM_SOFTPIPE=yes
-if test "x$MESA_LLVM" = x1; then
+if test "x$MESA_LLVM" = x1 && test "x$enable_gallium_llvm" ==
"xyes"; then
HAVE_GALLIUM_LLVMPIPE=yes
fi
;;
--
2.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 20/20] configure.ac: Create correct LLVM_VERSION_INT with minor >= 10
This makes sure that we handle LLVM minor version >= 10 correctly.
Signed-off-by: Tobias Droste
---
configure.ac | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 5fc2c87..4cdd0cc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -990,7 +990,11 @@ llvm_set_environment_variables() {
LLVM_VERSION_PATCH=0
fi
-LLVM_VERSION_INT="${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}"
+if test "$LLVM_VERSION_MINOR" -lt 10; then
+LLVM_VERSION_INT="${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}"
+else
+LLVM_VERSION_INT="${LLVM_VERSION_MAJOR}${LLVM_VERSION_MINOR}"
+fi
DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT
-DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
MESA_LLVM=1
--
2.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 19/20] configure.ac: Get complete LLVM version from header
Major and minor version are included in the header file since LLVM
version 3.1.0. Since the minimal required version is 3.3.0 we can
remove the workaround if no values for major/minor were found in the
header.
Since LLVM 3.6.0 the patch version is inside the header file of LLVM.
Only radeon drivers need the patch version and they depend on
LLVM >= 3.6.0, so this is safe too.
Signed-off-by: Tobias Droste
---
configure.ac | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index c92aa82..5fc2c87 100644
--- a/configure.ac
+++ b/configure.ac
@@ -982,17 +982,15 @@ llvm_set_environment_variables() {
[#include "${LLVM_INCLUDEDIR}/llvm/Config/llvm-config.h"])
AC_COMPUTE_INT([LLVM_VERSION_MINOR], [LLVM_VERSION_MINOR],
[#include "${LLVM_INCLUDEDIR}/llvm/Config/llvm-config.h"])
+AC_COMPUTE_INT([LLVM_VERSION_PATCH], [LLVM_VERSION_PATCH],
+[#include "${LLVM_INCLUDEDIR}/llvm/Config/llvm-config.h"])
-LLVM_VERSION_PATCH=`echo $LLVM_VERSION | cut -d. -f3 | egrep -o
'^[[0-9]]+'`
+# Only needed for LLVM < 3.6.0
if test -z "$LLVM_VERSION_PATCH"; then
LLVM_VERSION_PATCH=0
fi
-if test -n "${LLVM_VERSION_MAJOR}"; then
-LLVM_VERSION_INT="${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}"
-else
-LLVM_VERSION_INT=`echo $LLVM_VERSION | sed -e
's/\([[0-9]]\)\.\([[0-9]]\)/\10\2/g'`
-fi
+LLVM_VERSION_INT="${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}"
DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT
-DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
MESA_LLVM=1
--
2.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
