Re: [Mesa-dev] [PATCH 2/4] radeonsi: Set range metadata on calls to llvm.SI.tid
On 20.04.2016 02:52, Tom Stellard wrote: > The range metadata tells LLVM the range of expected values for this intrinsic, > so it can do some additional optimizations on the result. > --- > src/gallium/drivers/radeonsi/si_shader.c | 29 ++--- > 1 file changed, 26 insertions(+), 3 deletions(-) > > diff --git a/src/gallium/drivers/radeonsi/si_shader.c > b/src/gallium/drivers/radeonsi/si_shader.c > index 3b6d6e9..b4f2a42 100644 > --- a/src/gallium/drivers/radeonsi/si_shader.c > +++ b/src/gallium/drivers/radeonsi/si_shader.c > @@ -1114,12 +1114,35 @@ static LLVMValueRef get_sample_id(struct > radeon_llvm_context *radeon_bld) > SI_PARAM_ANCILLARY, 8, 4); > } > > +/** > + * Set range metadata on an instruction. This can only be used on load and > + * call instructions. To specify an instruciton can only produce the values Typo: instruciton -> instruction It would also be nice to always write LDS instead of lds in the commit log of patch 4, but either way, with the above typo fixed, the series is Reviewed-by: Michel Dänzer Nice work! -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: fix the --disable-llvm-shared-libs build
On 20.04.2016 03:39, Emil Velikov wrote: > On 19 April 2016 at 15:47, Chuck Atkins wrote: >> This still doesn't quite give what you want. One can also have an llvm with >> component shared libs. So there's three different options for llvm library >> configurations: a single shared lib, component shared libs, or component >> static libs. > From the three - only single shared lib and component static libs are > supported. Right, in fact I understand that the component shared libs are only intended for LLVM developers, and IME trying to use them causes various undesirable side effects. > Personally I'm leaning that we ought to go with the latter only... Esp > considering the problems that people tend to have with mesa + steam, > every so often. Steam and some Steam games unnecessarily overriding system libraries with stale versions causes problems with other libraries as well, so it requires other solutions than linking LLVM statically anyway. > Tom, what is your view on the topic - are you ok with us switching > back to static one and/or nuking the shared one ? For all the reasons Tom mentioned, I kindly ask to leave the possibility of dynamically linking LLVM. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 95003] [Clover / OpenCL] CL_DEVICE_WAVEFRONT_WIDTH_AMD - 0x4043 unimplemented
https://bugs.freedesktop.org/show_bug.cgi?id=95003 --- Comment #3 from Serge Martin --- That would be CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE from clGetKernelWorkGroupInfo -- 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/13] nir/lower_double_ops: lower trunc()
On Wed, 2016-04-20 at 08:37 +0200, Iago Toral wrote:
> On Tue, 2016-04-19 at 15:32 -0700, Jason Ekstrand wrote:
> >
> >
> > On Tue, Apr 12, 2016 at 1:05 AM, Samuel Iglesias Gonsálvez
> > wrote:
> > From: Iago Toral Quiroga
> >
> > At least i965 hardware does not have native support for
> > truncating doubles.
> > ---
> > src/compiler/nir/nir.h | 1 +
> > src/compiler/nir/nir_lower_double_ops.c | 83
> > +
> > 2 files changed, 84 insertions(+)
> >
> > diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> > index 434d92b..f83b2e0 100644
> > --- a/src/compiler/nir/nir.h
> > +++ b/src/compiler/nir/nir.h
> > @@ -2286,6 +2286,7 @@ typedef enum {
> > nir_lower_drcp = (1 << 0),
> > nir_lower_dsqrt = (1 << 1),
> > nir_lower_drsq = (1 << 2),
> > + nir_lower_dtrunc = (1 << 3),
> > } nir_lower_doubles_options;
> >
> > void nir_lower_doubles(nir_shader *shader,
> > nir_lower_doubles_options options);
> > diff --git a/src/compiler/nir/nir_lower_double_ops.c
> > b/src/compiler/nir/nir_lower_double_ops.c
> > index 4cd153c..9eec858 100644
> > --- a/src/compiler/nir/nir_lower_double_ops.c
> > +++ b/src/compiler/nir/nir_lower_double_ops.c
> > @@ -302,6 +302,81 @@ lower_sqrt_rsq(nir_builder *b,
> > nir_ssa_def *src, bool sqrt)
> > return res;
> > }
> >
> > +static nir_ssa_def *
> > +lower_trunc(nir_builder *b, nir_ssa_def *src)
> > +{
> > + nir_ssa_def *unbiased_exp = nir_isub(b, get_exponent(b,
> > src),
> > +nir_imm_int(b,
> > 1023));
> > +
> > + nir_ssa_def *frac_bits = nir_isub(b, nir_imm_int(b, 52),
> > unbiased_exp);
> > +
> > + /*
> > +* Depending on the exponent, we compute a mask with the
> > bits we need to
> > +* remove in order to trunc the double. The mask is
> > computed like this:
> > +*
> > +* if (unbiased_exp < 0)
> > +*mask = 0x0
> > +* else if (unbiased_exp > 52)
> > +*mask = 0x7fff
> > +* else
> > +*mask = (1LL < frac_bits) - 1
> >
> >
> > I'm having a bit of trouble convincing myself that this is correct.
> > Let me walk through it one case at a time:
> >
> >
> > unbiased_exp < 0:
> >
> > In this case, 2^exp <= 2 so src < 1 and the result should be zero. In
> > that case we want to stomp all the bits to zero, not keep them all.
> >
> >
> > unbiased_exp > 52:
> >
> > In this case 2^exp is large enough that all of the bits matter. We
> > want to keep them all not zero them out.
> >
> >
> > else:
> >
> > In this case, 2^exp >= 1 but not big enough to make all the mantissa
> > bits matter. We need to mask off the bottom 52-exp many bits.
> >
> >
> > If I'm getting this backwards, please let me know. If it's doing what
> > I think it's doing, there are several cases this should be getting
> > wrong. Are we testing all of those cases?
>
> Yes, I think you are getting it backwards.
> The mask is used to select
> the bits from the src that we want to keep. So in the case that
> unbiased_exp < 0, a mask of 0 means that we effectively discard all the
> bits, as you expect. If unbiased_exp > 52 then mask is all 1's, meaning
> that we take all the bits.
Actually, the "else" case was implemented backwards and the piglit tests
were not checking that case, so that has to be fixed. Also, the
implementation of this was a bit more complex that it really needs to
be. What a mess... sorry about that.
I changed the implementation so we do this instead:
if (unbiased_exp < 0)
return 0;
else if (unbiased_exp > 52)
return src;
else
return src & (0~ << frac_bits);
And added a few more cases to piglit to make sure we cover all 3
branches now.
> > One other aside: I think it's more efficient to generate the masks
> > with either (~0u >> (32 - bits)) or (0x8000 >> (bits - 1)) if you
> > want the top bits. NIR should be able to easily get rid of the
> > integer adds and subtracts. Getting rid of the -1 on (1 << frac_bits)
> > - 1 is much harder.
>
> Sure, we can do that.
>
> > +*
> > +* Notice that the else branch is a 64-bit integer
> > operation that we need
> > +* to implement in terms of 32-bit integer arithmetics (at
> > least until we
> > +* support 64-bit integer arithmetics).
> > +*/
> > +
> > + /* Compute "mask = (1LL << frac_bits) - 1" in terms of
> > hi/lo 32-bit chunks
> > +* for the else branch
> > +*/
> > + nir_ssa_de
Re: [Mesa-dev] [PATCH v2 04/11] gallium: add endian_format field to struct pipe_resource
On 20.04.2016 03:13, Oded Gabbay wrote: > On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák wrote: >> On Tue, Apr 19, 2016 at 3:11 PM, Oded Gabbay wrote: >>> On Mon, Apr 18, 2016 at 6:03 PM, >>> Ilia Mirkin wrote: On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay wrote: > On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote: >> On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay >> wrote: Wouldn't it make more sense to handle such issues in transfer_map? (i.e. create a staging memory area, and decode into it)? This assumes that the transfer_map() call has enough information to "do the right thing". I don't think it does today, but perhaps it could be taught? >>> It doesn't have all the info today, that's for sure. I imagine though >>> we can add parameters to it. >>> That way everything that's in a pipe_resource is in some tightly-controlled format, and we specify the LE <-> BE parameters when converting between CPU-read/written and GPU-read/written data. I believe this is a better match for what's really happening, too. What do you think? -ilia >>> >>> Unless I'm missing something, I think, at the end of the day, it will >>> be the same issues as in my solution - per code path per format is a >>> different case. That's because you will still need to "teach" >>> transfer_map, per each transfer per format what to do. So one will >>> need to go and debug every single code path there is in mesa for >>> drawing/copying/reading/textures/etc., like what I did in the last 1.5 >>> months. It's a great learning experience but it won't give anything >>> generic. >>> >>> Again, for example, in st_ReadPixels, I imagine you will need to give >>> "different orders" to transfer_map for the two different scenarios - >>> H/W blit and fallback. So what's the gain here ? >>> >>> If I'm missing something, please tell me. >> >> One of us is... let's figure out which one :) >> >> Here's my proposal: >> >> All data stored inside of resources is stored in a driver-happy >> format. The driver ensures that it's stored in proper endianness, etc. >> (Much like it does today wrt proper stride.) >> >> Blitting(/copying) between resources doesn't require any additional >> information, since you have the format(s) of the respective resources, >> and it's all inside the driver, so the driver does whatever it needs >> to do to make it all "work". >> >> *Accessing and modifying* resources (directly) from the CPU is what >> becomes tricky. The state tracker may have incorrect expectations of >> the actual backing data. There are a few different ways to resolve >> this. The one I'm proposing is that you only ever return a pointer to >> the directly underlying data if it matches the CPU's expectations >> (which will only be the case for byte-oriented array formats like >> PIPE_FORMAT_R8G8B8A8_* & co). Everything else, like e.g. >> PIPE_FORMAT_R5G6B5_UNORM and countless others, will have to go through >> a bounce buffer. >> >> At transfer map time, you convert the data from GPU-style to >> CPU-style, and copy back the relevant bits at unmap/flush time. >> >> This presents a nice clean boundary for this stuff. Instead of the >> state tracker trying to guess what the driver will do and feeding it >> endiannesses that it can't possibly guess properly, the tracking logic >> is relegated to the driver, and we extend the interfaces to allow the >> state tracker to access the data in a proper way. >> >> I believe the advantage of this scheme is that beyond adding format >> parameters to pipe_transfer_map() calls, there will not need to be any >> adjustments to the state trackers. >> >> One yet-to-be-resolved issue is what to do about glMapBuffer* - it >> maps a buffer, it's formatless (at map time), and yet the GPU will be >> required to interpret it correctly. We could decree that PIPE_BUFFER >> is just *always* an array of R8_UNORM and thus never needs any type of >> swapping. The driver needs to adjust accordingly to deal with accesses >> that don't fit that pattern (and where parameters can't be fed to the >> GPU to interpret it properly). >> >> I think something like the above will work. And I think it presents a >> cleaner barrier than your proposal, because none of the "this GPU can >> kinda-sorta understand BE, but not everywhere" details are ever >> exposed to the state tracker. >> >> Thoughts? >> >> -ilia > > Ilia, > > To make the GPU do a conversion during blitting, I need to configure > registers. This is done in a couple of functions in the r600g driver > (r600_translate_texformat, r600_colorformat_endian_swap, > r600_
[Mesa-dev] [PATCH 0/3] glsl: tests for glsl warnings
In order to implement the "uninitialized variable" warning it was needed to hande several corner cases manually. Recently I sent a series to fix the last false positive: https://lists.freedesktop.org/archives/mesa-dev/2016-April/113614.html At this point I think that it would be better to include some unit tests, to ensure that changes on glsl doesn't break the warning, being false positives the worst problem (imho). This series add those tests. This is basically a set of shaders, and the expected InfoLog. It uses the standalone compiler to compile those shaders, and use just a diff to compare with the expected outcome. It is not exactly really formal, but I think that would work fine. This could be used to test the expected warnings for any kind of warning, but the series is focused on the "unitialized warning" warning. Alejandro Piñeiro (3): glsl: add just-log option for the standalone compiler. glsl: add warning-test glsl: add unit tests data vertex/expected outcome for unitialized warning src/compiler/Makefile.glsl.am | 3 ++- src/compiler/glsl/main.cpp | 20 +++--- src/compiler/glsl/tests/warnings-test | 31 ++ .../glsl/tests/warnings/000-basic-test.vert| 10 +++ .../tests/warnings/000-basic-test.vert.expected| 1 + .../warnings/001-use-undefined-then-define.vert| 12 + .../001-use-undefined-then-define.vert.expected| 1 + src/compiler/glsl/tests/warnings/002-loop.vert | 23 .../glsl/tests/warnings/002-loop.vert.expected | 3 +++ src/compiler/glsl/tests/warnings/003-less.vert | 17 .../glsl/tests/warnings/003-less.vert.expected | 1 + src/compiler/glsl/tests/warnings/004-greater.vert | 17 .../glsl/tests/warnings/004-greater.vert.expected | 1 + src/compiler/glsl/tests/warnings/005-lequal.vert | 17 .../glsl/tests/warnings/005-lequal.vert.expected | 1 + src/compiler/glsl/tests/warnings/006-gequal.vert | 17 .../glsl/tests/warnings/006-gequal.vert.expected | 1 + src/compiler/glsl/tests/warnings/007-test-mod.vert | 25 + .../glsl/tests/warnings/007-test-mod.vert.expected | 3 +++ .../glsl/tests/warnings/008-mulassign.vert | 12 + .../tests/warnings/008-mulassign.vert.expected | 1 + .../glsl/tests/warnings/009-div-assign.vert| 12 + .../tests/warnings/009-div-assign.vert.expected| 1 + .../glsl/tests/warnings/010-add-assign.vert| 12 + .../tests/warnings/010-add-assign.vert.expected| 1 + .../glsl/tests/warnings/011-sub-assign.vert| 12 + .../tests/warnings/011-sub-assign.vert.expected| 1 + .../glsl/tests/warnings/012-modassign.vert | 12 + .../tests/warnings/012-modassign.vert.expected | 1 + src/compiler/glsl/tests/warnings/013-lsassign.vert | 12 + .../glsl/tests/warnings/013-lsassign.vert.expected | 1 + src/compiler/glsl/tests/warnings/014-rsassign.vert | 12 + .../glsl/tests/warnings/014-rsassign.vert.expected | 1 + .../glsl/tests/warnings/015-andassign.vert | 12 + .../tests/warnings/015-andassign.vert.expected | 1 + src/compiler/glsl/tests/warnings/016-orassign.vert | 12 + .../glsl/tests/warnings/016-orassign.vert.expected | 1 + .../glsl/tests/warnings/017-xorassign.vert | 12 + .../tests/warnings/017-xorassign.vert.expected | 1 + src/compiler/glsl/tests/warnings/018-bitand.vert | 24 + .../glsl/tests/warnings/018-bitand.vert.expected | 3 +++ src/compiler/glsl/tests/warnings/019-array.vert| 23 .../glsl/tests/warnings/019-array.vert.expected| 5 .../glsl/tests/warnings/020-array-length.vert | 12 + .../tests/warnings/020-array-length.vert.expected | 0 src/compiler/glsl/tests/warnings/021-lshift.vert | 25 + .../glsl/tests/warnings/021-lshift.vert.expected | 3 +++ src/compiler/glsl/tests/warnings/022-rshift.vert | 25 + .../glsl/tests/warnings/022-rshift.vert.expected | 3 +++ src/compiler/glsl/tests/warnings/023-switch.vert | 28 +++ .../glsl/tests/warnings/023-switch.vert.expected | 3 +++ .../glsl/tests/warnings/024-shaderout.vert | 19 + .../tests/warnings/024-shaderout.vert.expected | 2 ++ .../025-out-inout-function-parameters.vert | 16 +++ ...025-out-inout-function-parameters.vert.expected | 1 + .../glsl/tests/warnings/026-conditional.vert | 17 .../tests/warnings/026-conditional.vert.expected | 6 + .../glsl/tests/warnings/027-fieldselection.vert| 23 .../warnings/027-fieldselection.vert.expected | 1 + 59 files changed, 568 insertions(+), 5 deletions(-) create mode 100755 src/compiler/glsl/tests/warnings-test create mode 100644 src
[Mesa-dev] [PATCH 3/3] glsl: add unit tests data vertex/expected outcome for unitialized warning
--- Those are basically the shaders I used while developing the warning, plus some cleaning and some extra ones. The only reason they are vertex shaders is that the standalone compiler needs to receive a shader with a valid shader extension. .../glsl/tests/warnings/000-basic-test.vert| 10 .../tests/warnings/000-basic-test.vert.expected| 1 + .../warnings/001-use-undefined-then-define.vert| 12 ++ .../001-use-undefined-then-define.vert.expected| 1 + src/compiler/glsl/tests/warnings/002-loop.vert | 23 ++ .../glsl/tests/warnings/002-loop.vert.expected | 3 +++ src/compiler/glsl/tests/warnings/003-less.vert | 17 + .../glsl/tests/warnings/003-less.vert.expected | 1 + src/compiler/glsl/tests/warnings/004-greater.vert | 17 + .../glsl/tests/warnings/004-greater.vert.expected | 1 + src/compiler/glsl/tests/warnings/005-lequal.vert | 17 + .../glsl/tests/warnings/005-lequal.vert.expected | 1 + src/compiler/glsl/tests/warnings/006-gequal.vert | 17 + .../glsl/tests/warnings/006-gequal.vert.expected | 1 + src/compiler/glsl/tests/warnings/007-test-mod.vert | 25 +++ .../glsl/tests/warnings/007-test-mod.vert.expected | 3 +++ .../glsl/tests/warnings/008-mulassign.vert | 12 ++ .../tests/warnings/008-mulassign.vert.expected | 1 + .../glsl/tests/warnings/009-div-assign.vert| 12 ++ .../tests/warnings/009-div-assign.vert.expected| 1 + .../glsl/tests/warnings/010-add-assign.vert| 12 ++ .../tests/warnings/010-add-assign.vert.expected| 1 + .../glsl/tests/warnings/011-sub-assign.vert| 12 ++ .../tests/warnings/011-sub-assign.vert.expected| 1 + .../glsl/tests/warnings/012-modassign.vert | 12 ++ .../tests/warnings/012-modassign.vert.expected | 1 + src/compiler/glsl/tests/warnings/013-lsassign.vert | 12 ++ .../glsl/tests/warnings/013-lsassign.vert.expected | 1 + src/compiler/glsl/tests/warnings/014-rsassign.vert | 12 ++ .../glsl/tests/warnings/014-rsassign.vert.expected | 1 + .../glsl/tests/warnings/015-andassign.vert | 12 ++ .../tests/warnings/015-andassign.vert.expected | 1 + src/compiler/glsl/tests/warnings/016-orassign.vert | 12 ++ .../glsl/tests/warnings/016-orassign.vert.expected | 1 + .../glsl/tests/warnings/017-xorassign.vert | 12 ++ .../tests/warnings/017-xorassign.vert.expected | 1 + src/compiler/glsl/tests/warnings/018-bitand.vert | 24 +++ .../glsl/tests/warnings/018-bitand.vert.expected | 3 +++ src/compiler/glsl/tests/warnings/019-array.vert| 23 ++ .../glsl/tests/warnings/019-array.vert.expected| 5 .../glsl/tests/warnings/020-array-length.vert | 12 ++ .../tests/warnings/020-array-length.vert.expected | 0 src/compiler/glsl/tests/warnings/021-lshift.vert | 25 +++ .../glsl/tests/warnings/021-lshift.vert.expected | 3 +++ src/compiler/glsl/tests/warnings/022-rshift.vert | 25 +++ .../glsl/tests/warnings/022-rshift.vert.expected | 3 +++ src/compiler/glsl/tests/warnings/023-switch.vert | 28 ++ .../glsl/tests/warnings/023-switch.vert.expected | 3 +++ .../glsl/tests/warnings/024-shaderout.vert | 19 +++ .../tests/warnings/024-shaderout.vert.expected | 2 ++ .../025-out-inout-function-parameters.vert | 16 + ...025-out-inout-function-parameters.vert.expected | 1 + .../glsl/tests/warnings/026-conditional.vert | 17 + .../tests/warnings/026-conditional.vert.expected | 6 + .../glsl/tests/warnings/027-fieldselection.vert| 23 ++ .../warnings/027-fieldselection.vert.expected | 1 + 56 files changed, 519 insertions(+) create mode 100644 src/compiler/glsl/tests/warnings/000-basic-test.vert create mode 100644 src/compiler/glsl/tests/warnings/000-basic-test.vert.expected create mode 100644 src/compiler/glsl/tests/warnings/001-use-undefined-then-define.vert create mode 100644 src/compiler/glsl/tests/warnings/001-use-undefined-then-define.vert.expected create mode 100644 src/compiler/glsl/tests/warnings/002-loop.vert create mode 100644 src/compiler/glsl/tests/warnings/002-loop.vert.expected create mode 100644 src/compiler/glsl/tests/warnings/003-less.vert create mode 100644 src/compiler/glsl/tests/warnings/003-less.vert.expected create mode 100644 src/compiler/glsl/tests/warnings/004-greater.vert create mode 100644 src/compiler/glsl/tests/warnings/004-greater.vert.expected create mode 100644 src/compiler/glsl/tests/warnings/005-lequal.vert create mode 100644 src/compiler/glsl/tests/warnings/005-lequal.vert.expected create mode 100644 src/compiler/glsl/tests/warnings/006-gequal.vert create mode 100644 src/compiler/glsl/tests/warnings/00
[Mesa-dev] [PATCH 1/3] glsl: add just-log option for the standalone compiler.
Add an option in order to ask to just print the InfoLog, without any
header or separator. Useful if we want to use the standalone compiler
to track only the warning/error messages.
---
src/compiler/glsl/main.cpp | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/compiler/glsl/main.cpp b/src/compiler/glsl/main.cpp
index d253575..727f67c 100644
--- a/src/compiler/glsl/main.cpp
+++ b/src/compiler/glsl/main.cpp
@@ -274,12 +274,14 @@ int dump_ast = 0;
int dump_hir = 0;
int dump_lir = 0;
int do_link = 0;
+int just_log = 0;
const struct option compiler_opts[] = {
{ "dump-ast", no_argument, &dump_ast, 1 },
{ "dump-hir", no_argument, &dump_hir, 1 },
{ "dump-lir", no_argument, &dump_lir, 1 },
{ "link", no_argument, &do_link, 1 },
+ { "just-log", no_argument, &just_log, 1 },
{ "version", required_argument, NULL, 'v' },
{ NULL, 0, NULL, 0 }
};
@@ -414,8 +416,13 @@ main(int argc, char **argv)
compile_shader(ctx, shader);
- if (strlen(shader->InfoLog) > 0)
-printf("Info log for %s:\n%s\n", argv[optind], shader->InfoLog);
+ if (strlen(shader->InfoLog) > 0) {
+ if (!just_log)
+printf("Info log for %s:\n", argv[optind]);
+
+ printf("%s", shader->InfoLog);
+ if (!just_log) printf("\n");
+ }
if (!shader->CompileStatus) {
status = EXIT_FAILURE;
@@ -429,8 +436,13 @@ main(int argc, char **argv)
link_shaders(ctx, whole_program);
status = (whole_program->LinkStatus) ? EXIT_SUCCESS : EXIT_FAILURE;
- if (strlen(whole_program->InfoLog) > 0)
-printf("Info log for linking:\n%s\n", whole_program->InfoLog);
+ if (strlen(whole_program->InfoLog) > 0) {
+ printf("\n");
+ if (!just_log)
+printf("Info log for linking:\n");
+ printf("%s", whole_program->InfoLog);
+ if (!just_log) printf("\n");
+ }
}
for (unsigned i = 0; i < MESA_SHADER_STAGES; i++)
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] glsl: add warning-test
It executes compiler-glsl on all the available shaders, and it checks that the outcome is the expected. Bash code based on the already existing optimization-test --- src/compiler/Makefile.glsl.am | 3 ++- src/compiler/glsl/tests/warnings-test | 31 +++ 2 files changed, 33 insertions(+), 1 deletion(-) create mode 100755 src/compiler/glsl/tests/warnings-test diff --git a/src/compiler/Makefile.glsl.am b/src/compiler/Makefile.glsl.am index daf98f6..645b94f 100644 --- a/src/compiler/Makefile.glsl.am +++ b/src/compiler/Makefile.glsl.am @@ -35,7 +35,8 @@ TESTS += glsl/glcpp/tests/glcpp-test \ glsl/tests/general-ir-test \ glsl/tests/optimization-test\ glsl/tests/sampler-types-test \ - glsl/tests/uniform-initializer-test + glsl/tests/uniform-initializer-test \ + glsl/tests/warnings-test TESTS_ENVIRONMENT= \ export PYTHON2=$(PYTHON2); \ diff --git a/src/compiler/glsl/tests/warnings-test b/src/compiler/glsl/tests/warnings-test new file mode 100755 index 000..7ec029b --- /dev/null +++ b/src/compiler/glsl/tests/warnings-test @@ -0,0 +1,31 @@ +#!/usr/bin/env bash + +# Execute several shaders, and check that the InfoLog outcome is the expected. + +compiler=./glsl_compiler +total=0 +pass=0 + +echo "== Testing compilation output ==" +for test in `find . -iname '*.vert'`; do +echo -n "Testing $test..." +$compiler --just-log "$test" > "$test.out" 2>&1 +total=$((total+1)) +if diff "$test.expected" "$test.out" >/dev/null 2>&1; then +echo "PASS" +pass=$((pass+1)) +else +echo "FAIL" +diff "$test.expected" "$test.out" +fi +done + +echo "" +echo "$pass/$total tests returned correct results" +echo "" + +if [[ $pass == $total ]]; then +exit 0 +else +exit 1 +fi -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94291] llvmpipe tests fail if built on skylake i7-6700k
https://bugs.freedesktop.org/show_bug.cgi?id=94291 --- Comment #5 from Timo Aaltonen --- llvm-3.8 misdetects skylake features, this is fixed in 3.9-snapshot.. -- 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 v2 04/11] gallium: add endian_format field to struct pipe_resource
On Wed, Apr 20, 2016 at 11:28 AM, Michel Dänzer wrote: > On 20.04.2016 03:13, Oded Gabbay wrote: >> On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák wrote: >>> On Tue, Apr 19, 2016 at 3:11 PM, Oded Gabbay wrote: On Mon, Apr 18, 2016 at 6:03 PM, Ilia Mirkin wrote: > On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay > wrote: >> On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin >> wrote: >>> On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay >>> wrote: > Wouldn't it make more sense to handle such issues in transfer_map? > (i.e. create a staging memory area, and decode into it)? This assumes > that the transfer_map() call has enough information to "do the right > thing". I don't think it does today, but perhaps it could be taught? It doesn't have all the info today, that's for sure. I imagine though we can add parameters to it. > That way everything that's in a pipe_resource is in some > tightly-controlled format, and we specify the LE <-> BE parameters > when converting between CPU-read/written and GPU-read/written data. I > believe this is a better match for what's really happening, too. What > do you think? > > -ilia Unless I'm missing something, I think, at the end of the day, it will be the same issues as in my solution - per code path per format is a different case. That's because you will still need to "teach" transfer_map, per each transfer per format what to do. So one will need to go and debug every single code path there is in mesa for drawing/copying/reading/textures/etc., like what I did in the last 1.5 months. It's a great learning experience but it won't give anything generic. Again, for example, in st_ReadPixels, I imagine you will need to give "different orders" to transfer_map for the two different scenarios - H/W blit and fallback. So what's the gain here ? If I'm missing something, please tell me. >>> >>> One of us is... let's figure out which one :) >>> >>> Here's my proposal: >>> >>> All data stored inside of resources is stored in a driver-happy >>> format. The driver ensures that it's stored in proper endianness, etc. >>> (Much like it does today wrt proper stride.) >>> >>> Blitting(/copying) between resources doesn't require any additional >>> information, since you have the format(s) of the respective resources, >>> and it's all inside the driver, so the driver does whatever it needs >>> to do to make it all "work". >>> >>> *Accessing and modifying* resources (directly) from the CPU is what >>> becomes tricky. The state tracker may have incorrect expectations of >>> the actual backing data. There are a few different ways to resolve >>> this. The one I'm proposing is that you only ever return a pointer to >>> the directly underlying data if it matches the CPU's expectations >>> (which will only be the case for byte-oriented array formats like >>> PIPE_FORMAT_R8G8B8A8_* & co). Everything else, like e.g. >>> PIPE_FORMAT_R5G6B5_UNORM and countless others, will have to go through >>> a bounce buffer. >>> >>> At transfer map time, you convert the data from GPU-style to >>> CPU-style, and copy back the relevant bits at unmap/flush time. >>> >>> This presents a nice clean boundary for this stuff. Instead of the >>> state tracker trying to guess what the driver will do and feeding it >>> endiannesses that it can't possibly guess properly, the tracking logic >>> is relegated to the driver, and we extend the interfaces to allow the >>> state tracker to access the data in a proper way. >>> >>> I believe the advantage of this scheme is that beyond adding format >>> parameters to pipe_transfer_map() calls, there will not need to be any >>> adjustments to the state trackers. >>> >>> One yet-to-be-resolved issue is what to do about glMapBuffer* - it >>> maps a buffer, it's formatless (at map time), and yet the GPU will be >>> required to interpret it correctly. We could decree that PIPE_BUFFER >>> is just *always* an array of R8_UNORM and thus never needs any type of >>> swapping. The driver needs to adjust accordingly to deal with accesses >>> that don't fit that pattern (and where parameters can't be fed to the >>> GPU to interpret it properly). >>> >>> I think something like the above will work. And I think it presents a >>> cleaner barrier than your proposal, because none of the "this GPU can >>> kinda-sorta understand BE, but not everywhere" details are ever >>> exposed to the state tracker. >>> >>> Thoughts? >>> >>> -ilia >> >> Ilia, >> >> To make the GPU do a conversion during blitting, I need t
Re: [Mesa-dev] [PATCH v2 0/2] Fix Gallium RGB565 image support
On 19.04.2016 00:55, Nicolas Dufresne wrote: > Le lundi 18 avril 2016 à 11:40 +0900, Michel Dänzer a écrit : >> On 17.04.2016 09:49, nico...@ndufresne.ca wrote: >>> >>> From: Nicolas Dufresne >>> >>> Sorry for the long delay breaking down this patch. I have now >>> rebased >>> on top recent mesa tree. First patch creates a new function to >>> convert >>> DRI2 format into PIPE format (to avoid more copy paste). The second >>> fixes >>> the wrong pitch to stride calculation fixing RGB565 support. Note >>> that, in >>> that part of the code, pitch is considered to be in pixels while >>> stride is >>> in bytes. >>> >>> Nicolas Dufresne (2): >>> gallium/dri2: Factor out DRI2 to PIPE_FORMAT conversion >>> gallium/dri2: Fix RGB565 EGLImage creation >>> >>> src/gallium/state_trackers/dri/dri2.c | 105 +- >>> >>> 1 file changed, 51 insertions(+), 54 deletions(-) >> The series is >> >> Reviewed-by: Michel Dänzer >> >> Do you need somebody to push the patches for you? > > Yes please, thanks for the review. Pushed (with the shortlog prefix changed to the more conventional "st/dri:", sorry I missed that before), thanks! -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 04/11] gallium: add endian_format field to struct pipe_resource
On 20.04.2016 17:48, Oded Gabbay wrote: > On Wed, Apr 20, 2016 at 11:28 AM, Michel Dänzer wrote: >> On 20.04.2016 03:13, Oded Gabbay wrote: >>> On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák wrote: On Tue, Apr 19, 2016 at 3:11 PM, Oded Gabbay wrote: > On Mon, Apr 18, 2016 at 6:03 PM, > Ilia Mirkin wrote: >> On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay >> wrote: >>> On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin >>> wrote: On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay wrote: >> Wouldn't it make more sense to handle such issues in transfer_map? >> (i.e. create a staging memory area, and decode into it)? This assumes >> that the transfer_map() call has enough information to "do the right >> thing". I don't think it does today, but perhaps it could be taught? > It doesn't have all the info today, that's for sure. I imagine though > we can add parameters to it. > >> That way everything that's in a pipe_resource is in some >> tightly-controlled format, and we specify the LE <-> BE parameters >> when converting between CPU-read/written and GPU-read/written data. I >> believe this is a better match for what's really happening, too. What >> do you think? >> >> -ilia > > Unless I'm missing something, I think, at the end of the day, it will > be the same issues as in my solution - per code path per format is a > different case. That's because you will still need to "teach" > transfer_map, per each transfer per format what to do. So one will > need to go and debug every single code path there is in mesa for > drawing/copying/reading/textures/etc., like what I did in the last 1.5 > months. It's a great learning experience but it won't give anything > generic. > > Again, for example, in st_ReadPixels, I imagine you will need to give > "different orders" to transfer_map for the two different scenarios - > H/W blit and fallback. So what's the gain here ? > > If I'm missing something, please tell me. One of us is... let's figure out which one :) Here's my proposal: All data stored inside of resources is stored in a driver-happy format. The driver ensures that it's stored in proper endianness, etc. (Much like it does today wrt proper stride.) Blitting(/copying) between resources doesn't require any additional information, since you have the format(s) of the respective resources, and it's all inside the driver, so the driver does whatever it needs to do to make it all "work". *Accessing and modifying* resources (directly) from the CPU is what becomes tricky. The state tracker may have incorrect expectations of the actual backing data. There are a few different ways to resolve this. The one I'm proposing is that you only ever return a pointer to the directly underlying data if it matches the CPU's expectations (which will only be the case for byte-oriented array formats like PIPE_FORMAT_R8G8B8A8_* & co). Everything else, like e.g. PIPE_FORMAT_R5G6B5_UNORM and countless others, will have to go through a bounce buffer. At transfer map time, you convert the data from GPU-style to CPU-style, and copy back the relevant bits at unmap/flush time. This presents a nice clean boundary for this stuff. Instead of the state tracker trying to guess what the driver will do and feeding it endiannesses that it can't possibly guess properly, the tracking logic is relegated to the driver, and we extend the interfaces to allow the state tracker to access the data in a proper way. I believe the advantage of this scheme is that beyond adding format parameters to pipe_transfer_map() calls, there will not need to be any adjustments to the state trackers. One yet-to-be-resolved issue is what to do about glMapBuffer* - it maps a buffer, it's formatless (at map time), and yet the GPU will be required to interpret it correctly. We could decree that PIPE_BUFFER is just *always* an array of R8_UNORM and thus never needs any type of swapping. The driver needs to adjust accordingly to deal with accesses that don't fit that pattern (and where parameters can't be fed to the GPU to interpret it properly). I think something like the above will work. And I think it presents a cleaner barrier than your proposal, because none of the "this GPU can kinda-sorta understand BE, but not everywhere" details are ever exposed to the state tracker. >
Re: [Mesa-dev] [PATCH v2 04/11] gallium: add endian_format field to struct pipe_resource
On Wed, Apr 20, 2016 at 12:04 PM, Michel Dänzer wrote: > On 20.04.2016 17:48, Oded Gabbay wrote: >> On Wed, Apr 20, 2016 at 11:28 AM, Michel Dänzer wrote: >>> On 20.04.2016 03:13, Oded Gabbay wrote: On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák wrote: > On Tue, Apr 19, 2016 at 3:11 PM, Oded Gabbay > wrote: >> On Mon, Apr 18, 2016 at 6:03 PM, >> Ilia Mirkin wrote: >>> On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay >>> wrote: On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote: > On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay > wrote: >>> Wouldn't it make more sense to handle such issues in transfer_map? >>> (i.e. create a staging memory area, and decode into it)? This >>> assumes >>> that the transfer_map() call has enough information to "do the right >>> thing". I don't think it does today, but perhaps it could be taught? >> It doesn't have all the info today, that's for sure. I imagine though >> we can add parameters to it. >> >>> That way everything that's in a pipe_resource is in some >>> tightly-controlled format, and we specify the LE <-> BE parameters >>> when converting between CPU-read/written and GPU-read/written data. >>> I >>> believe this is a better match for what's really happening, too. >>> What >>> do you think? >>> >>> -ilia >> >> Unless I'm missing something, I think, at the end of the day, it will >> be the same issues as in my solution - per code path per format is a >> different case. That's because you will still need to "teach" >> transfer_map, per each transfer per format what to do. So one will >> need to go and debug every single code path there is in mesa for >> drawing/copying/reading/textures/etc., like what I did in the last >> 1.5 >> months. It's a great learning experience but it won't give anything >> generic. >> >> Again, for example, in st_ReadPixels, I imagine you will need to give >> "different orders" to transfer_map for the two different scenarios - >> H/W blit and fallback. So what's the gain here ? >> >> If I'm missing something, please tell me. > > One of us is... let's figure out which one :) > > Here's my proposal: > > All data stored inside of resources is stored in a driver-happy > format. The driver ensures that it's stored in proper endianness, etc. > (Much like it does today wrt proper stride.) > > Blitting(/copying) between resources doesn't require any additional > information, since you have the format(s) of the respective resources, > and it's all inside the driver, so the driver does whatever it needs > to do to make it all "work". > > *Accessing and modifying* resources (directly) from the CPU is what > becomes tricky. The state tracker may have incorrect expectations of > the actual backing data. There are a few different ways to resolve > this. The one I'm proposing is that you only ever return a pointer to > the directly underlying data if it matches the CPU's expectations > (which will only be the case for byte-oriented array formats like > PIPE_FORMAT_R8G8B8A8_* & co). Everything else, like e.g. > PIPE_FORMAT_R5G6B5_UNORM and countless others, will have to go through > a bounce buffer. > > At transfer map time, you convert the data from GPU-style to > CPU-style, and copy back the relevant bits at unmap/flush time. > > This presents a nice clean boundary for this stuff. Instead of the > state tracker trying to guess what the driver will do and feeding it > endiannesses that it can't possibly guess properly, the tracking logic > is relegated to the driver, and we extend the interfaces to allow the > state tracker to access the data in a proper way. > > I believe the advantage of this scheme is that beyond adding format > parameters to pipe_transfer_map() calls, there will not need to be any > adjustments to the state trackers. > > One yet-to-be-resolved issue is what to do about glMapBuffer* - it > maps a buffer, it's formatless (at map time), and yet the GPU will be > required to interpret it correctly. We could decree that PIPE_BUFFER > is just *always* an array of R8_UNORM and thus never needs any type of > swapping. The driver needs to adjust accordingly to deal with accesses > that don't fit that pattern (and where parameters can't be fed to the > GPU to interpret it properly). > > I think something like the above will work. And I think it presents
Re: [Mesa-dev] [PATCH v2 04/11] gallium: add endian_format field to struct pipe_resource
On Wed, Apr 20, 2016 at 11:14 AM, Oded Gabbay wrote: > On Wed, Apr 20, 2016 at 12:04 PM, Michel Dänzer wrote: >> On 20.04.2016 17:48, Oded Gabbay wrote: >>> On Wed, Apr 20, 2016 at 11:28 AM, Michel Dänzer wrote: On 20.04.2016 03:13, Oded Gabbay wrote: > On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák wrote: >> On Tue, Apr 19, 2016 at 3:11 PM, Oded Gabbay >> wrote: >>> On Mon, Apr 18, 2016 at 6:03 PM, >>> Ilia Mirkin wrote: On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay wrote: > On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin > wrote: >> On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay >> wrote: Wouldn't it make more sense to handle such issues in transfer_map? (i.e. create a staging memory area, and decode into it)? This assumes that the transfer_map() call has enough information to "do the right thing". I don't think it does today, but perhaps it could be taught? >>> It doesn't have all the info today, that's for sure. I imagine >>> though >>> we can add parameters to it. >>> That way everything that's in a pipe_resource is in some tightly-controlled format, and we specify the LE <-> BE parameters when converting between CPU-read/written and GPU-read/written data. I believe this is a better match for what's really happening, too. What do you think? -ilia >>> >>> Unless I'm missing something, I think, at the end of the day, it >>> will >>> be the same issues as in my solution - per code path per format is a >>> different case. That's because you will still need to "teach" >>> transfer_map, per each transfer per format what to do. So one will >>> need to go and debug every single code path there is in mesa for >>> drawing/copying/reading/textures/etc., like what I did in the last >>> 1.5 >>> months. It's a great learning experience but it won't give anything >>> generic. >>> >>> Again, for example, in st_ReadPixels, I imagine you will need to >>> give >>> "different orders" to transfer_map for the two different scenarios - >>> H/W blit and fallback. So what's the gain here ? >>> >>> If I'm missing something, please tell me. >> >> One of us is... let's figure out which one :) >> >> Here's my proposal: >> >> All data stored inside of resources is stored in a driver-happy >> format. The driver ensures that it's stored in proper endianness, >> etc. >> (Much like it does today wrt proper stride.) >> >> Blitting(/copying) between resources doesn't require any additional >> information, since you have the format(s) of the respective >> resources, >> and it's all inside the driver, so the driver does whatever it needs >> to do to make it all "work". >> >> *Accessing and modifying* resources (directly) from the CPU is what >> becomes tricky. The state tracker may have incorrect expectations of >> the actual backing data. There are a few different ways to resolve >> this. The one I'm proposing is that you only ever return a pointer to >> the directly underlying data if it matches the CPU's expectations >> (which will only be the case for byte-oriented array formats like >> PIPE_FORMAT_R8G8B8A8_* & co). Everything else, like e.g. >> PIPE_FORMAT_R5G6B5_UNORM and countless others, will have to go >> through >> a bounce buffer. >> >> At transfer map time, you convert the data from GPU-style to >> CPU-style, and copy back the relevant bits at unmap/flush time. >> >> This presents a nice clean boundary for this stuff. Instead of the >> state tracker trying to guess what the driver will do and feeding it >> endiannesses that it can't possibly guess properly, the tracking >> logic >> is relegated to the driver, and we extend the interfaces to allow the >> state tracker to access the data in a proper way. >> >> I believe the advantage of this scheme is that beyond adding format >> parameters to pipe_transfer_map() calls, there will not need to be >> any >> adjustments to the state trackers. >> >> One yet-to-be-resolved issue is what to do about glMapBuffer* - it >> maps a buffer, it's formatless (at map time), and yet the GPU will be >> required to interpret it correctly. We could decree that PIPE_BUFFER >> is just *always* an array of R8_UNORM and thus never needs any type >> of >>>
Re: [Mesa-dev] [PATCH] Update Doxygen for Windows users
On 20 April 2016 at 01:46, Elie TOURNIER wrote: > Now Windows users have the same doxygen files than *nix users > Not tested (I don't have a windows) > > Signed-off-by: Elie TOURNIER > --- > doxygen/doxy.bat | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/doxygen/doxy.bat b/doxygen/doxy.bat > index e566ca3..408964e 100644 > --- a/doxygen/doxy.bat > +++ b/doxygen/doxy.bat > @@ -6,6 +6,9 @@ doxygen swrast_setup.doxy > doxygen tnl.doxy > doxygen core.doxy > doxygen glapi.doxy > +doxygen glsl.doxy > +doxygen nir.doxy > +doxygen i965.doxy > > echo Building again, to resolve tags > doxygen tnl_dd.doxy > @@ -14,4 +17,8 @@ doxygen math.doxy > doxygen swrast.doxy > doxygen swrast_setup.doxy > doxygen tnl.doxy > +doxygen core.doxy > doxygen glapi.doxy > +doxygen glsl.doxy > +doxygen nir.doxy > +doxygen i965.doxy > -- > 1.9.1 > > First word of the first line of the git comment should identify the Mesa sub system. I'd suggest something like "doxygen: Add missing modules to Windows runner". ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] dri/common: add MESA_FORMAT_R8G8B8{A8, X8}_UNORM formats as supported configs
For the series:
Reviewed-by: Marek Olšák
You might want to wait for others to comment.
Mare
On Tue, Apr 19, 2016 at 9:38 PM, Rob Herring wrote:
> Add MESA_FORMAT_R8G8B8A8_UNORM and MESA_FORMAT_R8G8B8X8_UNORM formats as
> these are the preferred formats for Android.
>
> Signed-off-by: Rob Herring
> ---
> src/mesa/drivers/dri/common/utils.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/common/utils.c
> b/src/mesa/drivers/dri/common/utils.c
> index ae8fcab..4b2e89c 100644
> --- a/src/mesa/drivers/dri/common/utils.c
> +++ b/src/mesa/drivers/dri/common/utils.c
> @@ -171,6 +171,10 @@ driCreateConfigs(mesa_format format,
>{ 0x3FF0, 0x000FFC00, 0x03FF, 0x },
>/* MESA_FORMAT_B10G10R10A2_UNORM */
>{ 0x3FF0, 0x000FFC00, 0x03FF, 0xC000 },
> + /* MESA_FORMAT_R8G8B8A8_UNORM */
> + { 0x00FF, 0xFF00, 0x00FF, 0xFF00 },
> + /* MESA_FORMAT_R8G8B8X8_UNORM */
> + { 0x00FF, 0xFF00, 0x00FF, 0x },
> };
>
> const uint32_t * masks;
> @@ -197,6 +201,12 @@ driCreateConfigs(mesa_format format,
> case MESA_FORMAT_B8G8R8A8_SRGB:
>masks = masks_table[2];
>break;
> + case MESA_FORMAT_R8G8B8A8_UNORM:
> + masks = masks_table[5];
> + break;
> + case MESA_FORMAT_R8G8B8X8_UNORM:
> + masks = masks_table[6];
> + break;
> case MESA_FORMAT_B10G10R10X2_UNORM:
>masks = masks_table[3];
>break;
> --
> 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] dri2: Check for dummyContext to see if the glx_context is valid
According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext() always returns a valid pointer. If no context is made current, it will contain dummyContext. Thus a test for NULL will always fail. Patch author: Egbert Eich https://bugzilla.opensuse.org/show_bug.cgi?id=962609 Signed-off-by: Egbert Eich Tested-by: Olaf Hering --- src/glx/dri2_glx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c index 7710349..7288266 100644 --- a/src/glx/dri2_glx.c +++ b/src/glx/dri2_glx.c @@ -520,7 +520,7 @@ dri2GetCurrentContext() struct glx_context *gc = __glXGetCurrentContext(); struct dri2_context *dri2Ctx = (struct dri2_context *)gc; - return dri2Ctx ? dri2Ctx->driContext : NULL; + return (gc != &dummyContext) ? dri2Ctx->driContext : NULL; } /** -- 2.6.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/va: hardlink driver instances to gallium_drv_video.so
Removes the need to set LIBVA_DRIVER_NAME=gallium for supported targets and is
consistent with vdpau and general gallium drivers.
Author: Jimmy Berry
Signed-off-by: Jimmy Berry
---
src/gallium/targets/va/Makefile.am | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/gallium/targets/va/Makefile.am
b/src/gallium/targets/va/Makefile.am
index 1edd5c2..df825b7 100644
--- a/src/gallium/targets/va/Makefile.am
+++ b/src/gallium/targets/va/Makefile.am
@@ -66,3 +66,17 @@ if HAVE_MESA_LLVM
gallium_drv_video_la_LIBADD += $(LLVM_LIBS)
gallium_drv_video_la_LDFLAGS += $(LLVM_LDFLAGS)
endif
+
+# hardlink each megadriver instance, but don't actually have
+# gallium_drv_video.so in the set of final installed files.
+install-data-hook:
+ for i in $(TARGET_DRIVERS); do \
+ ln -f $(DESTDIR)$(vadir)/gallium_drv_video.so\
+ $(DESTDIR)$(vadir)/$${i}_drv_video.so; \
+ done; \
+ $(RM) $(DESTDIR)$(vadir)/gallium_drv_video.*
+
+uninstall-hook:
+ for i in $(TARGET_DRIVERS); do \
+ $(RM) $(DESTDIR)$(vadir)/$${i}_drv_video.so; \
+ done;
--
2.6.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radeonsi: use CE suballocator for CP DMA realignment.
On Wed, Apr 20, 2016 at 1:29 AM, Bas Nieuwenhuizen wrote: > I retract patch 1 and 2. Large scratch buffers are nice, but the > hardware only supports a 32-bit offset into it. You can still allocate a smaller scratch buffer. This should limit the number of waves in hw. TMPRING_SIZE.WAVES should be adjusted accordingly. We can also decrease the size of scratch based on the max number of waves with the given register and LDS usage. si_shader_dump_stats calculates the max number of waves. You just need to: - set TMPRING_SIZE.WAVES = MIN2(32, max_simd_waves * 4) - allocate scratch for TMPRING_SIZE.WAVES waves per CU (instead of 32) - si_context::scratch_waves can be moved to si_shader in some form (e.g. max_scratch_bytes_per_cu) Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] radeonsi: Implement ddx/ddy on VI using ds_bpermute
Patches 1-3:
Reviewed-by: Marek Olšák
Patch 4:
Acked-by: Marek Olšák
Marek
On Tue, Apr 19, 2016 at 7:52 PM, Tom Stellard wrote:
> The ds_bpermute instruction allows threads to transfer data directly
> to or from the vgprs of other threads. These instructions use the lds
> hardware to transfer data, but do not read or write lds memory.
>
> DDX BEFORE:| DDX AFTER:
>|
> v_mbcnt_lo_u32_b32_e64 v2, -1, 0 | v_mbcnt_lo_u32_b32_e64 v2, -1, 0
> v_mbcnt_hi_u32_b32_e64 v2, -1, v2 | v_mbcnt_hi_u32_b32_e64 v2, -1, v2
> v_lshlrev_b32_e32 v4, 2, v2| v_and_b32_e32 v2, 60, v2
> v_and_b32_e32 v2, 60, v2 | v_lshlrev_b32_e32 v2, 2, v2
> v_lshlrev_b32_e32 v3, 2, v2| ds_bpermute_b32 v3, v2, v0
> s_mov_b32 m0, -1 | ds_bpermute_b32 v0, v2, v0 offset:4
> ds_write_b32 v4, v0| s_waitcnt lgkmcnt(0)
> s_waitcnt lgkmcnt(0) |
> v_or_b32_e32 v0, 1, v2 |
> v_lshlrev_b32_e32 v0, 2, v0|
> ds_read_b32 v1, v3 |
> ds_read_b32 v0, v0 |
> s_waitcnt lgkmcnt(0) |
>|
> LDS: 1 blocks | LDS: 0 blocks
> ---
> src/gallium/drivers/radeonsi/si_shader.c | 42
> +++-
> 1 file changed, 30 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c
> b/src/gallium/drivers/radeonsi/si_shader.c
> index 2a747f9..d3e445b 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -4162,6 +4162,7 @@ static void si_llvm_emit_ddxy(
> LLVMValueRef indices[2];
> LLVMValueRef store_ptr, load_ptr0, load_ptr1;
> LLVMValueRef tl, trbl, result[4];
> + LLVMValueRef tl_tid, trbl_tid;
> unsigned swizzle[4];
> unsigned c;
> int idx;
> @@ -4179,20 +4180,24 @@ static void si_llvm_emit_ddxy(
> else
> mask = TID_MASK_TOP_LEFT;
>
> - indices[1] = LLVMBuildAnd(gallivm->builder, indices[1],
> - lp_build_const_int32(gallivm, mask), "");
> + tl_tid = LLVMBuildAnd(gallivm->builder, indices[1],
> + lp_build_const_int32(gallivm, mask), "");
> + indices[1] = tl_tid;
> load_ptr0 = LLVMBuildGEP(gallivm->builder, ctx->lds,
> indices, 2, "");
>
> /* for DDX we want to next X pixel, DDY next Y pixel. */
> idx = (opcode == TGSI_OPCODE_DDX || opcode == TGSI_OPCODE_DDX_FINE) ?
> 1 : 2;
> - indices[1] = LLVMBuildAdd(gallivm->builder, indices[1],
> + trbl_tid = LLVMBuildAdd(gallivm->builder, indices[1],
> lp_build_const_int32(gallivm, idx), "");
> + indices[1] = trbl_tid;
> load_ptr1 = LLVMBuildGEP(gallivm->builder, ctx->lds,
> indices, 2, "");
>
> for (c = 0; c < 4; ++c) {
> unsigned i;
> + LLVMValueRef val;
> + LLVMValueRef args[2];
>
> swizzle[c] =
> tgsi_util_get_full_src_register_swizzle(&inst->Src[0], c);
> for (i = 0; i < c; ++i) {
> @@ -4204,18 +4209,31 @@ static void si_llvm_emit_ddxy(
> if (i != c)
> continue;
>
> - LLVMBuildStore(gallivm->builder,
> - LLVMBuildBitCast(gallivm->builder,
> - lp_build_emit_fetch(bld_base,
> inst, 0, c),
> - ctx->i32, ""),
> - store_ptr);
> + val = LLVMBuildBitCast(gallivm->builder,
> + lp_build_emit_fetch(bld_base, inst, 0, c),
> + ctx->i32, "");
>
> - tl = LLVMBuildLoad(gallivm->builder, load_ptr0, "");
> - tl = LLVMBuildBitCast(gallivm->builder, tl, ctx->f32, "");
> + if ((HAVE_LLVM >= 0x0309) && ctx->screen->b.family >=
> CHIP_TONGA) {
>
> - trbl = LLVMBuildLoad(gallivm->builder, load_ptr1, "");
> - trbl = LLVMBuildBitCast(gallivm->builder, trbl, ctx->f32, "");
> + args[0] = LLVMBuildMul(gallivm->builder, tl_tid,
> +lp_build_const_int32(gallivm, 4),
> "");
> + args[1] = val;
> + tl = lp_build_intrinsic(gallivm->builder,
> + "llvm.amdgcn.ds.bpermute", ctx->i32,
> + args, 2, LLVMReadNoneAttribute);
>
> + args[0] = LLVMBuildMul(gallivm->builder, trbl_tid,
> +lp_build_const_int32(gallivm, 4),
> "");
> + trbl = lp_build_intrinsic(gallivm->builder,
> +
[Mesa-dev] [Bug 94291] llvmpipe tests fail if built on skylake i7-6700k
https://bugs.freedesktop.org/show_bug.cgi?id=94291 --- Comment #6 from Jose Fonseca --- It's not the first time LLVM misidentifies modern CPUs. I thought that all the logic in src/gallium/auxiliary/gallivm/lp_bld_misc.cpp for setting +/-foo mattrs would save us from this sort of grief. On the other hand, I suppose that actually knowing the exact CPU model allows it to better model instruction latency/throughput. -- 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 mesa v2 1/2] nouveau: codegen: Use FILE_MEMORY_BUFFER for buffers
Hi, On 15-04-16 00:29, Samuel Pitoiset wrote: On 04/12/2016 12:04 PM, Hans de Goede wrote: Hi, On 08-04-16 18:14, Samuel Pitoiset wrote: On 04/08/2016 12:17 PM, Hans de Goede wrote: Hi, On 23-03-16 23:10, Samuel Pitoiset wrote: Are you sure this won't break compute shaders on fermi? Could you please double-check that? I just checked: lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1) Before this patch-set: [hans@plank piglit]$ ./piglit run -o shader -t '.*arb_shader_storage_buffer_object.*' results/shader [9/9] pass: 9 / After this patch-set: [hans@plank piglit]$ ./piglit run -o shader -t '.*arb_shader_storage_buffer_object.*' results/shader [9/9] pass: 9 / And what about compute shaders? (ie. -t arb_compute_shader) Sorry to ask you again but I just want to be sure it's fine. :-) Those tests don't run yet on mesa master on the GF119 card I've: [hans@plank piglit]$ ./piglit run -o shader -t '.*arb_compute_shader.*' results/shader [20/20] skip: 20 | My patches don't change anything about this, and they only touch the buffer handling paths and the buffer tests (still) pass... I've also tried on a: 01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GT 740] (rev a1) Same result. Sorry for the delay, I was dealing with images. Well, you needed to override ARB_compute_shader because the extension is not currently exposed. For example: MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader MESA_GL_VERSION_OVERRIDE=4.2 ./piglit-run.py blabla I tried myself to test your series but it no longer applies on top of master. Well, if you make a quick test with: MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader MESA_GL_VERSION_OVERRIDE=4.2 ./piglit-run.py -1 --dmesg -t arb_compute_shader that might be nice Done on both a gf119 and gk107, result on both: [hans@plank piglit]$ DISPLAY=:0 MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader MESA_GL_VERSION_OVERRIDE=4.2 ./piglit run -o shader -t '.*arb_compute_shader.*' results/shader [20/20] skip: 4, pass: 16 | Thank you for running Piglit! > but whatever, series is: Reviewed-by: Samuel Pitoiset Thanks, I've updated the commit msg with the results of the extra tests I've done and pushed these 2 patches to master. Regards, Hans ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: android: add dma-buf fd support
On Tue, Apr 19, 2016 at 11:02 PM, Rob Herring wrote: >> It would ofc be good to make sure we don't break things for >> android-x86, but I think they would stick on dri2 + pre-atomic state >> w/ compile time build decisions until enough of the desktop gpu's >> support atomic.. although maybe it helps to switch them over to >> prime+render without switching to gbm_gralloc and kms hwc stuff yet? > > I'm not sure that will work without a lot of work to drm_gralloc to > support using both the render and card nodes and prime support for > each gpu. > > gbm_gralloc and non-atomic kms in hwc seems like the quickest path to > me, but I may be missing something. hmm, yeah, I guess if it was straightforward to add pageflip support in kms hwc, that sounds like a good option, since all the drivers that android-x86 cares about should support prime+render BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] loader: add a libdrm case for loader_get_device_name_for_fd
On 20 April 2016 at 03:27, Jonathan Gray wrote: > On Tue, Apr 19, 2016 at 07:00:18PM +0100, Emil Velikov wrote: >> On 19 April 2016 at 04:03, Jonathan Gray wrote: >> > Any objections to this? >> > >> Absolutely none. I simply missed it. >> >> > On Mon, Dec 21, 2015 at 04:39:55PM +1100, Jonathan Gray wrote: >> >> Use dev_node_from_fd() with HAVE_LIBDRM to provide an implmentation >> >> of loader_get_device_name_for_fd() for non-linux systems that >> >> use libdrm but don't have udev or sysfs. >> >> >> >> Signed-off-by: Jonathan Gray >> Reviewed-by: Emil Velikov >> >> Jonathan, apart from the patches that I've replied to (and the llvm >> one in a second) do you have any more, even if they're >> nasty/subjective/etc. ? Please send them over and ping me/us is >> there's no reply within a week or so. > > Well some are things like disabling drirc so we can sandbox the chromium > process with a GL context which aren't really suitable. > Ahh yes - drirc workaround might not be applicable. Although others such as the "LLVM requirement and r300" (as described in another thread) are good. So please do send the lot and don't get (too) annoyed if some things get bikeshed(ed) to death. Hopefully that won't happen but you never know. >> >> On the topic of the loader I hope you managed to take a look at the >> libdrm drmDevice API. It does (almost) the same thing as the below >> patch, but my goal is to keep it separate so that one can reuse it >> from other places, plus we can re-spin a libdrm release as often >> and/fast as we need to. In other words - most/all of this nasty code >> will get moved from mesa to libdrm. Note current libdrm implementation >> is Linux only. Please throw in a patch when you can spare some time. > > From a quick look: > > drmGetMinorNameForFD / /dev path matching fd > drm_get_device_name_for_fd from mesa > drmParseSubsystemType / return fixed int for bus > always return DRM_BUS_PCI > drmParsePciDeviceInfo / get pci vendorid/deviceid and subids > drm_get_pci_id_for_fd from mesa > > drmParsePciBusInfo / get pci domain/bus/dev/func from only major/minor > > libpciaccess wouldn't work here, I suspect this would need a new drm > ioctl. Would it be possible to somehow reserve an ioctl number on the > linux side that linux wouldn't need to use? Surely you have some way to get such (somewhat trivial) information from another userspace, right ? Pretty much anyone can/should be able to query the 'hardware location' of a device - aka lspci style. You guys must have that one. Adding (DRM specific) IOCTLS is definitely not what we want here. If any of the split and/or implementation does not work for you guys, feel free to scrap it and plug your own version. Related: Who is responsible for creating the card/render/control/etc nodes as the hardware is detected (system goes up) ? Is it really libdrm or you guys have a some method (daemon?) that manages these kind of things. Why ? I'm really inclined on nuking the mknod and friends from libdrm. Hopefully in the near future. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: fix the --disable-llvm-shared-libs build
On 19/04/16 19:39, Emil Velikov wrote: Hi Chuck, Thanks for chipping in. On 19 April 2016 at 15:47, Chuck Atkins wrote: This still doesn't quite give what you want. One can also have an llvm with component shared libs. So there's three different options for llvm library configurations: a single shared lib, component shared libs, or component static libs. From the three - only single shared lib and component static libs are supported. Personally I'm leaning that we ought to go with the latter only... Esp considering the problems that people tend to have with mesa + steam, every so often. IIRC all the issues that we had with static llvm have been resolved. Plus we have great people like Kai who promptly send patches when things break (which hasn't happen in a long time) Tom, what is your view on the topic - are you ok with us switching back to static one and/or nuking the shared one ? Iirc Jose was clear that in his view one should just static link LLVM. I believe that's still the case, right Jose ? Yes, I think that distros should statically link LLVM. Otherwise Mesa's LLVM can clash with other projects LLVM, which can and often do require a different LLVM version. And there's *lots* of projects out there that use LLVM and OpenGL, particularly languages w/ JIT compilation. That said, I have no objection to allow shared LLVM as an option, particularly if improves developer productivity. I'd still recommend the default would be static and printing a warning when using shared LLVM to warn about the pitfalls. I always statically link LLVM on my case, but unlike Tom I seldom develop on LLVM itself, and I do strip debugging info from LLVM static libraries to avoid huge binaries and slow link time. Anyway, this is just my 2c. As long as the option to link LLVM statically doesn't go away, I'm happy. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94291] llvmpipe tests fail if built on skylake i7-6700k
https://bugs.freedesktop.org/show_bug.cgi?id=94291 --- Comment #7 from Roland Scheidegger --- (In reply to Jose Fonseca from comment #6) > It's not the first time LLVM misidentifies modern CPUs. > > I thought that all the logic in > src/gallium/auxiliary/gallivm/lp_bld_misc.cpp for setting +/-foo mattrs > would save us from this sort of grief. For features we already know about (I think I even mentioned that back then, hoping it wouldn't be a problem)... If I look at the list of skylake features, I'd nearly bet the winner is avx512 (and/or any subvariant). -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: Use correct size for compute CAPs.
Some CAPs are stored as 64-bit value while Mesa stores
the related constant as 32-bit value.
Signed-off-by: Bas Nieuwenhuizen
---
src/mesa/state_tracker/st_extensions.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 939f15d..3f769b6 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1152,6 +1152,7 @@ void st_init_extensions(struct pipe_screen *screen,
PIPE_SHADER_CAP_SUPPORTED_IRS);
if (compute_supported_irs & (1 << PIPE_SHADER_IR_TGSI)) {
uint64_t grid_size[3], block_size[3];
+ uint64_t max_local_size, max_threads_per_block;
screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
PIPE_COMPUTE_CAP_MAX_GRID_SIZE, grid_size);
@@ -1159,10 +1160,13 @@ void st_init_extensions(struct pipe_screen *screen,
PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE,
block_size);
screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
PIPE_COMPUTE_CAP_MAX_THREADS_PER_BLOCK,
- &consts->MaxComputeWorkGroupInvocations);
+ &max_threads_per_block);
screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
PIPE_COMPUTE_CAP_MAX_LOCAL_SIZE,
- &consts->MaxComputeSharedMemorySize);
+ &max_local_size);
+
+ consts->MaxComputeWorkGroupInvocations = max_threads_per_block;
+ consts->MaxComputeSharedMemorySize = max_local_size;
for (i = 0; i < 3; i++) {
consts->MaxComputeWorkGroupCount[i] = grid_size[i];
--
2.8.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [android-x86-devel] [PATCH] android: fix glcpp building error
On Tue, Apr 19, 2016 at 8:45 PM, Mauro Rossi wrote: > LOCAL_C_INCLUDES needs an additional path to fix the following build error: > > external/mesa/src/compiler/glsl/glcpp/glcpp-lex.l:30:25: fatal error: > glcpp-parse.h: No such file or directory > #include "glcpp-parse.h" > ^ > compilation terminated. > build/core/binary.mk:821: recipe for target > 'out/target/product/x86_64/obj/STATIC_LIBRARIES/libmesa_glsl_intermediates/glsl/glcpp/glcpp-lex.o' > failed > make: *** > [out/target/product/x86_64/obj/STATIC_LIBRARIES/libmesa_glsl_intermediates/glsl/glcpp/glcpp-lex.o] > Error 1 > make: *** Waiting for unfinished jobs Already sent a patch for this which should get applied today. Rob ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Use correct mode for split components.
The mode should stay the same as the original struct. In particular, shared should not be changed to temporary. Signed-off-by: Bas Nieuwenhuizen --- src/compiler/glsl/opt_structure_splitting.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler/glsl/opt_structure_splitting.cpp b/src/compiler/glsl/opt_structure_splitting.cpp index 0d18a2f..f4c129e 100644 --- a/src/compiler/glsl/opt_structure_splitting.cpp +++ b/src/compiler/glsl/opt_structure_splitting.cpp @@ -351,7 +351,7 @@ do_structure_splitting(exec_list *instructions) entry->components[i] = new(entry->mem_ctx) ir_variable(type->fields.structure[i].type, name, - ir_var_temporary); + (ir_variable_mode) entry->var->data.mode); entry->var->insert_before(entry->components[i]); } -- 2.8.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] loader: add a libdrm case for loader_get_device_name_for_fd
On Wed, Apr 20, 2016 at 01:33:24PM +0100, Emil Velikov wrote: > On 20 April 2016 at 03:27, Jonathan Gray wrote: > > On Tue, Apr 19, 2016 at 07:00:18PM +0100, Emil Velikov wrote: > >> On 19 April 2016 at 04:03, Jonathan Gray wrote: > >> > Any objections to this? > >> > > >> Absolutely none. I simply missed it. > >> > >> > On Mon, Dec 21, 2015 at 04:39:55PM +1100, Jonathan Gray wrote: > >> >> Use dev_node_from_fd() with HAVE_LIBDRM to provide an implmentation > >> >> of loader_get_device_name_for_fd() for non-linux systems that > >> >> use libdrm but don't have udev or sysfs. > >> >> > >> >> Signed-off-by: Jonathan Gray > >> Reviewed-by: Emil Velikov > >> > >> Jonathan, apart from the patches that I've replied to (and the llvm > >> one in a second) do you have any more, even if they're > >> nasty/subjective/etc. ? Please send them over and ping me/us is > >> there's no reply within a week or so. > > > > Well some are things like disabling drirc so we can sandbox the chromium > > process with a GL context which aren't really suitable. > > > Ahh yes - drirc workaround might not be applicable. Although others > such as the "LLVM requirement and r300" (as described in another > thread) are good. So please do send the lot and don't get (too) > annoyed if some things get bikeshed(ed) to death. Hopefully that won't > happen but you never know. I don't think all are suitable, and some need to be reworked/generalised. > > >> > >> On the topic of the loader I hope you managed to take a look at the > >> libdrm drmDevice API. It does (almost) the same thing as the below > >> patch, but my goal is to keep it separate so that one can reuse it > >> from other places, plus we can re-spin a libdrm release as often > >> and/fast as we need to. In other words - most/all of this nasty code > >> will get moved from mesa to libdrm. Note current libdrm implementation > >> is Linux only. Please throw in a patch when you can spare some time. > > > > From a quick look: > > > > drmGetMinorNameForFD / /dev path matching fd > > drm_get_device_name_for_fd from mesa > > drmParseSubsystemType / return fixed int for bus > > always return DRM_BUS_PCI > > drmParsePciDeviceInfo / get pci vendorid/deviceid and subids > > drm_get_pci_id_for_fd from mesa > > > > drmParsePciBusInfo / get pci domain/bus/dev/func from only major/minor > > > > libpciaccess wouldn't work here, I suspect this would need a new drm > > ioctl. Would it be possible to somehow reserve an ioctl number on the > > linux side that linux wouldn't need to use? > Surely you have some way to get such (somewhat trivial) information > from another userspace, right ? Pretty much anyone can/should be able > to query the 'hardware location' of a device - aka lspci style. You > guys must have that one. Access to pci devices via /dev/pci* with pcidump(8) or lspci from ports requires root. It seems strange to want something that isn't an ioctl when the function takes an open file descriptor to a drm device as an argument. > > Adding (DRM specific) IOCTLS is definitely not what we want here. > > If any of the split and/or implementation does not work for you guys, > feel free to scrap it and plug your own version. > > Related: Who is responsible for creating the card/render/control/etc > nodes as the hardware is detected (system goes up) ? Is it really > libdrm or you guys have a some method (daemon?) that manages these > kind of things. Why ? I'm really inclined on nuking the mknod and > friends from libdrm. Hopefully in the near future. We don't do render/control nodes yet but will in future. The version of libdrm we have have in xenocara currently has a #ifndef __OpenBSD__ around the mknod block. So removing it wouldn't cause any problems for us. There is no daemon or vfs for dev entries. The default device nodes are platform specific, on amd64 it is currently /dev/drm0 -> /dev/drm3 with any additional entries created via the MAKEDEV script or mknod. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swr: fix resource backed constant buffers
While i never got this error in the first place, I can attest that it
certainly hasn't broken any use in paraview, so...
Tested-by: Chuck Atkins
- Chuck
On Tue, Apr 19, 2016 at 1:45 AM, Markus Wick wrote:
> Am 2016-04-19 01:12, schrieb Tim Rowley:
>
>> Code was using an incorrect address for the base pointer.
>>
>
> Tested-by: Markus Wick
>
>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94979
>> ---
>> src/gallium/drivers/swr/swr_state.cpp | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/drivers/swr/swr_state.cpp
>> b/src/gallium/drivers/swr/swr_state.cpp
>> index ded51a9..0e0979d 100644
>> --- a/src/gallium/drivers/swr/swr_state.cpp
>> +++ b/src/gallium/drivers/swr/swr_state.cpp
>> @@ -1138,7 +1138,8 @@ swr_update_derived(struct pipe_context *pipe,
>> pDC->num_constantsVS[i] = cb->buffer_size;
>> if (cb->buffer)
>> pDC->constantVS[i] =
>> - (const float *)((const uint8_t *)cb->buffer +
>> cb->buffer_offset);
>> + (const float
>> *)(swr_resource(cb->buffer)->swr.pBaseAddress +
>> + cb->buffer_offset);
>> else {
>> /* Need to copy these constants to scratch space */
>> if (cb->user_buffer && cb->buffer_size) {
>> @@ -1163,7 +1164,8 @@ swr_update_derived(struct pipe_context *pipe,
>> pDC->num_constantsFS[i] = cb->buffer_size;
>> if (cb->buffer)
>> pDC->constantFS[i] =
>> - (const float *)((const uint8_t *)cb->buffer +
>> cb->buffer_offset);
>> + (const float
>> *)(swr_resource(cb->buffer)->swr.pBaseAddress +
>> + cb->buffer_offset);
>> else {
>> /* Need to copy these constants to scratch space */
>> if (cb->user_buffer && cb->buffer_size) {
>>
>
> ___
> 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] configure.ac: fix the --disable-llvm-shared-libs build
On 19 April 2016 at 20:59, Tom Stellard wrote: > On Tue, Apr 19, 2016 at 07:39:13PM +0100, Emil Velikov wrote: >> Hi Chuck, >> >> Thanks for chipping in. >> >> On 19 April 2016 at 15:47, Chuck Atkins wrote: >> > This still doesn't quite give what you want. One can also have an llvm >> > with >> > component shared libs. So there's three different options for llvm library >> > configurations: a single shared lib, component shared libs, or component >> > static libs. >> From the three - only single shared lib and component static libs are >> supported. >> >> Personally I'm leaning that we ought to go with the latter only... Esp >> considering the problems that people tend to have with mesa + steam, >> every so often. >> >> IIRC all the issues that we had with static llvm have been resolved. >> Plus we have great people like Kai who promptly send patches when >> things break (which hasn't happen in a long time) >> >> Tom, what is your view on the topic - are you ok with us switching >> back to static one and/or nuking the shared one ? Iirc Jose was clear >> that in his view one should just static link LLVM. I believe that's >> still the case, right Jose ? >> > > The shared option is useful for development, because then you don't > need to rebuild mesa every time you make an LLVM change, so I don't want > to remove it. > > I don't really have a strong opinion of what should be default. Static > libraries have the disadvantage of requiring you to explicitly list the > libraries you need, so if a library changes names or a new dependency is > added, the build will break. > It does sound a bit annoying, but surely we can sort these out. There are plenty people using/testing mesa+llvm trunk, so we're bound to get reports and/or patches as things go south. > Static libraries builds also take up a huge amount of disk/memory since > each pipe driver and state tracker has their own copy of LLVM linked in. > Indeed, but we're better than before - we used to have multiple separate driver (per state-tracker) which were (iirc) 70%+ identical. Now we have only one ;-) I have some work laying around to fold the radeon pipe-drivers into one. There was also another to make things completely modular (i.e. toggle between static and dynamic pipe-driver via a configure tweak). Guess I need to revisit that one and finish it (convert Clover). This way you'll get small state tracker libraries and just one pipe-driver shared by all. So in general any issues that we may have with static LLVM are not impossible to resolve. Although based on your and Michel's request I won't attempt removing shared LLVM support. Just going to toggle it back to disabled, barring any objections of course. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] i965/vec4: Use nir_intrinsic_base in the load_uniform implementation
Patched 3-5 are: Reviewed-by: Iago Toral Quiroga On Mon, 2016-04-18 at 19:04 -0700, Jason Ekstrand wrote: > We shouldn't be reading the const_index directly > --- > src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp > b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp > index e199d96..b5c23c9 100644 > --- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp > +++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp > @@ -691,7 +691,7 @@ vec4_visitor::nir_emit_intrinsic(nir_intrinsic_instr > *instr) > >dest = get_nir_dest(instr->dest); > > - src = src_reg(dst_reg(UNIFORM, instr->const_index[0] / 16)); > + src = src_reg(dst_reg(UNIFORM, nir_intrinsic_base(instr) / 16)); >src.type = dest.type; > >/* Uniforms don't actually have to be vec4 aligned. In the case that ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] Support for Android RGBX/RGBA formats
2016-04-20 3:38 GMT+08:00 Rob Herring : > The RGBX/RGBA pixel formats used in the Android EGL don't get configs > created due to the missing formats in the DRI state tracker. This series > adds the necessary formats for configs and DRI images. Support in GBM is > also added as it will be needed soon for Android. > > AFAICT, this has been a long standing bug in Android-x86 which was > worked around with the patch "GLSurfaceView: Be less picky about > EGLConfig alpha sizes". With this series, this patch is no longer needed > and several other bugs like wallpaper not getting displayed are fixed. Sounds great! Thanks a lot for the fix. I'm always curious why they are not supported for such a long time. -- Chih-Wei Android-x86 project http://www.android-x86.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: Use correct size for compute CAPs.
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 20, 2016 at 3:35 PM, Bas Nieuwenhuizen
wrote:
> Some CAPs are stored as 64-bit value while Mesa stores
> the related constant as 32-bit value.
>
> Signed-off-by: Bas Nieuwenhuizen
> ---
> src/mesa/state_tracker/st_extensions.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index 939f15d..3f769b6 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -1152,6 +1152,7 @@ void st_init_extensions(struct pipe_screen *screen,
>PIPE_SHADER_CAP_SUPPORTED_IRS);
>if (compute_supported_irs & (1 << PIPE_SHADER_IR_TGSI)) {
> uint64_t grid_size[3], block_size[3];
> + uint64_t max_local_size, max_threads_per_block;
>
> screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
> PIPE_COMPUTE_CAP_MAX_GRID_SIZE,
> grid_size);
> @@ -1159,10 +1160,13 @@ void st_init_extensions(struct pipe_screen *screen,
> PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE,
> block_size);
> screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
> PIPE_COMPUTE_CAP_MAX_THREADS_PER_BLOCK,
> - &consts->MaxComputeWorkGroupInvocations);
> + &max_threads_per_block);
> screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
> PIPE_COMPUTE_CAP_MAX_LOCAL_SIZE,
> - &consts->MaxComputeSharedMemorySize);
> + &max_local_size);
> +
> + consts->MaxComputeWorkGroupInvocations = max_threads_per_block;
> + consts->MaxComputeSharedMemorySize = max_local_size;
>
> for (i = 0; i < 3; i++) {
> consts->MaxComputeWorkGroupCount[i] = grid_size[i];
> --
> 2.8.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] egl: implement EGL part of interop interface (v2)
Hi Marek,
This patch ended up breaking make check for me (src/egl/egl-symbols-check).
Also, while bisecting, it occurred to me that you pushed v2 of the series,
while you had previously sent a v3 to the mesa-dev list. Was pushing v2
intentional?
--Aaron
On Tue, Mar 8, 2016 at 4:52 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> v2: - use const
> ---
> src/egl/drivers/dri2/egl_dri2.c | 32 ++
> src/egl/drivers/dri2/egl_dri2.h | 1 +
> src/egl/main/eglapi.c | 72
> +
> src/egl/main/eglapi.h | 9 ++
> 4 files changed, 114 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c
> b/src/egl/drivers/dri2/egl_dri2.c
> index 8f50f0c..6e23b71 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -44,6 +44,7 @@
> #endif
> #include
> #include
> +#include "GL/mesa_glinterop.h"
> #include
> #include
>
> @@ -736,6 +737,8 @@ dri2_create_screen(_EGLDisplay *disp)
>if (strcmp(extensions[i]->name, __DRI2_RENDERER_QUERY) == 0) {
> dri2_dpy->rendererQuery = (__DRI2rendererQueryExtension *)
> extensions[i];
>}
> + if (strcmp(extensions[i]->name, __DRI2_INTEROP) == 0)
> + dri2_dpy->interop = (__DRI2interopExtension *) extensions[i];
> }
>
> dri2_setup_screen(disp);
> @@ -2512,6 +2515,33 @@ dri2_server_wait_sync(_EGLDriver *drv, _EGLDisplay
> *dpy, _EGLSync *sync)
> return EGL_TRUE;
> }
>
> +static int
> +dri2_interop_query_device_info(_EGLDisplay *dpy, _EGLContext *ctx,
> + mesa_glinterop_device_info *out)
> +{
> + struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
> + struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
> +
> + if (!dri2_dpy->interop)
> + return MESA_GLINTEROP_UNSUPPORTED;
> +
> + return dri2_dpy->interop->query_device_info(dri2_ctx->dri_context,
> out);
> +}
> +
> +static int
> +dri2_interop_export_object(_EGLDisplay *dpy, _EGLContext *ctx,
> + const mesa_glinterop_export_in *in,
> + mesa_glinterop_export_out *out)
> +{
> + struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
> + struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
> +
> + if (!dri2_dpy->interop)
> + return MESA_GLINTEROP_UNSUPPORTED;
> +
> + return dri2_dpy->interop->export_object(dri2_ctx->dri_context, in,
> out);
> +}
> +
> static void
> dri2_unload(_EGLDriver *drv)
> {
> @@ -2622,6 +2652,8 @@ _eglBuiltInDriverDRI2(const char *args)
> dri2_drv->base.API.ClientWaitSyncKHR = dri2_client_wait_sync;
> dri2_drv->base.API.WaitSyncKHR = dri2_server_wait_sync;
> 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.Name = "DRI2";
> dri2_drv->base.Unload = dri2_unload;
> diff --git a/src/egl/drivers/dri2/egl_dri2.h
> b/src/egl/drivers/dri2/egl_dri2.h
> index 52ad92b..d83bc1e 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -174,6 +174,7 @@ struct dri2_egl_display
> const __DRI2configQueryExtension *config;
> const __DRI2fenceExtension *fence;
> const __DRI2rendererQueryExtension *rendererQuery;
> + const __DRI2interopExtension *interop;
> int fd;
>
> int own_device;
> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> index 32f6823..e229334 100644
> --- a/src/egl/main/eglapi.c
> +++ b/src/egl/main/eglapi.c
> @@ -88,6 +88,7 @@
> #include
> #include "c99_compat.h"
> #include "c11/threads.h"
> +#include "GL/mesa_glinterop.h"
> #include "eglcompiler.h"
>
> #include "eglglobals.h"
> @@ -1905,3 +1906,74 @@ eglGetProcAddress(const char *procname)
>
> RETURN_EGL_SUCCESS(NULL, ret);
> }
> +
> +static int
> +_eglLockDisplayInterop(EGLDisplay dpy, EGLContext context,
> + _EGLDisplay **disp, _EGLDriver **drv,
> + _EGLContext **ctx)
> +{
> +
> + *disp = _eglLockDisplay(dpy);
> + if (!*disp || !(*disp)->Initialized || !(*disp)->Driver) {
> + if (*disp)
> + _eglUnlockDisplay(*disp);
> + return MESA_GLINTEROP_INVALID_DISPLAY;
> + }
> +
> + *drv = (*disp)->Driver;
> +
> + *ctx = _eglLookupContext(context, *disp);
> + if (!*ctx ||
> + ((*ctx)->ClientAPI != EGL_OPENGL_API &&
> +(*ctx)->ClientAPI != EGL_OPENGL_ES_API)) {
> + _eglUnlockDisplay(*disp);
> + return MESA_GLINTEROP_INVALID_CONTEXT;
> + }
> +
> + return MESA_GLINTEROP_SUCCESS;
> +}
> +
> +GLAPI int GLAPIENTRY
> +MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
> +mesa_glinterop_device_info *out)
> +{
> + _EGLDisplay *disp;
> + _EGLDriver *drv;
> + _EGLContext *ctx;
> + int ret;
> +
> + ret = _egl
Re: [Mesa-dev] [PATCH 3/5] egl: implement EGL part of interop interface (v2)
On Wed, Apr 20, 2016 at 4:56 PM, Aaron Watry wrote: > Hi Marek, > > This patch ended up breaking make check for me (src/egl/egl-symbols-check). > > Also, while bisecting, it occurred to me that you pushed v2 of the series, > while you had previously sent a v3 to the mesa-dev list. Was pushing v2 > intentional? Yes, I had to go back, because some the changes in v3 had not been well received by certain individuals. :) Yeah, there are some new exported functions in libGL and libEGL. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94291] llvmpipe tests fail if built on skylake i7-6700k
https://bugs.freedesktop.org/show_bug.cgi?id=94291 --- Comment #8 from Timo Aaltonen --- Actually it wasn't avx512, that was the first one I tried :) It's enabled also on 3.7 and that version works fine. Only one that was added in 3.8 is PKU, but dropping just that didn't help. I did try dropping all non-client features (AVX512, CDI, DQI, BWI, VLX, PKU) and that worked. Maybe one of CDI/DQI/BWI/VLX is somewhat broken on 3.8? -- 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] st/mesa: Use correct size for compute CAPs.
Reviewed-by: Nicolai Hähnle
On 20.04.2016 08:35, Bas Nieuwenhuizen wrote:
Some CAPs are stored as 64-bit value while Mesa stores
the related constant as 32-bit value.
Signed-off-by: Bas Nieuwenhuizen
---
src/mesa/state_tracker/st_extensions.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 939f15d..3f769b6 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1152,6 +1152,7 @@ void st_init_extensions(struct pipe_screen *screen,
PIPE_SHADER_CAP_SUPPORTED_IRS);
if (compute_supported_irs & (1 << PIPE_SHADER_IR_TGSI)) {
uint64_t grid_size[3], block_size[3];
+ uint64_t max_local_size, max_threads_per_block;
screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
PIPE_COMPUTE_CAP_MAX_GRID_SIZE, grid_size);
@@ -1159,10 +1160,13 @@ void st_init_extensions(struct pipe_screen *screen,
PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE,
block_size);
screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
PIPE_COMPUTE_CAP_MAX_THREADS_PER_BLOCK,
- &consts->MaxComputeWorkGroupInvocations);
+ &max_threads_per_block);
screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
PIPE_COMPUTE_CAP_MAX_LOCAL_SIZE,
- &consts->MaxComputeSharedMemorySize);
+ &max_local_size);
+
+ consts->MaxComputeWorkGroupInvocations = max_threads_per_block;
+ consts->MaxComputeSharedMemorySize = max_local_size;
for (i = 0; i < 3; i++) {
consts->MaxComputeWorkGroupCount[i] = grid_size[i];
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] st/mesa: check return value of begin/end_query
From: Nicolai Hähnle
They can only indicate out of memory conditions, since the other error
conditions are caught earlier.
---
src/mesa/state_tracker/st_cb_queryobj.c | 55 -
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
b/src/mesa/state_tracker/st_cb_queryobj.c
index cdb9efc..784ffde 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -61,13 +61,9 @@ st_NewQueryObject(struct gl_context *ctx, GLuint id)
}
-
static void
-st_DeleteQuery(struct gl_context *ctx, struct gl_query_object *q)
+free_queries(struct pipe_context *pipe, struct st_query_object *stq)
{
- struct pipe_context *pipe = st_context(ctx)->pipe;
- struct st_query_object *stq = st_query_object(q);
-
if (stq->pq) {
pipe->destroy_query(pipe, stq->pq);
stq->pq = NULL;
@@ -77,6 +73,16 @@ st_DeleteQuery(struct gl_context *ctx, struct
gl_query_object *q)
pipe->destroy_query(pipe, stq->pq_begin);
stq->pq_begin = NULL;
}
+}
+
+
+static void
+st_DeleteQuery(struct gl_context *ctx, struct gl_query_object *q)
+{
+ struct pipe_context *pipe = st_context(ctx)->pipe;
+ struct st_query_object *stq = st_query_object(q);
+
+ free_queries(pipe, stq);
free(stq);
}
@@ -89,6 +95,7 @@ st_BeginQuery(struct gl_context *ctx, struct gl_query_object
*q)
struct pipe_context *pipe = st->pipe;
struct st_query_object *stq = st_query_object(q);
unsigned type;
+ bool ret = false;
st_flush_bitmap_cache(st_context(ctx));
@@ -133,14 +140,7 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
if (stq->type != type) {
/* free old query of different type */
- if (stq->pq) {
- pipe->destroy_query(pipe, stq->pq);
- stq->pq = NULL;
- }
- if (stq->pq_begin) {
- pipe->destroy_query(pipe, stq->pq_begin);
- stq->pq_begin = NULL;
- }
+ free_queries(pipe, stq);
stq->type = PIPE_QUERY_TYPES; /* an invalid value */
}
@@ -151,20 +151,25 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
stq->pq_begin = pipe->create_query(pipe, type, 0);
stq->type = type;
}
- pipe->end_query(pipe, stq->pq_begin);
+ if (stq->pq_begin)
+ ret = pipe->end_query(pipe, stq->pq_begin);
} else {
if (!stq->pq) {
stq->pq = pipe->create_query(pipe, type, q->Stream);
stq->type = type;
}
- if (stq->pq) {
- pipe->begin_query(pipe, stq->pq);
- }
- else {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
- return;
- }
+ if (stq->pq)
+ ret = pipe->begin_query(pipe, stq->pq);
}
+
+ if (!ret) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
+
+ free_queries(pipe, stq);
+ q->Active = GL_FALSE;
+ return;
+ }
+
assert(stq->type == type);
}
@@ -174,6 +179,7 @@ st_EndQuery(struct gl_context *ctx, struct gl_query_object
*q)
{
struct pipe_context *pipe = st_context(ctx)->pipe;
struct st_query_object *stq = st_query_object(q);
+ bool ret = false;
st_flush_bitmap_cache(st_context(ctx));
@@ -185,7 +191,12 @@ st_EndQuery(struct gl_context *ctx, struct gl_query_object
*q)
}
if (stq->pq)
- pipe->end_query(pipe, stq->pq);
+ ret = pipe->end_query(pipe, stq->pq);
+
+ if (!ret) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
+ return;
+ }
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] radeon: handle query buffer allocation and mapping failures
From: Nicolai Hähnle
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94984
---
src/gallium/drivers/radeon/r600_query.c | 40 ++---
src/gallium/drivers/radeon/r600_query.h | 2 +-
2 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index e5e032b..922d2b5 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -271,14 +271,20 @@ static struct r600_resource *r600_new_query_buffer(struct
r600_common_context *c
struct r600_resource *buf = (struct r600_resource*)
pipe_buffer_create(ctx->b.screen, PIPE_BIND_CUSTOM,
PIPE_USAGE_STAGING, buf_size);
+ if (!buf)
+ return NULL;
- if (query->flags & R600_QUERY_HW_FLAG_PREDICATE)
- query->ops->prepare_buffer(ctx, query, buf);
+ if (query->flags & R600_QUERY_HW_FLAG_PREDICATE) {
+ if (!query->ops->prepare_buffer(ctx, query, buf)) {
+ pipe_resource_reference((struct pipe_resource **)&buf,
NULL);
+ return NULL;
+ }
+ }
return buf;
}
-static void r600_query_hw_prepare_buffer(struct r600_common_context *ctx,
+static bool r600_query_hw_prepare_buffer(struct r600_common_context *ctx,
struct r600_query_hw *query,
struct r600_resource *buffer)
{
@@ -286,6 +292,8 @@ static void r600_query_hw_prepare_buffer(struct
r600_common_context *ctx,
uint32_t *results = ctx->ws->buffer_map(buffer->buf, NULL,
PIPE_TRANSFER_WRITE |
PIPE_TRANSFER_UNSYNCHRONIZED);
+ if (!results)
+ return false;
memset(results, 0, buffer->b.b.width0);
@@ -306,6 +314,8 @@ static void r600_query_hw_prepare_buffer(struct
r600_common_context *ctx,
results += 4 * ctx->max_db;
}
}
+
+ return true;
}
static struct r600_query_ops query_hw_ops = {
@@ -496,6 +506,9 @@ static void r600_query_hw_emit_start(struct
r600_common_context *ctx,
{
uint64_t va;
+ if (!query->buffer.buf)
+ return; // previous buffer allocation failure
+
r600_update_occlusion_query_state(ctx, query->b.type, 1);
r600_update_prims_generated_query_state(ctx, query->b.type, 1);
@@ -506,9 +519,11 @@ static void r600_query_hw_emit_start(struct
r600_common_context *ctx,
if (query->buffer.results_end + query->result_size >
query->buffer.buf->b.b.width0) {
struct r600_query_buffer *qbuf =
MALLOC_STRUCT(r600_query_buffer);
*qbuf = query->buffer;
- query->buffer.buf = r600_new_query_buffer(ctx, query);
query->buffer.results_end = 0;
query->buffer.previous = qbuf;
+ query->buffer.buf = r600_new_query_buffer(ctx, query);
+ if (!query->buffer.buf)
+ return;
}
/* emit begin query */
@@ -575,6 +590,9 @@ static void r600_query_hw_emit_stop(struct
r600_common_context *ctx,
{
uint64_t va;
+ if (!query->buffer.buf)
+ return; // previous buffer allocation failure
+
/* The queries which need begin already called this in begin_query. */
if (query->flags & R600_QUERY_HW_FLAG_NO_START) {
ctx->need_gfx_cs_space(&ctx->b, query->num_cs_dw_end, FALSE);
@@ -694,6 +712,9 @@ static void r600_query_hw_reset_buffers(struct
r600_common_context *rctx,
FREE(qbuf);
}
+ query->buffer.results_end = 0;
+ query->buffer.previous = NULL;
+
if (query->flags & R600_QUERY_HW_FLAG_PREDICATE) {
/* Obtain a new buffer if the current one can't be mapped
without a stall. */
if (r600_rings_is_buffer_referenced(rctx,
query->buffer.buf->buf, RADEON_USAGE_READWRITE) ||
@@ -701,12 +722,10 @@ static void r600_query_hw_reset_buffers(struct
r600_common_context *rctx,
pipe_resource_reference((struct
pipe_resource**)&query->buffer.buf, NULL);
query->buffer.buf = r600_new_query_buffer(rctx, query);
} else {
- query->ops->prepare_buffer(rctx, query,
query->buffer.buf);
+ if (!query->ops->prepare_buffer(rctx, query,
query->buffer.buf))
+ pipe_resource_reference((struct
pipe_resource**)&query->buffer.buf, NULL);
}
}
-
- query->buffer.results_end = 0;
- query->buffer.previous = NULL;
}
boolean r600_query_hw_begin(struct r600_common_context *rctx,
@@ -722,6 +741,8 @@ boolean r600_query_hw_begin(struct r600_common_context
*rctx,
r600_query
[Mesa-dev] [PATCH 01/10] radeonsi: rename and rearrange RW buffer slots
From: Marek Olšák
- use an enum
- use a unique slot number regardless of the shader stage
(the per-stage slots will go away for RW buffers)
---
src/gallium/drivers/radeonsi/si_descriptors.c | 6 ++---
src/gallium/drivers/radeonsi/si_shader.c| 13 ++
src/gallium/drivers/radeonsi/si_state.h | 34 +++--
src/gallium/drivers/radeonsi/si_state_shaders.c | 16 ++--
4 files changed, 39 insertions(+), 30 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 1580e61..01cf79e 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -1045,7 +1045,7 @@ static void si_set_streamout_targets(struct pipe_context
*ctx,
/* Set the shader resources.*/
for (i = 0; i < num_targets; i++) {
- bufidx = SI_SO_BUF_OFFSET + i;
+ bufidx = SI_VS_STREAMOUT_BUF0 + i;
if (targets[i]) {
struct pipe_resource *buffer = targets[i]->buffer;
@@ -1085,7 +1085,7 @@ static void si_set_streamout_targets(struct pipe_context
*ctx,
buffers->desc.dirty_mask |= 1llu << bufidx;
}
for (; i < old_num_targets; i++) {
- bufidx = SI_SO_BUF_OFFSET + i;
+ bufidx = SI_VS_STREAMOUT_BUF0 + i;
/* Clear the descriptor and unset the resource. */
memset(buffers->desc.list + bufidx*4, 0, sizeof(uint32_t) * 4);
pipe_resource_reference(&buffers->buffers[bufidx], NULL);
@@ -1212,7 +1212,7 @@ static void si_invalidate_buffer(struct pipe_context
*ctx, struct pipe_resource
rbuffer,
buffers->shader_usage,
buffers->priority);
- if (i >= SI_SO_BUF_OFFSET && shader ==
PIPE_SHADER_VERTEX) {
+ if (i >= SI_VS_STREAMOUT_BUF0 && shader ==
PIPE_SHADER_VERTEX) {
/* Update the streamout state. */
if (sctx->b.streamout.begin_emitted) {
r600_emit_streamout_end(&sctx->b);
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 3bf68eb..231b2c3 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2186,7 +2186,7 @@ static void si_write_tess_factors(struct
lp_build_tgsi_context *bld_base,
rw_buffers = LLVMGetParam(ctx->radeon_bld.main_fn,
SI_PARAM_RW_BUFFERS);
buffer = build_indexed_load_const(ctx, rw_buffers,
- lp_build_const_int32(gallivm, SI_RING_TESS_FACTOR));
+ lp_build_const_int32(gallivm, SI_HS_RING_TESS_FACTOR));
/* Get the offset. */
tf_base = LLVMGetParam(ctx->radeon_bld.main_fn,
@@ -5240,7 +5240,7 @@ static void preload_streamout_buffers(struct
si_shader_context *ctx)
for (i = 0; i < 4; ++i) {
if (ctx->shader->selector->so.stride[i]) {
LLVMValueRef offset = lp_build_const_int32(gallivm,
-
SI_SO_BUF_OFFSET + i);
+
SI_VS_STREAMOUT_BUF0 + i);
ctx->so_buffers[i] = build_indexed_load_const(ctx,
buf_ptr, offset);
}
@@ -5264,14 +5264,17 @@ static void preload_ring_buffers(struct
si_shader_context *ctx)
(ctx->type == TGSI_PROCESSOR_TESS_EVAL &&
ctx->shader->key.tes.as_es) ||
ctx->type == TGSI_PROCESSOR_GEOMETRY) {
- LLVMValueRef offset = lp_build_const_int32(gallivm,
SI_RING_ESGS);
+ unsigned ring =
+ ctx->type == TGSI_PROCESSOR_GEOMETRY ? SI_GS_RING_ESGS
+: SI_ES_RING_ESGS;
+ LLVMValueRef offset = lp_build_const_int32(gallivm, ring);
ctx->esgs_ring =
build_indexed_load_const(ctx, buf_ptr, offset);
}
if (ctx->is_gs_copy_shader) {
- LLVMValueRef offset = lp_build_const_int32(gallivm,
SI_RING_GSVS);
+ LLVMValueRef offset = lp_build_const_int32(gallivm,
SI_VS_RING_GSVS);
ctx->gsvs_ring[0] =
build_indexed_load_const(ctx, buf_ptr, offset);
@@ -5279,7 +5282,7 @@ static void preload_ring_buffers(struct si_shader_context
*ctx)
if (ctx->type == TGSI_PROCESSOR_GEOMETRY) {
int i;
for (i = 0; i < 4; i++) {
- LLVMValueRef offset = lp_build_const_int32(gallivm,
SI_RING_GSVS + i);
+ LLVMValueRef offset = lp_build_const_int3
[Mesa-dev] [PATCH 06/10] radeonsi: move sample positions constant buffer to RW buffers
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 4 ++--
src/gallium/drivers/radeonsi/si_state.c | 4 ++--
src/gallium/drivers/radeonsi/si_state.h | 1 +
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index c9760f0..c3a9120 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1135,8 +1135,8 @@ static LLVMValueRef load_sample_position(struct
radeon_llvm_context *radeon_bld,
struct lp_build_context *uint_bld = &radeon_bld->soa.bld_base.uint_bld;
struct gallivm_state *gallivm = &radeon_bld->gallivm;
LLVMBuilderRef builder = gallivm->builder;
- LLVMValueRef desc = LLVMGetParam(ctx->radeon_bld.main_fn,
SI_PARAM_CONST_BUFFERS);
- LLVMValueRef buf_index = lp_build_const_int32(gallivm,
SI_DRIVER_STATE_CONST_BUF);
+ LLVMValueRef desc = LLVMGetParam(ctx->radeon_bld.main_fn,
SI_PARAM_RW_BUFFERS);
+ LLVMValueRef buf_index = lp_build_const_int32(gallivm,
SI_PS_CONST_SAMPLE_POSITIONS);
LLVMValueRef resource = build_indexed_load_const(ctx, desc, buf_index);
/* offset = sample_id * 8 (8 = 2 floats containing samplepos.xy) */
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 1e4f35d..56f484a 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -2544,8 +2544,8 @@ static void si_set_framebuffer_state(struct pipe_context
*ctx,
assert(0);
}
constbuf.buffer_size = sctx->framebuffer.nr_samples * 2 * 4;
- ctx->set_constant_buffer(ctx, PIPE_SHADER_FRAGMENT,
-SI_DRIVER_STATE_CONST_BUF, &constbuf);
+ si_set_constant_buffer(sctx, &sctx->rw_buffers,
+ SI_PS_CONST_SAMPLE_POSITIONS, &constbuf);
/* Smoothing (only possible with nr_samples == 1) uses the same
* sample locations as the MSAA it simulates.
diff --git a/src/gallium/drivers/radeonsi/si_state.h
b/src/gallium/drivers/radeonsi/si_state.h
index a017536..159bdea 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -180,6 +180,7 @@ enum {
SI_VS_CONST_CLIP_PLANES,
SI_PS_CONST_POLY_STIPPLE,
+ SI_PS_CONST_SAMPLE_POSITIONS,
SI_NUM_RW_BUFFERS,
};
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] radeonsi: make RW buffer descriptor array global, not per shader stage
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_descriptors.c | 50 +--
src/gallium/drivers/radeonsi/si_pipe.h| 2 +-
2 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 01cf79e..c802b1e 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -900,7 +900,7 @@ void si_set_ring_buffer(struct pipe_context *ctx, uint
shader, uint slot,
unsigned element_size, unsigned index_stride, uint64_t
offset)
{
struct si_context *sctx = (struct si_context *)ctx;
- struct si_buffer_resources *buffers = &sctx->rw_buffers[shader];
+ struct si_buffer_resources *buffers = &sctx->rw_buffers;
if (shader >= SI_NUM_SHADERS)
return;
@@ -994,7 +994,7 @@ static void si_set_streamout_targets(struct pipe_context
*ctx,
const unsigned *offsets)
{
struct si_context *sctx = (struct si_context *)ctx;
- struct si_buffer_resources *buffers =
&sctx->rw_buffers[PIPE_SHADER_VERTEX];
+ struct si_buffer_resources *buffers = &sctx->rw_buffers;
unsigned old_num_targets = sctx->b.streamout.num_targets;
unsigned i, bufidx;
@@ -1198,7 +1198,7 @@ static void si_invalidate_buffer(struct pipe_context
*ctx, struct pipe_resource
/* Read/Write buffers. */
for (shader = 0; shader < SI_NUM_SHADERS; shader++) {
- struct si_buffer_resources *buffers = &sctx->rw_buffers[shader];
+ struct si_buffer_resources *buffers = &sctx->rw_buffers;
uint64_t mask = buffers->desc.enabled_mask;
while (mask) {
@@ -1289,7 +1289,6 @@ static void si_mark_shader_pointers_dirty(struct
si_context *sctx,
unsigned shader)
{
sctx->const_buffers[shader].desc.pointer_dirty = true;
- sctx->rw_buffers[shader].desc.pointer_dirty = true;
sctx->shader_buffers[shader].desc.pointer_dirty = true;
sctx->samplers[shader].views.desc.pointer_dirty = true;
sctx->images[shader].desc.pointer_dirty = true;
@@ -1307,6 +1306,7 @@ static void si_shader_userdata_begin_new_cs(struct
si_context *sctx)
for (i = 0; i < SI_NUM_SHADERS; i++) {
si_mark_shader_pointers_dirty(sctx, i);
}
+ sctx->rw_buffers.desc.pointer_dirty = true;
}
/* Set a base register address for user data constants in the given shader.
@@ -1385,22 +1385,23 @@ void si_emit_graphics_shader_userdata(struct si_context
*sctx,
uint32_t *sh_base = sctx->shader_userdata.sh_base;
if (sctx->gs_shader.cso) {
- /* The VS copy shader needs these for clipping, streamout, and
rings. */
+ /* The VS copy shader needs this for clipping. */
unsigned vs_base = R_00B130_SPI_SHADER_USER_DATA_VS_0;
unsigned i = PIPE_SHADER_VERTEX;
si_emit_shader_pointer(sctx, &sctx->const_buffers[i].desc,
vs_base, true);
- si_emit_shader_pointer(sctx, &sctx->rw_buffers[i].desc,
vs_base, true);
+ }
- if (sctx->tes_shader.cso) {
- /* The TESSEVAL shader needs this for the ESGS ring
buffer. */
- si_emit_shader_pointer(sctx, &sctx->rw_buffers[i].desc,
-
R_00B330_SPI_SHADER_USER_DATA_ES_0, true);
- }
- } else if (sctx->tes_shader.cso) {
- /* The TESSEVAL shader needs this for streamout. */
- si_emit_shader_pointer(sctx,
&sctx->rw_buffers[PIPE_SHADER_VERTEX].desc,
+ if (sctx->rw_buffers.desc.pointer_dirty) {
+ si_emit_shader_pointer(sctx, &sctx->rw_buffers.desc,
R_00B130_SPI_SHADER_USER_DATA_VS_0,
true);
+ si_emit_shader_pointer(sctx, &sctx->rw_buffers.desc,
+ R_00B230_SPI_SHADER_USER_DATA_GS_0,
true);
+ si_emit_shader_pointer(sctx, &sctx->rw_buffers.desc,
+ R_00B330_SPI_SHADER_USER_DATA_ES_0,
true);
+ si_emit_shader_pointer(sctx, &sctx->rw_buffers.desc,
+ R_00B430_SPI_SHADER_USER_DATA_HS_0,
true);
+ sctx->rw_buffers.desc.pointer_dirty = false;
}
for (i = 0; i < SI_NUM_GRAPHICS_SHADERS; i++) {
@@ -1409,9 +1410,6 @@ void si_emit_graphics_shader_userdata(struct si_context
*sctx,
if (!base)
continue;
- if (i != PIPE_SHADER_TESS_EVAL)
- si_emit_shader_pointer(sctx, &sctx->rw_buffers[i].desc,
base, false);
-
si_emit_shader_pointer(sctx, &sctx->const_buffers[i].desc,
base, false);
si_emit_shader_pointer(sctx, &
[Mesa-dev] [PATCH 00/10] RadeonSI: cleanup RW shader slots
Hi, This moves all private shader resources to the RW buffer bindings, including all driver constant buffers, and the poly stipple image (which is converted into a constant buffer). RW buffer descriptors are made global, not per shader stage, so all shaders receive the same pointer. Finally, all shader resource binding masks are shortened to 32 bits. Please review. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] radeonsi: generalize si_set_constant_buffer
From: Marek Olšák
this will be used in the next commit
---
src/gallium/drivers/radeonsi/si_descriptors.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index c802b1e..b8f74f4 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -775,15 +775,10 @@ void si_upload_const_buffer(struct si_context *sctx,
struct r600_resource **rbuf
util_memcpy_cpu_to_le32(tmp, ptr, size);
}
-static void si_set_constant_buffer(struct pipe_context *ctx, uint shader, uint
slot,
- struct pipe_constant_buffer *input)
+static void si_set_constant_buffer(struct si_context *sctx,
+ struct si_buffer_resources *buffers,
+ uint slot, struct pipe_constant_buffer
*input)
{
- struct si_context *sctx = (struct si_context *)ctx;
- struct si_buffer_resources *buffers = &sctx->const_buffers[shader];
-
- if (shader >= SI_NUM_SHADERS)
- return;
-
assert(slot < buffers->desc.num_elements);
pipe_resource_reference(&buffers->buffers[slot], NULL);
@@ -806,7 +801,7 @@ static void si_set_constant_buffer(struct pipe_context
*ctx, uint shader, uint s
input->buffer_size,
&buffer_offset);
if (!buffer) {
/* Just unbind on failure. */
- si_set_constant_buffer(ctx, shader, slot, NULL);
+ si_set_constant_buffer(sctx, buffers, slot,
NULL);
return;
}
va = r600_resource(buffer)->gpu_address + buffer_offset;
@@ -842,6 +837,18 @@ static void si_set_constant_buffer(struct pipe_context
*ctx, uint shader, uint s
buffers->desc.dirty_mask |= 1llu << slot;
}
+static void si_pipe_set_constant_buffer(struct pipe_context *ctx,
+ uint shader, uint slot,
+ struct pipe_constant_buffer *input)
+{
+ struct si_context *sctx = (struct si_context *)ctx;
+
+ if (shader >= SI_NUM_SHADERS)
+ return;
+
+ si_set_constant_buffer(sctx, &sctx->const_buffers[shader], slot, input);
+}
+
/* SHADER BUFFERS */
static void si_set_shader_buffers(struct pipe_context *ctx, unsigned shader,
@@ -1470,7 +1477,7 @@ void si_init_all_descriptors(struct si_context *sctx)
/* Set pipe_context functions. */
sctx->b.b.bind_sampler_states = si_bind_sampler_states;
sctx->b.b.set_shader_images = si_set_shader_images;
- sctx->b.b.set_constant_buffer = si_set_constant_buffer;
+ sctx->b.b.set_constant_buffer = si_pipe_set_constant_buffer;
sctx->b.b.set_shader_buffers = si_set_shader_buffers;
sctx->b.b.set_sampler_views = si_set_sampler_views;
sctx->b.b.set_stream_output_targets = si_set_streamout_targets;
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/10] radeonsi: decrease GS copy shader user SGPRs to 2
From: Marek Olšák
const buffers are no longer used since the clip plane const buffer was
moved to RW buffers
---
src/gallium/drivers/radeonsi/si_shader.c | 4 ++--
src/gallium/drivers/radeonsi/si_shader.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 19452bf..efe7743 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -4901,8 +4901,8 @@ static void create_function(struct si_shader_context *ctx)
num_params = SI_PARAM_LS_OUT_LAYOUT+1;
} else {
if (ctx->is_gs_copy_shader) {
- last_array_pointer = SI_PARAM_CONST_BUFFERS;
- num_params = SI_PARAM_CONST_BUFFERS+1;
+ last_array_pointer = SI_PARAM_RW_BUFFERS;
+ num_params = SI_PARAM_RW_BUFFERS+1;
} else {
params[SI_PARAM_VS_STATE_BITS] = ctx->i32;
num_params = SI_PARAM_VS_STATE_BITS+1;
diff --git a/src/gallium/drivers/radeonsi/si_shader.h
b/src/gallium/drivers/radeonsi/si_shader.h
index a16e2a0..e40064b 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -117,7 +117,7 @@ enum {
/* GS limits */
SI_GS_NUM_USER_SGPR = SI_NUM_RESOURCE_SGPRS,
- SI_GSCOPY_NUM_USER_SGPR = SI_SGPR_CONST_BUFFERS_HI + 1,
+ SI_GSCOPY_NUM_USER_SGPR = SI_SGPR_RW_BUFFERS_HI + 1,
/* PS only */
SI_SGPR_ALPHA_REF = SI_NUM_RESOURCE_SGPRS,
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/10] radeonsi: rework polygon stippling to use constant buffer instead of texture
From: Marek Olšák
add it to the RW_BUFFERS descriptor array
now the slot masks don't have to have 64 bits
---
src/gallium/drivers/radeonsi/si_descriptors.c | 23 +
src/gallium/drivers/radeonsi/si_pipe.c| 2 -
src/gallium/drivers/radeonsi/si_pipe.h| 1 -
src/gallium/drivers/radeonsi/si_shader.c | 67 ---
src/gallium/drivers/radeonsi/si_state.c | 55 --
src/gallium/drivers/radeonsi/si_state.h | 8 ++--
6 files changed, 55 insertions(+), 101 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index b8f74f4..194b2eb 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -1121,6 +1121,26 @@ static void si_desc_reset_buffer_offset(struct
pipe_context *ctx,
S_008F04_BASE_ADDRESS_HI(va >> 32);
}
+/* INTERNAL CONST BUFFERS */
+
+static void si_set_polygon_stipple(struct pipe_context *ctx,
+ const struct pipe_poly_stipple *state)
+{
+ struct si_context *sctx = (struct si_context *)ctx;
+ struct pipe_constant_buffer cb = {};
+ unsigned stipple[32];
+ int i;
+
+ for (i = 0; i < 32; i++)
+ stipple[i] = util_bitreverse(state->stipple[i]);
+
+ cb.user_buffer = stipple;
+ cb.buffer_size = sizeof(stipple);
+
+ si_set_constant_buffer(sctx, &sctx->rw_buffers,
+ SI_PS_CONST_POLY_STIPPLE, &cb);
+}
+
/* TEXTURE METADATA ENABLE/DISABLE */
/* CMASK can be enabled (for fast clear) and disabled (for texture export)
@@ -1401,6 +1421,8 @@ void si_emit_graphics_shader_userdata(struct si_context
*sctx,
if (sctx->rw_buffers.desc.pointer_dirty) {
si_emit_shader_pointer(sctx, &sctx->rw_buffers.desc,
+ R_00B030_SPI_SHADER_USER_DATA_PS_0,
true);
+ si_emit_shader_pointer(sctx, &sctx->rw_buffers.desc,
R_00B130_SPI_SHADER_USER_DATA_VS_0,
true);
si_emit_shader_pointer(sctx, &sctx->rw_buffers.desc,
R_00B230_SPI_SHADER_USER_DATA_GS_0,
true);
@@ -1478,6 +1500,7 @@ void si_init_all_descriptors(struct si_context *sctx)
sctx->b.b.bind_sampler_states = si_bind_sampler_states;
sctx->b.b.set_shader_images = si_set_shader_images;
sctx->b.b.set_constant_buffer = si_pipe_set_constant_buffer;
+ sctx->b.b.set_polygon_stipple = si_set_polygon_stipple;
sctx->b.b.set_shader_buffers = si_set_shader_buffers;
sctx->b.b.set_sampler_views = si_set_sampler_views;
sctx->b.b.set_stream_output_targets = si_set_streamout_targets;
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 17d59b6..2a5cf0a 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -61,8 +61,6 @@ static void si_destroy_context(struct pipe_context *context)
for (i = 0; i < Elements(sctx->vgt_shader_config); i++)
si_pm4_delete_state(sctx, vgt_shader_config,
sctx->vgt_shader_config[i]);
- if (sctx->pstipple_sampler_state)
- sctx->b.b.delete_sampler_state(&sctx->b.b,
sctx->pstipple_sampler_state);
if (sctx->fixed_func_tcs_shader.cso)
sctx->b.b.delete_tcs_state(&sctx->b.b,
sctx->fixed_func_tcs_shader.cso);
if (sctx->custom_dsa_flush)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h
b/src/gallium/drivers/radeonsi/si_pipe.h
index 48095b0..85bf10f 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -190,7 +190,6 @@ struct si_context {
void*custom_blend_decompress;
void*custom_blend_fastclear;
void*custom_blend_dcc_decompress;
- void*pstipple_sampler_state;
struct si_screen*screen;
struct radeon_winsys_cs *ce_ib;
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 231b2c3..cfea2db 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -5291,15 +5291,14 @@ static void preload_ring_buffers(struct
si_shader_context *ctx)
}
static void si_llvm_emit_polygon_stipple(struct si_shader_context *ctx,
-LLVMValueRef param_sampler_views,
+LLVMValueRef param_rw_buffers,
unsigned param_pos_fixed_pt)
{
struct lp_build_tgsi_context *bld_base =
&ctx->radeon_bld.soa.bld_base;
struct gallivm_state *gallivm = bld_base->base.gallivm;
- struct lp_build_emit_data result = {};
-
[Mesa-dev] [PATCH 07/10] radeonsi: move default tess level constant buffer to RW buffers
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c| 19 +++
src/gallium/drivers/radeonsi/si_shader.h| 6 ++
src/gallium/drivers/radeonsi/si_state.c | 4 ++--
src/gallium/drivers/radeonsi/si_state.h | 1 +
src/gallium/drivers/radeonsi/si_state_shaders.c | 15 +++
5 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index c3a9120..5f76560 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1280,6 +1280,25 @@ static void declare_system_value(
break;
}
+ case TGSI_SEMANTIC_DEFAULT_TESSOUTER_SI:
+ case TGSI_SEMANTIC_DEFAULT_TESSINNER_SI:
+ {
+ LLVMValueRef buf, slot, val[4];
+ int i, offset;
+
+ slot = lp_build_const_int32(gallivm,
SI_HS_CONST_DEFAULT_TESS_LEVELS);
+ buf = LLVMGetParam(ctx->radeon_bld.main_fn,
SI_PARAM_RW_BUFFERS);
+ buf = build_indexed_load_const(ctx, buf, slot);
+ offset = decl->Semantic.Name ==
TGSI_SEMANTIC_DEFAULT_TESSINNER_SI ? 4 : 0;
+
+ for (i = 0; i < 4; i++)
+ val[i] = buffer_load_const(gallivm->builder, buf,
+
lp_build_const_int32(gallivm, (offset + i) * 4),
+ ctx->f32);
+ value = lp_build_gather_values(gallivm, val, 4);
+ break;
+ }
+
case TGSI_SEMANTIC_PRIMID:
value = get_primitive_id(&radeon_bld->soa.bld_base, 0);
break;
diff --git a/src/gallium/drivers/radeonsi/si_shader.h
b/src/gallium/drivers/radeonsi/si_shader.h
index 6ea849d..a16e2a0 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -210,6 +210,12 @@ enum {
SI_NUM_PARAMS = SI_PARAM_POS_FIXED_PT + 9, /* +8 for COLOR[0..1] */
};
+/* SI-specific system values. */
+enum {
+ TGSI_SEMANTIC_DEFAULT_TESSOUTER_SI = TGSI_SEMANTIC_COUNT,
+ TGSI_SEMANTIC_DEFAULT_TESSINNER_SI,
+};
+
struct si_shader;
/* A shader selector is a gallium CSO and contains shader variants and
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 56f484a..5e9decc 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3395,8 +3395,8 @@ static void si_set_tess_state(struct pipe_context *ctx,
(void*)array, sizeof(array),
&cb.buffer_offset);
- ctx->set_constant_buffer(ctx, PIPE_SHADER_TESS_CTRL,
-SI_DRIVER_STATE_CONST_BUF, &cb);
+ si_set_constant_buffer(sctx, &sctx->rw_buffers,
+ SI_HS_CONST_DEFAULT_TESS_LEVELS, &cb);
pipe_resource_reference(&cb.buffer, NULL);
}
diff --git a/src/gallium/drivers/radeonsi/si_state.h
b/src/gallium/drivers/radeonsi/si_state.h
index 159bdea..a961fbb 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -178,6 +178,7 @@ enum {
SI_VS_STREAMOUT_BUF2,
SI_VS_STREAMOUT_BUF3,
+ SI_HS_CONST_DEFAULT_TESS_LEVELS,
SI_VS_CONST_CLIP_PLANES,
SI_PS_CONST_POLY_STIPPLE,
SI_PS_CONST_SAMPLE_POSITIONS,
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 0318850..3bec4e9 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1804,7 +1804,7 @@ static void si_init_tess_factor_ring(struct si_context
*sctx)
*/
static void si_generate_fixed_func_tcs(struct si_context *sctx)
{
- struct ureg_src const0, const1;
+ struct ureg_src outer, inner;
struct ureg_dst tessouter, tessinner;
struct ureg_program *ureg = ureg_create(TGSI_PROCESSOR_TESS_CTRL);
@@ -1813,17 +1813,16 @@ static void si_generate_fixed_func_tcs(struct
si_context *sctx)
assert(!sctx->fixed_func_tcs_shader.cso);
- ureg_DECL_constant2D(ureg, 0, 1, SI_DRIVER_STATE_CONST_BUF);
- const0 = ureg_src_dimension(ureg_src_register(TGSI_FILE_CONSTANT, 0),
- SI_DRIVER_STATE_CONST_BUF);
- const1 = ureg_src_dimension(ureg_src_register(TGSI_FILE_CONSTANT, 1),
- SI_DRIVER_STATE_CONST_BUF);
+ outer = ureg_DECL_system_value(ureg,
+ TGSI_SEMANTIC_DEFAULT_TESSOUTER_SI, 0);
+ inner = ureg_DECL_system_value(ureg,
+ TGSI_SEMANTIC_DEFAULT_TESSINNER_SI, 0);
tessouter = ureg_DECL_output(ureg, TGSI_SEMANTIC_TESSOUTER, 0);
tessinner = ureg_DECL_output(ureg, TGSI_SEMANTIC_TESSINNER, 0);
-
[Mesa-dev] [PATCH 05/10] radeonsi: move clip plane constant buffer to RW buffers
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_descriptors.c | 14 +++---
src/gallium/drivers/radeonsi/si_shader.c | 5 +++--
src/gallium/drivers/radeonsi/si_state.c | 3 ++-
src/gallium/drivers/radeonsi/si_state.h | 4
4 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 194b2eb..aaff433 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -775,9 +775,9 @@ void si_upload_const_buffer(struct si_context *sctx, struct
r600_resource **rbuf
util_memcpy_cpu_to_le32(tmp, ptr, size);
}
-static void si_set_constant_buffer(struct si_context *sctx,
- struct si_buffer_resources *buffers,
- uint slot, struct pipe_constant_buffer
*input)
+void si_set_constant_buffer(struct si_context *sctx,
+ struct si_buffer_resources *buffers,
+ uint slot, struct pipe_constant_buffer *input)
{
assert(slot < buffers->desc.num_elements);
pipe_resource_reference(&buffers->buffers[slot], NULL);
@@ -1411,14 +1411,6 @@ void si_emit_graphics_shader_userdata(struct si_context
*sctx,
unsigned i;
uint32_t *sh_base = sctx->shader_userdata.sh_base;
- if (sctx->gs_shader.cso) {
- /* The VS copy shader needs this for clipping. */
- unsigned vs_base = R_00B130_SPI_SHADER_USER_DATA_VS_0;
- unsigned i = PIPE_SHADER_VERTEX;
-
- si_emit_shader_pointer(sctx, &sctx->const_buffers[i].desc,
vs_base, true);
- }
-
if (sctx->rw_buffers.desc.pointer_dirty) {
si_emit_shader_pointer(sctx, &sctx->rw_buffers.desc,
R_00B030_SPI_SHADER_USER_DATA_PS_0,
true);
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index cfea2db..c9760f0 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1690,8 +1690,9 @@ static void si_llvm_emit_clipvertex(struct
lp_build_tgsi_context *bld_base,
unsigned chan;
unsigned const_chan;
LLVMValueRef base_elt;
- LLVMValueRef ptr = LLVMGetParam(ctx->radeon_bld.main_fn,
SI_PARAM_CONST_BUFFERS);
- LLVMValueRef constbuf_index = lp_build_const_int32(base->gallivm,
SI_DRIVER_STATE_CONST_BUF);
+ LLVMValueRef ptr = LLVMGetParam(ctx->radeon_bld.main_fn,
SI_PARAM_RW_BUFFERS);
+ LLVMValueRef constbuf_index = lp_build_const_int32(base->gallivm,
+
SI_VS_CONST_CLIP_PLANES);
LLVMValueRef const_resource = build_indexed_load_const(ctx, ptr,
constbuf_index);
for (reg_index = 0; reg_index < 2; reg_index ++) {
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 1f3a5fa..1e4f35d 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -771,7 +771,8 @@ static void si_set_clip_state(struct pipe_context *ctx,
cb.user_buffer = state->ucp;
cb.buffer_offset = 0;
cb.buffer_size = 4*4*8;
- ctx->set_constant_buffer(ctx, PIPE_SHADER_VERTEX,
SI_DRIVER_STATE_CONST_BUF, &cb);
+ si_set_constant_buffer(sctx, &sctx->rw_buffers,
+ SI_VS_CONST_CLIP_PLANES, &cb);
pipe_resource_reference(&cb.buffer, NULL);
}
diff --git a/src/gallium/drivers/radeonsi/si_state.h
b/src/gallium/drivers/radeonsi/si_state.h
index 9875606..a017536 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -178,6 +178,7 @@ enum {
SI_VS_STREAMOUT_BUF2,
SI_VS_STREAMOUT_BUF3,
+ SI_VS_CONST_CLIP_PLANES,
SI_PS_CONST_POLY_STIPPLE,
SI_NUM_RW_BUFFERS,
@@ -272,6 +273,9 @@ void si_update_compressed_colortex_masks(struct si_context
*sctx);
void si_emit_graphics_shader_userdata(struct si_context *sctx,
struct r600_atom *atom);
void si_emit_compute_shader_userdata(struct si_context *sctx);
+void si_set_constant_buffer(struct si_context *sctx,
+ struct si_buffer_resources *buffers,
+ uint slot, struct pipe_constant_buffer *input);
/* si_state.c */
struct si_shader_selector;
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/10] radeonsi: shorten slot masks to 32 bits
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_blit.c| 12 +--
src/gallium/drivers/radeonsi/si_descriptors.c | 110 +-
src/gallium/drivers/radeonsi/si_pipe.h| 4 +-
src/gallium/drivers/radeonsi/si_state.h | 4 +-
4 files changed, 64 insertions(+), 66 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index 7ca0e23..7b028c1 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -243,14 +243,14 @@ si_flush_depth_textures(struct si_context *sctx,
struct si_textures_info *textures)
{
unsigned i;
- uint64_t mask = textures->depth_texture_mask;
+ unsigned mask = textures->depth_texture_mask;
while (mask) {
struct pipe_sampler_view *view;
struct si_sampler_view *sview;
struct r600_texture *tex;
- i = u_bit_scan64(&mask);
+ i = u_bit_scan(&mask);
view = textures->views.views[i];
assert(view);
@@ -326,13 +326,13 @@ si_decompress_sampler_color_textures(struct si_context
*sctx,
struct si_textures_info *textures)
{
unsigned i;
- uint64_t mask = textures->compressed_colortex_mask;
+ unsigned mask = textures->compressed_colortex_mask;
while (mask) {
struct pipe_sampler_view *view;
struct r600_texture *tex;
- i = u_bit_scan64(&mask);
+ i = u_bit_scan(&mask);
view = textures->views.views[i];
assert(view);
@@ -352,13 +352,13 @@ si_decompress_image_color_textures(struct si_context
*sctx,
struct si_images_info *images)
{
unsigned i;
- uint64_t mask = images->compressed_colortex_mask;
+ unsigned mask = images->compressed_colortex_mask;
while (mask) {
const struct pipe_image_view *view;
struct r600_texture *tex;
- i = u_bit_scan64(&mask);
+ i = u_bit_scan(&mask);
view = &images->views[i];
assert(view->resource->target != PIPE_BUFFER);
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index aaff433..44892ed 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -110,7 +110,7 @@ static void si_init_descriptors(struct si_descriptors *desc,
desc->list = CALLOC(num_elements, element_dw_size * 4);
desc->element_dw_size = element_dw_size;
desc->num_elements = num_elements;
- desc->dirty_mask = num_elements == 64 ? ~0llu : (1llu << num_elements)
- 1;
+ desc->dirty_mask = num_elements == 32 ? ~0u : (1u << num_elements) - 1;
desc->shader_userdata_offset = shader_userdata_index * 4;
if (ce_offset) {
@@ -202,8 +202,8 @@ static bool si_upload_descriptors(struct si_context *sctx,
while(desc->dirty_mask) {
int begin, count;
- u_bit_scan_consecutive_range64(&desc->dirty_mask,
&begin,
- &count);
+ u_bit_scan_consecutive_range(&desc->dirty_mask, &begin,
+&count);
begin *= desc->element_dw_size;
count *= desc->element_dw_size;
@@ -268,11 +268,11 @@ static void si_sampler_view_add_buffer(struct si_context
*sctx,
static void si_sampler_views_begin_new_cs(struct si_context *sctx,
struct si_sampler_views *views)
{
- uint64_t mask = views->desc.enabled_mask;
+ unsigned mask = views->desc.enabled_mask;
/* Add buffers to the CS. */
while (mask) {
- int i = u_bit_scan64(&mask);
+ int i = u_bit_scan(&mask);
si_sampler_view_add_buffer(sctx, views->views[i]->texture);
}
@@ -321,16 +321,16 @@ static void si_set_sampler_view(struct si_context *sctx,
views->sampler_states[slot], 4*4);
}
- views->desc.enabled_mask |= 1llu << slot;
+ views->desc.enabled_mask |= 1u << slot;
} else {
pipe_sampler_view_reference(&views->views[slot], NULL);
memcpy(views->desc.list + slot*16, null_texture_descriptor,
8*4);
/* Only clear the lower dwords of FMASK. */
memcpy(views->desc.list + slot*16 + 8, null_texture_descriptor,
4*4);
- views->desc.enabled_mask &= ~(1llu << slot);
+ views->desc.enabled_mask &= ~(1u << slot);
}
- views->desc.dirty_mask |= 1llu << slot;
+ views->desc.dirty_mask |= 1u <
[Mesa-dev] [PATCH 08/10] radeonsi: clean up shader resource limit definitions
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_pipe.c | 4 ++--
src/gallium/drivers/radeonsi/si_shader.c | 6 +++---
src/gallium/drivers/radeonsi/si_state.h | 25 +++--
3 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 2a5cf0a..ab6ea40 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -541,7 +541,7 @@ static int si_get_shader_param(struct pipe_screen* pscreen,
unsigned shader, enu
case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE:
return 4096 * sizeof(float[4]); /* actually only memory limits
this */
case PIPE_SHADER_CAP_MAX_CONST_BUFFERS:
- return SI_NUM_USER_CONST_BUFFERS;
+ return SI_NUM_CONST_BUFFERS;
case PIPE_SHADER_CAP_MAX_PREDS:
return 0; /* FIXME */
case PIPE_SHADER_CAP_TGSI_CONT_SUPPORTED:
@@ -563,7 +563,7 @@ static int si_get_shader_param(struct pipe_screen* pscreen,
unsigned shader, enu
return 0;
case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
case PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS:
- return SI_NUM_USER_SAMPLERS;
+ return SI_NUM_SAMPLERS;
case PIPE_SHADER_CAP_PREFERRED_IR:
return PIPE_SHADER_IR_TGSI;
case PIPE_SHADER_CAP_SUPPORTED_IRS:
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 5f76560..19452bf 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -101,7 +101,7 @@ struct si_shader_context
LLVMValueRef shader_buffers[SI_NUM_SHADER_BUFFERS];
LLVMValueRef sampler_views[SI_NUM_SAMPLERS];
LLVMValueRef sampler_states[SI_NUM_SAMPLERS];
- LLVMValueRef fmasks[SI_NUM_USER_SAMPLERS];
+ LLVMValueRef fmasks[SI_NUM_SAMPLERS];
LLVMValueRef images[SI_NUM_IMAGES];
LLVMValueRef so_buffers[4];
LLVMValueRef esgs_ring;
@@ -1406,7 +1406,7 @@ static LLVMValueRef fetch_constant(
LLVMValueRef index;
index = get_bounded_indirect_index(ctx, ®->DimIndirect,
reg->Dimension.Index,
- SI_NUM_USER_CONST_BUFFERS);
+ SI_NUM_CONST_BUFFERS);
bufp = build_indexed_load_const(ctx, ptr, index);
} else
bufp = ctx->const_buffers[buf];
@@ -3822,7 +3822,7 @@ static void tex_fetch_ptrs(
ind_index = get_bounded_indirect_index(ctx,
®->Indirect,
reg->Register.Index,
- SI_NUM_USER_SAMPLERS);
+ SI_NUM_SAMPLERS);
*res_ptr = get_sampler_desc(ctx, ind_index, DESC_IMAGE);
diff --git a/src/gallium/drivers/radeonsi/si_state.h
b/src/gallium/drivers/radeonsi/si_state.h
index a961fbb..d3a8c81 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -32,7 +32,13 @@
#define SI_NUM_GRAPHICS_SHADERS (PIPE_SHADER_TESS_EVAL+1)
#define SI_NUM_SHADERS (PIPE_SHADER_COMPUTE+1)
-#define SI_MAX_ATTRIBS 16
+
+#define SI_MAX_ATTRIBS 16
+#define SI_NUM_VERTEX_BUFFERS SI_MAX_ATTRIBS
+#define SI_NUM_SAMPLERS32 /* OpenGL textures units per
shader */
+#define SI_NUM_CONST_BUFFERS 16
+#define SI_NUM_IMAGES 16
+#define SI_NUM_SHADER_BUFFERS 16
struct si_screen;
struct si_shader;
@@ -146,20 +152,6 @@ struct si_shader_data {
uint32_tsh_base[SI_NUM_SHADERS];
};
-#define SI_NUM_USER_SAMPLERS32 /* AKA OpenGL textures units per
shader */
-#define SI_NUM_SAMPLERS SI_NUM_USER_SAMPLERS
-
-/* User constant buffers: 0..15
- * Driver state constants: 16
- */
-#define SI_NUM_USER_CONST_BUFFERS 16
-#define SI_DRIVER_STATE_CONST_BUF SI_NUM_USER_CONST_BUFFERS
-#define SI_NUM_CONST_BUFFERS (SI_DRIVER_STATE_CONST_BUF + 1)
-
-#define SI_NUM_IMAGES 16
-
-#define SI_NUM_SHADER_BUFFERS 16
-
/* Private read-write buffer slots. */
enum {
SI_HS_RING_TESS_FACTOR,
@@ -186,9 +178,6 @@ enum {
SI_NUM_RW_BUFFERS,
};
-#define SI_NUM_VERTEX_BUFFERS SI_MAX_ATTRIBS
-
-
/* This represents descriptors in memory, such as buffer resources,
* image resources, and sampler states.
*/
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] gallium: add bool return to pipe_context::end_query
From: Nicolai Hähnle
Even when begin_query succeeds, there can still be failures in query handling.
For example for radeon, additional buffers may have to be allocated when
queries span multiple command buffers.
---
src/gallium/drivers/ddebug/dd_context.c | 4 ++--
src/gallium/drivers/freedreno/freedreno_query.c | 3 ++-
src/gallium/drivers/i915/i915_query.c | 3 ++-
src/gallium/drivers/ilo/ilo_query.c | 6 --
src/gallium/drivers/llvmpipe/lp_query.c | 4 +++-
src/gallium/drivers/noop/noop_pipe.c| 3 ++-
src/gallium/drivers/nouveau/nv30/nv30_query.c | 3 ++-
src/gallium/drivers/nouveau/nv50/nv50_query.c | 3 ++-
src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 3 ++-
src/gallium/drivers/r300/r300_query.c | 8 +---
src/gallium/drivers/radeon/r600_query.c | 3 ++-
src/gallium/drivers/rbug/rbug_context.c | 9 ++---
src/gallium/drivers/softpipe/sp_query.c | 3 ++-
src/gallium/drivers/svga/svga_pipe_query.c | 3 ++-
src/gallium/drivers/swr/swr_query.cpp | 3 ++-
src/gallium/drivers/trace/tr_context.c | 6 --
src/gallium/drivers/vc4/vc4_query.c | 3 ++-
src/gallium/drivers/virgl/virgl_query.c | 3 ++-
src/gallium/include/pipe/p_context.h| 2 +-
19 files changed, 49 insertions(+), 26 deletions(-)
diff --git a/src/gallium/drivers/ddebug/dd_context.c
b/src/gallium/drivers/ddebug/dd_context.c
index 72a950a..d06efbc 100644
--- a/src/gallium/drivers/ddebug/dd_context.c
+++ b/src/gallium/drivers/ddebug/dd_context.c
@@ -104,13 +104,13 @@ dd_context_begin_query(struct pipe_context *_pipe, struct
pipe_query *query)
return pipe->begin_query(pipe, dd_query_unwrap(query));
}
-static void
+static bool
dd_context_end_query(struct pipe_context *_pipe, struct pipe_query *query)
{
struct dd_context *dctx = dd_context(_pipe);
struct pipe_context *pipe = dctx->pipe;
- pipe->end_query(pipe, dd_query_unwrap(query));
+ return pipe->end_query(pipe, dd_query_unwrap(query));
}
static boolean
diff --git a/src/gallium/drivers/freedreno/freedreno_query.c
b/src/gallium/drivers/freedreno/freedreno_query.c
index a942705..18e0c79 100644
--- a/src/gallium/drivers/freedreno/freedreno_query.c
+++ b/src/gallium/drivers/freedreno/freedreno_query.c
@@ -66,11 +66,12 @@ fd_begin_query(struct pipe_context *pctx, struct pipe_query
*pq)
return q->funcs->begin_query(fd_context(pctx), q);
}
-static void
+static bool
fd_end_query(struct pipe_context *pctx, struct pipe_query *pq)
{
struct fd_query *q = fd_query(pq);
q->funcs->end_query(fd_context(pctx), q);
+ return true;
}
static boolean
diff --git a/src/gallium/drivers/i915/i915_query.c
b/src/gallium/drivers/i915/i915_query.c
index fa1b01d..d6015a6 100644
--- a/src/gallium/drivers/i915/i915_query.c
+++ b/src/gallium/drivers/i915/i915_query.c
@@ -60,8 +60,9 @@ static boolean i915_begin_query(struct pipe_context *ctx,
return true;
}
-static void i915_end_query(struct pipe_context *ctx, struct pipe_query *query)
+static bool i915_end_query(struct pipe_context *ctx, struct pipe_query *query)
{
+ return true;
}
static boolean i915_get_query_result(struct pipe_context *ctx,
diff --git a/src/gallium/drivers/ilo/ilo_query.c
b/src/gallium/drivers/ilo/ilo_query.c
index 8a42f58..3088c96 100644
--- a/src/gallium/drivers/ilo/ilo_query.c
+++ b/src/gallium/drivers/ilo/ilo_query.c
@@ -128,7 +128,7 @@ ilo_begin_query(struct pipe_context *pipe, struct
pipe_query *query)
return true;
}
-static void
+static bool
ilo_end_query(struct pipe_context *pipe, struct pipe_query *query)
{
struct ilo_query *q = ilo_query(query);
@@ -136,7 +136,7 @@ ilo_end_query(struct pipe_context *pipe, struct pipe_query
*query)
if (!q->active) {
/* require ilo_begin_query() first */
if (q->in_pairs)
- return;
+ return false;
ilo_begin_query(pipe, query);
}
@@ -144,6 +144,8 @@ ilo_end_query(struct pipe_context *pipe, struct pipe_query
*query)
q->active = false;
ilo_query_table[q->type].end(ilo_context(pipe), q);
+
+ return true;
}
/**
diff --git a/src/gallium/drivers/llvmpipe/lp_query.c
b/src/gallium/drivers/llvmpipe/lp_query.c
index 2fddc90..d5ed656 100644
--- a/src/gallium/drivers/llvmpipe/lp_query.c
+++ b/src/gallium/drivers/llvmpipe/lp_query.c
@@ -239,7 +239,7 @@ llvmpipe_begin_query(struct pipe_context *pipe, struct
pipe_query *q)
}
-static void
+static bool
llvmpipe_end_query(struct pipe_context *pipe, struct pipe_query *q)
{
struct llvmpipe_context *llvmpipe = llvmpipe_context( pipe );
@@ -298,6 +298,8 @@ llvmpipe_end_query(struct pipe_context *pipe, struct
pipe_query *q)
default:
break;
}
+
+ return true;
}
boolean
diff --git a/src/gallium/drivers/noop/noop_pipe.c
b/src/gallium/drivers/noop/noop_pipe.c
index 55aca74..99e5f1a 100644
--- a/src/gallium/drivers/noop/noop_pipe.c
+++ b/src/g
[Mesa-dev] [PATCH 3/4] radeon: wire end_query return value to sw/hw_end
From: Nicolai Hähnle
---
src/gallium/drivers/radeon/r600_query.c | 13 -
src/gallium/drivers/radeon/r600_query.h | 4 ++--
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 813885b..e5e032b 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -113,7 +113,7 @@ static boolean r600_query_sw_begin(struct
r600_common_context *rctx,
return TRUE;
}
-static void r600_query_sw_end(struct r600_common_context *rctx,
+static bool r600_query_sw_end(struct r600_common_context *rctx,
struct r600_query *rquery)
{
struct r600_query_sw *query = (struct r600_query_sw *)rquery;
@@ -161,6 +161,8 @@ static void r600_query_sw_end(struct r600_common_context
*rctx,
default:
unreachable("r600_query_sw_end: bad query type");
}
+
+ return true;
}
static boolean r600_query_sw_get_result(struct r600_common_context *rctx,
@@ -730,12 +732,11 @@ static bool r600_end_query(struct pipe_context *ctx,
struct pipe_query *query)
struct r600_common_context *rctx = (struct r600_common_context *)ctx;
struct r600_query *rquery = (struct r600_query *)query;
- rquery->ops->end(rctx, rquery);
- return true;
+ return rquery->ops->end(rctx, rquery);
}
-void r600_query_hw_end(struct r600_common_context *rctx,
- struct r600_query *rquery)
+bool r600_query_hw_end(struct r600_common_context *rctx,
+ struct r600_query *rquery)
{
struct r600_query_hw *query = (struct r600_query_hw *)rquery;
@@ -746,6 +747,8 @@ void r600_query_hw_end(struct r600_common_context *rctx,
if (!(query->flags & R600_QUERY_HW_FLAG_NO_START))
LIST_DELINIT(&query->list);
+
+ return true;
}
static unsigned r600_query_read_result(void *map, unsigned start_index,
unsigned end_index,
diff --git a/src/gallium/drivers/radeon/r600_query.h
b/src/gallium/drivers/radeon/r600_query.h
index 9f3a917..3b8fbe6 100644
--- a/src/gallium/drivers/radeon/r600_query.h
+++ b/src/gallium/drivers/radeon/r600_query.h
@@ -69,7 +69,7 @@ enum {
struct r600_query_ops {
void (*destroy)(struct r600_common_context *, struct r600_query *);
boolean (*begin)(struct r600_common_context *, struct r600_query *);
- void (*end)(struct r600_common_context *, struct r600_query *);
+ bool (*end)(struct r600_common_context *, struct r600_query *);
boolean (*get_result)(struct r600_common_context *,
struct r600_query *, boolean wait,
union pipe_query_result *result);
@@ -139,7 +139,7 @@ void r600_query_hw_destroy(struct r600_common_context *rctx,
struct r600_query *rquery);
boolean r600_query_hw_begin(struct r600_common_context *rctx,
struct r600_query *rquery);
-void r600_query_hw_end(struct r600_common_context *rctx,
+bool r600_query_hw_end(struct r600_common_context *rctx,
struct r600_query *rquery);
boolean r600_query_hw_get_result(struct r600_common_context *rctx,
struct r600_query *rquery,
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] include/GL: fix the interop header for a --disable-glx build
This header should not blindly include the GLX and should also
conditionally define functions that use GLX parameters. The
MESA_EGL_NO_X11_HEADERS macro is used to check if we're building without
GLX support.
Signed-off-by: Mircea Gherzan
---
include/GL/mesa_glinterop.h | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
index 814064d..cd3151f 100644
--- a/include/GL/mesa_glinterop.h
+++ b/include/GL/mesa_glinterop.h
@@ -50,7 +50,12 @@
#ifndef MESA_GLINTEROP_H
#define MESA_GLINTEROP_H
+#ifdef MESA_EGL_NO_X11_HEADERS
+#include
+#else
#include
+#endif
+
#include
#ifdef __cplusplus
@@ -219,6 +224,7 @@ typedef struct _mesa_glinterop_export_out {
} mesa_glinterop_export_out;
+#ifndef MESA_EGL_NO_X11_HEADERS
/**
* Query device information.
*
@@ -232,16 +238,6 @@ GLAPI int GLAPIENTRY
MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext context,
mesa_glinterop_device_info *out);
-
-/**
- * Same as MesaGLInteropGLXQueryDeviceInfo except that it accepts EGLDisplay
- * and EGLContext.
- */
-GLAPI int GLAPIENTRY
-MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
-mesa_glinterop_device_info *out);
-
-
/**
* Create and return a DMABUF handle corresponding to the given OpenGL
* object, and return other parameters about the OpenGL object.
@@ -258,6 +254,20 @@ MesaGLInteropGLXExportObject(Display *dpy, GLXContext
context,
const mesa_glinterop_export_in *in,
mesa_glinterop_export_out *out);
+typedef int (APIENTRYP PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(Display *dpy,
GLXContext context,
+
mesa_glinterop_device_info *out);
+typedef int (APIENTRYP PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(Display *dpy,
GLXContext context,
+const
mesa_glinterop_export_in *in,
+
mesa_glinterop_export_out *out);
+#endif /* MESA_EGL_NO_X11_HEADERS */
+
+/**
+ * Same as MesaGLInteropGLXQueryDeviceInfo except that it accepts EGLDisplay
+ * and EGLContext.
+ */
+GLAPI int GLAPIENTRY
+MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
+mesa_glinterop_device_info *out);
/**
* Same as MesaGLInteropGLXExportObject except that it accepts
@@ -268,18 +278,11 @@ MesaGLInteropEGLExportObject(EGLDisplay dpy, EGLContext
context,
const mesa_glinterop_export_in *in,
mesa_glinterop_export_out *out);
-
-typedef int (APIENTRYP PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(Display *dpy,
GLXContext context,
-
mesa_glinterop_device_info *out);
typedef int (APIENTRYP PFNMESAGLINTEROPEGLQUERYDEVICEINFOPROC)(EGLDisplay dpy,
EGLContext context,
mesa_glinterop_device_info *out);
-typedef int (APIENTRYP PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(Display *dpy,
GLXContext context,
-const
mesa_glinterop_export_in *in,
-
mesa_glinterop_export_out *out);
typedef int (APIENTRYP PFNMESAGLINTEROPEGLEXPORTOBJECTPROC)(EGLDisplay dpy,
EGLContext context,
const
mesa_glinterop_export_in *in,
mesa_glinterop_export_out *out);
-
#ifdef __cplusplus
}
#endif
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94291] llvmpipe tests fail if built on skylake i7-6700k
https://bugs.freedesktop.org/show_bug.cgi?id=94291 --- Comment #9 from Roland Scheidegger --- (In reply to Timo Aaltonen from comment #8) > Actually it wasn't avx512, that was the first one I tried :) It's enabled > also on 3.7 and that version works fine. Only one that was added in 3.8 is > PKU, but dropping just that didn't help. > > I did try dropping all non-client features (AVX512, CDI, DQI, BWI, VLX, PKU) > and that worked. Maybe one of CDI/DQI/BWI/VLX is somewhat broken on 3.8? Which is why I said "or any subvariant" ;-). ERI, CDI, PFI, DQI, BWI, VLX are all avx512 variants (omg naming???), though that skylake in the llvm 3.8 list doesn't suport ERI and PFI. I'm not sure, but probably dropping avx512 manually when a enhanced variant still gets enabled won't do anything. I don't think PKU would matter (but no guarantee...). I suppose we should explicitly disable all of them via mattrs too (not that it's a battle we can win, there will be some extensions at some point...). -- 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] st/mesa: Use correct size for compute CAPs.
Reviewed-by: Samuel Pitoiset
On 04/20/2016 03:35 PM, Bas Nieuwenhuizen wrote:
Some CAPs are stored as 64-bit value while Mesa stores
the related constant as 32-bit value.
Signed-off-by: Bas Nieuwenhuizen
---
src/mesa/state_tracker/st_extensions.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 939f15d..3f769b6 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1152,6 +1152,7 @@ void st_init_extensions(struct pipe_screen *screen,
PIPE_SHADER_CAP_SUPPORTED_IRS);
if (compute_supported_irs & (1 << PIPE_SHADER_IR_TGSI)) {
uint64_t grid_size[3], block_size[3];
+ uint64_t max_local_size, max_threads_per_block;
screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
PIPE_COMPUTE_CAP_MAX_GRID_SIZE, grid_size);
@@ -1159,10 +1160,13 @@ void st_init_extensions(struct pipe_screen *screen,
PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE,
block_size);
screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
PIPE_COMPUTE_CAP_MAX_THREADS_PER_BLOCK,
- &consts->MaxComputeWorkGroupInvocations);
+ &max_threads_per_block);
screen->get_compute_param(screen, PIPE_SHADER_IR_TGSI,
PIPE_COMPUTE_CAP_MAX_LOCAL_SIZE,
- &consts->MaxComputeSharedMemorySize);
+ &max_local_size);
+
+ consts->MaxComputeWorkGroupInvocations = max_threads_per_block;
+ consts->MaxComputeSharedMemorySize = max_local_size;
for (i = 0; i < 3; i++) {
consts->MaxComputeWorkGroupCount[i] = grid_size[i];
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium: add bool return to pipe_context::end_query
Yeah, this makes sense.
Reviewed-by: Samuel Pitoiset
On 04/20/2016 05:43 PM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Even when begin_query succeeds, there can still be failures in query handling.
For example for radeon, additional buffers may have to be allocated when
queries span multiple command buffers.
---
src/gallium/drivers/ddebug/dd_context.c | 4 ++--
src/gallium/drivers/freedreno/freedreno_query.c | 3 ++-
src/gallium/drivers/i915/i915_query.c | 3 ++-
src/gallium/drivers/ilo/ilo_query.c | 6 --
src/gallium/drivers/llvmpipe/lp_query.c | 4 +++-
src/gallium/drivers/noop/noop_pipe.c| 3 ++-
src/gallium/drivers/nouveau/nv30/nv30_query.c | 3 ++-
src/gallium/drivers/nouveau/nv50/nv50_query.c | 3 ++-
src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 3 ++-
src/gallium/drivers/r300/r300_query.c | 8 +---
src/gallium/drivers/radeon/r600_query.c | 3 ++-
src/gallium/drivers/rbug/rbug_context.c | 9 ++---
src/gallium/drivers/softpipe/sp_query.c | 3 ++-
src/gallium/drivers/svga/svga_pipe_query.c | 3 ++-
src/gallium/drivers/swr/swr_query.cpp | 3 ++-
src/gallium/drivers/trace/tr_context.c | 6 --
src/gallium/drivers/vc4/vc4_query.c | 3 ++-
src/gallium/drivers/virgl/virgl_query.c | 3 ++-
src/gallium/include/pipe/p_context.h| 2 +-
19 files changed, 49 insertions(+), 26 deletions(-)
diff --git a/src/gallium/drivers/ddebug/dd_context.c
b/src/gallium/drivers/ddebug/dd_context.c
index 72a950a..d06efbc 100644
--- a/src/gallium/drivers/ddebug/dd_context.c
+++ b/src/gallium/drivers/ddebug/dd_context.c
@@ -104,13 +104,13 @@ dd_context_begin_query(struct pipe_context *_pipe, struct
pipe_query *query)
return pipe->begin_query(pipe, dd_query_unwrap(query));
}
-static void
+static bool
dd_context_end_query(struct pipe_context *_pipe, struct pipe_query *query)
{
struct dd_context *dctx = dd_context(_pipe);
struct pipe_context *pipe = dctx->pipe;
- pipe->end_query(pipe, dd_query_unwrap(query));
+ return pipe->end_query(pipe, dd_query_unwrap(query));
}
static boolean
diff --git a/src/gallium/drivers/freedreno/freedreno_query.c
b/src/gallium/drivers/freedreno/freedreno_query.c
index a942705..18e0c79 100644
--- a/src/gallium/drivers/freedreno/freedreno_query.c
+++ b/src/gallium/drivers/freedreno/freedreno_query.c
@@ -66,11 +66,12 @@ fd_begin_query(struct pipe_context *pctx, struct pipe_query
*pq)
return q->funcs->begin_query(fd_context(pctx), q);
}
-static void
+static bool
fd_end_query(struct pipe_context *pctx, struct pipe_query *pq)
{
struct fd_query *q = fd_query(pq);
q->funcs->end_query(fd_context(pctx), q);
+ return true;
}
static boolean
diff --git a/src/gallium/drivers/i915/i915_query.c
b/src/gallium/drivers/i915/i915_query.c
index fa1b01d..d6015a6 100644
--- a/src/gallium/drivers/i915/i915_query.c
+++ b/src/gallium/drivers/i915/i915_query.c
@@ -60,8 +60,9 @@ static boolean i915_begin_query(struct pipe_context *ctx,
return true;
}
-static void i915_end_query(struct pipe_context *ctx, struct pipe_query *query)
+static bool i915_end_query(struct pipe_context *ctx, struct pipe_query *query)
{
+ return true;
}
static boolean i915_get_query_result(struct pipe_context *ctx,
diff --git a/src/gallium/drivers/ilo/ilo_query.c
b/src/gallium/drivers/ilo/ilo_query.c
index 8a42f58..3088c96 100644
--- a/src/gallium/drivers/ilo/ilo_query.c
+++ b/src/gallium/drivers/ilo/ilo_query.c
@@ -128,7 +128,7 @@ ilo_begin_query(struct pipe_context *pipe, struct
pipe_query *query)
return true;
}
-static void
+static bool
ilo_end_query(struct pipe_context *pipe, struct pipe_query *query)
{
struct ilo_query *q = ilo_query(query);
@@ -136,7 +136,7 @@ ilo_end_query(struct pipe_context *pipe, struct pipe_query
*query)
if (!q->active) {
/* require ilo_begin_query() first */
if (q->in_pairs)
- return;
+ return false;
ilo_begin_query(pipe, query);
}
@@ -144,6 +144,8 @@ ilo_end_query(struct pipe_context *pipe, struct pipe_query
*query)
q->active = false;
ilo_query_table[q->type].end(ilo_context(pipe), q);
+
+ return true;
}
/**
diff --git a/src/gallium/drivers/llvmpipe/lp_query.c
b/src/gallium/drivers/llvmpipe/lp_query.c
index 2fddc90..d5ed656 100644
--- a/src/gallium/drivers/llvmpipe/lp_query.c
+++ b/src/gallium/drivers/llvmpipe/lp_query.c
@@ -239,7 +239,7 @@ llvmpipe_begin_query(struct pipe_context *pipe, struct
pipe_query *q)
}
-static void
+static bool
llvmpipe_end_query(struct pipe_context *pipe, struct pipe_query *q)
{
struct llvmpipe_context *llvmpipe = llvmpipe_context( pipe );
@@ -298,6 +298,8 @@ llvmpipe_end_query(struct pipe_context *pipe, struct
pipe_query *q)
default:
break;
}
+
+ return true;
}
boolean
diff --git a/src/galliu
Re: [Mesa-dev] [PATCH 2/4] st/mesa: check return value of begin/end_query
On 04/20/2016 05:43 PM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
They can only indicate out of memory conditions, since the other error
conditions are caught earlier.
---
src/mesa/state_tracker/st_cb_queryobj.c | 55 -
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
b/src/mesa/state_tracker/st_cb_queryobj.c
index cdb9efc..784ffde 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -61,13 +61,9 @@ st_NewQueryObject(struct gl_context *ctx, GLuint id)
}
-
static void
-st_DeleteQuery(struct gl_context *ctx, struct gl_query_object *q)
+free_queries(struct pipe_context *pipe, struct st_query_object *stq)
{
- struct pipe_context *pipe = st_context(ctx)->pipe;
- struct st_query_object *stq = st_query_object(q);
-
if (stq->pq) {
pipe->destroy_query(pipe, stq->pq);
stq->pq = NULL;
@@ -77,6 +73,16 @@ st_DeleteQuery(struct gl_context *ctx, struct
gl_query_object *q)
pipe->destroy_query(pipe, stq->pq_begin);
stq->pq_begin = NULL;
}
+}
+
+
+static void
+st_DeleteQuery(struct gl_context *ctx, struct gl_query_object *q)
+{
+ struct pipe_context *pipe = st_context(ctx)->pipe;
+ struct st_query_object *stq = st_query_object(q);
+
+ free_queries(pipe, stq);
free(stq);
}
@@ -89,6 +95,7 @@ st_BeginQuery(struct gl_context *ctx, struct gl_query_object
*q)
struct pipe_context *pipe = st->pipe;
struct st_query_object *stq = st_query_object(q);
unsigned type;
+ bool ret = false;
st_flush_bitmap_cache(st_context(ctx));
@@ -133,14 +140,7 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
if (stq->type != type) {
/* free old query of different type */
- if (stq->pq) {
- pipe->destroy_query(pipe, stq->pq);
- stq->pq = NULL;
- }
- if (stq->pq_begin) {
- pipe->destroy_query(pipe, stq->pq_begin);
- stq->pq_begin = NULL;
- }
+ free_queries(pipe, stq);
stq->type = PIPE_QUERY_TYPES; /* an invalid value */
}
@@ -151,20 +151,25 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
stq->pq_begin = pipe->create_query(pipe, type, 0);
stq->type = type;
}
- pipe->end_query(pipe, stq->pq_begin);
+ if (stq->pq_begin)
+ ret = pipe->end_query(pipe, stq->pq_begin);
} else {
if (!stq->pq) {
stq->pq = pipe->create_query(pipe, type, q->Stream);
stq->type = type;
}
- if (stq->pq) {
- pipe->begin_query(pipe, stq->pq);
- }
- else {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
- return;
- }
+ if (stq->pq)
+ ret = pipe->begin_query(pipe, stq->pq);
}
+
+ if (!ret) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
+
+ free_queries(pipe, stq);
Why do you need to free queries now? Was there a memleak before? And why
not in glEndQuery too?
+ q->Active = GL_FALSE;
+ return;
+ }
+
assert(stq->type == type);
}
@@ -174,6 +179,7 @@ st_EndQuery(struct gl_context *ctx, struct gl_query_object
*q)
{
struct pipe_context *pipe = st_context(ctx)->pipe;
struct st_query_object *stq = st_query_object(q);
+ bool ret = false;
st_flush_bitmap_cache(st_context(ctx));
@@ -185,7 +191,12 @@ st_EndQuery(struct gl_context *ctx, struct gl_query_object
*q)
}
if (stq->pq)
- pipe->end_query(pipe, stq->pq);
+ ret = pipe->end_query(pipe, stq->pq);
+
+ if (!ret) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
This should be "glEndQuery", right? I think it would be better to move
the error message inside the previous branch, what do you think?
+ return;
+ }
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] Support for Android RGBX/RGBA formats
Rob Herring writes: > The RGBX/RGBA pixel formats used in the Android EGL don't get configs > created due to the missing formats in the DRI state tracker. This series > adds the necessary formats for configs and DRI images. Support in GBM is > also added as it will be needed soon for Android. > > AFAICT, this has been a long standing bug in Android-x86 which was > worked around with the patch "GLSurfaceView: Be less picky about > EGLConfig alpha sizes". With this series, this patch is no longer needed > and several other bugs like wallpaper not getting displayed are fixed. Reviewed-by: Eric Anholt 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] include/GL: fix the interop header for a --disable-glx build
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 20, 2016 at 5:52 PM, Mircea Gherzan
wrote:
> This header should not blindly include the GLX and should also
> conditionally define functions that use GLX parameters. The
> MESA_EGL_NO_X11_HEADERS macro is used to check if we're building without
> GLX support.
>
> Signed-off-by: Mircea Gherzan
> ---
> include/GL/mesa_glinterop.h | 37 -
> 1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
> index 814064d..cd3151f 100644
> --- a/include/GL/mesa_glinterop.h
> +++ b/include/GL/mesa_glinterop.h
> @@ -50,7 +50,12 @@
> #ifndef MESA_GLINTEROP_H
> #define MESA_GLINTEROP_H
>
> +#ifdef MESA_EGL_NO_X11_HEADERS
> +#include
> +#else
> #include
> +#endif
> +
> #include
>
> #ifdef __cplusplus
> @@ -219,6 +224,7 @@ typedef struct _mesa_glinterop_export_out {
> } mesa_glinterop_export_out;
>
>
> +#ifndef MESA_EGL_NO_X11_HEADERS
> /**
> * Query device information.
> *
> @@ -232,16 +238,6 @@ GLAPI int GLAPIENTRY
> MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext context,
> mesa_glinterop_device_info *out);
>
> -
> -/**
> - * Same as MesaGLInteropGLXQueryDeviceInfo except that it accepts EGLDisplay
> - * and EGLContext.
> - */
> -GLAPI int GLAPIENTRY
> -MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
> -mesa_glinterop_device_info *out);
> -
> -
> /**
> * Create and return a DMABUF handle corresponding to the given OpenGL
> * object, and return other parameters about the OpenGL object.
> @@ -258,6 +254,20 @@ MesaGLInteropGLXExportObject(Display *dpy, GLXContext
> context,
> const mesa_glinterop_export_in *in,
> mesa_glinterop_export_out *out);
>
> +typedef int (APIENTRYP PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(Display *dpy,
> GLXContext context,
> +
> mesa_glinterop_device_info *out);
> +typedef int (APIENTRYP PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(Display *dpy,
> GLXContext context,
> +const
> mesa_glinterop_export_in *in,
> +
> mesa_glinterop_export_out *out);
> +#endif /* MESA_EGL_NO_X11_HEADERS */
> +
> +/**
> + * Same as MesaGLInteropGLXQueryDeviceInfo except that it accepts EGLDisplay
> + * and EGLContext.
> + */
> +GLAPI int GLAPIENTRY
> +MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
> +mesa_glinterop_device_info *out);
>
> /**
> * Same as MesaGLInteropGLXExportObject except that it accepts
> @@ -268,18 +278,11 @@ MesaGLInteropEGLExportObject(EGLDisplay dpy, EGLContext
> context,
> const mesa_glinterop_export_in *in,
> mesa_glinterop_export_out *out);
>
> -
> -typedef int (APIENTRYP PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(Display *dpy,
> GLXContext context,
> -
> mesa_glinterop_device_info *out);
> typedef int (APIENTRYP PFNMESAGLINTEROPEGLQUERYDEVICEINFOPROC)(EGLDisplay
> dpy, EGLContext context,
>
> mesa_glinterop_device_info *out);
> -typedef int (APIENTRYP PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(Display *dpy,
> GLXContext context,
> -const
> mesa_glinterop_export_in *in,
> -
> mesa_glinterop_export_out *out);
> typedef int (APIENTRYP PFNMESAGLINTEROPEGLEXPORTOBJECTPROC)(EGLDisplay dpy,
> EGLContext context,
> const
> mesa_glinterop_export_in *in,
>
> mesa_glinterop_export_out *out);
> -
> #ifdef __cplusplus
> }
> #endif
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] include/GL: fix the interop header for a --disable-glx build
Minor comment below. Either way:
Reviewed-by: Sinclair Yeh
On Wed, Apr 20, 2016 at 05:52:17PM +0200, Mircea Gherzan wrote:
> This header should not blindly include the GLX and should also
> conditionally define functions that use GLX parameters. The
> MESA_EGL_NO_X11_HEADERS macro is used to check if we're building without
> GLX support.
>
> Signed-off-by: Mircea Gherzan
> ---
> include/GL/mesa_glinterop.h | 37 -
> 1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
> index 814064d..cd3151f 100644
> --- a/include/GL/mesa_glinterop.h
> +++ b/include/GL/mesa_glinterop.h
> @@ -50,7 +50,12 @@
> #ifndef MESA_GLINTEROP_H
> #define MESA_GLINTEROP_H
>
> +#ifdef MESA_EGL_NO_X11_HEADERS
> +#include
> +#else
> #include
> +#endif
> +
> #include
>
> #ifdef __cplusplus
> @@ -219,6 +224,7 @@ typedef struct _mesa_glinterop_export_out {
> } mesa_glinterop_export_out;
>
>
> +#ifndef MESA_EGL_NO_X11_HEADERS
Assuming rearranging the code won't cause too many issues, instead of
the double negative, "#ifdef MESA_EGL_NO_X11_HEADER" is easier to
read.
> /**
> * Query device information.
> *
> @@ -232,16 +238,6 @@ GLAPI int GLAPIENTRY
> MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext context,
> mesa_glinterop_device_info *out);
>
> -
> -/**
> - * Same as MesaGLInteropGLXQueryDeviceInfo except that it accepts EGLDisplay
> - * and EGLContext.
> - */
> -GLAPI int GLAPIENTRY
> -MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
> -mesa_glinterop_device_info *out);
> -
> -
> /**
> * Create and return a DMABUF handle corresponding to the given OpenGL
> * object, and return other parameters about the OpenGL object.
> @@ -258,6 +254,20 @@ MesaGLInteropGLXExportObject(Display *dpy, GLXContext
> context,
> const mesa_glinterop_export_in *in,
> mesa_glinterop_export_out *out);
>
> +typedef int (APIENTRYP PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(Display *dpy,
> GLXContext context,
> +
> mesa_glinterop_device_info *out);
> +typedef int (APIENTRYP PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(Display *dpy,
> GLXContext context,
> +const
> mesa_glinterop_export_in *in,
> +
> mesa_glinterop_export_out *out);
> +#endif /* MESA_EGL_NO_X11_HEADERS */
> +
> +/**
> + * Same as MesaGLInteropGLXQueryDeviceInfo except that it accepts EGLDisplay
> + * and EGLContext.
> + */
> +GLAPI int GLAPIENTRY
> +MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
> +mesa_glinterop_device_info *out);
>
> /**
> * Same as MesaGLInteropGLXExportObject except that it accepts
> @@ -268,18 +278,11 @@ MesaGLInteropEGLExportObject(EGLDisplay dpy, EGLContext
> context,
> const mesa_glinterop_export_in *in,
> mesa_glinterop_export_out *out);
>
> -
> -typedef int (APIENTRYP PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(Display *dpy,
> GLXContext context,
> -
> mesa_glinterop_device_info *out);
> typedef int (APIENTRYP PFNMESAGLINTEROPEGLQUERYDEVICEINFOPROC)(EGLDisplay
> dpy, EGLContext context,
>
> mesa_glinterop_device_info *out);
> -typedef int (APIENTRYP PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(Display *dpy,
> GLXContext context,
> -const
> mesa_glinterop_export_in *in,
> -
> mesa_glinterop_export_out *out);
> typedef int (APIENTRYP PFNMESAGLINTEROPEGLEXPORTOBJECTPROC)(EGLDisplay dpy,
> EGLContext context,
> const
> mesa_glinterop_export_in *in,
>
> mesa_glinterop_export_out *out);
> -
> #ifdef __cplusplus
> }
> #endif
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gk110/ir: make use of IMUL32I for all immediates
Signed-off-by: Samuel Pitoiset
Cc: "11.1 11.2"
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index 59e5c83..f69567a 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -612,7 +612,7 @@ CodeEmitterGK110::emitIMUL(const Instruction *i)
assert(!i->src(0).mod.neg() && !i->src(1).mod.neg());
assert(!i->src(0).mod.abs() && !i->src(1).mod.abs());
- if (isLIMM(i->src(1), TYPE_S32)) {
+ if (i->src(1).getFile() == FILE_IMMEDIATE) {
emitForm_L(i, 0x280, 2, Modifier(0));
if (i->subOp == NV50_IR_SUBOP_MUL_HIGH)
--
2.8.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] gk110/ir: use separate signed expressions for dst/src with IMUL32I
Forcing the destination type to be signed when the source is signed
is not totally correct.
Signed-off-by: Samuel Pitoiset
Cc: "11.1 11.2"
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index f69567a..90b90bc 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -617,8 +617,10 @@ CodeEmitterGK110::emitIMUL(const Instruction *i)
if (i->subOp == NV50_IR_SUBOP_MUL_HIGH)
code[1] |= 1 << 24;
+ if (i->dType == TYPE_S32)
+ code[1] |= 1 << 25;
if (i->sType == TYPE_S32)
- code[1] |= 3 << 25;
+ code[1] |= 1 << 26;
} else {
emitForm_21(i, 0x21c, 0xc1c);
--
2.8.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 95035] Gallium OSMesa driver is far from being thread-safe
https://bugs.freedesktop.org/show_bug.cgi?id=95035 Bug ID: 95035 Summary: Gallium OSMesa driver is far from being thread-safe Product: Mesa Version: 11.2 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: frederic.dever...@m4x.org QA Contact: mesa-dev@lists.freedesktop.org see src/gallium/state_trackers/osmesa/osmesa.c There are at least three global variables with no protection: - stapi in get_st_api() - stmgr in get_st_manager() - BufferList Consequently: - OSMesaCreateContext cannot be called simultaneously from two threads - OSMesaMakeCurrent called from two threads with the same buffer attribs will share the same element in BufferList, and thus render to the same memory! My guess is that these two objects should simply be stored in the context itself, but I cannot foresee the consequences. For example, will shared display lists still work? I am willing to help on solving this (we use OSMesa in highly multithreaded application). -- 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 4/4] radeon: handle query buffer allocation and mapping failures
For patches 1,3,4:
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 20, 2016 at 5:43 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94984
> ---
> src/gallium/drivers/radeon/r600_query.c | 40
> ++---
> src/gallium/drivers/radeon/r600_query.h | 2 +-
> 2 files changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_query.c
> b/src/gallium/drivers/radeon/r600_query.c
> index e5e032b..922d2b5 100644
> --- a/src/gallium/drivers/radeon/r600_query.c
> +++ b/src/gallium/drivers/radeon/r600_query.c
> @@ -271,14 +271,20 @@ static struct r600_resource
> *r600_new_query_buffer(struct r600_common_context *c
> struct r600_resource *buf = (struct r600_resource*)
> pipe_buffer_create(ctx->b.screen, PIPE_BIND_CUSTOM,
>PIPE_USAGE_STAGING, buf_size);
> + if (!buf)
> + return NULL;
>
> - if (query->flags & R600_QUERY_HW_FLAG_PREDICATE)
> - query->ops->prepare_buffer(ctx, query, buf);
> + if (query->flags & R600_QUERY_HW_FLAG_PREDICATE) {
> + if (!query->ops->prepare_buffer(ctx, query, buf)) {
> + pipe_resource_reference((struct pipe_resource
> **)&buf, NULL);
> + return NULL;
> + }
> + }
>
> return buf;
> }
>
> -static void r600_query_hw_prepare_buffer(struct r600_common_context *ctx,
> +static bool r600_query_hw_prepare_buffer(struct r600_common_context *ctx,
> struct r600_query_hw *query,
> struct r600_resource *buffer)
> {
> @@ -286,6 +292,8 @@ static void r600_query_hw_prepare_buffer(struct
> r600_common_context *ctx,
> uint32_t *results = ctx->ws->buffer_map(buffer->buf, NULL,
> PIPE_TRANSFER_WRITE |
> PIPE_TRANSFER_UNSYNCHRONIZED);
> + if (!results)
> + return false;
>
> memset(results, 0, buffer->b.b.width0);
>
> @@ -306,6 +314,8 @@ static void r600_query_hw_prepare_buffer(struct
> r600_common_context *ctx,
> results += 4 * ctx->max_db;
> }
> }
> +
> + return true;
> }
>
> static struct r600_query_ops query_hw_ops = {
> @@ -496,6 +506,9 @@ static void r600_query_hw_emit_start(struct
> r600_common_context *ctx,
> {
> uint64_t va;
>
> + if (!query->buffer.buf)
> + return; // previous buffer allocation failure
> +
> r600_update_occlusion_query_state(ctx, query->b.type, 1);
> r600_update_prims_generated_query_state(ctx, query->b.type, 1);
>
> @@ -506,9 +519,11 @@ static void r600_query_hw_emit_start(struct
> r600_common_context *ctx,
> if (query->buffer.results_end + query->result_size >
> query->buffer.buf->b.b.width0) {
> struct r600_query_buffer *qbuf =
> MALLOC_STRUCT(r600_query_buffer);
> *qbuf = query->buffer;
> - query->buffer.buf = r600_new_query_buffer(ctx, query);
> query->buffer.results_end = 0;
> query->buffer.previous = qbuf;
> + query->buffer.buf = r600_new_query_buffer(ctx, query);
> + if (!query->buffer.buf)
> + return;
> }
>
> /* emit begin query */
> @@ -575,6 +590,9 @@ static void r600_query_hw_emit_stop(struct
> r600_common_context *ctx,
> {
> uint64_t va;
>
> + if (!query->buffer.buf)
> + return; // previous buffer allocation failure
> +
> /* The queries which need begin already called this in begin_query. */
> if (query->flags & R600_QUERY_HW_FLAG_NO_START) {
> ctx->need_gfx_cs_space(&ctx->b, query->num_cs_dw_end, FALSE);
> @@ -694,6 +712,9 @@ static void r600_query_hw_reset_buffers(struct
> r600_common_context *rctx,
> FREE(qbuf);
> }
>
> + query->buffer.results_end = 0;
> + query->buffer.previous = NULL;
> +
> if (query->flags & R600_QUERY_HW_FLAG_PREDICATE) {
> /* Obtain a new buffer if the current one can't be mapped
> without a stall. */
> if (r600_rings_is_buffer_referenced(rctx,
> query->buffer.buf->buf, RADEON_USAGE_READWRITE) ||
> @@ -701,12 +722,10 @@ static void r600_query_hw_reset_buffers(struct
> r600_common_context *rctx,
> pipe_resource_reference((struct
> pipe_resource**)&query->buffer.buf, NULL);
> query->buffer.buf = r600_new_query_buffer(rctx,
> query);
> } else {
> - query->ops->prepare_buffer(rctx, query,
> query->buffer.buf);
> + if (!query->ops->prepare_buffer(rctx, query,
> query->buffer.buf))
> + pipe_resource_refer
Re: [Mesa-dev] Mesa (master): 29 new commits
On Thu, Apr 14, 2016 at 9:29 AM, Michel Dänzer wrote: > On 14.04.2016 11:37, Michel Dänzer wrote: >> On 12.04.2016 21:33, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote: >>> >>> URL: >>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=5a4b74d1ba2c156766a7a5dbfef099c7db5d6694 >>> Author: Marek Olšák >>> Date: Mon Apr 11 19:56:07 2016 +0200 >>> >>> gallium/radeon: relax requirements on VRAM placements on APUs >> >> This change caused a bunch of ARB_shader_load_image_store piglit tests >> to fail on my Kaveri, see some examples below. The incorrect values >> seem consistent. >> >> I suppose some buffers end up in GTT instead of VRAM with this >> change, but I'm not sure how that could cause problems. Any ideas? > > Also, with the code modified to use GTT only for everything but > (potential) scanout buffers, the performance of Unigine Valley and the > Unreal Engine 4 Elemental demo is reduced by about 30%. So the premise > that GTT is about as fast as VRAM doesn't seem to hold true in practice > (at least with Kaveri and presumably other (pre-)CIK APUs; maybe it's > better with Carrizo and newer), which means that this change may cause > performance of long-running processes to drop significantly over time. > > Given all these issues, I'm afraid it may be better to revert this > change for now, until we have a better plan for dealing with this. Assuming you use the radeon kernel driver and you are not busy, would you please check whether the performance is lower on amdgpu as well? Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gk110/ir: make use of IMUL32I for all immediates
Reviewed-by: Ilia Mirkin
On Wed, Apr 20, 2016 at 1:06 PM, Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> Cc: "11.1 11.2"
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> index 59e5c83..f69567a 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> @@ -612,7 +612,7 @@ CodeEmitterGK110::emitIMUL(const Instruction *i)
> assert(!i->src(0).mod.neg() && !i->src(1).mod.neg());
> assert(!i->src(0).mod.abs() && !i->src(1).mod.abs());
>
> - if (isLIMM(i->src(1), TYPE_S32)) {
> + if (i->src(1).getFile() == FILE_IMMEDIATE) {
>emitForm_L(i, 0x280, 2, Modifier(0));
>
>if (i->subOp == NV50_IR_SUBOP_MUL_HIGH)
> --
> 2.8.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] gk110/ir: use separate signed expressions for dst/src with IMUL32I
Presumably you'd want to touch up the non-limm side of this as well?
Although TBH, I can't really think of a time when it'd matter. I think
you're pretty much guaranteed to have stype == dtype for mul's. Maybe
I'm wrong?
-ilia
On Wed, Apr 20, 2016 at 1:06 PM, Samuel Pitoiset
wrote:
> Forcing the destination type to be signed when the source is signed
> is not totally correct.
>
> Signed-off-by: Samuel Pitoiset
> Cc: "11.1 11.2"
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> index f69567a..90b90bc 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> @@ -617,8 +617,10 @@ CodeEmitterGK110::emitIMUL(const Instruction *i)
>
>if (i->subOp == NV50_IR_SUBOP_MUL_HIGH)
> code[1] |= 1 << 24;
> + if (i->dType == TYPE_S32)
> + code[1] |= 1 << 25;
>if (i->sType == TYPE_S32)
> - code[1] |= 3 << 25;
> + code[1] |= 1 << 26;
> } else {
>emitForm_21(i, 0x21c, 0xc1c);
>
> --
> 2.8.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gk110/ir: do not overwrite def value with zero for EXCH ops
This is only valid for other atomic operations (including CAS). This
fixes an invalid opcode error from dmesg. While we are it, make sure
to initialize global addr to 0 for other atomic operations.
Signed-off-by: Samuel Pitoiset
Cc: "11.1 11.2"
---
.../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index 70f3c3f..e2c3b8e 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -1808,6 +1808,9 @@ uses64bitAddress(const Instruction *ldst)
void
CodeEmitterGK110::emitATOM(const Instruction *i)
{
+ const bool hasDst = i->defExists(0);
+ const bool exch = i->subOp == NV50_IR_SUBOP_ATOM_EXCH;
+
code[0] = 0x0002;
if (i->subOp == NV50_IR_SUBOP_ATOM_CAS)
code[1] = 0x7780;
@@ -1836,15 +1839,21 @@ CodeEmitterGK110::emitATOM(const Instruction *i)
/* TODO: cas: flip bits if $r255 is used */
srcId(i->src(1), 23);
- if (i->defExists(0))
+ if (hasDst) {
defId(i->def(0), 2);
- else
+ } else
+ if (!exch) {
code[0] |= 255 << 2;
+ }
- const int32_t offset = SDATA(i->src(0)).offset;
- assert(offset < 0x8 && offset >= -0x8);
- code[0] |= (offset & 1) << 31;
- code[1] |= (offset & 0xe) >> 1;
+ if (hasDst || !exch) {
+ const int32_t offset = SDATA(i->src(0)).offset;
+ assert(offset < 0x8 && offset >= -0x8);
+ code[0] |= (offset & 1) << 31;
+ code[1] |= (offset & 0xe) >> 1;
+ } else {
+ srcAddr32(i->src(0), 31);
+ }
if (i->getIndirect(0, 0)) {
srcId(i->getIndirect(0, 0), 10);
--
2.8.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gk110/ir: do not overwrite def value with zero for EXCH ops
The SM20/SM30 logic does this for exch || cas. Are you *sure* this
shouldn't be the same? It's pretty silly to do a CAS without a dst,
but it's definitely possible (through DCE).
On Wed, Apr 20, 2016 at 1:47 PM, Samuel Pitoiset
wrote:
> This is only valid for other atomic operations (including CAS). This
> fixes an invalid opcode error from dmesg. While we are it, make sure
> to initialize global addr to 0 for other atomic operations.
>
> Signed-off-by: Samuel Pitoiset
> Cc: "11.1 11.2"
> ---
> .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 21
> +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> index 70f3c3f..e2c3b8e 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> @@ -1808,6 +1808,9 @@ uses64bitAddress(const Instruction *ldst)
> void
> CodeEmitterGK110::emitATOM(const Instruction *i)
> {
> + const bool hasDst = i->defExists(0);
> + const bool exch = i->subOp == NV50_IR_SUBOP_ATOM_EXCH;
> +
> code[0] = 0x0002;
> if (i->subOp == NV50_IR_SUBOP_ATOM_CAS)
>code[1] = 0x7780;
> @@ -1836,15 +1839,21 @@ CodeEmitterGK110::emitATOM(const Instruction *i)
> /* TODO: cas: flip bits if $r255 is used */
> srcId(i->src(1), 23);
>
> - if (i->defExists(0))
> + if (hasDst) {
>defId(i->def(0), 2);
> - else
> + } else
> + if (!exch) {
>code[0] |= 255 << 2;
> + }
>
> - const int32_t offset = SDATA(i->src(0)).offset;
> - assert(offset < 0x8 && offset >= -0x8);
> - code[0] |= (offset & 1) << 31;
> - code[1] |= (offset & 0xe) >> 1;
> + if (hasDst || !exch) {
> + const int32_t offset = SDATA(i->src(0)).offset;
> + assert(offset < 0x8 && offset >= -0x8);
> + code[0] |= (offset & 1) << 31;
> + code[1] |= (offset & 0xe) >> 1;
> + } else {
> + srcAddr32(i->src(0), 31);
> + }
>
> if (i->getIndirect(0, 0)) {
>srcId(i->getIndirect(0, 0), 10);
> --
> 2.8.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: fix building on i686 with -mcpu=generic
Pushed! On Sat, Apr 16, 2016 at 9:52 PM, Jason Ekstrand wrote: > Reviewed-by: Jason Ekstrand > On Apr 16, 2016 12:50 PM, "Laurent Carlier" wrote: > >> mcpu=generic doesn't enable sse2, and anvil definitly needs it >> --- >> src/intel/vulkan/Makefile.am | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am >> index cba6671..a84be72 100644 >> --- a/src/intel/vulkan/Makefile.am >> +++ b/src/intel/vulkan/Makefile.am >> @@ -67,7 +67,7 @@ AM_CPPFLAGS = \ >> -I$(top_builddir)/src/compiler/nir \ >> -I$(top_builddir)/src/intel >> >> -libvulkan_intel_la_CFLAGS = $(CFLAGS) -Wno-override-init >> +libvulkan_intel_la_CFLAGS = $(CFLAGS) -Wno-override-init -msse2 >> >> VULKAN_SOURCES =\ >> anv_allocator.c \ >> -- >> 2.8.0 >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: fix build without Wayland platform
Pushed. Thanks! On Sat, Apr 16, 2016 at 1:48 PM, Marcin Ślusarz wrote: > > --- > src/intel/vulkan/Makefile.am | 9 + > src/intel/vulkan/anv_private.h | 3 --- > 2 files changed, 5 insertions(+), 7 deletions(-) > > diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am > index cba6671..a201bed 100644 > --- a/src/intel/vulkan/Makefile.am > +++ b/src/intel/vulkan/Makefile.am > @@ -31,8 +31,7 @@ vulkan_include_HEADERS = \ > # Used when generating entrypoints to filter out unwanted extensions > VULKAN_ENTRYPOINT_CPPFLAGS = \ > -I$(top_srcdir)/include/vulkan \ > - -DVK_USE_PLATFORM_XCB_KHR \ > - -DVK_USE_PLATFORM_WAYLAND_KHR > + -DVK_USE_PLATFORM_XCB_KHR > > lib_LTLIBRARIES = libvulkan_intel.la > > @@ -67,7 +66,7 @@ AM_CPPFLAGS = \ > -I$(top_builddir)/src/compiler/nir \ > -I$(top_builddir)/src/intel > > -libvulkan_intel_la_CFLAGS = $(CFLAGS) -Wno-override-init > +libvulkan_intel_la_CFLAGS = $(CFLAGS) -DVK_USE_PLATFORM_XCB_KHR > -Wno-override-init > > VULKAN_SOURCES =\ > anv_allocator.c \ > @@ -150,7 +149,9 @@ AM_CPPFLAGS += > -I$(top_srcdir)/src/egl/wayland/wayland-drm > VULKAN_SOURCES += \ > wayland-drm-protocol.c \ > anv_wsi_wayland.c > -libvulkan_intel_la_CFLAGS += -DHAVE_WAYLAND_PLATFORM > +libvulkan_intel_la_CFLAGS += -DHAVE_WAYLAND_PLATFORM > -DVK_USE_PLATFORM_WAYLAND_KHR > + > +VULKAN_ENTRYPOINT_CPPFLAGS += -DVK_USE_PLATFORM_WAYLAND_KHR > endif > > libvulkan_intel_la_SOURCES =\ > diff --git a/src/intel/vulkan/anv_private.h > b/src/intel/vulkan/anv_private.h > index ae2e08d..2840f98 100644 > --- a/src/intel/vulkan/anv_private.h > +++ b/src/intel/vulkan/anv_private.h > @@ -52,9 +52,6 @@ typedef struct xcb_connection_t xcb_connection_t; > typedef uint32_t xcb_visualid_t; > typedef uint32_t xcb_window_t; > > -#define VK_USE_PLATFORM_XCB_KHR > -#define VK_USE_PLATFORM_WAYLAND_KHR > - > #define VK_PROTOTYPES > #include > #include > -- > 2.5.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94291] llvmpipe tests fail if built on skylake i7-6700k
https://bugs.freedesktop.org/show_bug.cgi?id=94291 --- Comment #10 from Timo Aaltonen --- Oh, I didn't know they were subvariants :) I've dropped them from our llvm-3.8 for now at least.. -- 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 1/2] winsys/amdgpu: adjust IB size based on buffer wait time
On 2016-04-20 02:20, Nicolai Hähnle wrote:
This is just a slight massaging of the patch you sent previously. What
happened to the discussion we had about how to do this properly?
This already provides good value as-is and it is (IMHO) reasonably
clean, so why not include it for the time being? Marek seemed to like
the general concept as well. I agree that basing IB size on GPU idleness
is a great idea and I'll look into that, either as an alternative or as
an addition to this.
Just a random question: we can count on up to date gfx fence sequence
numbers being available without any calls into the kernel, right? The
winsys code makes that conditional and calls into the kernel when no
fence pointer is available.
Grigori
On 19.04.2016 18:13, Grigori Goronzy wrote:
Small IBs help to reduce stalls for workloads that require a lot of
synchronization. On the other hand, if there is no notable
synchronization, we can use a large IB size to slightly improve
performance in some cases.
This introduces tuning of the IB size based on feedback on the average
buffer wait time. The average wait time is tracked with exponential
smoothing.
---
src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 6 +-
src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 17 -
src/gallium/winsys/amdgpu/drm/amdgpu_cs.h | 2 ++
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h | 9 +
4 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index 036301e..4b8554d 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -195,8 +195,10 @@ static void *amdgpu_bo_map(struct pb_buffer *buf,
return NULL;
}
}
+ amdgpu_winsys_update_buffer_wait_avg(bo->ws, 0);
} else {
uint64_t time = os_time_get_nano();
+ uint64_t duration;
if (!(usage & PIPE_TRANSFER_WRITE)) {
/* Mapping for read.
@@ -221,7 +223,9 @@ static void *amdgpu_bo_map(struct pb_buffer *buf,
RADEON_USAGE_READWRITE);
}
- bo->ws->buffer_wait_time += os_time_get_nano() - time;
+ duration = os_time_get_nano() - time;
+ bo->ws->buffer_wait_time += duration;
+ amdgpu_winsys_update_buffer_wait_avg(bo->ws, duration);
}
}
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
index 69902c4..b9a7c5b 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
@@ -201,10 +201,7 @@ amdgpu_ctx_query_reset_status(struct
radeon_winsys_ctx *rwctx)
static bool amdgpu_get_new_ib(struct radeon_winsys *ws, struct
amdgpu_ib *ib,
struct amdgpu_cs_ib_info *info,
unsigned ib_type)
{
- /* Small IBs are better than big IBs, because the GPU goes idle
quicker
-* and there is less waiting for buffers and fences. Proof:
-*
http://www.phoronix.com/scan.php?page=article&item=mesa-111-si&num=1
-*/
+ struct amdgpu_winsys *aws = (struct amdgpu_winsys *)ws;
unsigned buffer_size, ib_size;
switch (ib_type) {
@@ -216,8 +213,18 @@ static bool amdgpu_get_new_ib(struct
radeon_winsys *ws, struct amdgpu_ib *ib,
ib_size = 128 * 1024 * 4;
break;
case IB_MAIN:
+ /* Small IBs are often better than big IBs, because the GPU
goes idle
+ * quicker and there is less waiting for buffers and fences.
Proof:
+ *
http://www.phoronix.com/scan.php?page=article&item=mesa-111-si&num=1
+ * Tune IB size depending on average buffer waiting time, which
is an
+ * indicator for the amount of synchronization going on. Some
+ * applications don't cause notable synchronization, so we can
use
+ * large IB size for slightly improved throughput.
+ */
buffer_size = 128 * 1024 * 4;
- ib_size = 20 * 1024 * 4;
+ ib_size = 32 * 1024 * 4;
+ if (aws->buffer_wait_time_avg > IB_SIZE_WAIT_THRESHOLD_NS)
+ ib_size = 10 * 1024 * 4;
}
ib->base.cdw = 0;
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h
index 4ed830b..98e58a2 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h
@@ -35,6 +35,8 @@
#include "amdgpu_bo.h"
#include "util/u_memory.h"
+#define IB_SIZE_WAIT_THRESHOLD_NS 1
+
struct amdgpu_ctx {
struct amdgpu_winsys *ws;
amdgpu_context_handle ctx;
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h
index 91b9be4..3bd63b6 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h
@@ -54,6 +54,7 @@ struct amdgpu_winsys {
uint64_t allocated_vram;
uint64_t allocated_gtt;
uint64_t buff
[Mesa-dev] [Bug 95036] make check egl-symbols-check regression
https://bugs.freedesktop.org/show_bug.cgi?id=95036 Bug ID: 95036 Summary: make check egl-symbols-check regression Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Keywords: 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 mesa: 3caf2e89aa1711e80db80d2056e0a44663d9c7d2 (master 11.3.0-devel) === Mesa 11.3.0-devel: src/egl/test-suite.log === # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: egl-symbols-check === MesaGLInteropEGLExportObject MesaGLInteropEGLQueryDeviceInfo FAIL egl-symbols-check (exit status: 1) -- 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 00/18] anv: Switch to a new emit macro
On Mon, Apr 18, 2016 at 5:10 PM, Jason Ekstrand wrote: > The first patch in this series adds a short style guide for the Vulkan > driver. The rest adds a new emit macro and updates the entire driver to > use it and, while we're there, makes the style more consistent. > > Jason Ekstrand (18): > anv: Add a short style guide > anv: Add a new block-based batch emit macro > anv/cmd_buffer: Use the new emit macro for 3DPRIMITIVE commands > anv/cmd_buffer: Use the new emit macro for PIPE_CONTROL and > STATE_BASE_ADDRESS > anv/cmd_buffer: Use the new emit macro for DEPTH/STENCIL_BUFFER > anv/cmd_buffer: Use the new emit macro for 3DSTATE_CONSTANT > anv/cmd_buffer: Use the new emit macro for compute shader dispatch > anv/cmd_buffer: Use the new emit macro for DRAWING_RECTANGLE > anv/cmd_buffer: Use the new emit macro for quaries > anv/gen8_cmd_buffer: Use the new emit macro > anv/genX_pipeline: Use the new emit macro > anv/gen8_pipeline: Use the new emit macro > anv/state: Use the new emit macro > anv/device: Use the new emit macro > anv/gen7_cmd_buffer: Use the new emit macro > anv/gen7_pipeline: Use the new emit macro > anv: Remove the old emit macro > anv: s/anv_batch_emit_blk/anv_batch_emit/ > > src/intel/vulkan/STYLE| 67 + > src/intel/vulkan/anv_batch_chain.c| 17 +- > src/intel/vulkan/anv_device.c | 8 +- > src/intel/vulkan/anv_private.h| 19 +- > src/intel/vulkan/gen7_cmd_buffer.c| 115 > src/intel/vulkan/gen7_pipeline.c | 236 + > src/intel/vulkan/gen8_cmd_buffer.c| 155 ++- > src/intel/vulkan/gen8_pipeline.c | 367 +- > src/intel/vulkan/genX_cmd_buffer.c| 480 > +++--- > src/intel/vulkan/genX_pipeline.c | 25 +- > src/intel/vulkan/genX_pipeline_util.h | 58 ++-- > src/intel/vulkan/genX_state.c | 155 +-- > 12 files changed, 938 insertions(+), 764 deletions(-) > create mode 100644 src/intel/vulkan/STYLE That's a lot of lines! Acked-by: Kristian Høgsberg > > -- > 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/18] anv: Switch to a new emit macro
On Wed, Apr 20, 2016 at 11:38 AM, Kristian Høgsberg wrote: > On Mon, Apr 18, 2016 at 5:10 PM, Jason Ekstrand > wrote: > > The first patch in this series adds a short style guide for the Vulkan > > driver. The rest adds a new emit macro and updates the entire driver to > > use it and, while we're there, makes the style more consistent. > > > > Jason Ekstrand (18): > > anv: Add a short style guide > > anv: Add a new block-based batch emit macro > > anv/cmd_buffer: Use the new emit macro for 3DPRIMITIVE commands > > anv/cmd_buffer: Use the new emit macro for PIPE_CONTROL and > > STATE_BASE_ADDRESS > > anv/cmd_buffer: Use the new emit macro for DEPTH/STENCIL_BUFFER > > anv/cmd_buffer: Use the new emit macro for 3DSTATE_CONSTANT > > anv/cmd_buffer: Use the new emit macro for compute shader dispatch > > anv/cmd_buffer: Use the new emit macro for DRAWING_RECTANGLE > > anv/cmd_buffer: Use the new emit macro for quaries > > anv/gen8_cmd_buffer: Use the new emit macro > > anv/genX_pipeline: Use the new emit macro > > anv/gen8_pipeline: Use the new emit macro > > anv/state: Use the new emit macro > > anv/device: Use the new emit macro > > anv/gen7_cmd_buffer: Use the new emit macro > > anv/gen7_pipeline: Use the new emit macro > > anv: Remove the old emit macro > > anv: s/anv_batch_emit_blk/anv_batch_emit/ > > > > src/intel/vulkan/STYLE| 67 + > > src/intel/vulkan/anv_batch_chain.c| 17 +- > > src/intel/vulkan/anv_device.c | 8 +- > > src/intel/vulkan/anv_private.h| 19 +- > > src/intel/vulkan/gen7_cmd_buffer.c| 115 > > src/intel/vulkan/gen7_pipeline.c | 236 + > > src/intel/vulkan/gen8_cmd_buffer.c| 155 ++- > > src/intel/vulkan/gen8_pipeline.c | 367 +- > > src/intel/vulkan/genX_cmd_buffer.c| 480 > +++--- > > src/intel/vulkan/genX_pipeline.c | 25 +- > > src/intel/vulkan/genX_pipeline_util.h | 58 ++-- > > src/intel/vulkan/genX_state.c | 155 +-- > > 12 files changed, 938 insertions(+), 764 deletions(-) > > create mode 100644 src/intel/vulkan/STYLE > > That's a lot of lines! > I'm just trying to make as much of the Vulkan driver blame to me as possible. :-P > Acked-by: Kristian Høgsberg > > > > > -- > > 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] gallium/radeon: implement randomized SDMA testing
From: Marek Olšák
---
src/gallium/drivers/r600/r600_pipe.c | 3 +
src/gallium/drivers/radeon/Makefile.sources | 1 +
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +
src/gallium/drivers/radeon/r600_pipe_common.h | 5 +
src/gallium/drivers/radeon/r600_test_dma.c| 360 ++
src/gallium/drivers/radeonsi/si_pipe.c| 3 +
6 files changed, 374 insertions(+)
create mode 100644 src/gallium/drivers/radeon/r600_test_dma.c
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 52f0986..98c5a89 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -707,5 +707,8 @@ struct pipe_screen *r600_screen_create(struct radeon_winsys
*ws)
}
#endif
+ if (rscreen->b.debug_flags & DBG_TEST_DMA)
+ r600_test_dma(&rscreen->b);
+
return &rscreen->b.b;
}
diff --git a/src/gallium/drivers/radeon/Makefile.sources
b/src/gallium/drivers/radeon/Makefile.sources
index f993d75..6fbed81 100644
--- a/src/gallium/drivers/radeon/Makefile.sources
+++ b/src/gallium/drivers/radeon/Makefile.sources
@@ -10,6 +10,7 @@ C_SOURCES := \
r600_query.c \
r600_query.h \
r600_streamout.c \
+ r600_test_dma.c \
r600_texture.c \
r600_viewport.c \
radeon_uvd.c \
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 9ed6da6..2b3f57e 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -385,6 +385,8 @@ static const struct debug_named_value
common_debug_options[] = {
{ "noasm", DBG_NO_ASM, "Don't print disassembled shaders"},
{ "preoptir", DBG_PREOPT_IR, "Print the LLVM IR before initial
optimizations" },
+ { "testdma", DBG_TEST_DMA, "Invoke SDMA tests and exit." },
+
/* features */
{ "nodma", DBG_NO_ASYNC_DMA, "Disable asynchronous DMA" },
{ "nohyperz", DBG_NO_HYPERZ, "Disable Hyper-Z" },
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 44ab675..f7cdc24 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -77,6 +77,8 @@
#define DBG_NO_TGSI(1 << 13)
#define DBG_NO_ASM (1 << 14)
#define DBG_PREOPT_IR (1 << 15)
+/* gaps */
+#define DBG_TEST_DMA (1 << 20)
/* Bits 21-31 are reserved for the r600g driver. */
/* features */
#define DBG_NO_ASYNC_DMA (1llu << 32)
@@ -617,6 +619,9 @@ void r600_update_prims_generated_query_state(struct
r600_common_context *rctx,
unsigned type, int diff);
void r600_streamout_init(struct r600_common_context *rctx);
+/* r600_test_dma.c */
+void r600_test_dma(struct r600_common_screen *rscreen);
+
/* r600_texture.c */
void r600_texture_get_fmask_info(struct r600_common_screen *rscreen,
struct r600_texture *rtex,
diff --git a/src/gallium/drivers/radeon/r600_test_dma.c
b/src/gallium/drivers/radeon/r600_test_dma.c
new file mode 100644
index 000..62c7d13
--- /dev/null
+++ b/src/gallium/drivers/radeon/r600_test_dma.c
@@ -0,0 +1,360 @@
+/*
+ * Copyright 2016 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ */
+
+/* This file implements randomized SDMA texture blit tests. */
+
+#include "r600_pipe_common.h"
+#include "util/u_surface.h"
+
+static uint64_t seed_xorshift128plus[2];
+
+/* Super fast random number generator.
+ *
+ * This rand_xorshift128plus function by Sebastiano Vigna belongs
+ * to the public domain.
+ */
+static uint64_t rand_xorshift128plus(void)
+{
+ uint64_t *s = seed_xorshift128plus;
+
+ uint64_t s1 = s[0];
+ const uint64_t s0 = s[1];
+ s[0] = s0;
+
[Mesa-dev] [Bug 95038] atomic_add and atomic_or cause a OpenCL crashes
https://bugs.freedesktop.org/show_bug.cgi?id=95038 Bug ID: 95038 Summary: atomic_add and atomic_or cause a OpenCL crashes Product: Mesa Version: 11.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: ros...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org No real idea if this is an issue for LLVM or for Mesa but on my r600g GPU(6520g) LLVM crashes when compiling an opencl kernel that uses either atomic_add or atomic_or. On LLVM 3.8 and mesa 11.2 -- 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] gk110/ir: do not overwrite def value with zero for EXCH ops
On 04/20/2016 07:49 PM, Ilia Mirkin wrote:
The SM20/SM30 logic does this for exch || cas. Are you *sure* this
shouldn't be the same? It's pretty silly to do a CAS without a dst,
but it's definitely possible (through DCE).
Yeah, I'm sure. It's definitely not the same logic between gk104 and gk110.
About gk104, there are different opcodes for EXCH, CAS and one for all
other atomic operations (ADD, MIN, etc). And this logic is only valid
for EXCH and CAS.
About gk110, there are only two different opcodes, one for CAS, and the
other one for EXCH including ADD, MIN etc. But it's invalid to not
define a dst for EXCH *only*.
For your input, it's possible to do a CAS without a dst on GK110, as you
can see below: :-)
.headerflags@"EF_CUDA_SM35 EF_CUDA_PTX_SM(EF_CUDA_SM35)"
/**/ @P0 ATOM.CAS RZ, [R0], R0, R1; /* 0x778003fe */
On Wed, Apr 20, 2016 at 1:47 PM, Samuel Pitoiset
wrote:
This is only valid for other atomic operations (including CAS). This
fixes an invalid opcode error from dmesg. While we are it, make sure
to initialize global addr to 0 for other atomic operations.
Signed-off-by: Samuel Pitoiset
Cc: "11.1 11.2"
---
.../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index 70f3c3f..e2c3b8e 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -1808,6 +1808,9 @@ uses64bitAddress(const Instruction *ldst)
void
CodeEmitterGK110::emitATOM(const Instruction *i)
{
+ const bool hasDst = i->defExists(0);
+ const bool exch = i->subOp == NV50_IR_SUBOP_ATOM_EXCH;
+
code[0] = 0x0002;
if (i->subOp == NV50_IR_SUBOP_ATOM_CAS)
code[1] = 0x7780;
@@ -1836,15 +1839,21 @@ CodeEmitterGK110::emitATOM(const Instruction *i)
/* TODO: cas: flip bits if $r255 is used */
srcId(i->src(1), 23);
- if (i->defExists(0))
+ if (hasDst) {
defId(i->def(0), 2);
- else
+ } else
+ if (!exch) {
code[0] |= 255 << 2;
+ }
- const int32_t offset = SDATA(i->src(0)).offset;
- assert(offset < 0x8 && offset >= -0x8);
- code[0] |= (offset & 1) << 31;
- code[1] |= (offset & 0xe) >> 1;
+ if (hasDst || !exch) {
+ const int32_t offset = SDATA(i->src(0)).offset;
+ assert(offset < 0x8 && offset >= -0x8);
+ code[0] |= (offset & 1) << 31;
+ code[1] |= (offset & 0xe) >> 1;
+ } else {
+ srcAddr32(i->src(0), 31);
+ }
if (i->getIndirect(0, 0)) {
srcId(i->getIndirect(0, 0), 10);
--
2.8.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 4/4] i965: Properly handle integer types in opt_vector_float().
On Tue, Apr 19, 2016 at 12:44 PM, Matt Turner wrote: > On Mon, Apr 18, 2016 at 11:52 PM, Kenneth Graunke > wrote: >> Previously, opt_vector_float() always interpreted MOV sources as >> floating point, and always created a MOV with a F-type destination. >> >> This meant that we could mess up sequences of integer loads, such as: >> >>mov vgrf6.0.x:D, 0D >>mov vgrf6.0.y:D, 1D >>mov vgrf6.0.z:D, 2D >>mov vgrf6.0.w:D, 3D >> >> Here, integer 0/1/2/3 become approximately 0.0f, so we generated: >> >>mov vgrf6.0:F, [0F, 0F, 0F, 0F] >> >> which is clearly wrong. We can properly handle this by converting >> integer values to float (rather than bitcasting), and emitting a type >> converting MOV: >> >>mov vgrf6.0:D, [0F, 1F, 2F, 3F] >> >> To do this, see first see if the integer values (converted to float) >> are representable. If so, we use a D-type MOV. If not, we then try >> the floating point values and an F-type MOV. We make zero not impose >> type restrictions. This is important because 0D would imply a D-type >> MOV, but is often used in sequences such as MOV 0D, MOV 0x3f80D, >> where we want to use an F-type MOV. >> >> Fixes about 54 dEQP-GLES2 failures with the vec4 VS backend. This >> recently became visible due to changes in opt_vector_float() which >> made it optimize more cases, but it was a pre-existing bug. >> >> v2: Handle the type of zero better. >> >> Signed-off-by: Kenneth Graunke > > This patch has these shader-db stats on HSW: > > total instructions in shared programs: 7084195 -> 7082191 (-0.03%) > instructions in affected programs: 246027 -> 244023 (-0.81%) > helped: 1937 > > total cycles in shared programs: 65669642 -> 65651968 (-0.03%) > cycles in affected programs: 531064 -> 513390 (-3.33%) > helped: 1177 Looks like a lot of vertex shaders benefit because they compare against ivec4(0, 1, 2, 3) which we now load as a VF in one instruction. Neat! The series is Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] gk110/ir: use separate signed expressions for dst/src with IMUL32I
On 04/20/2016 07:47 PM, Ilia Mirkin wrote:
Presumably you'd want to touch up the non-limm side of this as well?
Although TBH, I can't really think of a time when it'd matter. I think
you're pretty much guaranteed to have stype == dtype for mul's. Maybe
I'm wrong?
Well, the non-limm part is wrong because 0xc1c won't be used anymore
with the previous patch, as emitForm_21() uses opc1 when src(1) is an
immediate. The different flags was only useful for 0xc1c but now they
are useless, because 0x21c is actually:
/**/ @P0 FMUL32I.FTZ R0.CC, R0, -0; /* 0x21c2 */
I was thinking to make a new patch to remove them, but this one doesn't
need to be backported.
I think we are pretty guaranteed that stype == dtype, but does this is
correct all the time? Not sure. If you look at NVC0::emitUMUL() you will
see that the signed expressions for dst/src are separated.
-ilia
On Wed, Apr 20, 2016 at 1:06 PM, Samuel Pitoiset
wrote:
Forcing the destination type to be signed when the source is signed
is not totally correct.
Signed-off-by: Samuel Pitoiset
Cc: "11.1 11.2"
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index f69567a..90b90bc 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -617,8 +617,10 @@ CodeEmitterGK110::emitIMUL(const Instruction *i)
if (i->subOp == NV50_IR_SUBOP_MUL_HIGH)
code[1] |= 1 << 24;
+ if (i->dType == TYPE_S32)
+ code[1] |= 1 << 25;
if (i->sType == TYPE_S32)
- code[1] |= 3 << 25;
+ code[1] |= 1 << 26;
} else {
emitForm_21(i, 0x21c, 0xc1c);
--
2.8.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 95036] make check egl-symbols-check regression
https://bugs.freedesktop.org/show_bug.cgi?id=95036 Vinson Lee changed: What|Removed |Added Keywords||bisected CC||mar...@gmail.com --- Comment #1 from Vinson Lee --- b6eda708431b91a3b568da0efac845c08cb36796 is the first bad commit commit b6eda708431b91a3b568da0efac845c08cb36796 Author: Marek Olšák Date: Thu Mar 3 15:59:48 2016 +0100 egl: implement EGL part of interop interface (v2) v2: - use const :04 04 72d180aa00fbc6459645a545151ad1312cc1b592 6737ab9fdd00cd7717efb2770035cc8a3ce5e8c8 Msrc bisect run success -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] winsys/amdgpu: adjust IB size based on buffer wait time
On Wed, Apr 20, 2016 at 8:18 PM, Grigori Goronzy wrote: > On 2016-04-20 02:20, Nicolai Hähnle wrote: >> >> This is just a slight massaging of the patch you sent previously. What >> happened to the discussion we had about how to do this properly? >> > > This already provides good value as-is and it is (IMHO) reasonably clean, so > why not include it for the time being? Marek seemed to like the general > concept as well. I agree that basing IB size on GPU idleness is a great idea > and I'll look into that, either as an alternative or as an addition to this. > > Just a random question: we can count on up to date gfx fence sequence > numbers being available without any calls into the kernel, right? The winsys > code makes that conditional and calls into the kernel when no fence pointer > is available. Yes, there is a fence buffer you can read to get the latest sequence numbers for different rings. That buffer might not be updated when IBs of other process finish though. Only UVD and VCE don't support user fences. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Relax GLSL 1.10 float suffix error to a warning.
Float suffixes are allowed in all subsequent GLSL specifications, and
it's obvious what the user meant if they specify one. Accept it with a
warning to avoid breaking applications, like Planeshift.
---
src/compiler/glsl/glsl_lexer.ll | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll
index 6b1ef17..8a562cb 100644
--- a/src/compiler/glsl/glsl_lexer.ll
+++ b/src/compiler/glsl/glsl_lexer.ll
@@ -476,8 +476,8 @@ layout {
char suffix = yytext[strlen(yytext) - 1];
if (!state->is_version(120, 300) &&
(suffix == 'f' || suffix == 'F')) {
- _mesa_glsl_error(yylloc, state,
-"Float suffixes are invalid in
GLSL 1.10");
+ _mesa_glsl_warning(yylloc, state,
+ "Float suffixes are invalid
in GLSL 1.10");
}
yylval->real = _mesa_strtof(yytext, NULL);
return FLOATCONSTANT;
--
2.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] st/mesa: check return value of begin/end_query
On 20.04.2016 11:13, Samuel Pitoiset wrote:
On 04/20/2016 05:43 PM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
They can only indicate out of memory conditions, since the other error
conditions are caught earlier.
---
src/mesa/state_tracker/st_cb_queryobj.c | 55
-
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
b/src/mesa/state_tracker/st_cb_queryobj.c
index cdb9efc..784ffde 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -61,13 +61,9 @@ st_NewQueryObject(struct gl_context *ctx, GLuint id)
}
-
static void
-st_DeleteQuery(struct gl_context *ctx, struct gl_query_object *q)
+free_queries(struct pipe_context *pipe, struct st_query_object *stq)
{
- struct pipe_context *pipe = st_context(ctx)->pipe;
- struct st_query_object *stq = st_query_object(q);
-
if (stq->pq) {
pipe->destroy_query(pipe, stq->pq);
stq->pq = NULL;
@@ -77,6 +73,16 @@ st_DeleteQuery(struct gl_context *ctx, struct
gl_query_object *q)
pipe->destroy_query(pipe, stq->pq_begin);
stq->pq_begin = NULL;
}
+}
+
+
+static void
+st_DeleteQuery(struct gl_context *ctx, struct gl_query_object *q)
+{
+ struct pipe_context *pipe = st_context(ctx)->pipe;
+ struct st_query_object *stq = st_query_object(q);
+
+ free_queries(pipe, stq);
free(stq);
}
@@ -89,6 +95,7 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
struct pipe_context *pipe = st->pipe;
struct st_query_object *stq = st_query_object(q);
unsigned type;
+ bool ret = false;
st_flush_bitmap_cache(st_context(ctx));
@@ -133,14 +140,7 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
if (stq->type != type) {
/* free old query of different type */
- if (stq->pq) {
- pipe->destroy_query(pipe, stq->pq);
- stq->pq = NULL;
- }
- if (stq->pq_begin) {
- pipe->destroy_query(pipe, stq->pq_begin);
- stq->pq_begin = NULL;
- }
+ free_queries(pipe, stq);
stq->type = PIPE_QUERY_TYPES; /* an invalid value */
}
@@ -151,20 +151,25 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
stq->pq_begin = pipe->create_query(pipe, type, 0);
stq->type = type;
}
- pipe->end_query(pipe, stq->pq_begin);
+ if (stq->pq_begin)
+ ret = pipe->end_query(pipe, stq->pq_begin);
} else {
if (!stq->pq) {
stq->pq = pipe->create_query(pipe, type, q->Stream);
stq->type = type;
}
- if (stq->pq) {
- pipe->begin_query(pipe, stq->pq);
- }
- else {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
- return;
- }
+ if (stq->pq)
+ ret = pipe->begin_query(pipe, stq->pq);
}
+
+ if (!ret) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
+
+ free_queries(pipe, stq);
Why do you need to free queries now? Was there a memleak before? And why
not in glEndQuery too?
There wasn't a memleak. The idea is that deleting objects that might be
in "weird" internal states earlier is less likely to cause problems
later on, but if you feel strongly about it I can remove it.
+ q->Active = GL_FALSE;
+ return;
+ }
+
assert(stq->type == type);
}
@@ -174,6 +179,7 @@ st_EndQuery(struct gl_context *ctx, struct
gl_query_object *q)
{
struct pipe_context *pipe = st_context(ctx)->pipe;
struct st_query_object *stq = st_query_object(q);
+ bool ret = false;
st_flush_bitmap_cache(st_context(ctx));
@@ -185,7 +191,12 @@ st_EndQuery(struct gl_context *ctx, struct
gl_query_object *q)
}
if (stq->pq)
- pipe->end_query(pipe, stq->pq);
+ ret = pipe->end_query(pipe, stq->pq);
+
+ if (!ret) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
This should be "glEndQuery", right?
Good point, I've changed it locally.
I think it would be better to move
the error message inside the previous branch, what do you think?
No, this is in purpose, to catch a failure of pipe->create_query above.
Nicolai
+ return;
+ }
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Relax GLSL 1.10 float suffix error to a warning.
I am fine with this, it would be nice if we could modify the following
piglit tests to pass when a warning is emitted:
https://cgit.freedesktop.org/piglit/tree/tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-capital-f.vert
https://cgit.freedesktop.org/piglit/tree/tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-f.vert
Either way,
Reviewed-by: Lars Hamre
On Wed, Apr 20, 2016 at 3:29 PM, Matt Turner wrote:
>
> Float suffixes are allowed in all subsequent GLSL specifications, and
> it's obvious what the user meant if they specify one. Accept it with a
> warning to avoid breaking applications, like Planeshift.
> ---
> src/compiler/glsl/glsl_lexer.ll | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll
> index 6b1ef17..8a562cb 100644
> --- a/src/compiler/glsl/glsl_lexer.ll
> +++ b/src/compiler/glsl/glsl_lexer.ll
> @@ -476,8 +476,8 @@ layout {
> char suffix = yytext[strlen(yytext) - 1];
> if (!state->is_version(120, 300) &&
> (suffix == 'f' || suffix == 'F')) {
> - _mesa_glsl_error(yylloc, state,
> -"Float suffixes are invalid
> in GLSL 1.10");
> + _mesa_glsl_warning(yylloc, state,
> + "Float suffixes are
> invalid in GLSL 1.10");
> }
> yylval->real = _mesa_strtof(yytext, NULL);
> return FLOATCONSTANT;
> --
> 2.7.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Relax GLSL 1.10 float suffix error to a warning.
Am 20.04.2016 um 21:29 schrieb Matt Turner:
> Float suffixes are allowed in all subsequent GLSL specifications, and
> it's obvious what the user meant if they specify one. Accept it with a
> warning to avoid breaking applications, like Planeshift.
> ---
> src/compiler/glsl/glsl_lexer.ll | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll
> index 6b1ef17..8a562cb 100644
> --- a/src/compiler/glsl/glsl_lexer.ll
> +++ b/src/compiler/glsl/glsl_lexer.ll
> @@ -476,8 +476,8 @@ layout{
> char suffix = yytext[strlen(yytext) - 1];
> if (!state->is_version(120, 300) &&
> (suffix == 'f' || suffix == 'F')) {
> - _mesa_glsl_error(yylloc, state,
> - "Float suffixes are invalid in
> GLSL 1.10");
> + _mesa_glsl_warning(yylloc, state,
> +"Float suffixes are invalid
> in GLSL 1.10");
> }
> yylval->real = _mesa_strtof(yytext, NULL);
> return FLOATCONSTANT;
>
Sine I "voted" for warning instead of making it a driconf option, looks
fine to me.
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Relax GLSL 1.10 float suffix error to a warning.
On Wed, Apr 20, 2016 at 12:48 PM, Lars Hamre wrote: > I am fine with this, it would be nice if we could modify the following > piglit tests to pass when a warning is emitted: > https://cgit.freedesktop.org/piglit/tree/tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-capital-f.vert > https://cgit.freedesktop.org/piglit/tree/tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-f.vert Right. Unfortunately, that would require adding some infrastructure to glslparsertest to accept "warn" as a result, and I'm not sure how that would work. In this case we'd want that to mean "accept failure to compile" but also "accept compilation succeeded but with a warning message". ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH demos 1/4] eglinfo: Note when an EGLConfig is streams-compatible
Signed-off-by: Adam Jackson --- src/egl/opengl/eglinfo.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/egl/opengl/eglinfo.c b/src/egl/opengl/eglinfo.c index 1f79fef..ca22df2 100644 --- a/src/egl/opengl/eglinfo.c +++ b/src/egl/opengl/eglinfo.c @@ -93,6 +93,8 @@ PrintConfigs(EGLDisplay d) strcat(surfString, "pb,"); if (surfaces & EGL_PIXMAP_BIT) strcat(surfString, "pix,"); + if (surfaces & EGL_STREAM_BIT_KHR) + strcat(surfString, "str,"); if (strlen(surfString) > 0) surfString[strlen(surfString) - 1] = 0; -- 2.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH demos 4/4] eglinfo: Add EXT_platform_* awareness
Signed-off-by: Adam Jackson
---
src/egl/opengl/eglinfo.c | 41 +++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/src/egl/opengl/eglinfo.c b/src/egl/opengl/eglinfo.c
index 875e407..75d9fe5 100644
--- a/src/egl/opengl/eglinfo.c
+++ b/src/egl/opengl/eglinfo.c
@@ -115,7 +115,7 @@ PrintConfigs(EGLDisplay d)
}
-static void
+static const char *
PrintExtensions(EGLDisplay d)
{
const char *extensions, *p, *end, *next;
@@ -126,7 +126,7 @@ PrintExtensions(EGLDisplay d)
extensions = eglQueryString(d, EGL_EXTENSIONS);
if (!extensions)
- return;
+ return NULL;
column = 0;
end = extensions + strlen(extensions);
@@ -153,6 +153,8 @@ PrintExtensions(EGLDisplay d)
if (column > 0)
printf("\n");
+
+ return extensions;
}
static int
@@ -162,7 +164,7 @@ doOneDisplay(EGLDisplay d, const char *name)
printf("%s:\n", name);
if (!eglInitialize(d, &maj, &min)) {
- printf("eglinfo: eglInitialize failed\n");
+ printf("eglinfo: eglInitialize failed\n\n");
return 1;
}
@@ -183,12 +185,39 @@ doOneDisplay(EGLDisplay d, const char *name)
int
main(int argc, char *argv[])
{
- int ret;
+ int ret = 0;
+ const char *clientext;
- PrintExtensions(EGL_NO_DISPLAY);
+ clientext = PrintExtensions(EGL_NO_DISPLAY);
printf("\n");
- ret = doOneDisplay(eglGetDisplay(EGL_DEFAULT_DISPLAY), "Default display");
+ if (strstr(clientext, "EGL_EXT_platform_base")) {
+ PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplay =
+ (PFNEGLGETPLATFORMDISPLAYEXTPROC)
+ eglGetProcAddress("eglGetPlatformDisplayEXT");
+ if (strstr(clientext, "EGL_KHR_platform_android"))
+ ret += doOneDisplay(getPlatformDisplay(EGL_PLATFORM_ANDROID_KHR,
+ EGL_DEFAULT_DISPLAY,
+ NULL), "Android platform");
+ if (strstr(clientext, "EGL_MESA_platform_gbm") ||
+ strstr(clientext, "EGL_KHR_platform_gbm"))
+ ret += doOneDisplay(getPlatformDisplay(EGL_PLATFORM_GBM_MESA,
+ EGL_DEFAULT_DISPLAY,
+ NULL), "GBM platform");
+ if (strstr(clientext, "EGL_EXT_platform_wayland") ||
+ strstr(clientext, "EGL_KHR_platform_wayland"))
+ ret += doOneDisplay(getPlatformDisplay(EGL_PLATFORM_WAYLAND_EXT,
+ EGL_DEFAULT_DISPLAY,
+ NULL), "Wayland platform");
+ if (strstr(clientext, "EGL_EXT_platform_x11") ||
+ strstr(clientext, "EGL_KHR_platform_x11"))
+ ret += doOneDisplay(getPlatformDisplay(EGL_PLATFORM_X11_EXT,
+ EGL_DEFAULT_DISPLAY,
+ NULL), "X11 platform");
+ }
+ else {
+ ret = doOneDisplay(eglGetDisplay(EGL_DEFAULT_DISPLAY), "Default
display");
+ }
return ret;
}
--
2.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH demos 3/4] eglinfo: Factor out a "probe one display" function
Signed-off-by: Adam Jackson
---
src/egl/opengl/eglinfo.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/src/egl/opengl/eglinfo.c b/src/egl/opengl/eglinfo.c
index b044eaa..875e407 100644
--- a/src/egl/opengl/eglinfo.c
+++ b/src/egl/opengl/eglinfo.c
@@ -155,19 +155,15 @@ PrintExtensions(EGLDisplay d)
printf("\n");
}
-int
-main(int argc, char *argv[])
+static int
+doOneDisplay(EGLDisplay d, const char *name)
{
int maj, min;
- EGLDisplay d;
-
- PrintExtensions(EGL_NO_DISPLAY);
-
- d = eglGetDisplay(EGL_DEFAULT_DISPLAY);
+ printf("%s:\n", name);
if (!eglInitialize(d, &maj, &min)) {
printf("eglinfo: eglInitialize failed\n");
- exit(1);
+ return 1;
}
printf("EGL API version: %d.%d\n", maj, min);
@@ -180,8 +176,19 @@ main(int argc, char *argv[])
PrintExtensions(d);
PrintConfigs(d);
-
- eglTerminate(d);
-
+ printf("\n");
return 0;
}
+
+int
+main(int argc, char *argv[])
+{
+ int ret;
+
+ PrintExtensions(EGL_NO_DISPLAY);
+ printf("\n");
+
+ ret = doOneDisplay(eglGetDisplay(EGL_DEFAULT_DISPLAY), "Default display");
+
+ return ret;
+}
--
2.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH demos 2/4] eglinfo: Print client extensions first
These are independent of the display, and I want to iterate over those.
Signed-off-by: Adam Jackson
---
src/egl/opengl/eglinfo.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/egl/opengl/eglinfo.c b/src/egl/opengl/eglinfo.c
index ca22df2..b044eaa 100644
--- a/src/egl/opengl/eglinfo.c
+++ b/src/egl/opengl/eglinfo.c
@@ -159,7 +159,11 @@ int
main(int argc, char *argv[])
{
int maj, min;
- EGLDisplay d = eglGetDisplay(EGL_DEFAULT_DISPLAY);
+ EGLDisplay d;
+
+ PrintExtensions(EGL_NO_DISPLAY);
+
+ d = eglGetDisplay(EGL_DEFAULT_DISPLAY);
if (!eglInitialize(d, &maj, &min)) {
printf("eglinfo: eglInitialize failed\n");
@@ -174,7 +178,6 @@ main(int argc, char *argv[])
#endif
PrintExtensions(d);
- PrintExtensions(EGL_NO_DISPLAY);
PrintConfigs(d);
--
2.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] gk110/ir: use separate signed expressions for dst/src with IMUL32I
On Wed, Apr 20, 2016 at 3:14 PM, Samuel Pitoiset
wrote:
>
>
> On 04/20/2016 07:47 PM, Ilia Mirkin wrote:
>>
>> Presumably you'd want to touch up the non-limm side of this as well?
>> Although TBH, I can't really think of a time when it'd matter. I think
>> you're pretty much guaranteed to have stype == dtype for mul's. Maybe
>> I'm wrong?
>
>
> Well, the non-limm part is wrong because 0xc1c won't be used anymore with
> the previous patch, as emitForm_21() uses opc1 when src(1) is an immediate.
> The different flags was only useful for 0xc1c but now they are useless,
> because 0x21c is actually:
>
> /**/ @P0 FMUL32I.FTZ R0.CC, R0, -0; /* 0x21c2 */
huh? It or's some bits depending on arg types, so it'll be 61c or whatever.
>
> I was thinking to make a new patch to remove them, but this one doesn't need
> to be backported.
>
> I think we are pretty guaranteed that stype == dtype, but does this is
> correct all the time? Not sure. If you look at NVC0::emitUMUL() you will see
> that the signed expressions for dst/src are separated.
>
>
>>
>>-ilia
>>
>> On Wed, Apr 20, 2016 at 1:06 PM, Samuel Pitoiset
>> wrote:
>>>
>>> Forcing the destination type to be signed when the source is signed
>>> is not totally correct.
>>>
>>> Signed-off-by: Samuel Pitoiset
>>> Cc: "11.1 11.2"
>>> ---
>>> src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
>>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
>>> index f69567a..90b90bc 100644
>>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
>>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
>>> @@ -617,8 +617,10 @@ CodeEmitterGK110::emitIMUL(const Instruction *i)
>>>
>>> if (i->subOp == NV50_IR_SUBOP_MUL_HIGH)
>>>code[1] |= 1 << 24;
>>> + if (i->dType == TYPE_S32)
>>> + code[1] |= 1 << 25;
>>> if (i->sType == TYPE_S32)
>>> - code[1] |= 3 << 25;
>>> + code[1] |= 1 << 26;
>>> } else {
>>> emitForm_21(i, 0x21c, 0xc1c);
>>>
>>> --
>>> 2.8.0
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] st/mesa: check return value of begin/end_query
On 04/20/2016 09:37 PM, Nicolai Hähnle wrote:
On 20.04.2016 11:13, Samuel Pitoiset wrote:
On 04/20/2016 05:43 PM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
They can only indicate out of memory conditions, since the other error
conditions are caught earlier.
---
src/mesa/state_tracker/st_cb_queryobj.c | 55
-
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
b/src/mesa/state_tracker/st_cb_queryobj.c
index cdb9efc..784ffde 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -61,13 +61,9 @@ st_NewQueryObject(struct gl_context *ctx, GLuint id)
}
-
static void
-st_DeleteQuery(struct gl_context *ctx, struct gl_query_object *q)
+free_queries(struct pipe_context *pipe, struct st_query_object *stq)
{
- struct pipe_context *pipe = st_context(ctx)->pipe;
- struct st_query_object *stq = st_query_object(q);
-
if (stq->pq) {
pipe->destroy_query(pipe, stq->pq);
stq->pq = NULL;
@@ -77,6 +73,16 @@ st_DeleteQuery(struct gl_context *ctx, struct
gl_query_object *q)
pipe->destroy_query(pipe, stq->pq_begin);
stq->pq_begin = NULL;
}
+}
+
+
+static void
+st_DeleteQuery(struct gl_context *ctx, struct gl_query_object *q)
+{
+ struct pipe_context *pipe = st_context(ctx)->pipe;
+ struct st_query_object *stq = st_query_object(q);
+
+ free_queries(pipe, stq);
free(stq);
}
@@ -89,6 +95,7 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
struct pipe_context *pipe = st->pipe;
struct st_query_object *stq = st_query_object(q);
unsigned type;
+ bool ret = false;
st_flush_bitmap_cache(st_context(ctx));
@@ -133,14 +140,7 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
if (stq->type != type) {
/* free old query of different type */
- if (stq->pq) {
- pipe->destroy_query(pipe, stq->pq);
- stq->pq = NULL;
- }
- if (stq->pq_begin) {
- pipe->destroy_query(pipe, stq->pq_begin);
- stq->pq_begin = NULL;
- }
+ free_queries(pipe, stq);
stq->type = PIPE_QUERY_TYPES; /* an invalid value */
}
@@ -151,20 +151,25 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
stq->pq_begin = pipe->create_query(pipe, type, 0);
stq->type = type;
}
- pipe->end_query(pipe, stq->pq_begin);
+ if (stq->pq_begin)
+ ret = pipe->end_query(pipe, stq->pq_begin);
} else {
if (!stq->pq) {
stq->pq = pipe->create_query(pipe, type, q->Stream);
stq->type = type;
}
- if (stq->pq) {
- pipe->begin_query(pipe, stq->pq);
- }
- else {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
- return;
- }
+ if (stq->pq)
+ ret = pipe->begin_query(pipe, stq->pq);
}
+
+ if (!ret) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
+
+ free_queries(pipe, stq);
Why do you need to free queries now? Was there a memleak before? And why
not in glEndQuery too?
There wasn't a memleak. The idea is that deleting objects that might be
in "weird" internal states earlier is less likely to cause problems
later on, but if you feel strongly about it I can remove it.
No, it's fine by me. I was just wondering. :-)
+ q->Active = GL_FALSE;
+ return;
+ }
+
assert(stq->type == type);
}
@@ -174,6 +179,7 @@ st_EndQuery(struct gl_context *ctx, struct
gl_query_object *q)
{
struct pipe_context *pipe = st_context(ctx)->pipe;
struct st_query_object *stq = st_query_object(q);
+ bool ret = false;
st_flush_bitmap_cache(st_context(ctx));
@@ -185,7 +191,12 @@ st_EndQuery(struct gl_context *ctx, struct
gl_query_object *q)
}
if (stq->pq)
- pipe->end_query(pipe, stq->pq);
+ ret = pipe->end_query(pipe, stq->pq);
+
+ if (!ret) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBeginQuery");
This should be "glEndQuery", right?
Good point, I've changed it locally.
I think it would be better to move
the error message inside the previous branch, what do you think?
No, this is in purpose, to catch a failure of pipe->create_query above.
Okay, thanks!
Reviewed-by: Samuel Pitoiset
Nicolai
+ return;
+ }
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gk110/ir: do not overwrite def value with zero for EXCH ops
Reviewed-by: Ilia Mirkin
On Wed, Apr 20, 2016 at 1:47 PM, Samuel Pitoiset
wrote:
> This is only valid for other atomic operations (including CAS). This
> fixes an invalid opcode error from dmesg. While we are it, make sure
> to initialize global addr to 0 for other atomic operations.
>
> Signed-off-by: Samuel Pitoiset
> Cc: "11.1 11.2"
> ---
> .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 21
> +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> index 70f3c3f..e2c3b8e 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> @@ -1808,6 +1808,9 @@ uses64bitAddress(const Instruction *ldst)
> void
> CodeEmitterGK110::emitATOM(const Instruction *i)
> {
> + const bool hasDst = i->defExists(0);
> + const bool exch = i->subOp == NV50_IR_SUBOP_ATOM_EXCH;
> +
> code[0] = 0x0002;
> if (i->subOp == NV50_IR_SUBOP_ATOM_CAS)
>code[1] = 0x7780;
> @@ -1836,15 +1839,21 @@ CodeEmitterGK110::emitATOM(const Instruction *i)
> /* TODO: cas: flip bits if $r255 is used */
> srcId(i->src(1), 23);
>
> - if (i->defExists(0))
> + if (hasDst) {
>defId(i->def(0), 2);
> - else
> + } else
> + if (!exch) {
>code[0] |= 255 << 2;
> + }
>
> - const int32_t offset = SDATA(i->src(0)).offset;
> - assert(offset < 0x8 && offset >= -0x8);
> - code[0] |= (offset & 1) << 31;
> - code[1] |= (offset & 0xe) >> 1;
> + if (hasDst || !exch) {
> + const int32_t offset = SDATA(i->src(0)).offset;
> + assert(offset < 0x8 && offset >= -0x8);
> + code[0] |= (offset & 1) << 31;
> + code[1] |= (offset & 0xe) >> 1;
> + } else {
> + srcAddr32(i->src(0), 31);
> + }
>
> if (i->getIndirect(0, 0)) {
>srcId(i->getIndirect(0, 0), 10);
> --
> 2.8.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos 4/4] eglinfo: Add EXT_platform_* awareness
On Wed, Apr 20, 2016 at 4:10 PM, Adam Jackson wrote:
> Signed-off-by: Adam Jackson
Series is:
Reviewed-by: Alex Deucher
> ---
> src/egl/opengl/eglinfo.c | 41 +++--
> 1 file changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/src/egl/opengl/eglinfo.c b/src/egl/opengl/eglinfo.c
> index 875e407..75d9fe5 100644
> --- a/src/egl/opengl/eglinfo.c
> +++ b/src/egl/opengl/eglinfo.c
> @@ -115,7 +115,7 @@ PrintConfigs(EGLDisplay d)
> }
>
>
> -static void
> +static const char *
> PrintExtensions(EGLDisplay d)
> {
> const char *extensions, *p, *end, *next;
> @@ -126,7 +126,7 @@ PrintExtensions(EGLDisplay d)
>
> extensions = eglQueryString(d, EGL_EXTENSIONS);
> if (!extensions)
> - return;
> + return NULL;
>
> column = 0;
> end = extensions + strlen(extensions);
> @@ -153,6 +153,8 @@ PrintExtensions(EGLDisplay d)
>
> if (column > 0)
>printf("\n");
> +
> + return extensions;
> }
>
> static int
> @@ -162,7 +164,7 @@ doOneDisplay(EGLDisplay d, const char *name)
>
> printf("%s:\n", name);
> if (!eglInitialize(d, &maj, &min)) {
> - printf("eglinfo: eglInitialize failed\n");
> + printf("eglinfo: eglInitialize failed\n\n");
>return 1;
> }
>
> @@ -183,12 +185,39 @@ doOneDisplay(EGLDisplay d, const char *name)
> int
> main(int argc, char *argv[])
> {
> - int ret;
> + int ret = 0;
> + const char *clientext;
>
> - PrintExtensions(EGL_NO_DISPLAY);
> + clientext = PrintExtensions(EGL_NO_DISPLAY);
> printf("\n");
>
> - ret = doOneDisplay(eglGetDisplay(EGL_DEFAULT_DISPLAY), "Default display");
> + if (strstr(clientext, "EGL_EXT_platform_base")) {
> + PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplay =
> + (PFNEGLGETPLATFORMDISPLAYEXTPROC)
> + eglGetProcAddress("eglGetPlatformDisplayEXT");
> + if (strstr(clientext, "EGL_KHR_platform_android"))
> + ret += doOneDisplay(getPlatformDisplay(EGL_PLATFORM_ANDROID_KHR,
> + EGL_DEFAULT_DISPLAY,
> + NULL), "Android platform");
> + if (strstr(clientext, "EGL_MESA_platform_gbm") ||
> + strstr(clientext, "EGL_KHR_platform_gbm"))
> + ret += doOneDisplay(getPlatformDisplay(EGL_PLATFORM_GBM_MESA,
> + EGL_DEFAULT_DISPLAY,
> + NULL), "GBM platform");
> + if (strstr(clientext, "EGL_EXT_platform_wayland") ||
> + strstr(clientext, "EGL_KHR_platform_wayland"))
> + ret += doOneDisplay(getPlatformDisplay(EGL_PLATFORM_WAYLAND_EXT,
> + EGL_DEFAULT_DISPLAY,
> + NULL), "Wayland platform");
> + if (strstr(clientext, "EGL_EXT_platform_x11") ||
> + strstr(clientext, "EGL_KHR_platform_x11"))
> + ret += doOneDisplay(getPlatformDisplay(EGL_PLATFORM_X11_EXT,
> + EGL_DEFAULT_DISPLAY,
> + NULL), "X11 platform");
> + }
> + else {
> + ret = doOneDisplay(eglGetDisplay(EGL_DEFAULT_DISPLAY), "Default
> display");
> + }
>
> return ret;
> }
> --
> 2.7.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
[Mesa-dev] [PATCH 5/7] gk110/ir: add emission for VSHL
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 58 ++
1 file changed, 58 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index 15280df..2bad6fe 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -140,6 +140,9 @@ private:
void emitSUCLAMPMode(uint16_t);
void emitSUCalc(Instruction *);
+ void emitVSHL(const Instruction *);
+ void emitVectorSubOp(const Instruction *);
+
inline void defId(const ValueDef&, const int pos);
inline void srcId(const ValueRef&, const int pos);
inline void srcId(const ValueRef *, const int pos);
@@ -1675,6 +1678,58 @@ CodeEmitterGK110::emitSUCalc(Instruction *i)
}
}
+
+void
+CodeEmitterGK110::emitVectorSubOp(const Instruction *i)
+{
+ switch (NV50_IR_SUBOP_Vn(i->subOp)) {
+ case 0:
+ code[1] |= (i->subOp & 0x000f) << 7; // vsrc1
+ code[1] |= (i->subOp & 0x00e0) >> 6; // vsrc2
+ code[1] |= (i->subOp & 0x0100) << 13; // vsrc2
+ code[1] |= (i->subOp & 0x3c00) << 12; // vdst
+ break;
+ default:
+ assert(0);
+ break;
+ }
+}
+
+void
+CodeEmitterGK110::emitVSHL(const Instruction *i)
+{
+ code[0] = 0x0002;
+ code[1] = 0xb800;
+
+ assert(NV50_IR_SUBOP_Vn(i->subOp) == 0);
+
+ if (isSignedType(i->dType)) code[1] |= 1 << 25;
+ if (isSignedType(i->sType)) code[1] |= 1 << 19;
+
+ emitVectorSubOp(i);
+
+ emitPredicate(i);
+ defId(i->def(0), 2);
+ srcId(i->src(0), 10);
+
+ if (i->getSrc(1)->reg.file == FILE_IMMEDIATE) {
+ ImmediateValue *imm = i->getSrc(1)->asImm();
+ assert(imm);
+ code[0] |= (imm->reg.data.u32 & 0x01ff) << 23;
+ code[1] |= (imm->reg.data.u32 & 0xfe00) >> 9;
+ } else {
+ assert(i->getSrc(1)->reg.file == FILE_GPR);
+ code[1] |= 1 << 21;
+ srcId(i->src(1), 23);
+ }
+ srcId(i->src(2), 42);
+
+ if (i->saturate)
+ code[0] |= 1 << 22;
+ if (i->flagsDef >= 0)
+ code[1] |= 1 << 18;
+}
+
void
CodeEmitterGK110::emitAFETCH(const Instruction *i)
{
@@ -2413,6 +2468,9 @@ CodeEmitterGK110::emitInstruction(Instruction *insn)
case OP_SUEAU:
emitSUCalc(insn);
break;
+ case OP_VSHL:
+ emitVSHL(insn);
+ break;
case OP_PHI:
case OP_UNION:
case OP_CONSTRAINT:
--
2.8.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
