Re: [Mesa-dev] [PATCH 8/9] i965/vec4: Handle saturated constants in opt_vector_float
On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_vec4.cpp | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index 155a550..02a00b3 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -384,7 +384,13 @@ vec4_visitor::opt_vector_float()
> continue;
>}
>
> - int vf = brw_float_to_vf(inst->src[0].f);
> + float f = inst->src[0].f;
> + if (inst->saturate) {
> + assert(inst->dst.type == BRW_REGISTER_TYPE_F);
> + f = CLAMP(f, 0.0f, 1.0f);
> + }
> +
> + int vf = brw_float_to_vf(f);
>if (vf == -1)
> continue;
Presumably the previous patch is to allow this to happen without
thinking about types.
This does look like a legitimate bug fix, but what does this fix or enable?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] doc: document spilling options accepted by INTEL_DEBUG
Reviewed-by: Jordan Justen On 2016-03-18 00:41:08, Iago Toral Quiroga wrote: > --- > docs/envvars.html | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/docs/envvars.html b/docs/envvars.html > index 06aa0ac..6b5511b 100644 > --- a/docs/envvars.html > +++ b/docs/envvars.html > @@ -163,6 +163,8 @@ See the Xlib software driver > page for details. > blorp - emit messages about the blorp operations (blits & > clears) > nodualobj - suppress generation of dual-object geometry shader > code > optimizer - dump shader assembly to files at each optimization pass > and iteration that make progress > + spill_fs - force spilling of all registers in the scalar backend > (useful to debug spilling code) > + spill_vec4 - force spilling of all registers in the vec4 backend > (useful to debug spilling code) > > > > -- > 1.9.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] st/mesa: simplify bitmap shader code with tgsi transform helper functions
---
src/mesa/state_tracker/st_cb_bitmap_shader.c | 45 +---
1 file changed, 8 insertions(+), 37 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_bitmap_shader.c
b/src/mesa/state_tracker/st_cb_bitmap_shader.c
index cddea36..88779bc 100644
--- a/src/mesa/state_tracker/st_cb_bitmap_shader.c
+++ b/src/mesa/state_tracker/st_cb_bitmap_shader.c
@@ -52,7 +52,6 @@ transform_instr(struct tgsi_transform_context *tctx,
struct tgsi_full_instruction *current_inst)
{
struct tgsi_bitmap_transform *ctx = tgsi_bitmap_transform(tctx);
- struct tgsi_full_declaration decl;
struct tgsi_full_instruction inst;
unsigned i, semantic;
int texcoord_index = -1;
@@ -66,9 +65,7 @@ transform_instr(struct tgsi_transform_context *tctx,
/* Add TEMP[0] if it's missing. */
if (ctx->info.file_max[TGSI_FILE_TEMPORARY] == -1) {
- decl = tgsi_default_full_declaration();
- decl.Declaration.File = TGSI_FILE_TEMPORARY;
- tctx->emit_declaration(tctx, &decl);
+ tgsi_transform_temp_decl(tctx, 0);
}
/* Add TEXCOORD[0] if it's missing. */
@@ -83,45 +80,19 @@ transform_instr(struct tgsi_transform_context *tctx,
}
if (texcoord_index == -1) {
- decl = tgsi_default_full_declaration();
- decl.Declaration.File = TGSI_FILE_INPUT;
- decl.Declaration.Semantic = 1;
- decl.Semantic.Name = semantic;
- decl.Declaration.Interpolate = 1;
- decl.Interp.Interpolate = TGSI_INTERPOLATE_PERSPECTIVE;
- decl.Range.First = decl.Range.Last = ctx->info.num_inputs;
texcoord_index = ctx->info.num_inputs;
- tctx->emit_declaration(tctx, &decl);
+ tgsi_transform_input_decl(tctx, texcoord_index,
+semantic, 0, TGSI_INTERPOLATE_PERSPECTIVE);
}
/* Declare the sampler. */
- decl = tgsi_default_full_declaration();
- decl.Declaration.File = TGSI_FILE_SAMPLER;
- decl.Range.First = decl.Range.Last = ctx->sampler_index;
- tctx->emit_declaration(tctx, &decl);
+ tgsi_transform_sampler_decl(tctx, ctx->sampler_index);
/* TEX tmp0, fragment.texcoord[0], texture[0], 2D; */
- inst = tgsi_default_full_instruction();
- inst.Instruction.Opcode = TGSI_OPCODE_TEX;
- inst.Instruction.Texture = 1;
- inst.Texture.Texture = TGSI_TEXTURE_2D;
-
- inst.Instruction.NumDstRegs = 1;
- inst.Dst[0].Register.File = TGSI_FILE_TEMPORARY;
- inst.Dst[0].Register.Index = 0;
- inst.Dst[0].Register.WriteMask = TGSI_WRITEMASK_XYZW;
-
- inst.Instruction.NumSrcRegs = 2;
- inst.Src[0].Register.File = TGSI_FILE_INPUT;
- inst.Src[0].Register.Index = texcoord_index;
- inst.Src[0].Register.SwizzleX = TGSI_SWIZZLE_X;
- inst.Src[0].Register.SwizzleY = TGSI_SWIZZLE_Y;
- inst.Src[0].Register.SwizzleZ = TGSI_SWIZZLE_Z;
- inst.Src[0].Register.SwizzleW = TGSI_SWIZZLE_W;
- inst.Src[1].Register.File = TGSI_FILE_SAMPLER;
- inst.Src[1].Register.Index = ctx->sampler_index;
-
- tctx->emit_instruction(tctx, &inst);
+ tgsi_transform_tex_2d_inst(tctx,
+ TGSI_FILE_TEMPORARY, 0,
+ TGSI_FILE_INPUT, texcoord_index,
+ ctx->sampler_index);
/* KIL if -tmp0 < 0 # texel=0 -> keep / texel=0 -> discard */
inst = tgsi_default_full_instruction();
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 13/14] nir: propagate bitsize information in nir_search
On Wed, Mar 16, 2016 at 2:01 AM, Iago Toral wrote:
> On Wed, 2016-03-16 at 09:48 +0100, Samuel Iglesias Gonsálvez wrote:
> >
> > On 15/03/16 08:41, Iago Toral wrote:
> > > On Mon, 2016-03-14 at 17:33 -0700, Jason Ekstrand wrote:
> > [...]
> > >> + nir_alu_type type; + union { - uint32_t u; -
> > >> int32_t i; - float f; + uint64_t u; + int64_t i; +
> > >> double d; } data; } nir_search_constant;
> > >
> > > Maybe we should rename these to u64, i64 as f64 like you suggested
> > > for a similar case in another patch?
> > >
> >
> > We decided to do the following changes to this patch series (among the
> > others already agreed): rename these fields and add the inline helper
> > functions to get type size and base type from nir_alu_type enum
> > values. So the rest of the fp64 patches will have those changes
> > already and everything would be easier to maintain.
> >
> > One question for Jason: Should we squash all the patches of this
> > series in a single commit as originally proposed? I'd rather have them
> > separately so we understand what each patch does in case of a git
> > bisect, however I don't have a strong opinion against squashing.
>
> At the very least we should squash the one for the copy-propagation pass
> with the new opcodes, otherwise we'd break the build.
>
> The main concern with squashing everything is that it is going to be a
> huge patch and it is going to be difficult to make sense of it like that
> for anyone who tracks something down to it, but otherwise we are going
> to break some things in between which is also not ideal...
>
Right. Let's squash the minimum. I think we can probably keep copy
propagation and nir_search mostly out of the squash. Right now, nothing
uses values of any size other than 32 so it should be safe to leave them
separate for the most part.
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94522] llvmpipe crash in rendering on Atom
https://bugs.freedesktop.org/show_bug.cgi?id=94522 --- Comment #14 from Pekka Paalanen --- (In reply to Jose Fonseca from comment #13) > I wonder if 0xa8ec01b0 is some sort of funky device memory, or if that > device memory was destroyed before llvmpipe was done. > > After all this is SwapBuffers path. That's very likely, isn't it? comicfans44, can you confirm the dri module used, I would assume it is kms_swrast_dri.so? EGL_LOG_LEVEL=debug environment variable will fish it out. This is triggered by Weston running on bare VT, so likely the DRM-backend (which could be confirmed from Weston's output/logs), and since KMS is involved, I would guess that kms_swrast_dri.so or EGL is using DRM dumb buffers as targets. Well, if it is not using a shadow buffer. I don't know how kms_swrast_dri.so works. Maybe the bug is in the KMS glue code rather than llvmpipe? -- 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 7/9] i965/vec4: Don't allow type conversion in opt_vector_float
On Thu, Mar 17, 2016 at 11:17 AM, Matt Turner wrote: > On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand > wrote: > > --- > > src/mesa/drivers/dri/i965/brw_vec4.cpp | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp > b/src/mesa/drivers/dri/i965/brw_vec4.cpp > > index baf72a2..155a550 100644 > > --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp > > +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp > > @@ -375,6 +375,7 @@ vec4_visitor::opt_vector_float() > >if (inst->opcode != BRW_OPCODE_MOV || > >inst->dst.writemask == WRITEMASK_XYZW || > >inst->src[0].file != IMM || > > + inst->src[0].type != inst->dst.type || > > Why? > That may be the wrong condition. The reason is that the code below doesn't look at the source type at all and just assumes that it's a float. If, for instance, we had the first case below but instead of 0D we had some non-zero VF-capable value, it would interpret it as a float, cram it into a VF, and then copy it to m2 doing a re-interpret instead of doing a conversion. Thinking about it harder, I'm convinced that this patch is bogus, but the bug is real. --Jasoan > This breaks legitimate optimizations, like > > -mov m2.xy:F, 0.50F > -mov m2.zw:F, 0D > +mov m2:F, [0.5F, 0.5F, 0F, 0F] > > and > > -mov vgrf6.0.x:D, -1082130432D > -mov vgrf6.0.y:D, 1056964608D > -mov vgrf6.0.z:D, 1065353216D > +mov vgrf6.0.xyz:F, [-1F, 0.5F, 1F, 0F] > > and > > -mov vgrf7.0.x:D, 1073741824D > -mov vgrf7.0.yz:D, 0D > +mov vgrf7.0.xyz:F, [2F, 0F, 0F, 0F] > > > The first one we should just handle in opt_algebraic by fixing the src > type. The other two look like NIR fail. If we fixed those things, I'd > be fine with this. > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 91556] [Clover / OpenCL] struct and union arguments handled incorrectly, producing CL_INVALID_ARG_SIZE
https://bugs.freedesktop.org/show_bug.cgi?id=91556 --- Comment #12 from Pavan Yalamanchili --- Is this patch going through into a future release? -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 4/6] nouveau: codegen: s/FILE_MEMORY_GLOBAL/FILE_MEMORY_BUFFER/
This approach leads to the emitters needing to know about both global and
buffer, even though at that point, they are identical. I was thinking that
in the lowering logic, buffer would just get rewritten as global (with the
offset added), thus not needing any change to the emitters. What do you
think about such an approach?
On Mar 16, 2016 2:24 AM, "Hans de Goede" wrote:
> FILE_MEMORY_GLOBAL is currently only used for buffer handling, as we
> do not yet have (opencl) global memory support. Global memory support
> actually requires some different handling during lowering, so rename
> FILE_MEMORY_GLOBAL to FILE_MEMORY_BUFFER to reflect that the current
> code is for buffer handling, this will allow the later (re-)addition
> of FILE_MEMORY_GLOBAL for regular global memory.
>
> Signed-off-by: Hans de Goede
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir.h| 2 +-
> src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 10
> +-
> src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 6 +++---
> src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp| 10
> +-
> src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp| 12
> ++--
> src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp| 8
> .../drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp| 10
> +-
> src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 8
> src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp| 2 +-
> src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 6 +++---
> src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp | 2 +-
> 11 files changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> index 7b0eb2f..fdc2195 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> @@ -332,7 +332,7 @@ enum DataFile
> FILE_MEMORY_CONST,
> FILE_SHADER_INPUT,
> FILE_SHADER_OUTPUT,
> - FILE_MEMORY_GLOBAL,
> + FILE_MEMORY_BUFFER,
> FILE_MEMORY_SHARED,
> FILE_MEMORY_LOCAL,
> FILE_SYSTEM_VALUE,
> 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..02a1101 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> @@ -1641,7 +1641,7 @@ CodeEmitterGK110::emitSTORE(const Instruction *i)
> int32_t offset = SDATA(i->src(0)).offset;
>
> switch (i->src(0).getFile()) {
> - case FILE_MEMORY_GLOBAL: code[1] = 0xe000; code[0] = 0x;
> break;
> + case FILE_MEMORY_BUFFER: code[1] = 0xe000; code[0] = 0x;
> break;
> case FILE_MEMORY_LOCAL: code[1] = 0x7a80; code[0] = 0x0002;
> break;
> case FILE_MEMORY_SHARED:
>code[0] = 0x0002;
> @@ -1678,7 +1678,7 @@ CodeEmitterGK110::emitSTORE(const Instruction *i)
>
> srcId(i->src(1), 2);
> srcId(i->src(0).getIndirect(0), 10);
> - if (i->src(0).getFile() == FILE_MEMORY_GLOBAL &&
> + if (i->src(0).getFile() == FILE_MEMORY_BUFFER &&
> i->src(0).isIndirect(0) &&
> i->getIndirect(0, 0)->reg.size == 8)
>code[1] |= 1 << 23;
> @@ -1690,7 +1690,7 @@ CodeEmitterGK110::emitLOAD(const Instruction *i)
> int32_t offset = SDATA(i->src(0)).offset;
>
> switch (i->src(0).getFile()) {
> - case FILE_MEMORY_GLOBAL: code[1] = 0xc000; code[0] = 0x;
> break;
> + case FILE_MEMORY_BUFFER: code[1] = 0xc000; code[0] = 0x;
> break;
> case FILE_MEMORY_LOCAL: code[1] = 0x7a00; code[0] = 0x0002;
> break;
> case FILE_MEMORY_SHARED:
>code[0] = 0x0002;
> @@ -1800,7 +1800,7 @@ CodeEmitterGK110::emitMOV(const Instruction *i)
> static inline bool
> uses64bitAddress(const Instruction *ldst)
> {
> - return ldst->src(0).getFile() == FILE_MEMORY_GLOBAL &&
> + return ldst->src(0).getFile() == FILE_MEMORY_BUFFER &&
>ldst->src(0).isIndirect(0) &&
>ldst->getIndirect(0, 0)->reg.size == 8;
> }
> @@ -1862,7 +1862,7 @@ CodeEmitterGK110::emitCCTL(const Instruction *i)
>
> code[0] = 0x0002 | (i->subOp << 2);
>
> - if (i->src(0).getFile() == FILE_MEMORY_GLOBAL) {
> + if (i->src(0).getFile() == FILE_MEMORY_BUFFER) {
>code[1] = 0x7b00;
> } else {
>code[1] = 0x7c00;
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> index e079a57..27f287f 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> @@ -2417,7 +2417,7 @@ void
> CodeEmitterGM107::emitCCTL()
> {
> unsigned width;
> - if (insn->src(0).getFile() == FILE_MEMORY_GLOBAL) {
> + if (insn->src(0).getFile() ==
[Mesa-dev] [PATCH] doc: add 'vec4' option in INTEL_DEBUG
--- docs/envvars.html | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/envvars.html b/docs/envvars.html index 06aa0ac..e21b7c1 100644 --- a/docs/envvars.html +++ b/docs/envvars.html @@ -163,6 +163,7 @@ See the Xlib software driver page for details. blorp - emit messages about the blorp operations (blits & clears) nodualobj - suppress generation of dual-object geometry shader code optimizer - dump shader assembly to files at each optimization pass and iteration that make progress + vec4 - force vec4 mode in vertex shader -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: enable_asm=yes when x-compiling across same X86 arch
On Thu, Mar 17, 2016 at 3:53 PM, dw kim wrote: > Matt, > > I uploaded v2 patch with corrected commit message. Other than > commit message, everything is still same. Can you please re-review > it and merge it if there's no issue? Pushed. Thanks! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] meta: Use the _mesa_meta_compile_and_link_program helper more places.
On Wed, Mar 16, 2016 at 12:12:58AM -0700, Kenneth Graunke wrote: > Less boilerplate. > > Signed-off-by: Kenneth Graunke > --- > src/mesa/drivers/common/meta.c | 34 > - > src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 14 +++--- > 2 files changed, 8 insertions(+), 40 deletions(-) > > diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c > index b05dfc7..bdcf316 100644 > --- a/src/mesa/drivers/common/meta.c > +++ b/src/mesa/drivers/common/meta.c > @@ -1537,21 +1537,8 @@ meta_glsl_clear_init(struct gl_context *ctx, struct > clear_state *clear) > if (clear->ShaderProg != 0) >return; > > - vs = _mesa_CreateShader(GL_VERTEX_SHADER); > - _mesa_ShaderSource(vs, 1, &vs_source, NULL); > - _mesa_CompileShader(vs); > - > - fs = _mesa_CreateShader(GL_FRAGMENT_SHADER); > - _mesa_ShaderSource(fs, 1, &fs_source, NULL); > - _mesa_CompileShader(fs); > - > - clear->ShaderProg = _mesa_CreateProgram(); > - _mesa_AttachShader(clear->ShaderProg, fs); > - _mesa_DeleteShader(fs); > - _mesa_AttachShader(clear->ShaderProg, vs); > - _mesa_DeleteShader(vs); > - _mesa_ObjectLabel(GL_PROGRAM, clear->ShaderProg, -1, "meta clear"); > - _mesa_LinkProgram(clear->ShaderProg); > + _mesa_meta_compile_and_link_program(ctx, vs_source, fs_source, "meta > clear", > + &clear->ShaderProg); While it takes care of all the above it also calls: _mesa_BindAttribLocation(*program, 0, "position"); _mesa_BindAttribLocation(*program, 1, "texcoords"); But then I realized you replaced these in your previous patches with explicit locations. This is: Reviewed-by: Topi Pohjolainen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] need help to build mesa with ASAN
Hello everyone, I'd like to build mesa with address sanitizer to help finding bugs , I''m using mesa-11.1.2 autogen.sh/configure with env CFLAGS="-fsanitize=address" CXXFLAGS="-fsanitize=address" LDFLAGS="-fsanitize=address" and then make, but it failed when linking .libs/pipe_r300.so with lots undefined reference to `__asan_report_XX` error, seems some file didn't link with LDFLAGS. I've checked the mail list and found others already have built mesa with ASAN successfully, so did I miss something? or I must build with scons ? Thanks for help. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/9] nir/algebraic: Add two more fsat optimizations
Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About the usage of the "flat" interpolation qualifier with input (unsigned) integers and doubles in fragment shaders
On Fri, Mar 4, 2016 at 5:43 AM, Andres Gomez wrote: > Hi, > > as complementary work to the one done to "Add FP64 support to the i965 > shader backends" at: > https://bugs.freedesktop.org/show_bug.cgi?id=92760 > > I've been working to add piglit tests that would check the new features > added by this addition. > > Checking the specification of the extension, when talking about inputs, > the extension instructs that any fragment input being a double or > derived type must be qualified with the interpolation qualifier "flat". > > This extends the restriction that already existed for signed and > unsigned integers to doubles too. > > In following versions of the spec, when doubles are already part of it > we can read: > > " > Fragment shader inputs that are signed or unsigned integers, integer > vectors, or any double-precision floating-point type must be qualified > with the interpolation qualifier flat. > " > > The specification doesn't explicitly say it, but as far as I understand, > it is reasonable to think that the restriction applies to input > variables in the form of arrays or members of structures of these types. > Yes, I think that's a reasonable assumption. The reason it's required for integers is because you can't interpolate them at all. Some hardware may also not support interpolating doubles so they are included in the statement. Incidentally, we could implement it in i965 because Intel hardware does its interpolation in the shader. That does not, however, mean that we should :-) > In fact, current implementation already fails on compilation if a > non-flat integer is in a fragment input as an array or a struct member. > The same happens with doubles (llvmpipe). > > It is also reasonable to think that the restriction would also apply to > input interface blocks holding variables of these types. > > However, the compilation doesn't fail when using a non-flat integer or a > double. On execution, the integer version just gives bogus values while, > with doubles, it crashes. > > -- > > The situation with the glslangValidator is (it doesn't support doubles): > * When using a non-flat integer as a fragment input in the form of > an array or as a member of a struct it fails with an error of > the type: > > int' : must be qualified as flat in > > * When using a non-flat integer as a fragment input in the form of > a member of an interface block it succeeds on compilation. > Glslang is an ok compiler, but I wouldn't give it too much weight. Just because it's billed as a "reference compiler" doesn't mean you should trust it to get all the edge cases right. I've personally fixed enough bugs in it to now better ;-) > The situation with nvidia proprietary driver is: > * When using a non-flat integer as a fragment input in the form of > a scalar, an array, a member of a struct or a member of an > interface block it doesn't fail on compilation but on linkage > with an error of the type: > > error C5215: Integer varying must be flat > > * When using a double as a fragment input in the form of a scalar > or an array it fails on compilation with an error of the type: > > error C7570: 64 bit input '' should be flat > > * When using a double as a fragment input in the form of a a > member of a struct or a member of an interface block it doesn't > fail. Actually, it seems to do some kind of interpolation. > > -- > > Hence, based on this, my proposal would be: > * To enforce the usage of the "flat" qualifier when in a member of > an input block interface in a fragment shader for (unsigned) > integers and doubles. > Agreed. That seems like the right thing to do. > * Open a bug in Khronos specs bugzilla about the ambiguity of > this. > Done. Khronos bug #15671. > > > Opinions? > > -- > Br, > > Andres > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/10] radeonsi: ignore PIPE_BIND_LINEAR in si_is_format_supported
Am 09.03.2016 um 15:53 schrieb Marek Olšák: On Wed, Mar 9, 2016 at 4:54 AM, Michel Dänzer wrote: On 08.03.2016 21:21, Christian König wrote: From: Christian König Linear layout should work for all formats as well. The hardware actually doesn't support linear e.g. for compressed formats or depth/stencil formats. The driver ignores the flag for compressed formats. It doesn't ignore the flag for depth/stencil formats, but it does support binding a linear depth/stencil buffer as a color buffer. That said, I think PIPE_BIND_LINEAR should not be an allowed parameter of is_format_supported (unless we have a very good reason to allow it). Why not? In my use case the state tracker just translates the format it got from the application into the internal representation and queries the driver if the result would be supported or not. I could query without the linear flag as well, but I think that this wouldn't be the correct approach. How about the attached updated patch? I'm allowing PIPE_BIND_LINEAR now when it's not depth/stencil or compressed. Regards, Christian. >From e63465efecf8b302d6384379878f7967bc39aece Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= Date: Thu, 14 Jan 2016 13:38:10 +0100 Subject: [PATCH] radeonsi: ignore PIPE_BIND_LINEAR in si_is_format_supported v2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Linear layout should work for all not compressed or depth/stencil formats. v2: restrict it a bit more Signed-off-by: Christian König --- src/gallium/drivers/radeonsi/si_state.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/gallium/drivers/radeonsi/si_state.c b/src/gallium/drivers/radeonsi/si_state.c index f823af1..788e75b 100644 --- a/src/gallium/drivers/radeonsi/si_state.c +++ b/src/gallium/drivers/radeonsi/si_state.c @@ -2046,6 +2046,11 @@ boolean si_is_format_supported(struct pipe_screen *screen, if (usage & PIPE_BIND_TRANSFER_WRITE) retval |= PIPE_BIND_TRANSFER_WRITE; + if ((usage & PIPE_BIND_LINEAR) && + !util_format_is_compressed(format) && + !(usage & PIPE_BIND_DEPTH_STENCIL)) + retval |= PIPE_BIND_LINEAR; + return retval == usage; } -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] lvm pipe crash under windows
Hi all, I was wondering if anyone knows of or has seen a crash when Mesa is compiled for with LVM Pipe ? The reason I ask is that if our user uses a compiled version of Mesa using the slower software render, it works fine, the moment we compile it with LVM, it crashes. I have an api trace that shows how far it got, and a dump file if this would be of assistance? Also, it is only this one server that exhibits this problem from what we have been able to discover, however it is a pretty vanilla install as it is a production server, it is also running Terminal Services, so it is quite tightly controlled in regards to what gets installed. Thanks for your help in advance. Cheers Jason Anderssen Internet Email Confidentiality Footer: This email and any files transmitted with it contain privileged/confidential information intended for the addressee. Neither the confidentiality of nor any privilege in the email is waived, lost or destroyed by reason that it has been transmitted other than to the addressee. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 9/9] i965/vec4: Disable algebraic optimizations on floats
No shader-db change on Haswell
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 40 +-
1 file changed, 10 insertions(+), 30 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 02a00b3..0a11991 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -633,23 +633,17 @@ vec4_visitor::opt_algebraic()
bool progress = false;
foreach_block_and_inst(block, vec4_instruction, inst, cfg) {
- switch (inst->opcode) {
- case BRW_OPCODE_MOV:
- if (inst->src[0].file != IMM)
-break;
-
- if (inst->saturate) {
-if (inst->dst.type != inst->src[0].type)
- assert(!"unimplemented: saturate mixed types");
-
-if (brw_saturate_immediate(inst->dst.type,
- &inst->src[0].as_brw_reg())) {
- inst->saturate = false;
- progress = true;
-}
- }
- break;
+ /* We don't want to do any float algebraic optimizations in the backend
+ * because they aren't bit-for-bit safe and the backend doesn't know
+ * when a value is declared precise or invariant.
+ */
+ if (inst->dst.type == BRW_REGISTER_TYPE_F ||
+ inst->src[0].type == BRW_REGISTER_TYPE_F ||
+ (inst->src[1].file != BAD_FILE &&
+ inst->src[1].type == BRW_REGISTER_TYPE_F))
+ continue;
+ switch (inst->opcode) {
case VEC4_OPCODE_UNPACK_UNIFORM:
if (inst->src[0].file != UNIFORM) {
inst->opcode = BRW_OPCODE_MOV;
@@ -669,9 +663,6 @@ vec4_visitor::opt_algebraic()
if (inst->src[1].is_zero()) {
inst->opcode = BRW_OPCODE_MOV;
switch (inst->src[0].type) {
- case BRW_REGISTER_TYPE_F:
- inst->src[0] = brw_imm_f(0.0f);
- break;
case BRW_REGISTER_TYPE_D:
inst->src[0] = brw_imm_d(0);
break;
@@ -706,17 +697,6 @@ vec4_visitor::opt_algebraic()
break;
}
break;
- case SHADER_OPCODE_RCP: {
- vec4_instruction *prev = (vec4_instruction *)inst->prev;
- if (prev->opcode == SHADER_OPCODE_SQRT) {
-if (inst->src[0].equals(src_reg(prev->dst))) {
- inst->opcode = SHADER_OPCODE_RSQ;
- inst->src[0] = prev->src[0];
- progress = true;
-}
- }
- break;
- }
case SHADER_OPCODE_BROADCAST:
if (is_uniform(inst->src[0]) ||
inst->src[1].is_zero()) {
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50/ra: `isinf()` is in namespace `std` since C++11
On Mar 17, 2016 8:27 PM, "Matt Turner" wrote: > > On Thu, Mar 17, 2016 at 5:17 PM, Pierre Moreau wrote: > > This fixes a compile error while building Nouveau with C++11 enabled (and > > glibc >= 2.23). This happens if SWR is enabled, as it forces C++11. > > That seems bad, right? > > Enabling OpenSWR should affect how any other drivers are built. Why > does this happen? Yeah, the fix here is to fix the build not to add random unrelated options from one driver when building another. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/12] compiler: Actually handle invariant and precise
Previously, the GLSL compiler successfully parsed the "invariant" and "precise" keywords and set bits on the variables, but we never did anything with them. This series adds code to propagate "invariant" and "precise" all the way thorugh NIR and bail in unsafe optimizations if we see it. The GLSL code sort-of tries to keep the two separate on the off chance that some of the gallium people want to do something more interesting with them. In NIR, we take a more scorched-earth policy and introduce a concept of an "exact" ALU operation. This fixes the remaining dEQP tests for "invariant". It probably also fixes the ES 3.1 CTS tests for "precise" but I haven't actually tried it. Jason Ekstrand (12): nir: Add an "exact" bit to nir_alu_instr nir/builder: Add a flag for setting exact nir/search: Propagate exactness into newly created expressions nir/algebraic: Allow for flagging operations as being inexact nir/algebraic: Flag inexact optimizations nir/cse: Properly handle nir_ssa_def.exact i965/peephole_ffma: Don't fuse exact adds nir/alu_to_scalar: Propagate the "exact" bit glsl: Add a pass to propagate the "invariant" and "precise" qualifiers glsl/opt_algebraic: Don't handle invariant or precise trees glsl/rebalance_tree: Don't handle invariant or precise trees nir/glsl: Propagate invariant into NIR alu ops src/compiler/Makefile.sources | 1 + src/compiler/glsl/glsl_parser_extras.cpp | 1 + src/compiler/glsl/ir_optimization.h| 1 + src/compiler/glsl/opt_algebraic.cpp| 16 ++ src/compiler/glsl/opt_rebalance_tree.cpp | 16 ++ src/compiler/glsl/propagate_invariance.cpp | 125 src/compiler/nir/glsl_to_nir.cpp | 2 + src/compiler/nir/nir.h | 11 ++ src/compiler/nir/nir_algebraic.py | 9 +- src/compiler/nir/nir_builder.h | 9 ++ src/compiler/nir/nir_clone.c | 1 + src/compiler/nir/nir_instr_set.c | 16 +- src/compiler/nir/nir_lower_alu_to_scalar.c | 1 + src/compiler/nir/nir_opt_algebraic.py | 165 +++-- src/compiler/nir/nir_print.c | 2 + src/compiler/nir/nir_search.c | 13 +- src/compiler/nir/nir_search.h | 6 + .../drivers/dri/i965/brw_nir_opt_peephole_ffma.c | 4 +- 18 files changed, 312 insertions(+), 87 deletions(-) create mode 100644 src/compiler/glsl/propagate_invariance.cpp -- 2.5.0.400.gff86faf ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/12] glsl/opt_algebraic: Don't handle invariant or precise trees
---
src/compiler/glsl/opt_algebraic.cpp | 16
1 file changed, 16 insertions(+)
diff --git a/src/compiler/glsl/opt_algebraic.cpp
b/src/compiler/glsl/opt_algebraic.cpp
index 1e58062..2fea240 100644
--- a/src/compiler/glsl/opt_algebraic.cpp
+++ b/src/compiler/glsl/opt_algebraic.cpp
@@ -58,6 +58,8 @@ public:
{
}
+ virtual ir_visitor_status visit_enter(ir_assignment *ir);
+
ir_rvalue *handle_expression(ir_expression *ir);
void handle_rvalue(ir_rvalue **rvalue);
bool reassociate_constant(ir_expression *ir1,
@@ -80,6 +82,20 @@ public:
} /* unnamed namespace */
+ir_visitor_status
+ir_algebraic_visitor::visit_enter(ir_assignment *ir)
+{
+ ir_variable *var = ir->lhs->variable_referenced();
+ if (var->data.invariant || var->data.precise) {
+ /* If we're assigning to an invariant or precise variable, just bail.
+ * Most of the algebraic optimizations aren't precision-safe.
+ */
+ return visit_continue_with_parent;
+ } else {
+ return visit_continue;
+ }
+}
+
static inline bool
is_vec_zero(ir_constant *ir)
{
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/12] nir/search: Propagate exactness into newly created expressions
---
src/compiler/nir/nir_search.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/compiler/nir/nir_search.c b/src/compiler/nir/nir_search.c
index 56d7e81..4cb2d4d 100644
--- a/src/compiler/nir/nir_search.c
+++ b/src/compiler/nir/nir_search.c
@@ -246,7 +246,7 @@ match_expression(const nir_search_expression *expr,
nir_alu_instr *instr,
static nir_alu_src
construct_value(const nir_search_value *value, nir_alu_type type,
-unsigned num_components, struct match_state *state,
+unsigned num_components, bool exact, struct match_state *state,
nir_instr *instr, void *mem_ctx)
{
switch (value->type) {
@@ -257,6 +257,7 @@ construct_value(const nir_search_value *value, nir_alu_type
type,
num_components = nir_op_infos[expr->opcode].output_size;
nir_alu_instr *alu = nir_alu_instr_create(mem_ctx, expr->opcode);
+ alu->exact = exact;
nir_ssa_dest_init(&alu->instr, &alu->dest.dest, num_components, NULL);
alu->dest.write_mask = (1 << num_components) - 1;
alu->dest.saturate = false;
@@ -270,7 +271,7 @@ construct_value(const nir_search_value *value, nir_alu_type
type,
alu->src[i] = construct_value(expr->srcs[i],
nir_op_infos[alu->op].input_types[i],
- num_components,
+ num_components, exact,
state, instr, mem_ctx);
}
@@ -362,8 +363,8 @@ nir_replace_instr(nir_alu_instr *instr, const
nir_search_expression *search,
instr->dest.dest.ssa.num_components, NULL);
mov->src[0] = construct_value(replace, nir_op_infos[instr->op].output_type,
- instr->dest.dest.ssa.num_components, &state,
- &instr->instr, mem_ctx);
+ instr->dest.dest.ssa.num_components,
+ instr->exact, &state, &instr->instr, mem_ctx);
nir_instr_insert_before(&instr->instr, &mov->instr);
nir_ssa_def_rewrite_uses(&instr->dest.dest.ssa,
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/9] i965/fs: Get rid of all remaining algebraic optimizations for floats
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 74 +---
1 file changed, 18 insertions(+), 56 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 365231e..9f303d5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2097,28 +2097,27 @@ fs_visitor::opt_algebraic()
bool progress = false;
foreach_block_and_inst(block, fs_inst, inst, cfg) {
- switch (inst->opcode) {
- case BRW_OPCODE_MOV:
- if (inst->src[0].file != IMM)
-break;
-
- if (inst->saturate) {
-if (inst->dst.type != inst->src[0].type)
- assert(!"unimplemented: saturate mixed types");
+ /* We don't want to do any float algebraic optimizations in the backend
+ * because they aren't bit-for-bit safe and the backend doesn't know
+ * when a value is declared precise or invariant.
+ */
+ if (inst->dst.type == BRW_REGISTER_TYPE_F)
+ continue;
-if (brw_saturate_immediate(inst->dst.type,
- &inst->src[0].as_brw_reg())) {
- inst->saturate = false;
- progress = true;
-}
- }
- break;
+ bool has_float_src = false;
+ for (unsigned i = 0; i < inst->sources; i++) {
+ if (inst->src[i].type == BRW_REGISTER_TYPE_F)
+has_float_src = true;
+ }
+ if (has_float_src)
+ continue;
+ switch (inst->opcode) {
case BRW_OPCODE_MUL:
if (inst->src[1].file != IMM)
continue;
-/* a * 1.0 = a */
+/* a * 1 = a */
if (inst->src[1].is_one()) {
inst->opcode = BRW_OPCODE_MOV;
inst->src[1] = reg_undef;
@@ -2126,7 +2125,7 @@ fs_visitor::opt_algebraic()
break;
}
- /* a * -1.0 = -a */
+ /* a * -1 = -a */
if (inst->src[1].is_negative_one()) {
inst->opcode = BRW_OPCODE_MOV;
inst->src[0].negate = !inst->src[0].negate;
@@ -2135,7 +2134,7 @@ fs_visitor::opt_algebraic()
break;
}
- /* a * 0.0 = 0.0 */
+ /* a * 0 = 0 */
if (inst->src[1].is_zero()) {
inst->opcode = BRW_OPCODE_MOV;
inst->src[0] = inst->src[1];
@@ -2157,7 +2156,7 @@ fs_visitor::opt_algebraic()
if (inst->src[1].file != IMM)
continue;
- /* a + 0.0 = a */
+ /* a + 0 = a */
if (inst->src[1].is_zero()) {
inst->opcode = BRW_OPCODE_MOV;
inst->src[1] = reg_undef;
@@ -2182,16 +2181,6 @@ fs_visitor::opt_algebraic()
break;
}
break;
- case BRW_OPCODE_LRP:
- if (inst->src[1].equals(inst->src[2])) {
-inst->opcode = BRW_OPCODE_MOV;
-inst->src[0] = inst->src[1];
-inst->src[1] = reg_undef;
-inst->src[2] = reg_undef;
-progress = true;
-break;
- }
- break;
case BRW_OPCODE_CMP:
if (inst->conditional_mod == BRW_CONDITIONAL_GE &&
inst->src[0].abs &&
@@ -2213,33 +2202,6 @@ fs_visitor::opt_algebraic()
progress = true;
}
break;
- case BRW_OPCODE_MAD:
- if (inst->src[1].is_zero() || inst->src[2].is_zero()) {
-inst->opcode = BRW_OPCODE_MOV;
-inst->src[1] = reg_undef;
-inst->src[2] = reg_undef;
-progress = true;
- } else if (inst->src[0].is_zero()) {
-inst->opcode = BRW_OPCODE_MUL;
-inst->src[0] = inst->src[2];
-inst->src[2] = reg_undef;
-progress = true;
- } else if (inst->src[1].is_one()) {
-inst->opcode = BRW_OPCODE_ADD;
-inst->src[1] = inst->src[2];
-inst->src[2] = reg_undef;
-progress = true;
- } else if (inst->src[2].is_one()) {
-inst->opcode = BRW_OPCODE_ADD;
-inst->src[2] = reg_undef;
-progress = true;
- } else if (inst->src[1].file == IMM && inst->src[2].file == IMM) {
-inst->opcode = BRW_OPCODE_ADD;
-inst->src[1].f *= inst->src[2].f;
-inst->src[2] = reg_undef;
-progress = true;
- }
- break;
case SHADER_OPCODE_BROADCAST:
if (is_uniform(inst->src[0])) {
inst->opcode = BRW_OPCODE_MOV;
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/9] i965/fs: Remove the RCP+RSQ peephole
On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand wrote:
> NIR already has this optimization and it can do much better than the little
> peephole in the backend.
>
> No shader-db change on Broadwell.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 86d2bd9..ba6ae59 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -2274,17 +2274,6 @@ fs_visitor::opt_algebraic()
> progress = true;
> }
> break;
> - case SHADER_OPCODE_RCP: {
> - fs_inst *prev = (fs_inst *)inst->prev;
> - if (prev->opcode == SHADER_OPCODE_SQRT) {
> -if (inst->src[0].equals(prev->dst)) {
> - inst->opcode = SHADER_OPCODE_RSQ;
> - inst->src[0] = prev->src[0];
> - progress = true;
> -}
> - }
> - break;
> - }
Do this in the vec4 backend as well, and with no shader-db regressions on HSW:
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 1/5] nv50, nvc0: replace resInfoCBSlot by auxCBSlot
Acked-by: Pierre Moreau
On 09:55 PM - Mar 15 2016, Samuel Pitoiset wrote:
> Having two different variables for the driver constant buffer slot
> is confusing and really useless.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 3 +--
> .../drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp| 4 ++--
> .../drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp| 12
> ++--
> src/gallium/drivers/nouveau/nouveau_compiler.c | 2 --
> src/gallium/drivers/nouveau/nv50/nv50_program.c | 1 -
> src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 4 +---
> 6 files changed, 10 insertions(+), 16 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> index 9f7d257..21523a2 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> @@ -160,7 +160,7 @@ struct nv50_ir_prog_info
>uint8_t clipDistances; /* number of clip distance outputs */
>uint8_t cullDistances; /* number of cull distance outputs */
>int8_t genUserClip;/* request user clip planes for ClipVertex
> */
> - uint8_t auxCBSlot; /* constant buffer index of UCP/draw data */
> + uint8_t auxCBSlot; /* driver constant buffer slot */
>uint16_t ucpBase; /* base address for UCPs */
>uint16_t drawInfoBase; /* base address for draw parameters */
>uint8_t pointSize; /* output index for PointSize */
> @@ -175,7 +175,6 @@ struct nv50_ir_prog_info
>uint8_t globalAccess; /* 1 for read, 2 for wr, 3 for rw */
>bool fp64; /* program uses fp64 math */
>bool nv50styleSurfaces;/* generate gX[] access for raw buffers */
> - uint8_t resInfoCBSlot; /* cX[] used for tex handles, surface info
> */
>uint16_t texBindBase; /* base address for tex handles (nve4) */
>uint16_t suInfoBase; /* base address for surface info (nve4) */
>uint16_t sampleInfoBase; /* base address for sample positions */
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
> index 12c5f69..5a46ede 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
> @@ -682,7 +682,7 @@ void NV50LoweringPreSSA::loadTexMsInfo(uint32_t off,
> Value **ms,
> Value **ms_x, Value **ms_y) {
> // This loads the texture-indexed ms setting from the constant buffer
> Value *tmp = new_LValue(func, FILE_GPR);
> - uint8_t b = prog->driver->io.resInfoCBSlot;
> + uint8_t b = prog->driver->io.auxCBSlot;
> off += prog->driver->io.suInfoBase;
> if (prog->getType() > Program::TYPE_VERTEX)
>off += 16 * 2 * 4;
> @@ -1174,7 +1174,7 @@ NV50LoweringPreSSA::handleRDSV(Instruction *i)
>bld.mkLoad(TYPE_F32,
> def,
> bld.mkSymbol(
> - FILE_MEMORY_CONST, prog->driver->io.resInfoCBSlot,
> + FILE_MEMORY_CONST, prog->driver->io.auxCBSlot,
> TYPE_U32, prog->driver->io.sampleInfoBase + 4 * idx),
> off);
>break;
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index d0936d8..d879339 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -600,7 +600,7 @@ NVC0LoweringPass::visit(BasicBlock *bb)
> inline Value *
> NVC0LoweringPass::loadTexHandle(Value *ptr, unsigned int slot)
> {
> - uint8_t b = prog->driver->io.resInfoCBSlot;
> + uint8_t b = prog->driver->io.auxCBSlot;
> uint32_t off = prog->driver->io.texBindBase + slot * 4;
> return bld.
>mkLoadv(TYPE_U32, bld.mkSymbol(FILE_MEMORY_CONST, b, TYPE_U32, off),
> ptr);
> @@ -1204,7 +1204,7 @@ NVC0LoweringPass::handleCasExch(Instruction *cas, bool
> needCctl)
> inline Value *
> NVC0LoweringPass::loadResInfo32(Value *ptr, uint32_t off)
> {
> - uint8_t b = prog->driver->io.resInfoCBSlot;
> + uint8_t b = prog->driver->io.auxCBSlot;
> off += prog->driver->io.suInfoBase;
> return bld.
>mkLoadv(TYPE_U32, bld.mkSymbol(FILE_MEMORY_CONST, b, TYPE_U32, off),
> ptr);
> @@ -1213,7 +1213,7 @@ NVC0LoweringPass::loadResInfo32(Value *ptr, uint32_t
> off)
> inline Value *
> NVC0LoweringPass::loadResInfo64(Value *ptr, uint32_t off)
> {
> - uint8_t b = prog->driver->io.resInfoCBSlot;
> + uint8_t b = prog->driver->io.auxCBSlot;
> off += prog->driver->io.suInfoBase;
>
> if (ptr)
> @@ -1226,7 +1226,7 @@ NVC0LoweringPass::loa
Re: [Mesa-dev] [PATCH] i965: Fix gl_TessLevelOuter[] for isolines.
Reviewed-by: Jordan Justen
On 2016-03-14 15:00:06, Kenneth Graunke wrote:
> Thanks to James Legg for finding this!
>
> From the ARB_tessellation_shader spec:
> "The number of isolines generated is derived from the first outer
> tessellation level; the number of segments in each isoline is
> derived from the second outer tessellation level."
>
> According to the PRM, "TF.LineDensity determines # lines" while
> "TF.LineDetail determines # segments". Line Density is stored at
> DWord 6, while Line Detail is at DWord 7. So, they're not reversed
> like they are for triangles and quads.
>
> Cc: mesa-sta...@lists.freedesktop.org
> Cc: lankyle...@gmail.com
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94524
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp | 16 +---
> src/mesa/drivers/dri/i965/brw_vec4_tes.cpp | 12 +---
> 2 files changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp
> index 8f77b59..e8bc379 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp
> @@ -402,6 +402,7 @@ vec4_tcs_visitor::nir_emit_intrinsic(nir_intrinsic_instr
> *instr)
> }
>} else if (imm_offset == 1 && indirect_offset.file == BAD_FILE) {
> dst.type = BRW_REGISTER_TYPE_F;
> + unsigned swiz = BRW_SWIZZLE_WZYX;
>
> /* This is a read of gl_TessLevelOuter[], which lives in the
>* high 4 DWords of the Patch URB header, in reverse order.
> @@ -414,6 +415,8 @@ vec4_tcs_visitor::nir_emit_intrinsic(nir_intrinsic_instr
> *instr)
> dst.writemask = WRITEMASK_XYZ;
> break;
> case GL_ISOLINES:
> +/* Isolines are not reversed; swizzle .zw -> .xy */
> +swiz = BRW_SWIZZLE_ZWZW;
> dst.writemask = WRITEMASK_XY;
> return;
> default:
> @@ -422,7 +425,7 @@ vec4_tcs_visitor::nir_emit_intrinsic(nir_intrinsic_instr
> *instr)
>
> dst_reg tmp(this, glsl_type::vec4_type);
> emit_output_urb_read(tmp, 1, src_reg());
> - emit(MOV(dst, swizzle(src_reg(tmp), BRW_SWIZZLE_WZYX)));
> + emit(MOV(dst, swizzle(src_reg(tmp), swiz)));
>} else {
> emit_output_urb_read(dst, imm_offset, indirect_offset);
>}
> @@ -475,8 +478,15 @@ vec4_tcs_visitor::nir_emit_intrinsic(nir_intrinsic_instr
> *instr)
>* Patch URB Header at DWords 4-7. However, it's reversed, so
>* instead of .xyzw we have .wzyx.
>*/
> - swiz = BRW_SWIZZLE_WZYX;
> - mask = writemask_for_backwards_vector(mask);
> + if (key->tes_primitive_mode == GL_ISOLINES) {
> +/* Isolines .xy should be stored in .zw, in order. */
> +swiz = BRW_SWIZZLE4(0, 0, 0, 1);
> +mask <<= 2;
> + } else {
> +/* Other domains are reversed; store .wzyx instead of .xyzw. */
> +swiz = BRW_SWIZZLE_WZYX;
> +mask = writemask_for_backwards_vector(mask);
> + }
>}
>
>emit_urb_write(swizzle(value, swiz), mask,
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
> index e3c23f1..7ba494f 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
> @@ -149,9 +149,15 @@ vec4_tes_visitor::nir_emit_intrinsic(nir_intrinsic_instr
> *instr)
> src_reg(brw_vec8_grf(1, 0;
>break;
> case nir_intrinsic_load_tess_level_outer:
> - emit(MOV(get_nir_dest(instr->dest, BRW_REGISTER_TYPE_F),
> - swizzle(src_reg(ATTR, 1, glsl_type::vec4_type),
> - BRW_SWIZZLE_WZYX)));
> + if (tes_prog_data->domain == BRW_TESS_DOMAIN_ISOLINE) {
> + emit(MOV(get_nir_dest(instr->dest, BRW_REGISTER_TYPE_F),
> + swizzle(src_reg(ATTR, 1, glsl_type::vec4_type),
> + BRW_SWIZZLE_ZWZW)));
> + } else {
> + emit(MOV(get_nir_dest(instr->dest, BRW_REGISTER_TYPE_F),
> + swizzle(src_reg(ATTR, 1, glsl_type::vec4_type),
> + BRW_SWIZZLE_WZYX)));
> + }
>break;
> case nir_intrinsic_load_tess_level_inner:
>if (tes_prog_data->domain == BRW_TESS_DOMAIN_QUAD) {
> --
> 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 06/12] nir/cse: Properly handle nir_ssa_def.exact
---
src/compiler/nir/nir_instr_set.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_instr_set.c b/src/compiler/nir/nir_instr_set.c
index 159ded0..00e4784 100644
--- a/src/compiler/nir/nir_instr_set.c
+++ b/src/compiler/nir/nir_instr_set.c
@@ -52,6 +52,7 @@ hash_alu(uint32_t hash, const nir_alu_instr *instr)
{
hash = HASH(hash, instr->op);
hash = HASH(hash, instr->dest.dest.ssa.num_components);
+ /* We explicitly don't hash instr->dest.dest.exact */
if (nir_op_infos[instr->op].algebraic_properties & NIR_OP_IS_COMMUTATIVE) {
assert(nir_op_infos[instr->op].num_inputs == 2);
@@ -267,6 +268,8 @@ nir_instrs_equal(const nir_instr *instr1, const nir_instr
*instr2)
if (alu1->dest.dest.ssa.num_components !=
alu2->dest.dest.ssa.num_components)
return false;
+ /* We explicitly don't hash instr->dest.dest.exact */
+
if (nir_op_infos[alu1->op].algebraic_properties & NIR_OP_IS_COMMUTATIVE)
{
assert(nir_op_infos[alu1->op].num_inputs == 2);
return (nir_alu_srcs_equal(alu1, alu2, 0, 0) &&
@@ -496,8 +499,17 @@ nir_instr_set_add_or_rewrite(struct set *instr_set,
nir_instr *instr)
struct set_entry *entry = _mesa_set_search(instr_set, instr);
if (entry) {
nir_ssa_def *def = nir_instr_get_dest_ssa_def(instr);
- nir_ssa_def *new_def =
- nir_instr_get_dest_ssa_def((nir_instr *) entry->key);
+ nir_instr *match = (nir_instr *) entry->key;
+ nir_ssa_def *new_def = nir_instr_get_dest_ssa_def(match);
+
+ /* It's safe to replace a exact instruction with an inexact one as
+ * long as we make it exact. If we got here, the two instructions are
+ * exactly identical in every other way so, once we've set the exact
+ * bit, they are the same.
+ */
+ if (instr->type == nir_instr_type_alu && nir_instr_as_alu(instr)->exact)
+ nir_instr_as_alu(match)->exact = true;
+
nir_ssa_def_rewrite_uses(def, nir_src_for_ssa(new_def));
return true;
}
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/9] i965/fs: Remove the RCP+RSQ peephole
NIR already has this optimization and it can do much better than the little
peephole in the backend.
No shader-db change on Broadwell.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 11 ---
1 file changed, 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 86d2bd9..ba6ae59 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2274,17 +2274,6 @@ fs_visitor::opt_algebraic()
progress = true;
}
break;
- case SHADER_OPCODE_RCP: {
- fs_inst *prev = (fs_inst *)inst->prev;
- if (prev->opcode == SHADER_OPCODE_SQRT) {
-if (inst->src[0].equals(prev->dst)) {
- inst->opcode = SHADER_OPCODE_RSQ;
- inst->src[0] = prev->src[0];
- progress = true;
-}
- }
- break;
- }
case SHADER_OPCODE_BROADCAST:
if (is_uniform(inst->src[0])) {
inst->opcode = BRW_OPCODE_MOV;
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] i965: Remove unneeded algebraic optimizations
On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand wrote: > This little series prepares the backend compiler for invariant and precise > by removing any potentially unsafe optimizations. The easiest > implementation for invariant and precise seems to be the same: Don't change > the semantics of invariant or precise values. This means that we need to > track what values are invariant or precise and be very careful how we > optimize them. In the backend, it's easier to just not do those > optimizations than to try and plumb that information through accurately. > Fortunately, NIR is doing a good enough job that this can be done with a > minimum of shader-db damage. > There has been some discussion on patches on the ML and in the cube as to how much we want to delete. According to my (admittedly a bit dated) shader-db, we can delete quite a lot without really hurting much. However, not everyone seems comfortable with this. I don't much care about deleting everything I just decided to try it and see what happens. Here are the things I think we do need to do: 1) Get rid of RCP+RSQ 2) Stop constant-folding RCP 3) Make opt_vector_float correct regardless of opt_algebraic handling mov.sat of immediates. I think (1) and (2) are enough for getting "invariant" and "precise" correct. The bugs in opt_vector_float I think are real, but my patches to fix them are equally bogus. The rest of the series is just deleting potentially dead code. I don't care too much either way on that. To summarize, the other potentially deletable things are: 1) the MAD optimization in fs_opt_algebraic 2) the SEL.sat optimization (both fs and vec4) 3) the trivial floating-point algebraic optimizations (most of these are probably precise-safe but they aren't doing anything) 4) MOV.sat on immediates Opinions? --Jason > Jason Ekstrand (9): > i965/fs: Remove the RCP+RSQ peephole > nir/algebraic: Add two more fsat optimizations > i965/fs: Get rid of the sel.sat peephole > i965/fs: Get rid of all remaining algebraic optimizations for floats > i965/fs: Don't constant-fold RCP > i965/vec4: Don't constant propagate saturated values > i965/vec4: Don't allow type conversion in opt_vector_float > i965/vec4: Handle saturated constants in opt_vector_float > i965/vec4: Disable algebraic optimizations on floats > > src/compiler/nir/nir_opt_algebraic.py | 2 + > src/mesa/drivers/dri/i965/brw_fs.cpp | 119 > - > .../drivers/dri/i965/brw_fs_copy_propagation.cpp | 15 --- > src/mesa/drivers/dri/i965/brw_vec4.cpp | 49 - > .../drivers/dri/i965/brw_vec4_copy_propagation.cpp | 3 + > 5 files changed, 41 insertions(+), 147 deletions(-) > > -- > 2.5.0.400.gff86faf > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/9] i965/vec4: Don't constant propagate saturated values
The FS backend bails as well.
---
src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
index 92423e1..2dfe623 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
@@ -149,6 +149,9 @@ try_constant_propagate(const struct brw_device_info
*devinfo,
if (value.file != IMM)
return false;
+ if (entry->saturatemask)
+ return false;
+
if (value.type == BRW_REGISTER_TYPE_VF) {
/* The result of bit-casting the component values of a vector float
* cannot in general be represented as an immediate.
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Work around SIN/COS output range problem.
On 16/03/16 19:33, Kenneth Graunke wrote:
The SIN and COS instructions on Intel hardware can produce values
slightly outside of the [-1.0, 1.0] range for a small set of values.
Obviously, this can break everyone's expectations about trig functions.
According to an internal presentation, the COS instruction can produce
a value up to 1.27 for inputs in the range (0.08296, 0.09888). One
suggested workaround is to multiply by 0.7, scaling down the
amplitude slightly. Apparently this also minimizes the error function,
reducing the maximum error from 0.6 to about 0.3.
I chose to apply this only when not saturating, as saturate already
clamps to 1.0. This may or may not be a good idea.
Fixes 16 dEQP precision tests
dEQP-GLES31.functional.shaders.builtin_functions.precision.
{cos,sin}.{highp,mediump}_compute.{scalar,vec2,vec4,vec4}.
at the cost of making every sin and cos call more expensive.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 26 --
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 26 --
2 files changed, 40 insertions(+), 12 deletions(-)
This has been in the Vulkan tree for a while - we needed it to pass the
Vulkan CTS, as it contains these same dEQP tests.
I haven't run shader-db yet, but I don't expect we'll like the results.
The patch is pretty sketchy, too. I'm sort of tempted to hide it behind
an INTEL_STRICT_CONFORMANCE=1 option, like we had way back in the day...
FYI, a quick run on hsw_gt2 shows -10.45% on Gputest:voplosion.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/9] i965: Remove unneeded algebraic optimizations
This little series prepares the backend compiler for invariant and precise by removing any potentially unsafe optimizations. The easiest implementation for invariant and precise seems to be the same: Don't change the semantics of invariant or precise values. This means that we need to track what values are invariant or precise and be very careful how we optimize them. In the backend, it's easier to just not do those optimizations than to try and plumb that information through accurately. Fortunately, NIR is doing a good enough job that this can be done with a minimum of shader-db damage. Jason Ekstrand (9): i965/fs: Remove the RCP+RSQ peephole nir/algebraic: Add two more fsat optimizations i965/fs: Get rid of the sel.sat peephole i965/fs: Get rid of all remaining algebraic optimizations for floats i965/fs: Don't constant-fold RCP i965/vec4: Don't constant propagate saturated values i965/vec4: Don't allow type conversion in opt_vector_float i965/vec4: Handle saturated constants in opt_vector_float i965/vec4: Disable algebraic optimizations on floats src/compiler/nir/nir_opt_algebraic.py | 2 + src/mesa/drivers/dri/i965/brw_fs.cpp | 119 - .../drivers/dri/i965/brw_fs_copy_propagation.cpp | 15 --- src/mesa/drivers/dri/i965/brw_vec4.cpp | 49 - .../drivers/dri/i965/brw_vec4_copy_propagation.cpp | 3 + 5 files changed, 41 insertions(+), 147 deletions(-) -- 2.5.0.400.gff86faf ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] mesa: simplify and inline _mesa_lookup_parameter_index()
On Thu, Mar 17, 2016 at 6:14 PM, Timothy Arceri
wrote:
> The function has only one user and strings are always null terminated.
> ---
> src/mesa/program/ir_to_mesa.cpp | 2 +-
> src/mesa/program/prog_parameter.c | 38 --
> src/mesa/program/prog_parameter.h | 19 +--
> 3 files changed, 18 insertions(+), 41 deletions(-)
>
> diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
> index 347d635..f02f406 100644
> --- a/src/mesa/program/ir_to_mesa.cpp
> +++ b/src/mesa/program/ir_to_mesa.cpp
> @@ -2359,7 +2359,7 @@ add_uniform_to_shader::visit_field(const glsl_type
> *type, const char *name,
>file = PROGRAM_UNIFORM;
> }
>
> - int index = _mesa_lookup_parameter_index(params, -1, name);
> + int index = _mesa_lookup_parameter_index(params, name);
> if (index < 0) {
>index = _mesa_add_parameter(params, file, name, size, type->gl_type,
> NULL, NULL);
> diff --git a/src/mesa/program/prog_parameter.c
> b/src/mesa/program/prog_parameter.c
> index 19b57ee..25d3835 100644
> --- a/src/mesa/program/prog_parameter.c
> +++ b/src/mesa/program/prog_parameter.c
> @@ -415,41 +415,3 @@ _mesa_add_state_reference(struct
> gl_program_parameter_list *paramList,
>
> return index;
> }
> -
> -
> -/**
> - * Given a program parameter name, find its position in the list of
> parameters.
> - * \param paramList the parameter list to search
> - * \param nameLen length of name (in chars).
> - * If length is negative, assume that name is
> null-terminated.
> - * \param name the name to search for
> - * \return index of parameter in the list.
> - */
> -GLint
> -_mesa_lookup_parameter_index(const struct gl_program_parameter_list
> *paramList,
> - GLsizei nameLen, const char *name)
> -{
> - GLint i;
> -
> - if (!paramList)
> - return -1;
> -
> - if (nameLen == -1) {
> - /* name is null-terminated */
> - for (i = 0; i < (GLint) paramList->NumParameters; i++) {
> - if (paramList->Parameters[i].Name &&
> -strcmp(paramList->Parameters[i].Name, name) == 0)
> -return i;
> - }
> - }
> - else {
> - /* name is not null-terminated, use nameLen */
> - for (i = 0; i < (GLint) paramList->NumParameters; i++) {
> - if (paramList->Parameters[i].Name &&
> -strncmp(paramList->Parameters[i].Name, name, nameLen) == 0
> - && strlen(paramList->Parameters[i].Name) == (size_t)nameLen)
> -return i;
> - }
> - }
> - return -1;
> -}
> diff --git a/src/mesa/program/prog_parameter.h
> b/src/mesa/program/prog_parameter.h
> index c17d703..002b4e8 100644
> --- a/src/mesa/program/prog_parameter.h
> +++ b/src/mesa/program/prog_parameter.h
> @@ -34,6 +34,7 @@
> #include "main/mtypes.h"
> #include "prog_statevars.h"
>
> +#include
>
> #ifdef __cplusplus
> extern "C" {
> @@ -124,9 +125,23 @@ extern GLint
> _mesa_add_state_reference(struct gl_program_parameter_list *paramList,
>const gl_state_index stateTokens[STATE_LENGTH]);
>
> -extern GLint
> +
> +static inline GLint
> _mesa_lookup_parameter_index(const struct gl_program_parameter_list
> *paramList,
> - GLsizei nameLen, const char *name);
> + const char *name)
> +{
> + if (!paramList)
> + return -1;
> +
> + /* name must be null-terminated */
> + for (GLint i = 0; i < (GLint) paramList->NumParameters; i++) {
> + if (paramList->Parameters[i].Name &&
> + strcmp(paramList->Parameters[i].Name, name) == 0)
Added a tab here.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] mesa: inline _mesa_add_unnamed_constant()
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 1/9] i965/fs: Remove the RCP+RSQ peephole
On Thu, Mar 17, 2016 at 10:45 AM, Matt Turner wrote:
> On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand
> wrote:
> > NIR already has this optimization and it can do much better than the
> little
> > peephole in the backend.
> >
> > No shader-db change on Broadwell.
> > ---
> > src/mesa/drivers/dri/i965/brw_fs.cpp | 11 ---
> > 1 file changed, 11 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > index 86d2bd9..ba6ae59 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > @@ -2274,17 +2274,6 @@ fs_visitor::opt_algebraic()
> > progress = true;
> > }
> > break;
> > - case SHADER_OPCODE_RCP: {
> > - fs_inst *prev = (fs_inst *)inst->prev;
> > - if (prev->opcode == SHADER_OPCODE_SQRT) {
> > -if (inst->src[0].equals(prev->dst)) {
> > - inst->opcode = SHADER_OPCODE_RSQ;
> > - inst->src[0] = prev->src[0];
> > - progress = true;
> > -}
> > - }
> > - break;
> > - }
>
> Do this in the vec4 backend as well, and with no shader-db regressions on
> HSW:
>
Do you want them in the same patch? The patch that disables float
opt_algebraic in vec4 does so with 0 shader-db regressions on haswell and
deletes the RCP+SQRT optimization. Seems nicer to put them together.
--Jason
> Reviewed-by: Matt Turner
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/12] nir: Add an "exact" bit to nir_alu_instr
---
src/compiler/nir/nir.h | 11 +++
src/compiler/nir/nir_clone.c | 1 +
src/compiler/nir/nir_print.c | 2 ++
3 files changed, 14 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 34f31eb..94b981b 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -671,6 +671,17 @@ extern const nir_op_info nir_op_infos[nir_num_opcodes];
typedef struct nir_alu_instr {
nir_instr instr;
nir_op op;
+
+ /** Indicates that this ALU instruction generates an exact value
+*
+* This is kind-of a mixture of GLSL "precise" and "invariant" and not
+* really equivalent to either. This indicates that the value generated by
+* this operation is high-precision and any code transformations that touch
+* it must ensure that the resulting value is bit-for-bit identical to the
+* original.
+*/
+ bool exact;
+
nir_alu_dest dest;
nir_alu_src src[];
} nir_alu_instr;
diff --git a/src/compiler/nir/nir_clone.c b/src/compiler/nir/nir_clone.c
index 198ca8b..90eefa7 100644
--- a/src/compiler/nir/nir_clone.c
+++ b/src/compiler/nir/nir_clone.c
@@ -303,6 +303,7 @@ static nir_alu_instr *
clone_alu(clone_state *state, const nir_alu_instr *alu)
{
nir_alu_instr *nalu = nir_alu_instr_create(state->ns, alu->op);
+ nalu->exact = alu->exact;
__clone_dst(state, &nalu->instr, &nalu->dest.dest, &alu->dest.dest);
nalu->dest.saturate = alu->dest.saturate;
diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
index bdfbd26..26014c1 100644
--- a/src/compiler/nir/nir_print.c
+++ b/src/compiler/nir/nir_print.c
@@ -207,6 +207,8 @@ print_alu_instr(nir_alu_instr *instr, print_state *state)
print_alu_dest(&instr->dest, state);
fprintf(fp, " = %s", nir_op_infos[instr->op].name);
+ if (instr->exact)
+ fprintf(fp, "!");
if (instr->dest.saturate)
fprintf(fp, ".sat");
fprintf(fp, " ");
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa v2 2/2] nouveau: codegen: Add support for OpenCL global memory buffers
Add support for OpenCL global memory buffers, note this has only
been tested with regular load and stores and likely needs more work
for e.g. atomic ops.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Redo on top of new "Use FILE_MEMORY_BUFFER for buffers" patch
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 7ae0cb2..a7a1d54 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -1286,7 +1286,9 @@ bool Source::scanInstruction(const struct
tgsi_full_instruction *inst)
if (dst.isIndirect(0))
indirectTempArrays.insert(dst.getArrayId());
} else
- if (dst.getFile() == TGSI_FILE_BUFFER) {
+ if (dst.getFile() == TGSI_FILE_BUFFER ||
+ (dst.getFile() == TGSI_FILE_MEMORY &&
+ memoryFiles[dst.getIndex(0)].mem_type == TGSI_MEMORY_TYPE_GLOBAL)) {
info->io.globalAccess |= 0x2;
}
}
@@ -1297,7 +1299,9 @@ bool Source::scanInstruction(const struct
tgsi_full_instruction *inst)
if (src.isIndirect(0))
indirectTempArrays.insert(src.getArrayId());
} else
- if (src.getFile() == TGSI_FILE_BUFFER) {
+ if (src.getFile() == TGSI_FILE_BUFFER ||
+ (src.getFile() == TGSI_FILE_MEMORY &&
+ memoryFiles[src.getIndex(0)].mem_type == TGSI_MEMORY_TYPE_GLOBAL)) {
info->io.globalAccess |= (insn.getOpcode() == TGSI_OPCODE_LOAD) ?
0x1 : 0x2;
} else
@@ -1531,6 +1535,10 @@ Converter::makeSym(uint tgsiFile, int fileIdx, int idx,
int c, uint32_t address)
if (tgsiFile == TGSI_FILE_MEMORY) {
switch (code->memoryFiles[fileIdx].mem_type) {
+ case TGSI_MEMORY_TYPE_GLOBAL:
+ /* No-op this is the default for TGSI_FILE_MEMORY */
+ sym->setFile(FILE_MEMORY_GLOBAL);
+ break;
case TGSI_MEMORY_TYPE_SHARED:
sym->setFile(FILE_MEMORY_SHARED);
break;
--
2.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/ir: Fix invalid bblock_t pointer dereference in dead_control_flow_eliminate.
For the first basic block in the program 'block->prev()' would return
an incorrectly cast list head sentinel and the subsequent
'prev_block->end()' dereference would read invalid memory. Introduced
in c7deee69ea6f64ea5b563985bf19d9deebe73b5b.
CC: Ian Romanick
---
src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
b/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
index 75c7be3..73aa1a9 100644
--- a/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
+++ b/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
@@ -43,9 +43,10 @@ dead_control_flow_eliminate(backend_shader *s)
bool progress = false;
foreach_block_safe (block, s->cfg) {
- bblock_t *prev_block = block->prev();
+ bblock_t *const prev_block = block->num ? block->prev() : NULL;
backend_instruction *const inst = block->start();
- backend_instruction *const prev_inst = prev_block->end();
+ backend_instruction *const prev_inst =
+ prev_block ? prev_block->end() : NULL;
/* ENDIF instructions, by definition, can only be found at the start of
* basic blocks.
--
2.7.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/nine: specify WINAPI only for i386 and amd64
Currently mesa fails building with the x32 abi as ms_abi is not defined
in such a case.
The patch uses ms_abi only for amd64 targets and stdcall only for i386
targets to be sure that those are defined.
This patch additionally checks for __GNUC__ to guarantee that
__attribute__ is available.
---
include/D3D9/d3d9types.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/D3D9/d3d9types.h b/include/D3D9/d3d9types.h
index d74ce80..e0b8652 100644
--- a/include/D3D9/d3d9types.h
+++ b/include/D3D9/d3d9types.h
@@ -178,11 +178,17 @@ typedef struct _RGNDATA {
#undef WINAPI
#endif /* WINAPI*/
-#if defined(__x86_64__) || defined(_M_X64)
-#define WINAPI __attribute__((ms_abi))
-#else /* x86_64 */
-#define WINAPI __attribute__((__stdcall__))
-#endif /* x86_64 */
+#ifdef __GNUC__
+ #if (defined(__x86_64__) && !defined(__ILP32__)) || defined(_M_X64)
+#define WINAPI __attribute__((ms_abi))
+ #elif defined(__i386) || defined(_M_IX86)
+#define WINAPI __attribute__((__stdcall__))
+ #else /* neither amd64 nor i386 */
+#define WINAPI
+ #endif
+#else /* __GNUC__ */
+ #define WINAPI
+#endif
/* Implementation caps */
#define D3DPRESENT_BACK_BUFFERS_MAX3
--
2.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50/ra: `isinf()` is in namespace `std` since C++11
On Thu, Mar 17, 2016 at 5:17 PM, Pierre Moreau wrote: > This fixes a compile error while building Nouveau with C++11 enabled (and > glibc >= 2.23). This happens if SWR is enabled, as it forces C++11. That seems bad, right? Enabling OpenSWR should affect how any other drivers are built. Why does this happen? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] lvm pipe crash under windows
Am 17.03.2016 um 01:52 schrieb Jason Anderssen: > Hi all, > > I was wondering if anyone knows of or has seen a crash when Mesa is > compiled for with LVM Pipe ? > The reason I ask is that if our user uses a compiled version of Mesa > using the slower software render, it works fine, the moment we compile > it with LVM, it crashes. > I have an api trace that shows how far it got, and a dump file if this > would be of assistance? > Also, it is only this one server that exhibits this problem from what we > have been able to discover, however it is a pretty vanilla install as it > is a production server, it is also running Terminal Services, so it is > quite tightly controlled in regards to what gets installed. > > Thanks for your help in advance. > > Cheers > Jason Anderssen > A gdb backtrace would probably be more useful. Also, what version of mesa? Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/20] radeonsi: Lower TGSI_OPCODE_LOAD down to LLVM op (v2)
From: Nicolai Hähnle
v2: new signature style for buffer intrinsics
---
I want to change the signature for buffer intrinsics while it is still
feasible to do so; the only difference with v1 is two lines that are removed
in buffer_append_args, but you'll need a new version of LLVM, which I've
pushed to https://cgit.freedesktop.org/~nh/llvm/log/?h=images
---
src/gallium/drivers/radeonsi/si_shader.c | 139 +++
1 file changed, 139 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index b655e34..32b84a8 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2761,6 +2761,143 @@ image_fetch_rsrc(
}
}
+static LLVMValueRef image_fetch_coords(
+ struct lp_build_tgsi_context *bld_base,
+ const struct tgsi_full_instruction *inst)
+{
+ struct gallivm_state *gallivm = bld_base->base.gallivm;
+ LLVMBuilderRef builder = gallivm->builder;
+ unsigned target = inst->Memory.Texture;
+ int sample;
+ unsigned num_coords = tgsi_util_get_texture_coord_dim(target, &sample);
+ LLVMValueRef coords[4];
+ LLVMValueRef tmp;
+ int chan;
+
+ for (chan = 0; chan < num_coords; ++chan) {
+ tmp = lp_build_emit_fetch(bld_base, inst, 1, chan);
+ tmp = LLVMBuildBitCast(builder, tmp,
bld_base->uint_bld.elem_type, "");
+ coords[chan] = tmp;
+ }
+
+ if (num_coords == 1)
+ return coords[0];
+
+ if (num_coords == 3) {
+ /* LLVM has difficulties lowering 3-element vectors. */
+ coords[3] = bld_base->uint_bld.undef;
+ num_coords = 4;
+ }
+
+ return lp_build_gather_values(gallivm, coords, num_coords);
+}
+
+/**
+ * Append the extra mode bits that are used by image load and store.
+ */
+static void image_append_args(
+ struct si_shader_context *ctx,
+ struct lp_build_emit_data * emit_data,
+ unsigned target)
+{
+ LLVMValueRef i1false = LLVMConstInt(ctx->i1, 0, 0);
+ LLVMValueRef i1true = LLVMConstInt(ctx->i1, 1, 0);
+
+ emit_data->args[emit_data->arg_count++] = i1false; /* r128 */
+ emit_data->args[emit_data->arg_count++] =
+ tgsi_is_array_image(target) ? i1true : i1false; /* da */
+ emit_data->args[emit_data->arg_count++] = i1false; /* glc */
+ emit_data->args[emit_data->arg_count++] = i1false; /* slc */
+}
+
+/**
+ * Append the resource and indexing arguments for buffer intrinsics.
+ *
+ * \param rsrc the 256 bit resource
+ * \param index index into the buffer
+ */
+static void buffer_append_args(
+ struct si_shader_context *ctx,
+ struct lp_build_emit_data *emit_data,
+ LLVMValueRef rsrc,
+ LLVMValueRef index)
+{
+ struct gallivm_state *gallivm = &ctx->radeon_bld.gallivm;
+ struct lp_build_tgsi_context *bld_base = &ctx->radeon_bld.soa.bld_base;
+ LLVMTypeRef v2i128 = LLVMVectorType(ctx->i128, 2);
+ LLVMValueRef i1false = LLVMConstInt(ctx->i1, 0, 0);
+
+ rsrc = LLVMBuildBitCast(gallivm->builder, rsrc, v2i128, "");
+ rsrc = LLVMBuildExtractElement(gallivm->builder, rsrc,
bld_base->uint_bld.one, "");
+ rsrc = LLVMBuildBitCast(gallivm->builder, rsrc, ctx->v4i32, "");
+
+ emit_data->args[emit_data->arg_count++] = rsrc;
+ emit_data->args[emit_data->arg_count++] = index; /* vindex */
+ emit_data->args[emit_data->arg_count++] = bld_base->uint_bld.zero; /*
voffset */
+ emit_data->args[emit_data->arg_count++] = i1false; /* glc */
+ emit_data->args[emit_data->arg_count++] = i1false; /* slc */
+}
+
+static void load_fetch_args(
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+ struct si_shader_context *ctx = si_shader_context(bld_base);
+ struct gallivm_state *gallivm = bld_base->base.gallivm;
+ const struct tgsi_full_instruction * inst = emit_data->inst;
+ unsigned target = inst->Memory.Texture;
+ LLVMValueRef coords;
+ LLVMValueRef rsrc;
+
+ emit_data->dst_type = LLVMVectorType(bld_base->base.elem_type, 4);
+
+ image_fetch_rsrc(bld_base, &inst->Src[0], &rsrc);
+ coords = image_fetch_coords(bld_base, inst);
+
+ if (target == TGSI_TEXTURE_BUFFER) {
+ buffer_append_args(ctx, emit_data, rsrc, coords);
+ } else {
+ emit_data->args[0] = coords;
+ emit_data->args[1] = rsrc;
+ emit_data->args[2] = lp_build_const_int32(gallivm, 15); /*
dmask */
+ emit_data->arg_count = 3;
+
+ image_append_args(ctx, emit_data, target);
+ }
+}
+
+static void load_emit(
+ const struct lp_build_tgsi_action *action,
+ struct lp_build_tgsi_context *bld_base,
+
[Mesa-dev] [PATCH 4/4] st/mesa: clean up st_translate_texture_target()
Reformat code. Improve assertion.
---
src/mesa/state_tracker/st_mesa_to_tgsi.c | 69
1 file changed, 44 insertions(+), 25 deletions(-)
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index 8772efb..8a12ce4 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -241,37 +241,56 @@ src_register( struct st_translate *t,
* Map mesa texture target to TGSI texture target.
*/
unsigned
-st_translate_texture_target( GLuint textarget,
- GLboolean shadow )
+st_translate_texture_target(GLuint textarget, GLboolean shadow)
{
if (shadow) {
- switch( textarget ) {
- case TEXTURE_1D_INDEX: return TGSI_TEXTURE_SHADOW1D;
- case TEXTURE_2D_INDEX: return TGSI_TEXTURE_SHADOW2D;
- case TEXTURE_RECT_INDEX: return TGSI_TEXTURE_SHADOWRECT;
- case TEXTURE_1D_ARRAY_INDEX: return TGSI_TEXTURE_SHADOW1D_ARRAY;
- case TEXTURE_2D_ARRAY_INDEX: return TGSI_TEXTURE_SHADOW2D_ARRAY;
- case TEXTURE_CUBE_INDEX: return TGSI_TEXTURE_SHADOWCUBE;
- case TEXTURE_CUBE_ARRAY_INDEX: return TGSI_TEXTURE_SHADOWCUBE_ARRAY;
- default: break;
+ switch (textarget) {
+ case TEXTURE_1D_INDEX:
+ return TGSI_TEXTURE_SHADOW1D;
+ case TEXTURE_2D_INDEX:
+ return TGSI_TEXTURE_SHADOW2D;
+ case TEXTURE_RECT_INDEX:
+ return TGSI_TEXTURE_SHADOWRECT;
+ case TEXTURE_1D_ARRAY_INDEX:
+ return TGSI_TEXTURE_SHADOW1D_ARRAY;
+ case TEXTURE_2D_ARRAY_INDEX:
+ return TGSI_TEXTURE_SHADOW2D_ARRAY;
+ case TEXTURE_CUBE_INDEX:
+ return TGSI_TEXTURE_SHADOWCUBE;
+ case TEXTURE_CUBE_ARRAY_INDEX:
+ return TGSI_TEXTURE_SHADOWCUBE_ARRAY;
+ default:
+ break;
}
}
- switch( textarget ) {
- case TEXTURE_2D_MULTISAMPLE_INDEX: return TGSI_TEXTURE_2D_MSAA;
- case TEXTURE_2D_MULTISAMPLE_ARRAY_INDEX: return TGSI_TEXTURE_2D_ARRAY_MSAA;
- case TEXTURE_BUFFER_INDEX: return TGSI_TEXTURE_BUFFER;
- case TEXTURE_1D_INDEX: return TGSI_TEXTURE_1D;
- case TEXTURE_2D_INDEX: return TGSI_TEXTURE_2D;
- case TEXTURE_3D_INDEX: return TGSI_TEXTURE_3D;
- case TEXTURE_CUBE_INDEX: return TGSI_TEXTURE_CUBE;
- case TEXTURE_CUBE_ARRAY_INDEX: return TGSI_TEXTURE_CUBE_ARRAY;
- case TEXTURE_RECT_INDEX: return TGSI_TEXTURE_RECT;
- case TEXTURE_1D_ARRAY_INDEX: return TGSI_TEXTURE_1D_ARRAY;
- case TEXTURE_2D_ARRAY_INDEX: return TGSI_TEXTURE_2D_ARRAY;
- case TEXTURE_EXTERNAL_INDEX: return TGSI_TEXTURE_2D;
+ switch (textarget) {
+ case TEXTURE_2D_MULTISAMPLE_INDEX:
+ return TGSI_TEXTURE_2D_MSAA;
+ case TEXTURE_2D_MULTISAMPLE_ARRAY_INDEX:
+ return TGSI_TEXTURE_2D_ARRAY_MSAA;
+ case TEXTURE_BUFFER_INDEX:
+ return TGSI_TEXTURE_BUFFER;
+ case TEXTURE_1D_INDEX:
+ return TGSI_TEXTURE_1D;
+ case TEXTURE_2D_INDEX:
+ return TGSI_TEXTURE_2D;
+ case TEXTURE_3D_INDEX:
+ return TGSI_TEXTURE_3D;
+ case TEXTURE_CUBE_INDEX:
+ return TGSI_TEXTURE_CUBE;
+ case TEXTURE_CUBE_ARRAY_INDEX:
+ return TGSI_TEXTURE_CUBE_ARRAY;
+ case TEXTURE_RECT_INDEX:
+ return TGSI_TEXTURE_RECT;
+ case TEXTURE_1D_ARRAY_INDEX:
+ return TGSI_TEXTURE_1D_ARRAY;
+ case TEXTURE_2D_ARRAY_INDEX:
+ return TGSI_TEXTURE_2D_ARRAY;
+ case TEXTURE_EXTERNAL_INDEX:
+ return TGSI_TEXTURE_2D;
default:
- debug_assert( 0 );
+ debug_assert(!"unexpected texture target index");
return TGSI_TEXTURE_1D;
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] i965/vec4: Handle saturated constants in opt_vector_float
On Thu, Mar 17, 2016 at 11:55 AM, Matt Turner wrote:
> On Thu, Mar 17, 2016 at 11:52 AM, Jason Ekstrand
> wrote:
> >
> >
> > On Thu, Mar 17, 2016 at 11:18 AM, Matt Turner
> wrote:
> >>
> >> On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand
> >> wrote:
> >> > ---
> >> > src/mesa/drivers/dri/i965/brw_vec4.cpp | 8 +++-
> >> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> > b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> > index 155a550..02a00b3 100644
> >> > --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> > +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> > @@ -384,7 +384,13 @@ vec4_visitor::opt_vector_float()
> >> > continue;
> >> >}
> >> >
> >> > - int vf = brw_float_to_vf(inst->src[0].f);
> >> > + float f = inst->src[0].f;
> >> > + if (inst->saturate) {
> >> > + assert(inst->dst.type == BRW_REGISTER_TYPE_F);
> >> > + f = CLAMP(f, 0.0f, 1.0f);
> >> > + }
> >> > +
> >> > + int vf = brw_float_to_vf(f);
> >> >if (vf == -1)
> >> > continue;
> >>
> >> Presumably the previous patch is to allow this to happen without
> >> thinking about types.
> >>
> >> This does look like a legitimate bug fix, but what does this fix or
> >> enable?
> >
> >
> > Patch 9 removes the mov.sat optimization from opt_algebraic which was
> fixing
> > up saturated constants before opt_vector_float ever saw them. When I
> > removed it, I got a bunch of piglit fails from things that were writing
> > out-of-bounds constant values to auto-clampped outputs. The problem was
> > that opt_vector_float was just throwing the .sat away.
>
> Oh, so this isn't even a legitimate bug fix unless you remove the code
> this relies on...
>
> Just keep the saturating code in opt_algebraic. Why would we remove it...?
>
Should we be trusting in opt_algebraic for correctness? That doesn't seem
right.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Set address rounding bits for GL_NEAREST filtering as well.
On Thu, Mar 17, 2016 at 4:42 PM, Jordan Justen
wrote:
> On 2016-03-17 01:04:27, Kenneth Graunke wrote:
> > Yuanhan Liu decided these were useful for linear filtering in
> > commit 76669381 (circa 2011). Prior to that, we never set them;
> > it seems he tried to preserve that behavior for nearest filtering.
> >
> > It turns out they're useful for nearest filtering, too: setting
> > these fixes the following dEQP-GLES3 tests:
> >
> > functional.fbo.blit.rect.nearest_consistency_mag
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_x
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_y
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_x
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_y
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_x
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_y
> > functional.fbo.blit.rect.nearest_consistency_min
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_x
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_y
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_x
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_y
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_x
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_y
> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_x
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_y
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_x
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_y
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_x
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_y
> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_x
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_y
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_x
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_y
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_x
> >
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_y
> >
> > Apparently, BLORP has always set these bits unconditionally.
> >
> > However, setting them unconditionally appears to regress tests using
> > texture projection, 3D samplers, integer formats, and vertex shaders,
> > all in combination, such as:
> >
> > functional.shaders.texture_functions.textureprojlod.isampler3d_vertex
> >
> > Setting them on Gen4-5 appears to regress Piglit's
> > tests/spec/arb_sampler_objects/framebufferblit.
> >
> > Honestly, it looks like the real problem here is a lack of precision.
> > I'm just hacking around problems here (as embarassing as it is).
> >
> > Signed-off-by: Kenneth Graunke
> > ---
> > src/mesa/drivers/dri/i965/brw_sampler_state.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_sampler_state.c
> b/src/mesa/drivers/dri/i965/brw_sampler_state.c
> > index c20a028..d53cb5d 100644
> > --- a/src/mesa/drivers/dri/i965/brw_sampler_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_sampler_state.c
> > @@ -436,14 +436,17 @@ brw_update_sampler_state(struct brw_context *brw,
> >}
> > }
> >
> > - /* Set address rounding bits if not using nearest filtering. */
> > + /* Set address rounding bits. The conditions are empirically
> > +* derived in order to pass test cases.
> > +*/
> > + bool round_nearest = brw->gen >= 6 && target != GL_TEXTURE_3D;
> > unsigned address_rounding = 0;
> > - if (min_filter != BRW_MAPFILTER_NEAREST) {
> > + if (min_filter != BRW_MAPFILTER_NEAREST || round_nearest) {
>
I feel the need to state, for the record, that this is super-sketchy. Then
again, given that GL doesn't really specify what we're supposed to do on
the edges of a NEAREST sampling, it doesn't much matter. That's explcitly
*not* a NAK, just a comment on the sketcyness of the whole thing.
I don't think it's too sketchy to merge, but it may be a good candidate for
the "pass dEQP" branch?
>
> How about folding the min_filter != BRW_MAPFILTER_NEAREST test into
> round_nearest?
>
> Reviewed-by: Jordan Justen
>
> >address_rounding |= BRW_ADDRESS_ROUNDING_ENABLE_U_MIN |
> >BRW_ADDRESS_ROUNDING_ENABLE_V_MIN |
> >BRW_ADDRESS_ROUNDING_ENABLE_R_MIN;
> > }
> > - if (mag_filter != BRW_MAPFILTER_NEAREST) {
> > + if (mag_filter != BRW_MAPFILTER_NEAREST || round_nearest) {
> >address_rounding |= BRW_ADDRESS_ROUNDING_ENABLE_U_MAG |
> >
Re: [Mesa-dev] [PATCH 3/9] i965/fs: Get rid of the sel.sat peephole
Matt Turner writes: > On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand wrote: >> Shader-db results on Broadwell: >> >> total instructions in shared programs: 7517815 -> 7517816 (0.00%) >> instructions in affected programs: 46 -> 47 (2.17%) >> HURT: 1 >> >> The one hurt shader is a shader from "The Swapper" that writes to >> gl_FrontColor and, as such, gets an implicit sat added to the output write. >> Since this is invisible to NIR, the optimization in the previous commit >> can't fix it for us. >> --- > > How could this possibly cause problems? I don't understand why you're > trying to remove it. Yeah, this optimization seems invariant- and precise-safe modulo the handling of NaNs in the src[1] >= 1.0 case (the <= 0 case is NaN and denorm-correct AFAICT because MOV.sat flushes them to zero just like 'SEL.sat.g(e) x, 0'), and it seems moderately useful, not sure it's a good plan to just get rid of it. > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Best way to create a debug version of Mesa
Hi, This is probably a very simple question I hope, using scons, what is the easiest way to create a debug build, the Doc on the website I think only refers to Make-Config ? I am also cross compiling for windows. Cheers and thanks again in advance. Jason Internet Email Confidentiality Footer: This email and any files transmitted with it contain privileged/confidential information intended for the addressee. Neither the confidentiality of nor any privilege in the email is waived, lost or destroyed by reason that it has been transmitted other than to the addressee. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: remove remaining tabs in prog_parameter.c
---
src/mesa/program/prog_parameter.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/mesa/program/prog_parameter.c
b/src/mesa/program/prog_parameter.c
index 470c98e..02d84f2 100644
--- a/src/mesa/program/prog_parameter.c
+++ b/src/mesa/program/prog_parameter.c
@@ -147,17 +147,17 @@ _mesa_new_parameter_list_sized(unsigned size)
/* alloc arrays */
p->Parameters = (struct gl_program_parameter *)
-calloc(size, sizeof(struct gl_program_parameter));
+ calloc(size, sizeof(struct gl_program_parameter));
p->ParameterValues = (gl_constant_value (*)[4])
_mesa_align_malloc(size * 4 *sizeof(gl_constant_value), 16);
if ((p->Parameters == NULL) || (p->ParameterValues == NULL)) {
-free(p->Parameters);
-_mesa_align_free(p->ParameterValues);
-free(p);
-p = NULL;
+ free(p->Parameters);
+ _mesa_align_free(p->ParameterValues);
+ free(p);
+ p = NULL;
}
}
@@ -284,7 +284,7 @@ _mesa_add_parameter(struct gl_program_parameter_list
*paramList,
else {
/* silence valgrind */
for (j = 0; j < 4; j++)
- paramList->ParameterValues[oldNum + i][j].f = 0;
+ paramList->ParameterValues[oldNum + i][j].f = 0;
}
size -= 4;
}
@@ -377,8 +377,8 @@ _mesa_add_state_reference(struct gl_program_parameter_list
*paramList,
/* Check if the state reference is already in the list */
for (index = 0; index < (GLint) paramList->NumParameters; index++) {
if (!memcmp(paramList->Parameters[index].StateIndexes,
- stateTokens, STATE_LENGTH * sizeof(gl_state_index))) {
-return index;
+ stateTokens, STATE_LENGTH * sizeof(gl_state_index))) {
+ return index;
}
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] nir: Add an "exact" bit to nir_alu_instr
On Thu, Mar 17, 2016 at 6:10 PM, Matt Turner wrote:
> On Thu, Mar 17, 2016 at 5:51 PM, Jason Ekstrand
> wrote:
> > ---
> > src/compiler/nir/nir.h | 11 +++
> > src/compiler/nir/nir_clone.c | 1 +
> > src/compiler/nir/nir_print.c | 2 ++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> > index 34f31eb..94b981b 100644
> > --- a/src/compiler/nir/nir.h
> > +++ b/src/compiler/nir/nir.h
> > @@ -671,6 +671,17 @@ extern const nir_op_info
> nir_op_infos[nir_num_opcodes];
> > typedef struct nir_alu_instr {
> > nir_instr instr;
> > nir_op op;
> > +
> > + /** Indicates that this ALU instruction generates an exact value
> > +*
> > +* This is kind-of a mixture of GLSL "precise" and "invariant" and
> not
>
> "kind of" isn't hyphenated.
>
Thanks
> > +* really equivalent to either. This indicates that the value
> generated by
> > +* this operation is high-precision and any code transformations
> that touch
> > +* it must ensure that the resulting value is bit-for-bit identical
> to the
> > +* original.
>
> I think this is a lot of the problem -- we don't seem to have a good
> idea of what these keywords mean, concretely.
>
> Precise is more clear to me: don't optimize things in such a way as to
> change the result.
>
> Invariant is much less clear to me though. I've read the GLSL spec of
> course, but can someone give me an example?
>
The best docs I've found are in the ES 3.2 spec. Basically it means that
you're allowed to optimize it in an imprecise way as long as you always
optimize the computation exactly the same way. One of the places this gets
us in trouble is in the fma peephole where we decide whether to fuse a
mul+add or not based on how many users the add has and if they're all mul.
This means that if we have a mul+add in an invariant expression and
another, unrelated, user of the mul, it won't get fused. If you dead-code
the other unrelated user of the mul, things change and we fuse them. This
is the kind of thing that's not allowed. Does that make more sense?
Unfortunately, invariant is horrifically difficult to think about. It's
much easier to just implement it as precise which is also a valid way to do
it.
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa v2 3/3] gallium: Remove unused TGSI_RESOURCE_ defines
These magic file-index defines where only ever used in the nouveau code
and that no longer uses them.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Split out of "nouveau: codegen: Disable more old resource handling code"
---
src/gallium/include/pipe/p_shader_tokens.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index 65d8ad9..5ef6c30 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -237,15 +237,6 @@ struct tgsi_declaration_array {
unsigned Padding : 22;
};
-/*
- * Special resources that don't need to be declared. They map to the
- * GLOBAL/LOCAL/PRIVATE/INPUT compute memory spaces.
- */
-#define TGSI_RESOURCE_GLOBAL 0x7fff
-#define TGSI_RESOURCE_LOCAL0x7ffe
-#define TGSI_RESOURCE_PRIVATE 0x7ffd
-#define TGSI_RESOURCE_INPUT0x7ffc
-
#define TGSI_IMM_FLOAT32 0
#define TGSI_IMM_UINT321
#define TGSI_IMM_INT32 2
--
2.7.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] st/mesa: clean up st_translate_texture_target()
For the series:
Reviewed-by: Charmaine Lee
From: Brian Paul
Sent: Wednesday, March 16, 2016 5:43 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee
Subject: [PATCH 4/4] st/mesa: clean up st_translate_texture_target()
Reformat code. Improve assertion.
---
src/mesa/state_tracker/st_mesa_to_tgsi.c | 69
1 file changed, 44 insertions(+), 25 deletions(-)
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index 8772efb..8a12ce4 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -241,37 +241,56 @@ src_register( struct st_translate *t,
* Map mesa texture target to TGSI texture target.
*/
unsigned
-st_translate_texture_target( GLuint textarget,
- GLboolean shadow )
+st_translate_texture_target(GLuint textarget, GLboolean shadow)
{
if (shadow) {
- switch( textarget ) {
- case TEXTURE_1D_INDEX: return TGSI_TEXTURE_SHADOW1D;
- case TEXTURE_2D_INDEX: return TGSI_TEXTURE_SHADOW2D;
- case TEXTURE_RECT_INDEX: return TGSI_TEXTURE_SHADOWRECT;
- case TEXTURE_1D_ARRAY_INDEX: return TGSI_TEXTURE_SHADOW1D_ARRAY;
- case TEXTURE_2D_ARRAY_INDEX: return TGSI_TEXTURE_SHADOW2D_ARRAY;
- case TEXTURE_CUBE_INDEX: return TGSI_TEXTURE_SHADOWCUBE;
- case TEXTURE_CUBE_ARRAY_INDEX: return TGSI_TEXTURE_SHADOWCUBE_ARRAY;
- default: break;
+ switch (textarget) {
+ case TEXTURE_1D_INDEX:
+ return TGSI_TEXTURE_SHADOW1D;
+ case TEXTURE_2D_INDEX:
+ return TGSI_TEXTURE_SHADOW2D;
+ case TEXTURE_RECT_INDEX:
+ return TGSI_TEXTURE_SHADOWRECT;
+ case TEXTURE_1D_ARRAY_INDEX:
+ return TGSI_TEXTURE_SHADOW1D_ARRAY;
+ case TEXTURE_2D_ARRAY_INDEX:
+ return TGSI_TEXTURE_SHADOW2D_ARRAY;
+ case TEXTURE_CUBE_INDEX:
+ return TGSI_TEXTURE_SHADOWCUBE;
+ case TEXTURE_CUBE_ARRAY_INDEX:
+ return TGSI_TEXTURE_SHADOWCUBE_ARRAY;
+ default:
+ break;
}
}
- switch( textarget ) {
- case TEXTURE_2D_MULTISAMPLE_INDEX: return TGSI_TEXTURE_2D_MSAA;
- case TEXTURE_2D_MULTISAMPLE_ARRAY_INDEX: return TGSI_TEXTURE_2D_ARRAY_MSAA;
- case TEXTURE_BUFFER_INDEX: return TGSI_TEXTURE_BUFFER;
- case TEXTURE_1D_INDEX: return TGSI_TEXTURE_1D;
- case TEXTURE_2D_INDEX: return TGSI_TEXTURE_2D;
- case TEXTURE_3D_INDEX: return TGSI_TEXTURE_3D;
- case TEXTURE_CUBE_INDEX: return TGSI_TEXTURE_CUBE;
- case TEXTURE_CUBE_ARRAY_INDEX: return TGSI_TEXTURE_CUBE_ARRAY;
- case TEXTURE_RECT_INDEX: return TGSI_TEXTURE_RECT;
- case TEXTURE_1D_ARRAY_INDEX: return TGSI_TEXTURE_1D_ARRAY;
- case TEXTURE_2D_ARRAY_INDEX: return TGSI_TEXTURE_2D_ARRAY;
- case TEXTURE_EXTERNAL_INDEX: return TGSI_TEXTURE_2D;
+ switch (textarget) {
+ case TEXTURE_2D_MULTISAMPLE_INDEX:
+ return TGSI_TEXTURE_2D_MSAA;
+ case TEXTURE_2D_MULTISAMPLE_ARRAY_INDEX:
+ return TGSI_TEXTURE_2D_ARRAY_MSAA;
+ case TEXTURE_BUFFER_INDEX:
+ return TGSI_TEXTURE_BUFFER;
+ case TEXTURE_1D_INDEX:
+ return TGSI_TEXTURE_1D;
+ case TEXTURE_2D_INDEX:
+ return TGSI_TEXTURE_2D;
+ case TEXTURE_3D_INDEX:
+ return TGSI_TEXTURE_3D;
+ case TEXTURE_CUBE_INDEX:
+ return TGSI_TEXTURE_CUBE;
+ case TEXTURE_CUBE_ARRAY_INDEX:
+ return TGSI_TEXTURE_CUBE_ARRAY;
+ case TEXTURE_RECT_INDEX:
+ return TGSI_TEXTURE_RECT;
+ case TEXTURE_1D_ARRAY_INDEX:
+ return TGSI_TEXTURE_1D_ARRAY;
+ case TEXTURE_2D_ARRAY_INDEX:
+ return TGSI_TEXTURE_2D_ARRAY;
+ case TEXTURE_EXTERNAL_INDEX:
+ return TGSI_TEXTURE_2D;
default:
- debug_assert( 0 );
+ debug_assert(!"unexpected texture target index");
return TGSI_TEXTURE_1D;
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] EXTENDED: 2016 X.Org Board of Directors Elections Nomination period is NOW
We had a number of last-minute nominations and this did not give all nominees the chance to respond to the nominations. Hence, we are extending the nomination period for two weeks. All election dates thus move back by two weeks. Below is the original text of the nomination request email. We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2016 election are now open and will remain open until 23:59 UTC on 29 March 2016. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2015 were Peter Hutterer, Martin Peres, Rob Clark and Daniel Vetter, They will continue to serve until their term ends in 2017. Current directors whose term expires in 2016 are Alex Deucher, Matt Dew, Egbert Eich and Keith Packard. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at electi...@x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the members account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23:59 UTC on 15 March 2016. The slate of candidates will be published 31 March 2016 and candidate Q&A will begin then. The deadline for Xorg membership applications and renewals is 31 March 2016. Cheers, Peter, on behalf of the X.Org BoD signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] mesa: remove unused function
---
src/mesa/program/prog_parameter.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/src/mesa/program/prog_parameter.h
b/src/mesa/program/prog_parameter.h
index c04d7a2..acc5b6c 100644
--- a/src/mesa/program/prog_parameter.h
+++ b/src/mesa/program/prog_parameter.h
@@ -99,12 +99,6 @@ _mesa_new_parameter_list_sized(unsigned size);
extern void
_mesa_free_parameter_list(struct gl_program_parameter_list *paramList);
-static inline GLuint
-_mesa_num_parameters(const struct gl_program_parameter_list *list)
-{
- return list ? list->NumParameters : 0;
-}
-
extern void
_mesa_reserve_parameter_storage(struct gl_program_parameter_list *paramList,
unsigned reserve_slots);
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 17/17] GL3.txt: Mark ARB_framebuffer_no_attachments as done
Edward O'Callaghan wrote on 19.03.2016 07:41: > Signed-off-by: Edward O'Callaghan > --- > docs/GL3.txt | 2 +- > docs/relnotes/11.3.0.html | 1 + > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/docs/GL3.txt b/docs/GL3.txt > index 3058996..b9fc86b 100644 > --- a/docs/GL3.txt > +++ b/docs/GL3.txt > @@ -172,7 +172,7 @@ GL 4.3, GLSL 4.30: >GL_KHR_debug DONE (all drivers) >GL_ARB_explicit_uniform_location DONE (all drivers > that support GLSL) >GL_ARB_fragment_layer_viewportDONE (i965, nv50, > nvc0, r600, radeonsi, llvmpipe) > - GL_ARB_framebuffer_no_attachments DONE (i965) > + GL_ARB_framebuffer_no_attachments DONE (i965, nvc0, > r600, radeonsi) >GL_ARB_internalformat_query2 DONE (i965) >GL_ARB_invalidate_subdata DONE (all drivers) >GL_ARB_multi_draw_indirectDONE (i965, nvc0, > r600, radeonsi, llvmpipe, softpipe) Should this also update the GL_ARB_framebuffer_no_attachments line in the OpenGL ES 3.1 section? Or is more work needed for that? In the latter case a small comment in the commit message might be nice. Cheers, Kai signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] st/mesa, radeonsi: some MemoryBarrier fixes
Hi Nicolai, This series is, Reviewed-by: Edward O'Callaghan Thanks, On 2016-03-19 14:37, Nicolai Hähnle wrote: Hi, these patches apply on top of my ARB_shader_image_load_store series. Together, they fix a few remaining fails with piglit's arb_shader_image_load_store-host-mem-barrier. You can see them in context at https://cgit.freedesktop.org/~nh/mesa/log/?h=ssbo The basic assumption for how barrier bits are translated is that each Gallium object / binding point has its own PIPE_BARRIER_* bit, but the driver will automatically do the necessary invalidations/flushes for transfers and blit-type operations, as well as when the framebuffer state is changed. This is still very tricky stuff to get right, but at least I think it's shaping up nicely for radeonsi, as evidenced by the fact that the host-mem-barrier test passes (and the control subtests also show that what we're doing here isn't just a no-op). Please review! Thanks, Nicolai --- src/gallium/drivers/radeonsi/si_state.c | 7 +++-- src/gallium/include/pipe/p_defines.h | 1 + .../state_tracker/st_cb_texturebarrier.c | 25 +- 3 files changed, 30 insertions(+), 3 deletions(-) ___ 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/4] st/mesa: emit sampler view decls in PBO upload shader
On Thu, Mar 17, 2016 at 12:47 PM, Nicolai Hähnle wrote: > On 16.03.2016 19:43, Brian Paul wrote: >> >> The return type is float, which is what was implicitly used before, >> AFAICT. > > > Isn't this technically incorrect when the uploaded texture is integer? > > To be honest, it's not really clear to me what the return type is supposed > to mean. I don't think any of the hardware drivers uses it. Adreno has different texture instructions depending on the desired return type. If you use a float return type on an int texture, you will get a floating point value of that integer (i.e. if the actual textured value were 100, you'd get 100.0f returned if you did sam.f32). -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 17/17] GL3.txt: Mark ARB_framebuffer_no_attachments as done
On 2016-03-19 21:08, Kai Wasserbäch wrote: Edward O'Callaghan wrote on 19.03.2016 07:41: Signed-off-by: Edward O'Callaghan --- docs/GL3.txt | 2 +- docs/relnotes/11.3.0.html | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 3058996..b9fc86b 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -172,7 +172,7 @@ GL 4.3, GLSL 4.30: GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) GL_ARB_fragment_layer_viewportDONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe) - GL_ARB_framebuffer_no_attachments DONE (i965) + GL_ARB_framebuffer_no_attachments DONE (i965, nvc0, r600, radeonsi) GL_ARB_internalformat_query2 DONE (i965) GL_ARB_invalidate_subdata DONE (all drivers) GL_ARB_multi_draw_indirectDONE (i965, nvc0, r600, radeonsi, llvmpipe, softpipe) Should this also update the GL_ARB_framebuffer_no_attachments line in the OpenGL ES 3.1 section? Or is more work needed for that? In the latter case a small comment in the commit message might be nice. Cheers, Kai I am not working on ES and don`t really know much about it so i`ll leave that one to the `experts`. My focus here is just usual GL. Thanks, ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/12] nir/glsl: Propagate invariant into NIR alu ops
Jason Ekstrand writes:
> ---
> src/compiler/nir/glsl_to_nir.cpp | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/compiler/nir/glsl_to_nir.cpp
> b/src/compiler/nir/glsl_to_nir.cpp
> index 613b138..f592c57 100644
> --- a/src/compiler/nir/glsl_to_nir.cpp
> +++ b/src/compiler/nir/glsl_to_nir.cpp
> @@ -1048,6 +1048,8 @@ nir_visitor::visit(ir_assignment *ir)
> {
> unsigned num_components = ir->lhs->type->vector_elements;
>
> + b.exact = ir->lhs->variable_referenced()->data.invariant;
> +
Wouldn't it make sense to set the exact flag for precise as well?
With that fixed:
Reviewed-by: Francisco Jerez
> if ((ir->rhs->as_dereference() || ir->rhs->as_constant()) &&
> (ir->write_mask == (1 << num_components) - 1 || ir->write_mask == 0))
> {
>/* We're doing a plain-as-can-be copy, so emit a copy_var */
> --
> 2.5.0.400.gff86faf
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/9] i965/fs: Don't constant-fold RCP
This code predates me. I can't believe it's been useful for a long time. 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 3/4] st/mesa: emit sampler view decls in PBO upload shader
On 17.03.2016 11:50, Ilia Mirkin wrote: On Thu, Mar 17, 2016 at 12:47 PM, Nicolai Hähnle wrote: On 16.03.2016 19:43, Brian Paul wrote: The return type is float, which is what was implicitly used before, AFAICT. Isn't this technically incorrect when the uploaded texture is integer? To be honest, it's not really clear to me what the return type is supposed to mean. I don't think any of the hardware drivers uses it. Adreno has different texture instructions depending on the desired return type. If you use a float return type on an int texture, you will get a floating point value of that integer (i.e. if the actual textured value were 100, you'd get 100.0f returned if you did sam.f32). I guess this mean PBO uploads of integer textures is currently broken for Adreno? Cheers, Nicolai -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: Do proper format error checks for GenerateMipmap in ES 3.x.
According to the OpenGL ES 3.2 spec's description of GenerateMipmap:
"An INVALID_OPERATION error is generated if the levelbase array was not
specified with an unsized internal format from table 8.3 or a sized
internal format that is both color-renderable and texture-filterable
according to table 8.10."
Similar text exists in the ES 3.0 specification as well.
Our existing rules are pretty close, but miss a few things. The
OpenGL specification actually doesn't have any text about internal
format checking - our existing code comes from a Khronos bug report.
The ES 3.x spec provides a clearer description.
Fixes dEQP-GLES3.functional.negative_api.texture.generatemipmap and
dEQP-GLES2.functional.negative_api.texture.generatemipmap_zero_level
_array_compressed.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/genmipmap.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/mesa/main/genmipmap.c b/src/mesa/main/genmipmap.c
index 6eacd42..1a6ae9a 100644
--- a/src/mesa/main/genmipmap.c
+++ b/src/mesa/main/genmipmap.c
@@ -79,6 +79,20 @@ bool
_mesa_is_valid_generate_texture_mipmap_internalformat(struct gl_context *ctx,
GLenum internalformat)
{
+ if (_mesa_is_gles3(ctx)) {
+ /* From the ES 3.2 specification's description of GenerateMipmap():
+ * "An INVALID_OPERATION error is generated if the levelbase array was
+ * not specified with an unsized internal format from table 8.3 or a
+ * sized internal format that is both color-renderable and
+ * texture-filterable according to table 8.10."
+ */
+ return internalformat == GL_RGBA || internalformat == GL_RGB ||
+ internalformat == GL_LUMINANCE_ALPHA ||
+ internalformat == GL_LUMINANCE || internalformat == GL_ALPHA ||
+ (_mesa_is_es3_color_renderable(internalformat) &&
+ _mesa_is_es3_texture_filterable(internalformat));
+ }
+
return (!_mesa_is_enum_format_integer(internalformat) &&
!_mesa_is_depthstencil_format(internalformat) &&
!_mesa_is_astc_format(internalformat) &&
--
2.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r300g: add missing layer argument to rws->buffer_get_handle() call
Fixes compilation error since 5aea0d691. --- src/gallium/drivers/r300/r300_texture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/r300/r300_texture.c b/src/gallium/drivers/r300/r300_texture.c index 22a613f..709345a 100644 --- a/src/gallium/drivers/r300/r300_texture.c +++ b/src/gallium/drivers/r300/r300_texture.c @@ -982,7 +982,7 @@ boolean r300_resource_get_handle(struct pipe_screen* screen, } return rws->buffer_get_handle(tex->buf, tex->tex.stride_in_bytes[0], - 0, whandle); + 0, 0, whandle); } static const struct u_resource_vtbl r300_texture_vtbl = -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] tgsi: add tgsi_transform_op3_inst() function
---
src/gallium/auxiliary/tgsi/tgsi_transform.h | 34 +
1 file changed, 34 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_transform.h
b/src/gallium/auxiliary/tgsi/tgsi_transform.h
index 27e6179..4dd7dda 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_transform.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_transform.h
@@ -302,6 +302,40 @@ tgsi_transform_op2_inst(struct tgsi_transform_context *ctx,
static inline void
+tgsi_transform_op3_inst(struct tgsi_transform_context *ctx,
+unsigned opcode,
+unsigned dst_file,
+unsigned dst_index,
+unsigned dst_writemask,
+unsigned src0_file,
+unsigned src0_index,
+unsigned src1_file,
+unsigned src1_index,
+unsigned src2_file,
+unsigned src2_index)
+{
+ struct tgsi_full_instruction inst;
+
+ inst = tgsi_default_full_instruction();
+ inst.Instruction.Opcode = opcode;
+ inst.Instruction.NumDstRegs = 1;
+ inst.Dst[0].Register.File = dst_file,
+ inst.Dst[0].Register.Index = dst_index;
+ inst.Dst[0].Register.WriteMask = dst_writemask;
+ inst.Instruction.NumSrcRegs = 3;
+ inst.Src[0].Register.File = src0_file;
+ inst.Src[0].Register.Index = src0_index;
+ inst.Src[1].Register.File = src1_file;
+ inst.Src[1].Register.Index = src1_index;
+ inst.Src[2].Register.File = src2_file;
+ inst.Src[2].Register.Index = src2_index;
+
+ ctx->emit_instruction(ctx, &inst);
+}
+
+
+
+static inline void
tgsi_transform_op1_swz_inst(struct tgsi_transform_context *ctx,
unsigned opcode,
unsigned dst_file,
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Work around SIN/COS output range problem.
On Thursday, March 17, 2016 6:18:39 PM PDT Martin Peres wrote:
> On 16/03/16 19:33, Kenneth Graunke wrote:
> > The SIN and COS instructions on Intel hardware can produce values
> > slightly outside of the [-1.0, 1.0] range for a small set of values.
> > Obviously, this can break everyone's expectations about trig functions.
> >
> > According to an internal presentation, the COS instruction can produce
> > a value up to 1.27 for inputs in the range (0.08296, 0.09888). One
> > suggested workaround is to multiply by 0.7, scaling down the
> > amplitude slightly. Apparently this also minimizes the error function,
> > reducing the maximum error from 0.6 to about 0.3.
> >
> > I chose to apply this only when not saturating, as saturate already
> > clamps to 1.0. This may or may not be a good idea.
> >
> > Fixes 16 dEQP precision tests
> >
> > dEQP-GLES31.functional.shaders.builtin_functions.precision.
> > {cos,sin}.{highp,mediump}_compute.{scalar,vec2,vec4,vec4}.
> >
> > at the cost of making every sin and cos call more expensive.
> >
> > Signed-off-by: Kenneth Graunke
> > ---
> > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 26 +++
+--
> > src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 26 +++
+--
> > 2 files changed, 40 insertions(+), 12 deletions(-)
> >
> > This has been in the Vulkan tree for a while - we needed it to pass the
> > Vulkan CTS, as it contains these same dEQP tests.
> >
> > I haven't run shader-db yet, but I don't expect we'll like the results.
> >
> > The patch is pretty sketchy, too. I'm sort of tempted to hide it behind
> > an INTEL_STRICT_CONFORMANCE=1 option, like we had way back in the day...
>
> FYI, a quick run on hsw_gt2 shows -10.45% on Gputest:voplosion.
Thanks! It sounds like we probably should hide this behind some kind of
INTEL_STRICT_CONFORMANCE option or build time flag. sin and cos are
really common, and making them cost effectively twice as much is really
painful.
I'll come up with a v2 at some point, let's NAK this for now.
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium/radeon: remove old CS tracing
Ping
On Fri, Mar 11, 2016 at 4:01 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Cons:
> - it was only integrated in r600g
> - it doesn't work with GPUVM
> - it records buffer contents at the end of IBs instead of at the beginning,
> so the replay isn't exact
> - it lacks an IB parser and user-friendliness
>
> A better solution is apitrace in combination with gallium/ddebug, which
> has a complete IB parser and can pinpoint hanging CP packets.
> ---
> src/gallium/drivers/r300/r300_context.c| 2 +-
> src/gallium/drivers/r300/r300_flush.c | 6 +-
> src/gallium/drivers/r600/r600_hw_context.c | 11 +-
> src/gallium/drivers/r600/r600_pipe.c | 4 +-
> src/gallium/drivers/r600/r600_pipe.h | 6 -
> src/gallium/drivers/r600/r600_state_common.c | 23 ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 21 +--
> src/gallium/drivers/radeon/r600_pipe_common.h | 6 +-
> src/gallium/drivers/radeon/radeon_uvd.c| 4 +-
> src/gallium/drivers/radeon/radeon_vce.c| 4 +-
> src/gallium/drivers/radeon/radeon_winsys.h | 8 +-
> src/gallium/drivers/radeonsi/si_hw_context.c | 3 +-
> src/gallium/drivers/radeonsi/si_pipe.c | 5 +-
> src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 6 +-
> src/gallium/winsys/radeon/drm/Makefile.am | 2 -
> src/gallium/winsys/radeon/drm/Makefile.sources | 4 -
> src/gallium/winsys/radeon/drm/radeon_ctx.h | 205
> -
> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 13 +-
> src/gallium/winsys/radeon/drm/radeon_drm_cs.h | 5 -
> src/gallium/winsys/radeon/drm/radeon_drm_cs_dump.c | 161
> 20 files changed, 23 insertions(+), 476 deletions(-)
> delete mode 100644 src/gallium/winsys/radeon/drm/radeon_ctx.h
> delete mode 100644 src/gallium/winsys/radeon/drm/radeon_drm_cs_dump.c
>
> diff --git a/src/gallium/drivers/r300/r300_context.c
> b/src/gallium/drivers/r300/r300_context.c
> index 6fa8920..d100a9d 100644
> --- a/src/gallium/drivers/r300/r300_context.c
> +++ b/src/gallium/drivers/r300/r300_context.c
> @@ -385,7 +385,7 @@ struct pipe_context* r300_create_context(struct
> pipe_screen* screen,
> if (!r300->ctx)
> goto fail;
>
> -r300->cs = rws->cs_create(r300->ctx, RING_GFX, r300_flush_callback,
> r300, NULL);
> +r300->cs = rws->cs_create(r300->ctx, RING_GFX, r300_flush_callback,
> r300);
> if (r300->cs == NULL)
> goto fail;
>
> diff --git a/src/gallium/drivers/r300/r300_flush.c
> b/src/gallium/drivers/r300/r300_flush.c
> index 7a75b43..63182cb 100644
> --- a/src/gallium/drivers/r300/r300_flush.c
> +++ b/src/gallium/drivers/r300/r300_flush.c
> @@ -53,7 +53,7 @@ static void r300_flush_and_cleanup(struct r300_context
> *r300, unsigned flags,
> }
>
> r300->flush_counter++;
> -r300->rws->cs_flush(r300->cs, flags, fence, 0);
> +r300->rws->cs_flush(r300->cs, flags, fence);
> r300->dirty_hw = 0;
>
> /* New kitchen sink, baby. */
> @@ -88,11 +88,11 @@ void r300_flush(struct pipe_context *pipe,
> * and we cannot emit an empty CS. Let's write to some reg. */
> CS_LOCALS(r300);
> OUT_CS_REG(RB3D_COLOR_CHANNEL_MASK, 0);
> -r300->rws->cs_flush(r300->cs, flags, fence, 0);
> +r300->rws->cs_flush(r300->cs, flags, fence);
> } else {
> /* Even if hw is not dirty, we should at least reset the CS in
> case
> * the space checking failed for the first draw operation. */
> -r300->rws->cs_flush(r300->cs, flags, NULL, 0);
> +r300->rws->cs_flush(r300->cs, flags, NULL);
> }
> }
>
> diff --git a/src/gallium/drivers/r600/r600_hw_context.c
> b/src/gallium/drivers/r600/r600_hw_context.c
> index 4951297..7a6f957 100644
> --- a/src/gallium/drivers/r600/r600_hw_context.c
> +++ b/src/gallium/drivers/r600/r600_hw_context.c
> @@ -57,18 +57,11 @@ void r600_need_cs_space(struct r600_context *ctx,
> unsigned num_dw,
>
> /* The number of dwords all the dirty states would take. */
> mask = ctx->dirty_atoms;
> - while (mask != 0) {
> + while (mask != 0)
> num_dw += ctx->atoms[u_bit_scan64(&mask)]->num_dw;
> - if (ctx->screen->b.trace_bo) {
> - num_dw += R600_TRACE_CS_DWORDS;
> - }
> - }
>
> /* The upper-bound of how much space a draw command would
> take. */
> num_dw += R600_MAX_FLUSH_CS_DWORDS + R600_MAX_DRAW_CS_DWORDS;
> - if (ctx->screen->b.trace_bo) {
> - num_dw += R600_TRACE_CS_DWORDS;
> - }
> }
>
> /* Count in queries_suspend. */
> @@ -273,7 +266,7 @@ void r600_context_gfx_flush(void *context, unsigned flags,
> flags |= RADEON
Re: [Mesa-dev] [PATCH] mesa: remove remaining tabs in prog_parameter.c
Acked-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Fix stencil texturing in ES 3.1.
Stencil texturing is required by ES 3.1. Apparently we never actually
turned it on, and we missed some necessary code.
Fixes nine dEQP-GLES31.functional tests:
stencil_texturing.format.stencil_index8_2d
texture.border_clamp.formats.stencil_index8.nearest_size_pot
texture.border_clamp.formats.stencil_index8.nearest_size_npot
texture.border_clamp.formats.stencil_index8.gather_size_pot
texture.border_clamp.formats.stencil_index8.gather_size_npot
texture.border_clamp.unused_channels.stencil_index8
state_query.internal_format.renderbuffer.stencil_index8_samples
state_query.internal_format.texture_2d_multisample.stencil_index8_samples
state_query.internal_format.texture_2d_multisample_array.stencil_index8_samples
For now, leave it turned off in desktop GL. There are still bugs with
stencil array textures, and I suspect there are multisampling bugs too.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/drivers/dri/i965/intel_extensions.c| 2 ++
src/mesa/main/texformat.c | 5 +
3 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 3c0b23b..a1160d9 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -718,6 +718,7 @@ brw_init_surface_formats(struct brw_context *brw)
ctx->TextureFormatSupported[MESA_FORMAT_Z24_UNORM_X8_UINT] = true;
ctx->TextureFormatSupported[MESA_FORMAT_Z_FLOAT32] = true;
ctx->TextureFormatSupported[MESA_FORMAT_Z32_FLOAT_S8X24_UINT] = true;
+ ctx->TextureFormatSupported[MESA_FORMAT_S_UINT8] = true;
/* Benchmarking shows that Z16 is slower than Z24, so there's no reason to
* use it unless you're under memory (not memory bandwidth) pressure.
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 60ac124..8d9dab5 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -367,6 +367,8 @@ intelInitExtensions(struct gl_context *ctx)
if (brw->gen >= 8) {
ctx->Extensions.ARB_stencil_texturing = true;
+ if (ctx->API == API_OPENGLES2)
+ ctx->Extensions.ARB_texture_stencil8 = true;
}
if (brw->gen >= 9) {
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index 419fd78..be2581b 100644
--- a/src/mesa/main/texformat.c
+++ b/src/mesa/main/texformat.c
@@ -765,6 +765,11 @@ _mesa_choose_tex_format(struct gl_context *ctx, GLenum
target,
RETURN_IF_SUPPORTED(MESA_FORMAT_B8G8R8A8_UNORM);
break;
+ case GL_STENCIL_INDEX:
+ case GL_STENCIL_INDEX8:
+ RETURN_IF_SUPPORTED(MESA_FORMAT_S_UINT8);
+ break;
+
default:
/* For non-generic compressed format we assert two things:
*
--
2.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] i965/vec4: Handle saturated constants in opt_vector_float
On Thu, Mar 17, 2016 at 11:18 AM, Matt Turner wrote:
> On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand
> wrote:
> > ---
> > src/mesa/drivers/dri/i965/brw_vec4.cpp | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> > index 155a550..02a00b3 100644
> > --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> > @@ -384,7 +384,13 @@ vec4_visitor::opt_vector_float()
> > continue;
> >}
> >
> > - int vf = brw_float_to_vf(inst->src[0].f);
> > + float f = inst->src[0].f;
> > + if (inst->saturate) {
> > + assert(inst->dst.type == BRW_REGISTER_TYPE_F);
> > + f = CLAMP(f, 0.0f, 1.0f);
> > + }
> > +
> > + int vf = brw_float_to_vf(f);
> >if (vf == -1)
> > continue;
>
> Presumably the previous patch is to allow this to happen without
> thinking about types.
>
> This does look like a legitimate bug fix, but what does this fix or enable?
>
Patch 9 removes the mov.sat optimization from opt_algebraic which was
fixing up saturated constants before opt_vector_float ever saw them. When
I removed it, I got a bunch of piglit fails from things that were writing
out-of-bounds constant values to auto-clampped outputs. The problem was
that opt_vector_float was just throwing the .sat away.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] nvc0: avoid using magic numbers for the uniform_bo offsets
Instead make use of constants to improve readability.
The first 32 bytes of the driver constant buffer are unknown... This
doesn't seem to be used in the codegen part, but if the texBindBase
offset is shifted from 0x20 to 0x00, this breaks the universe for
really weird reasons. This sounds like to be related to textures.
Anyway, name this NVC0_CB_AUX_UNK_INFO and add a todo should be
enough for now.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_compute.c| 13 +-
src/gallium/drivers/nouveau/nvc0/nvc0_context.h| 25 +++
src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 12 +-
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 14 +--
src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 2 +-
.../drivers/nouveau/nvc0/nvc0_state_validate.c | 28 --
src/gallium/drivers/nouveau/nvc0/nvc0_tex.c| 9 ---
src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c| 14 ++-
8 files changed, 73 insertions(+), 44 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
index ffbb16f..6aaa7ce 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
@@ -153,7 +153,7 @@ nvc0_compute_validate_constbufs(struct nvc0_context *nvc0)
if (nvc0->constbuf[s][i].user) {
struct nouveau_bo *bo = nvc0->screen->uniform_bo;
- const unsigned base = s << 16;
+ const unsigned base = NVC0_CB_USR_INFO(s);
const unsigned size = nvc0->constbuf[s][0].size;
assert(i == 0); /* we really only want OpenGL uniforms here */
assert(nvc0->constbuf[s][0].u.data);
@@ -207,8 +207,8 @@ nvc0_compute_validate_driverconst(struct nvc0_context *nvc0)
BEGIN_NVC0(push, NVC0_CP(CB_SIZE), 3);
PUSH_DATA (push, 1024);
- PUSH_DATAh(push, screen->uniform_bo->offset + (6 << 16) + (5 << 10));
- PUSH_DATA (push, screen->uniform_bo->offset + (6 << 16) + (5 << 10));
+ PUSH_DATAh(push, screen->uniform_bo->offset + NVC0_CB_AUX_INFO(5));
+ PUSH_DATA (push, screen->uniform_bo->offset + NVC0_CB_AUX_INFO(5));
BEGIN_NVC0(push, NVC0_CP(CB_BIND), 1);
PUSH_DATA (push, (15 << 8) | 1);
@@ -219,15 +219,16 @@ static void
nvc0_compute_validate_buffers(struct nvc0_context *nvc0)
{
struct nouveau_pushbuf *push = nvc0->base.pushbuf;
+ struct nvc0_screen *screen = nvc0->screen;
const int s = 5;
int i;
BEGIN_NVC0(push, NVC0_CP(CB_SIZE), 3);
PUSH_DATA (push, 1024);
- PUSH_DATAh(push, nvc0->screen->uniform_bo->offset + (6 << 16) + (s << 10));
- PUSH_DATA (push, nvc0->screen->uniform_bo->offset + (6 << 16) + (s << 10));
+ PUSH_DATAh(push, screen->uniform_bo->offset + NVC0_CB_AUX_INFO(s));
+ PUSH_DATA (push, screen->uniform_bo->offset + NVC0_CB_AUX_INFO(s));
BEGIN_1IC0(push, NVC0_CP(CB_POS), 1 + 4 * NVC0_MAX_BUFFERS);
- PUSH_DATA (push, 512);
+ PUSH_DATA (push, NVC0_CB_AUX_BUF_INFO(0));
for (i = 0; i < NVC0_MAX_BUFFERS; i++) {
if (nvc0->buffers[s][i].buffer) {
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
index 54afe88..31e1272 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
@@ -98,6 +98,31 @@
#define NVC0_BIND_M2MF 0
#define NVC0_BIND_FENCE 1
+/* 6 user uniform buffers, at 64K each */
+#define NVC0_CB_USR_INFO(s) (s << 16)
+#define NVC0_CB_USR_SIZE(6 << 16)
+/* 6 driver constbuts, at 1K each */
+#define NVC0_CB_AUX_INFO(s) NVC0_CB_USR_SIZE + (s << 10)
+#define NVC0_CB_AUX_SIZE(6 << 10)
+/* XXX: Figure out what this UNK data is. */
+#define NVC0_CB_AUX_UNK_INFO0x000
+#define NVC0_CB_AUX_UNK_SIZE(8 * 4)
+/* 32 textures handles, at 1 32-bits integer each */
+#define NVC0_CB_AUX_TEX_INFO(i) 0x020 + (i) * 4
+#define NVC0_CB_AUX_TEX_SIZE(32 * 4)
+/* 8 user clip planes, at 4 32-bits floats each */
+#define NVC0_CB_AUX_UCP_INFO0x100
+#define NVC0_CB_AUX_UCP_SIZE(PIPE_MAX_CLIP_PLANES * 4 * 4)
+/* 8 sets of 32-bits integer pairs sample offsets */
+#define NVC0_CB_AUX_SAMPLE_INFO 0x180 /* FP */
+#define NVC0_CB_AUX_SAMPLE_SIZE (8 * 4 * 2)
+/* draw parameters (index bais, base instance, drawid) */
+#define NVC0_CB_AUX_DRAW_INFO 0x180 /* VP */
+/* 32 user buffers, at 4 32-bits integers each */
+#define NVC0_CB_AUX_BUF_INFO(i) 0x200 + (i) * 4 * 4
+#define NVC0_CB_AUX_BUF_SIZE(NVC0_MAX_BUFFERS * 4 * 4)
+/* 4 32-bits floats for the vertex runout, put at the end */
+#define NVC0_CB_AUX_RUNOUT_INFO NVC0_CB_USR_SIZE + NVC0_CB_AUX_SIZE
struct nvc0_blitctx;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index 48e3475..b7c6faf 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
+++ b/src
[Mesa-dev] [PATCH 3/4] st/mesa: emit sampler view decls in PBO upload shader
The return type is float, which is what was implicitly used before, AFAICT.
---
src/mesa/state_tracker/st_cb_texture.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index bffa4d0..6ee55c6 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1228,6 +1228,12 @@ create_pbo_upload_fs(struct st_context *st)
out = ureg_DECL_output(ureg, TGSI_SEMANTIC_COLOR, 0);
sampler = ureg_DECL_sampler(ureg, 0);
+ ureg_DECL_sampler_view(ureg, 0, TGSI_TEXTURE_BUFFER,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT);
+
if (screen->get_param(screen, PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL)) {
pos = ureg_DECL_system_value(ureg, TGSI_SEMANTIC_POSITION, 0);
} else {
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: use the texture view's format for render-to-texture
From: Nicolai Hähnle
Aside from the bug below, it fixes a simplistic test I've written locally,
and I see no regression in Piglit for radeonsi.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94595
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_cb_fbo.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 82ab914..ff570e0 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -387,6 +387,7 @@ st_update_renderbuffer_surface(struct st_context *st,
{
struct pipe_context *pipe = st->pipe;
struct pipe_resource *resource = strb->texture;
+ struct st_texture_object *stTexObj = NULL;
unsigned rtt_width = strb->Base.Width;
unsigned rtt_height = strb->Base.Height;
unsigned rtt_depth = strb->Base.Depth;
@@ -398,9 +399,18 @@ st_update_renderbuffer_surface(struct st_context *st,
*/
boolean enable_srgb = (st->ctx->Color.sRGBEnabled &&
_mesa_get_format_color_encoding(strb->Base.Format) == GL_SRGB);
- enum pipe_format format = (enable_srgb) ?
- util_format_srgb(resource->format) :
- util_format_linear(resource->format);
+ enum pipe_format format = resource->format;
+
+ if (strb->is_rtt) {
+ stTexObj = st_texture_object(strb->Base.TexImage->TexObject);
+ if (stTexObj->surface_based)
+ format = stTexObj->surface_format;
+ }
+
+ format = (enable_srgb) ?
+ util_format_srgb(format) :
+ util_format_linear(format);
+
unsigned first_layer, last_layer, level;
if (resource->target == PIPE_TEXTURE_1D_ARRAY) {
@@ -431,8 +441,8 @@ st_update_renderbuffer_surface(struct st_context *st,
/* Adjust for texture views */
if (strb->is_rtt && resource->array_size > 1 &&
- strb->Base.TexImage->TexObject->Immutable) {
- struct gl_texture_object *tex = strb->Base.TexImage->TexObject;
+ stTexObj->base.Immutable) {
+ struct gl_texture_object *tex = &stTexObj->base;
first_layer += tex->MinLayer;
if (!strb->rtt_layered)
last_layer += tex->MinLayer;
@@ -492,8 +502,6 @@ st_render_texture(struct gl_context *ctx,
st_update_renderbuffer_surface(st, strb);
- strb->Base.Format = st_pipe_format_to_mesa_format(pt->format);
-
/* Invalidate buffer state so that the pipe's framebuffer state
* gets updated.
* That's where the new renderbuffer (which we just created) gets
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glsl: Don't require matching interpolation qualifiers for newer GLSL
On 03/16/2016 09:57 PM, Jordan Justen wrote:
The OpenGLES GLSL 3.1 and OpenGL GLSL 4.3 specifications both remove
the requirement for the output and input interpolation qualifiers to
match.
Note: I'm changing desktop OpenGL to allow the interpolation to
differ, starting with 4.3, whereas the code previously used 4.4. (This
was first added in 32a220f1f60980de50ecefb3b9ab1f754ade8c83.)
The OpenGL 4.2 spec says: "the last active shader stage output
variables and fragment shader input variables of the same name must
match in type and qualification (other than out matching to in)"
The OpenGL 4.3 spec says: "interpolation qualification (e.g., flat)
and auxiliary qualification (e.g. centroid) may differ."
I used 4.40 there because it's 'Changes' list includes following text:
"Remove old contradictory text requiring interpolation qualifiers to
match cross stage; they must only match within a stage."
(see Khronos bug #10990)
but if 4.30 spec already has similar changes done then this is correct.
The OpenGLES GLSL 3.00.4 specification says: "The output of the vertex
shader and the input of the fragment shader form an interface. For
this interface, vertex shader output variables and fragment shader
input variables of the same name must match in type and qualification
(other than precision and out matching to in)."
The OpenGLES GLSL 3.10 Specification says: "interpolation
qualification (e.g., flat) and auxiliary qualification (e.g. centroid)
may differ"
Signed-off-by: Jordan Justen
Cc: Tapani Pälli
---
src/compiler/glsl/link_varyings.cpp | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/src/compiler/glsl/link_varyings.cpp
b/src/compiler/glsl/link_varyings.cpp
index 9d7177d..0938cf1 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -172,17 +172,9 @@ cross_validate_types_and_qualifiers(struct
gl_shader_program *prog,
return;
}
- /* GLSL >= 4.40 removes text requiring interpolation qualifiers
-* to match cross stage, they must only match within the same stage.
-*
-* From page 84 (page 90 of the PDF) of the GLSL 4.40 spec:
-*
-* "It is a link-time error if, within the same stage, the interpolation
-* qualifiers of variables of the same name do not match.
-*
-*/
- if (input->data.interpolation != output->data.interpolation &&
- prog->Version < 440) {
+ /* Interpolation must match until OpenGL 4.3 and OpenGLES 3.1 */
+ if (prog->Version < (prog->IsES ? 310 : 430) &&
+ input->data.interpolation != output->data.interpolation) {
linker_error(prog,
"%s shader output `%s' specifies %s "
"interpolation qualifier, "
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] compiler: Check if check_explicit_uniform_locations has failed.
We should check whether check_explicit_uniform_locations has failed before we pass the number of explicit uniform locations to link_assign_uniform_locations. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94549#c3 --- src/compiler/glsl/linker.cpp | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp index 76b700d..a2091f4 100644 --- a/src/compiler/glsl/linker.cpp +++ b/src/compiler/glsl/linker.cpp @@ -4324,6 +4324,7 @@ link_shaders(struct gl_context *ctx, struct gl_shader_program *prog) goto done; unsigned first, last, prev; + int result; first = MESA_SHADER_STAGES; last = 0; @@ -4337,7 +4338,11 @@ link_shaders(struct gl_context *ctx, struct gl_shader_program *prog) last = i; } - num_explicit_uniform_locs = check_explicit_uniform_locations(ctx, prog); + result = check_explicit_uniform_locations(ctx, prog); + + if (result > 0) + num_explicit_uniform_locs = result; + link_assign_subroutine_types(prog); if (!prog->LinkStatus) -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] st/omx/dec: Correct the timestamping
From: Nishanth Peethambaran
Attach the timestamp to the dpb buffer and use that timestamp
while pushing buffer from dpb list to the omx client.
Reviewed-by: Christian König
Signed-off-by: Nishanth Peethambaran
Cc: "11.1 11.2"
---
src/gallium/state_trackers/omx/vid_dec.c| 11 +--
src/gallium/state_trackers/omx/vid_dec.h| 7 ++-
src/gallium/state_trackers/omx/vid_dec_h264.c | 18 +++---
src/gallium/state_trackers/omx/vid_dec_mpeg12.c | 6 --
4 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_dec.c
b/src/gallium/state_trackers/omx/vid_dec.c
index 9fcf20e..108a460 100644
--- a/src/gallium/state_trackers/omx/vid_dec.c
+++ b/src/gallium/state_trackers/omx/vid_dec.c
@@ -419,6 +419,7 @@ static OMX_ERRORTYPE vid_dec_DecodeBuffer(omx_base_PortType
*port, OMX_BUFFERHEA
priv->in_buffers[i] = buf;
priv->sizes[i] = buf->nFilledLen;
priv->inputs[i] = buf->pBuffer;
+ priv->timestamps[i] = buf->nTimeStamp;
while (priv->num_in_buffers > (!!(buf->nFlags & OMX_BUFFERFLAG_EOS) ? 0 :
1)) {
bool eos = !!(priv->in_buffers[0]->nFlags & OMX_BUFFERFLAG_EOS);
@@ -469,6 +470,7 @@ static OMX_ERRORTYPE vid_dec_DecodeBuffer(omx_base_PortType
*port, OMX_BUFFERHEA
priv->in_buffers[0] = priv->in_buffers[1];
priv->sizes[0] = priv->sizes[1] - delta;
priv->inputs[0] = priv->inputs[1] + delta;
+ priv->timestamps[0] = priv->timestamps[1];
}
if (r)
@@ -526,9 +528,13 @@ static void vid_dec_FrameDecoded(OMX_COMPONENTTYPE *comp,
OMX_BUFFERHEADERTYPE*
{
vid_dec_PrivateType *priv = comp->pComponentPrivate;
bool eos = !!(input->nFlags & OMX_BUFFERFLAG_EOS);
+ OMX_TICKS timestamp;
- if (!input->pInputPortPrivate)
- input->pInputPortPrivate = priv->Flush(priv);
+ if (!input->pInputPortPrivate) {
+ input->pInputPortPrivate = priv->Flush(priv, ×tamp);
+ if (timestamp != OMX_VID_DEC_TIMESTAMP_INVALID)
+ input->nTimeStamp = timestamp;
+ }
if (input->pInputPortPrivate) {
if (output->pInputPortPrivate) {
@@ -539,6 +545,7 @@ static void vid_dec_FrameDecoded(OMX_COMPONENTTYPE *comp,
OMX_BUFFERHEADERTYPE*
vid_dec_FillOutput(priv, input->pInputPortPrivate, output);
}
output->nFilledLen = output->nAllocLen;
+ output->nTimeStamp = input->nTimeStamp;
}
if (eos && input->pInputPortPrivate)
diff --git a/src/gallium/state_trackers/omx/vid_dec.h
b/src/gallium/state_trackers/omx/vid_dec.h
index 3b39826..649d745 100644
--- a/src/gallium/state_trackers/omx/vid_dec.h
+++ b/src/gallium/state_trackers/omx/vid_dec.h
@@ -59,6 +59,8 @@
#define OMX_VID_DEC_AVC_NAME "OMX.mesa.video_decoder.avc"
#define OMX_VID_DEC_AVC_ROLE "video_decoder.avc"
+#define OMX_VID_DEC_TIMESTAMP_INVALID ((OMX_TICKS) -1)
+
struct vl_vlc;
DERIVEDCLASS(vid_dec_PrivateType, omx_base_filter_PrivateType)
@@ -69,7 +71,7 @@ DERIVEDCLASS(vid_dec_PrivateType, omx_base_filter_PrivateType)
struct pipe_video_codec *codec; \
void (*Decode)(vid_dec_PrivateType *priv, struct vl_vlc *vlc, unsigned
min_bits_left); \
void (*EndFrame)(vid_dec_PrivateType *priv); \
- struct pipe_video_buffer *(*Flush)(vid_dec_PrivateType *priv); \
+ struct pipe_video_buffer *(*Flush)(vid_dec_PrivateType *priv, OMX_TICKS
*timestamp); \
struct pipe_video_buffer *target, *shadow; \
union { \
struct { \
@@ -100,6 +102,9 @@ DERIVEDCLASS(vid_dec_PrivateType,
omx_base_filter_PrivateType)
OMX_BUFFERHEADERTYPE *in_buffers[2]; \
const void *inputs[2]; \
unsigned sizes[2]; \
+ OMX_TICKS timestamps[2]; \
+ OMX_TICKS timestamp; \
+ bool first_buf_in_frame; \
bool frame_finished; \
bool frame_started; \
unsigned bytes_left; \
diff --git a/src/gallium/state_trackers/omx/vid_dec_h264.c
b/src/gallium/state_trackers/omx/vid_dec_h264.c
index 75f27d2..9aab6d1 100644
--- a/src/gallium/state_trackers/omx/vid_dec_h264.c
+++ b/src/gallium/state_trackers/omx/vid_dec_h264.c
@@ -45,6 +45,7 @@
struct dpb_list {
struct list_head list;
struct pipe_video_buffer *buffer;
+ OMX_TICKS timestamp;
unsigned poc;
};
@@ -82,7 +83,7 @@ static const uint8_t Default_8x8_Inter[64] = {
static void vid_dec_h264_Decode(vid_dec_PrivateType *priv, struct vl_vlc *vlc,
unsigned min_bits_left);
static void vid_dec_h264_EndFrame(vid_dec_PrivateType *priv);
-static struct pipe_video_buffer *vid_dec_h264_Flush(vid_dec_PrivateType *priv);
+static struct pipe_video_buffer *vid_dec_h264_Flush(vid_dec_PrivateType *priv,
OMX_TICKS *timestamp);
void vid_dec_h264_Init(vid_dec_PrivateType *priv)
{
@@ -94,6 +95,7 @@ void vid_dec_h264_Init(vid_dec_PrivateType *priv)
LIST_INITHEAD(&priv->codec_data.h264.dpb_list);
priv->picture.h264.field_order_cnt[0] =
priv->picture.h264.field_order_cnt[1] = INT_MAX;
+ priv->first_buf_in_frame = true;
}
static void vid_dec_h264_BeginFrame(vid_dec_PrivateType *priv)
@@ -104,6
[Mesa-dev] [PATCH] doc: document spilling options accepted by INTEL_DEBUG
--- docs/envvars.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/envvars.html b/docs/envvars.html index 06aa0ac..6b5511b 100644 --- a/docs/envvars.html +++ b/docs/envvars.html @@ -163,6 +163,8 @@ See the Xlib software driver page for details. blorp - emit messages about the blorp operations (blits & clears) nodualobj - suppress generation of dual-object geometry shader code optimizer - dump shader assembly to files at each optimization pass and iteration that make progress + spill_fs - force spilling of all registers in the scalar backend (useful to debug spilling code) + spill_vec4 - force spilling of all registers in the vec4 backend (useful to debug spilling code) -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa and LLVM cross compiling Linux to Windows issue
I suspect you simply ran into an issue with old mesa and new llvm. Unfortunately some usage of the c++ abi of llvm is unavoidable, and the abi is unstable, thus breaking quite often. And we do not generally backport such fixes to older mesa releases (if only mostly because nobodoy would actually test them). So you have 3 choices: a) use newer mesa version b) use older llvm version c) backport whatever is necessary on your own. If you really want to try c), you might actually be lucky, since it only was a link error, it might not be an abi issue - it is possible picking a5256012ef8ea31bc8025fc72193a9772372c9a1 from mesa git master (which adds LLVMInstrumentation to the libs in scons/llvm.py) will do the trick. But don't quote me on that, the other errors might be something else entirely (c++11 abi issue? cross-compile issue?) I'm definitely no expert on this. Roland Am 17.03.2016 um 10:46 schrieb Jason Anderssen: > Hi all, > > I have been trying to compile LLVM 3.8 and Mesa 11.0.7, and I have the > final last hurdle I think to get past > > scons: Building targets ... > > Linking build/windows-x86_64/gallium/targets/libgl-gdi/opengl32.dll ... > > /home/janderssen/mesa_win64/llvm-3.8.build/lib/libLLVMCodeGen.a(Passes.o):Passes.cpp:(.text+0x2239): > undefined reference to `llvm::createSafeStackPass(llvm::TargetMachine > const*)' > > /home/janderssen/mesa_win64/llvm-3.8.build/lib/libLLVMSupport.a(Path.o):Path.cpp:(.text+0x8e5): > undefined reference to `__imp_CoTaskMemFree' > > /home/janderssen/mesa_win64/llvm-3.8.build/lib/libLLVMSupport.a(Path.o):Path.cpp:(.rdata$.refptr.FOLDERID_Profile[.refptr.FOLDERID_Profile]+0x0): > undefined reference to `FOLDERID_Profile' > > /home/janderssen/mesa_win64/llvm-3.8.build/lib/libLLVMSupport.a(Path.o):Path.cpp:(.rdata$.refptr.FOLDERID_LocalAppData[.refptr.FOLDERID_LocalAppData]+0x0): > undefined reference to `FOLDERID_LocalAppData' > > collect2: error: ld returned 1 exit status > > scons: *** [build/windows-x86_64/gallium/targets/libgl-gdi/opengl32.dll] > Error 1 > > scons: building terminated because of errors. > > > I Managed to get this far, and would like to finalise it. > > LLVM Version 3.8 > > Mesa 11.0.7 > > > LVVM Configure line : > > ../*configure* -C --prefix=$HOME/mesa_win64/llvm-3.8.build > --host=x86_64-w64-mingw32 --enable-optimized --disable-assertions > --disable-pthreads --enable-targets=x86_64 --enable-bindings=none > --disable-libffi --with-c-include-dirs=/usr/x86_64-w64-mingw32 > --with-gcc-toolchain=/usr/x86_64-w64-mingw32 > --with-default-sysroot=/usr/x86_64-w64-mingw32 > > > Mesa Compile line : > > LDFLAGS="-static -s" CXXFLAGS="-std=c++11" scons build=release > platform=windows toolchain=crossmingw machine=x86_64 libgl-gdi > > > Any ideas of what I am doing wrong ? > > > Cheers and thanks in advance for your help. > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Set address rounding bits for GL_NEAREST filtering as well.
On 2016-03-17 01:04:27, Kenneth Graunke wrote:
> Yuanhan Liu decided these were useful for linear filtering in
> commit 76669381 (circa 2011). Prior to that, we never set them;
> it seems he tried to preserve that behavior for nearest filtering.
>
> It turns out they're useful for nearest filtering, too: setting
> these fixes the following dEQP-GLES3 tests:
>
> functional.fbo.blit.rect.nearest_consistency_mag
> functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_x
> functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_y
> functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_x
> functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_y
> functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_x
> functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_y
> functional.fbo.blit.rect.nearest_consistency_min
> functional.fbo.blit.rect.nearest_consistency_min_reverse_src_x
> functional.fbo.blit.rect.nearest_consistency_min_reverse_src_y
> functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_x
> functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_y
> functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_x
> functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_y
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_x
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_y
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_x
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_y
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_x
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_y
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_x
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_y
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_x
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_y
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_x
> functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_y
>
> Apparently, BLORP has always set these bits unconditionally.
>
> However, setting them unconditionally appears to regress tests using
> texture projection, 3D samplers, integer formats, and vertex shaders,
> all in combination, such as:
>
> functional.shaders.texture_functions.textureprojlod.isampler3d_vertex
>
> Setting them on Gen4-5 appears to regress Piglit's
> tests/spec/arb_sampler_objects/framebufferblit.
>
> Honestly, it looks like the real problem here is a lack of precision.
> I'm just hacking around problems here (as embarassing as it is).
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_sampler_state.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_sampler_state.c
> b/src/mesa/drivers/dri/i965/brw_sampler_state.c
> index c20a028..d53cb5d 100644
> --- a/src/mesa/drivers/dri/i965/brw_sampler_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_sampler_state.c
> @@ -436,14 +436,17 @@ brw_update_sampler_state(struct brw_context *brw,
>}
> }
>
> - /* Set address rounding bits if not using nearest filtering. */
> + /* Set address rounding bits. The conditions are empirically
> +* derived in order to pass test cases.
> +*/
> + bool round_nearest = brw->gen >= 6 && target != GL_TEXTURE_3D;
> unsigned address_rounding = 0;
> - if (min_filter != BRW_MAPFILTER_NEAREST) {
> + if (min_filter != BRW_MAPFILTER_NEAREST || round_nearest) {
How about folding the min_filter != BRW_MAPFILTER_NEAREST test into
round_nearest?
Reviewed-by: Jordan Justen
>address_rounding |= BRW_ADDRESS_ROUNDING_ENABLE_U_MIN |
>BRW_ADDRESS_ROUNDING_ENABLE_V_MIN |
>BRW_ADDRESS_ROUNDING_ENABLE_R_MIN;
> }
> - if (mag_filter != BRW_MAPFILTER_NEAREST) {
> + if (mag_filter != BRW_MAPFILTER_NEAREST || round_nearest) {
>address_rounding |= BRW_ADDRESS_ROUNDING_ENABLE_U_MAG |
>BRW_ADDRESS_ROUNDING_ENABLE_V_MAG |
>BRW_ADDRESS_ROUNDING_ENABLE_R_MAG;
> --
> 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
Re: [Mesa-dev] [PATCH] nv50,nvc0: Fix invalid constant.
On 06:34 PM - Mar 18 2016, Vinson Lee wrote:
> Fix clang build error.
>
> CXX codegen/nv50_ir_lowering_nvc0.lo
> codegen/nv50_ir_lowering_nvc0.cpp:1783:42: error: invalid suffix 'd' on
> floating constant
> Value *zero = bld.loadImm(NULL, 0.0d);
> ^
>
> Fixes: c1e4a6bfbf01 ("nv50,nvc0: handle SQRT lowering inside the driver")
> Signed-off-by: Vinson Lee
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index d0936d8..01364b3 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -1780,7 +1780,7 @@ NVC0LoweringPass::handleSQRT(Instruction *i)
> {
> if (i->dType == TYPE_F64) {
>Value *pred = bld.getSSA(1, FILE_PREDICATE);
> - Value *zero = bld.loadImm(NULL, 0.0d);
> + Value *zero = bld.loadImm(NULL, 0);
Shouldn't it rather be: `Value *zero = bld.loadImm(NULL, 0.0);` as you want a
double, not an int?
>Value *dst = bld.getSSA(8);
>bld.mkOp1(OP_RSQ, i->dType, dst, i->getSrc(0));
>bld.mkCmp(OP_SET, CC_LE, i->dType, pred, i->dType, i->getSrc(0), zero);
> --
> 2.7.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] i965/vec4: Handle saturated constants in opt_vector_float
On Thu, Mar 17, 2016 at 11:52 AM, Jason Ekstrand wrote:
>
>
> On Thu, Mar 17, 2016 at 11:18 AM, Matt Turner wrote:
>>
>> On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand
>> wrote:
>> > ---
>> > src/mesa/drivers/dri/i965/brw_vec4.cpp | 8 +++-
>> > 1 file changed, 7 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> > b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> > index 155a550..02a00b3 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> > +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> > @@ -384,7 +384,13 @@ vec4_visitor::opt_vector_float()
>> > continue;
>> >}
>> >
>> > - int vf = brw_float_to_vf(inst->src[0].f);
>> > + float f = inst->src[0].f;
>> > + if (inst->saturate) {
>> > + assert(inst->dst.type == BRW_REGISTER_TYPE_F);
>> > + f = CLAMP(f, 0.0f, 1.0f);
>> > + }
>> > +
>> > + int vf = brw_float_to_vf(f);
>> >if (vf == -1)
>> > continue;
>>
>> Presumably the previous patch is to allow this to happen without
>> thinking about types.
>>
>> This does look like a legitimate bug fix, but what does this fix or
>> enable?
>
>
> Patch 9 removes the mov.sat optimization from opt_algebraic which was fixing
> up saturated constants before opt_vector_float ever saw them. When I
> removed it, I got a bunch of piglit fails from things that were writing
> out-of-bounds constant values to auto-clampped outputs. The problem was
> that opt_vector_float was just throwing the .sat away.
Oh, so this isn't even a legitimate bug fix unless you remove the code
this relies on...
Just keep the saturating code in opt_algebraic. Why would we remove it...?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] nv50/ir: Check for valid insn instead of def size
Functions arguments get a definition from the function itself, a definition
which is therefore not linked to any instruction. If a value ends up having a
definition but no linked instruction, the register allocation pass doesn't
need to consider that value.
This fixes a null pointer dereference during the register allocation pass, if
a function had unused arguments.
v2: Rewrite commit message based on Ilia Mirkin's comment
v3: Rewrite an incorrect statement in the commit message that was pointed out
by Ilia Mirkin
Signed-off-by: Pierre Moreau
---
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index d877c25..500ab89 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -853,7 +853,7 @@ isShortRegOp(Instruction *insn)
static bool
isShortRegVal(LValue *lval)
{
- if (lval->defs.size() == 0)
+ if (lval->getInsn() == NULL)
return false;
for (Value::DefCIterator def = lval->defs.begin();
def != lval->defs.end(); ++def)
@@ -1467,7 +1467,7 @@ GCRA::allocateRegisters(ArrayList& insns)
nodes[i].init(regs, lval);
RIG.insert(&nodes[i]);
- if (lval->inFile(FILE_GPR) && lval->defs.size() > 0 &&
+ if (lval->inFile(FILE_GPR) && lval->getInsn() != NULL &&
prog->getTarget()->getChipset() < 0xc0) {
Instruction *insn = lval->getInsn();
if (insn->op == OP_MAD || insn->op == OP_SAD)
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] nvc0: shift driver constant buffer offsets by 32 bytes
On 03/16/2016 11:17 AM, Samuel Pitoiset wrote: The offsets are wrong in this patch... But even after fixing them I have a few number of regressions (~10 piglit tests). Anyway, these changes are not too useful for now, so I'm going to get rid of it. I'll now try with Kepler. Confirmed, no regressions on both Fermi and Kepler. Except this patch that will be removed, this series (especially the patch which removes unused data in the driver constbuf) doesn't break anything. :-) On 03/15/2016 09:55 PM, Samuel Pitoiset wrote: The first 32 bytes of the driver constant buffer are currently unused. Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/nouveau/nvc0/nvc0_context.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h index c63d138..e54018b 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h @@ -105,18 +105,18 @@ #define NVC0_CB_AUX_INFO(s) NVC0_CB_USR_SIZE + (s << 10) #define NVC0_CB_AUX_SIZE(6 << 10) /* 32 textures handles, at 1 32-bits integer each */ -#define NVC0_CB_AUX_TEX_INFO(i) 0x020 + (i) * 4 +#define NVC0_CB_AUX_TEX_INFO(i) 0x000 + (i) * 4 #define NVC0_CB_AUX_TEX_SIZE(32 * 4) /* 8 user clip planes, at 4 32-bits floats each */ -#define NVC0_CB_AUX_UCP_INFO0x100 +#define NVC0_CB_AUX_UCP_INFO0x080 #define NVC0_CB_AUX_UCP_SIZE(PIPE_MAX_CLIP_PLANES * 4 * 4) /* 8 sets of 32-bits integer pairs sample offsets */ -#define NVC0_CB_AUX_SAMPLE_INFO 0x180 /* FP */ +#define NVC0_CB_AUX_SAMPLE_INFO 0x160 /* FP */ #define NVC0_CB_AUX_SAMPLE_SIZE (8 * 4 * 2) /* draw parameters (index bais, base instance, drawid) */ -#define NVC0_CB_AUX_DRAW_INFO 0x180 /* VP */ +#define NVC0_CB_AUX_DRAW_INFO 0x160 /* VP */ /* 32 user buffers, at 4 32-bits integers each */ -#define NVC0_CB_AUX_BUF_INFO(i) 0x200 + (i) * 4 * 4 +#define NVC0_CB_AUX_BUF_INFO(i) 0x180 + (i) * 4 * 4 #define NVC0_CB_AUX_BUF_SIZE(NVC0_MAX_BUFFERS * 4 * 4) /* 4 32-bits floats for the vertex runout, put at the end */ #define NVC0_CB_AUX_RUNOUT_INFO NVC0_CB_USR_SIZE + NVC0_CB_AUX_SIZE ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] nir: Add an "exact" bit to nir_alu_instr
Jason Ekstrand writes:
> ---
> src/compiler/nir/nir.h | 11 +++
> src/compiler/nir/nir_clone.c | 1 +
> src/compiler/nir/nir_print.c | 2 ++
> 3 files changed, 14 insertions(+)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 34f31eb..94b981b 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -671,6 +671,17 @@ extern const nir_op_info nir_op_infos[nir_num_opcodes];
> typedef struct nir_alu_instr {
> nir_instr instr;
> nir_op op;
> +
> + /** Indicates that this ALU instruction generates an exact value
> +*
> +* This is kind-of a mixture of GLSL "precise" and "invariant" and not
> +* really equivalent to either. This indicates that the value generated
> by
> +* this operation is high-precision and any code transformations that
> touch
> +* it must ensure that the resulting value is bit-for-bit identical to the
> +* original.
> +*/
> + bool exact;
> +
> nir_alu_dest dest;
> nir_alu_src src[];
> } nir_alu_instr;
> diff --git a/src/compiler/nir/nir_clone.c b/src/compiler/nir/nir_clone.c
> index 198ca8b..90eefa7 100644
> --- a/src/compiler/nir/nir_clone.c
> +++ b/src/compiler/nir/nir_clone.c
> @@ -303,6 +303,7 @@ static nir_alu_instr *
> clone_alu(clone_state *state, const nir_alu_instr *alu)
> {
> nir_alu_instr *nalu = nir_alu_instr_create(state->ns, alu->op);
> + nalu->exact = alu->exact;
>
> __clone_dst(state, &nalu->instr, &nalu->dest.dest, &alu->dest.dest);
> nalu->dest.saturate = alu->dest.saturate;
> diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
> index bdfbd26..26014c1 100644
> --- a/src/compiler/nir/nir_print.c
> +++ b/src/compiler/nir/nir_print.c
> @@ -207,6 +207,8 @@ print_alu_instr(nir_alu_instr *instr, print_state *state)
> print_alu_dest(&instr->dest, state);
>
> fprintf(fp, " = %s", nir_op_infos[instr->op].name);
> + if (instr->exact)
> + fprintf(fp, "!");
> if (instr->dest.saturate)
>fprintf(fp, ".sat");
> fprintf(fp, " ");
Patches 1-3 are:
Reviewed-by: Francisco Jerez
> --
> 2.5.0.400.gff86faf
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/12] nir/alu_to_scalar: Propagate the "exact" bit
Jason Ekstrand writes: > --- > src/compiler/nir/nir_lower_alu_to_scalar.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/compiler/nir/nir_lower_alu_to_scalar.c > b/src/compiler/nir/nir_lower_alu_to_scalar.c > index 312d2f9..082242e 100644 > --- a/src/compiler/nir/nir_lower_alu_to_scalar.c > +++ b/src/compiler/nir/nir_lower_alu_to_scalar.c > @@ -80,6 +80,7 @@ lower_alu_instr_scalar(nir_alu_instr *instr, nir_builder *b) > assert(instr->dest.write_mask != 0); > > b->cursor = nir_before_instr(&instr->instr); > + b->exact = instr->exact; > Reviewed-by: Francisco Jerez > #define LOWER_REDUCTION(name, chan, merge) \ > case name##2: \ > -- > 2.5.0.400.gff86faf > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/omx: Remove trailing spaces
From: Nishanth Peethambaran
Reviewed-by: Christian König
Signed-off-by: Nishanth Peethambaran
Cc: "11.1 11.2"
---
src/gallium/state_trackers/omx/vid_dec.c | 10 +++---
src/gallium/state_trackers/omx/vid_dec_h264.c | 8 ++---
src/gallium/state_trackers/omx/vid_enc.c | 44 +--
3 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_dec.c
b/src/gallium/state_trackers/omx/vid_dec.c
index 5584348..9fcf20e 100644
--- a/src/gallium/state_trackers/omx/vid_dec.c
+++ b/src/gallium/state_trackers/omx/vid_dec.c
@@ -140,7 +140,7 @@ static OMX_ERRORTYPE vid_dec_Constructor(OMX_COMPONENTTYPE
*comp, OMX_STRING nam
r = omx_base_filter_Constructor(comp, name);
if (r)
- return r;
+ return r;
priv->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
@@ -268,7 +268,7 @@ static OMX_ERRORTYPE vid_dec_SetParameter(OMX_HANDLETYPE
handle, OMX_INDEXTYPE i
r = checkHeader(param, sizeof(OMX_PARAM_COMPONENTROLETYPE));
if (r)
return r;
-
+
if (!strcmp((char *)role->cRole, OMX_VID_DEC_MPEG2_ROLE)) {
priv->profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN;
} else if (!strcmp((char *)role->cRole, OMX_VID_DEC_AVC_ROLE)) {
@@ -321,7 +321,7 @@ static OMX_ERRORTYPE vid_dec_GetParameter(OMX_HANDLETYPE
handle, OMX_INDEXTYPE i
strcpy((char *)role->cRole, OMX_VID_DEC_MPEG2_ROLE);
else if (priv->profile == PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH)
strcpy((char *)role->cRole, OMX_VID_DEC_AVC_ROLE);
-
+
break;
}
@@ -474,7 +474,7 @@ static OMX_ERRORTYPE vid_dec_DecodeBuffer(omx_base_PortType
*port, OMX_BUFFERHEA
if (r)
return r;
}
-
+
return OMX_ErrorNone;
}
@@ -513,7 +513,7 @@ static void vid_dec_FillOutput(vid_dec_PrivateType *priv,
struct pipe_video_buff
box.width = def->nFrameWidth / 2;
box.height = def->nFrameHeight / 2;
-
+
src = priv->pipe->transfer_map(priv->pipe, views[1]->texture, 0,
PIPE_TRANSFER_READ, &box, &transfer);
util_copy_rect(dst, views[1]->texture->format, def->nStride, 0, 0,
diff --git a/src/gallium/state_trackers/omx/vid_dec_h264.c
b/src/gallium/state_trackers/omx/vid_dec_h264.c
index b453682..75f27d2 100644
--- a/src/gallium/state_trackers/omx/vid_dec_h264.c
+++ b/src/gallium/state_trackers/omx/vid_dec_h264.c
@@ -91,7 +91,7 @@ void vid_dec_h264_Init(vid_dec_PrivateType *priv)
priv->Decode = vid_dec_h264_Decode;
priv->EndFrame = vid_dec_h264_EndFrame;
priv->Flush = vid_dec_h264_Flush;
-
+
LIST_INITHEAD(&priv->codec_data.h264.dpb_list);
priv->picture.h264.field_order_cnt[0] =
priv->picture.h264.field_order_cnt[1] = INT_MAX;
}
@@ -829,7 +829,7 @@ static void slice_header(vid_dec_PrivateType *priv, struct
vl_rbsp *rbsp,
priv->picture.h264.field_order_cnt[0] = expectedPicOrderCnt +
priv->codec_data.h264.delta_pic_order_cnt[0];
priv->picture.h264.field_order_cnt[1] =
priv->picture.h264.field_order_cnt[0] +
sps->offset_for_top_to_bottom_field +
priv->codec_data.h264.delta_pic_order_cnt[1];
-
+
} else if (!priv->picture.h264.bottom_field_flag)
priv->picture.h264.field_order_cnt[0] = expectedPicOrderCnt +
priv->codec_data.h264.delta_pic_order_cnt[0];
else
@@ -859,7 +859,7 @@ static void slice_header(vid_dec_PrivateType *priv, struct
vl_rbsp *rbsp,
if (!priv->picture.h264.field_pic_flag) {
priv->picture.h264.field_order_cnt[0] = tempPicOrderCnt;
priv->picture.h264.field_order_cnt[1] = tempPicOrderCnt;
-
+
} else if (!priv->picture.h264.bottom_field_flag)
priv->picture.h264.field_order_cnt[0] = tempPicOrderCnt;
else
@@ -876,7 +876,7 @@ static void slice_header(vid_dec_PrivateType *priv, struct
vl_rbsp *rbsp,
priv->picture.h264.num_ref_idx_l0_active_minus1 =
pps->num_ref_idx_l0_default_active_minus1;
priv->picture.h264.num_ref_idx_l1_active_minus1 =
pps->num_ref_idx_l1_default_active_minus1;
-
+
if (slice_type == PIPE_H264_SLICE_TYPE_P ||
slice_type == PIPE_H264_SLICE_TYPE_SP ||
slice_type == PIPE_H264_SLICE_TYPE_B) {
diff --git a/src/gallium/state_trackers/omx/vid_enc.c
b/src/gallium/state_trackers/omx/vid_enc.c
index df22a97..4505fe1 100644
--- a/src/gallium/state_trackers/omx/vid_enc.c
+++ b/src/gallium/state_trackers/omx/vid_enc.c
@@ -179,7 +179,7 @@ static OMX_ERRORTYPE vid_enc_Constructor(OMX_COMPONENTTYPE
*comp, OMX_STRING nam
if (!screen->get_video_param(screen, PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
PIPE_VIDEO_ENTRYPOINT_ENCODE,
PIPE_VIDEO_CAP_SUPPORTED))
return OMX_ErrorBadParameter;
-
+
priv->stacked_frames_num = screen->get_video_param(screen,
PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
PIPE_VIDEO_ENTRYPOINT_ENCODE,
@@ -242,7 +242,7 @@ static OMX_ERRORTYPE vid_enc_Constructor(OMX
[Mesa-dev] [PATCH 09/12] glsl: Add a pass to propagate the "invariant" and "precise" qualifiers
---
src/compiler/Makefile.sources | 1 +
src/compiler/glsl/glsl_parser_extras.cpp | 1 +
src/compiler/glsl/ir_optimization.h| 1 +
src/compiler/glsl/propagate_invariance.cpp | 125 +
4 files changed, 128 insertions(+)
create mode 100644 src/compiler/glsl/propagate_invariance.cpp
diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 9f3bcf0..6ab0aa7 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -129,6 +129,7 @@ LIBGLSL_FILES = \
glsl/opt_tree_grafting.cpp \
glsl/opt_vectorize.cpp \
glsl/program.h \
+ glsl/propagate_invariance.cpp \
glsl/s_expression.cpp \
glsl/s_expression.h
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
b/src/compiler/glsl/glsl_parser_extras.cpp
index 1c6cd43..9fcca21 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -1885,6 +1885,7 @@ do_common_optimization(exec_list *ir, bool linked,
OPT(do_dead_functions, ir);
OPT(do_structure_splitting, ir);
}
+ propagate_invariance(ir);
OPT(do_if_simplification, ir);
OPT(opt_flatten_nested_if_blocks, ir);
OPT(opt_conditional_discard, ir);
diff --git a/src/compiler/glsl/ir_optimization.h
b/src/compiler/glsl/ir_optimization.h
index b56413a..4616f16 100644
--- a/src/compiler/glsl/ir_optimization.h
+++ b/src/compiler/glsl/ir_optimization.h
@@ -138,6 +138,7 @@ bool lower_tess_level(gl_shader *shader);
bool lower_vertex_id(gl_shader *shader);
bool lower_subroutine(exec_list *instructions, struct _mesa_glsl_parse_state
*state);
+void propagate_invariance(exec_list *instructions);
ir_rvalue *
compare_index_block(exec_list *instructions, ir_variable *index,
diff --git a/src/compiler/glsl/propagate_invariance.cpp
b/src/compiler/glsl/propagate_invariance.cpp
new file mode 100644
index 000..820259e
--- /dev/null
+++ b/src/compiler/glsl/propagate_invariance.cpp
@@ -0,0 +1,125 @@
+/*
+ * Copyright © 2010 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+/**
+ * \file propagate_invariance.cpp
+ * Propagate the "invariant" and "precise" qualifiers to variables used to
+ * compute invariant or precise values.
+ *
+ * The GLSL spec (depending on what version you read) says, among the
+ * conditions for geting bit-for-bit the same values on an invariant output:
+ *
+ *"All operations in the consuming expressions and any intermediate
+ *expressions must be the same, with the same order of operands and same
+ *associativity, to give the same order of evaluation."
+ *
+ * This effectively means that if a variable is used to compute an invariant
+ * value then that variable becomes invariant. The same should apply to the
+ * "precise" qualifier.
+ */
+
+#include "ir.h"
+#include "ir_visitor.h"
+#include "ir_rvalue_visitor.h"
+#include "ir_optimization.h"
+#include "compiler/glsl_types.h"
+
+namespace {
+
+class ir_invariance_propagation_visitor : public ir_hierarchical_visitor {
+public:
+ ir_invariance_propagation_visitor()
+ {
+ this->progress = false;
+ this->dst_var = NULL;
+ }
+
+ virtual ~ir_invariance_propagation_visitor()
+ {
+ /* empty */
+ }
+
+ virtual ir_visitor_status visit_enter(ir_assignment *ir);
+ virtual ir_visitor_status visit_leave(ir_assignment *ir);
+ virtual ir_visitor_status visit(ir_dereference_variable *ir);
+
+ ir_variable *dst_var;
+ bool progress;
+};
+
+} /* unnamed namespace */
+
+ir_visitor_status
+ir_invariance_propagation_visitor::visit_enter(ir_assignment *ir)
+{
+ assert(this->dst_var == NULL);
+ ir_variable *var = ir->lhs->variable_referenced();
+ if (var->data.invariant || var->data.precise) {
+ this->dst_var = var;
+ return visit_continue;
+ } else {
+ return visit_continue_with_parent;
+ }
+}
+
+ir_visi
Re: [Mesa-dev] [PATCH 10/21] nir/dominance: Handle unreachable blocks
On Wed, Feb 24, 2016 at 10:02 PM, Connor Abbott wrote:
> I believe this is correct, and won't cause any issues with phi node
> placement, etc. before dead_cf comes and gets rid any code in the
> unreachable block(s).
>
> Reviewed-by: Connor Abbott
>
> BTW, I'd ask that you hold off on pushing this until I at least get a
> chance to look at the phi builder stuff. I've already talked with you
> about the return lowering pass, and the inlining itself shouldn't be
> *that* bad, but when I glanced at the phi builder interface I couldn't
> grasp quite what was going on.
>
Um... Ping? I'd really like to get the rest of this pushed as soon as I
can.
>
>
> On Sat, Feb 13, 2016 at 9:14 PM, Jason Ekstrand
> wrote:
> > Previously, nir_dominance.c didn't properly handle unreachable blocks.
> > This can happen if, for instance, you have something like this:
> >
> > loop {
> >if (...) {
> > break;
> >} else {
> > break;
> >}
> > }
> >
> > In this case, the block right after the if statement will be unreachable.
> > This commit makes two changes to handle this. First, it removes an
> assert
> > and allows block->imm_dom to be null if the block is unreachable.
> Second,
> > it properly skips unreachable blocks in calc_dom_frontier_cb.
> >
> > Cc: Connor Abbott
> > ---
> > src/compiler/nir/nir_dominance.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/compiler/nir/nir_dominance.c
> b/src/compiler/nir/nir_dominance.c
> > index b345b85..d95f396 100644
> > --- a/src/compiler/nir/nir_dominance.c
> > +++ b/src/compiler/nir/nir_dominance.c
> > @@ -94,7 +94,6 @@ calc_dominance_cb(nir_block *block, void *_state)
> >}
> > }
> >
> > - assert(new_idom);
> > if (block->imm_dom != new_idom) {
> >block->imm_dom = new_idom;
> >state->progress = true;
> > @@ -112,6 +111,11 @@ calc_dom_frontier_cb(nir_block *block, void *state)
> >struct set_entry *entry;
> >set_foreach(block->predecessors, entry) {
> > nir_block *runner = (nir_block *) entry->key;
> > +
> > + /* Skip unreachable predecessors */
> > + if (runner->imm_dom == NULL)
> > +continue;
> > +
> > while (runner != block->imm_dom) {
> > _mesa_set_add(runner->dom_frontier, block);
> > runner = runner->imm_dom;
> > --
> > 2.5.0.400.gff86faf
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] compiler: Check if check_explicit_uniform_locations has failed.
On 03/18/2016 04:41 PM, Plamena Manolova wrote: We should check whether check_explicit_uniform_locations has failed before we pass the number of explicit uniform locations to link_assign_uniform_locations. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94549#c3 --- src/compiler/glsl/linker.cpp | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp index 76b700d..a2091f4 100644 --- a/src/compiler/glsl/linker.cpp +++ b/src/compiler/glsl/linker.cpp @@ -4324,6 +4324,7 @@ link_shaders(struct gl_context *ctx, struct gl_shader_program *prog) goto done; unsigned first, last, prev; + int result; first = MESA_SHADER_STAGES; last = 0; @@ -4337,7 +4338,11 @@ link_shaders(struct gl_context *ctx, struct gl_shader_program *prog) last = i; } - num_explicit_uniform_locs = check_explicit_uniform_locations(ctx, prog); + result = check_explicit_uniform_locations(ctx, prog); + Some nitpicks: I would remove the space between assigning result, and the 'if' below. + if (result > 0) + num_explicit_uniform_locs = result; + link_assign_subroutine_types(prog); if (!prog->LinkStatus) What about renaming 'result' to something like 'tmp_num_locs' or 'local_num_locs'. Naming it 'result' is a bit deceiving, since it is not a result but rather an intermediate value. thanks! Reviewed-by: Eduardo Lima Mitev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/11] gallium/tgsi: pass TGSI tex target to tgsi_transform_tex_inst()
Instead of hard-coded 2D tex target in tgsi_transform_tex_2d_inst()
---
src/gallium/auxiliary/draw/draw_pipe_aaline.c| 10 +-
src/gallium/auxiliary/tgsi/tgsi_transform.h | 17 ++---
src/gallium/auxiliary/util/u_pstipple.c | 10 +-
src/mesa/state_tracker/st_cb_bitmap_shader.c | 8
src/mesa/state_tracker/st_cb_drawpixels_shader.c | 6 +++---
5 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index e85ae16..cd9ee54 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -264,11 +264,11 @@ aa_transform_epilog(struct tgsi_transform_context *ctx)
if (aactx->colorOutput != -1) {
/* insert texture sampling code for antialiasing. */
- /* TEX texTemp, input_coord, sampler */
- tgsi_transform_tex_2d_inst(ctx,
- TGSI_FILE_TEMPORARY, aactx->texTemp,
- TGSI_FILE_INPUT, aactx->maxInput + 1,
- aactx->freeSampler);
+ /* TEX texTemp, input_coord, sampler, 2D */
+ tgsi_transform_tex_inst(ctx,
+ TGSI_FILE_TEMPORARY, aactx->texTemp,
+ TGSI_FILE_INPUT, aactx->maxInput + 1,
+ TGSI_TEXTURE_2D, aactx->freeSampler);
/* MOV rgb */
tgsi_transform_op1_inst(ctx, TGSI_OPCODE_MOV,
diff --git a/src/gallium/auxiliary/tgsi/tgsi_transform.h
b/src/gallium/auxiliary/tgsi/tgsi_transform.h
index 4dd7dda..c21ff95 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_transform.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_transform.h
@@ -516,15 +516,18 @@ tgsi_transform_kill_inst(struct tgsi_transform_context
*ctx,
static inline void
-tgsi_transform_tex_2d_inst(struct tgsi_transform_context *ctx,
- unsigned dst_file,
- unsigned dst_index,
- unsigned src_file,
- unsigned src_index,
- unsigned sampler_index)
+tgsi_transform_tex_inst(struct tgsi_transform_context *ctx,
+unsigned dst_file,
+unsigned dst_index,
+unsigned src_file,
+unsigned src_index,
+unsigned tex_target,
+unsigned sampler_index)
{
struct tgsi_full_instruction inst;
+ assert(tex_target < TGSI_TEXTURE_COUNT);
+
inst = tgsi_default_full_instruction();
inst.Instruction.Opcode = TGSI_OPCODE_TEX;
inst.Instruction.NumDstRegs = 1;
@@ -532,7 +535,7 @@ tgsi_transform_tex_2d_inst(struct tgsi_transform_context
*ctx,
inst.Dst[0].Register.Index = dst_index;
inst.Instruction.NumSrcRegs = 2;
inst.Instruction.Texture = TRUE;
- inst.Texture.Texture = TGSI_TEXTURE_2D;
+ inst.Texture.Texture = tex_target;
inst.Src[0].Register.File = src_file;
inst.Src[0].Register.Index = src_index;
inst.Src[1].Register.File = TGSI_FILE_SAMPLER;
diff --git a/src/gallium/auxiliary/util/u_pstipple.c
b/src/gallium/auxiliary/util/u_pstipple.c
index 74e6f99..bcbe2a2 100644
--- a/src/gallium/auxiliary/util/u_pstipple.c
+++ b/src/gallium/auxiliary/util/u_pstipple.c
@@ -344,11 +344,11 @@ pstip_transform_prolog(struct tgsi_transform_context *ctx)
pctx->wincoordFile, wincoordInput,
TGSI_FILE_IMMEDIATE, pctx->numImmed);
- /* TEX texTemp, texTemp, sampler; */
- tgsi_transform_tex_2d_inst(ctx,
- TGSI_FILE_TEMPORARY, texTemp,
- TGSI_FILE_TEMPORARY, texTemp,
- sampIdx);
+ /* TEX texTemp, texTemp, sampler, 2D; */
+ tgsi_transform_tex_inst(ctx,
+ TGSI_FILE_TEMPORARY, texTemp,
+ TGSI_FILE_TEMPORARY, texTemp,
+ TGSI_TEXTURE_2D, sampIdx);
/* KILL_IF -texTemp; # if -texTemp < 0, kill fragment */
tgsi_transform_kill_inst(ctx,
diff --git a/src/mesa/state_tracker/st_cb_bitmap_shader.c
b/src/mesa/state_tracker/st_cb_bitmap_shader.c
index 88779bc..42aa033 100644
--- a/src/mesa/state_tracker/st_cb_bitmap_shader.c
+++ b/src/mesa/state_tracker/st_cb_bitmap_shader.c
@@ -89,10 +89,10 @@ transform_instr(struct tgsi_transform_context *tctx,
tgsi_transform_sampler_decl(tctx, ctx->sampler_index);
/* TEX tmp0, fragment.texcoord[0], texture[0], 2D; */
- tgsi_transform_tex_2d_inst(tctx,
- TGSI_FILE_TEMPORARY, 0,
- TGSI_FILE_INPUT, texcoord_index,
- ctx->sampler_index);
+ tgsi_transform_tex_inst(tctx,
+ TGSI_FILE_TEMPORARY, 0,
+ TGSI_FILE_INPUT, texcoord_index,
+ TGSI_TEXTURE_2D, c
Re: [Mesa-dev] [PATCH] meta: Make BlitFramebuffer() do sRGB encoding in ES 3.x.
Reviewed-by: Jordan Justen
On 2016-03-15 00:49:47, Kenneth Graunke wrote:
> According to the ES 3.0 and GL 4.4 specifications, glBlitFramebuffer
> is supposed to perform sRGB decoding and encoding whenever sRGB formats
> are in use. The ES 3.0 specification is completely clear, and has
> always stated this.
>
> However, the GL specification has changed behavior in 4.1, 4.2, and
> 4.4. The original behavior stated that no sRGB encoding should occur.
> The 4.4 behavior matches ES 3.0's wording. However, implementing the
> new behavior appears to break applications such as Left 4 Dead 2.
>
> This patch changes Meta to apply the ES 3.x rules in ES 3.x, but
> leaves OpenGL alone for now, to avoid breaking applications.
>
> Meta implements several other functions in terms of BlitFramebuffer,
> and many of those explicitly do not perform sRGB encoding. So, this
> patch explicitly disables sRGB encoding in those other functions,
> preserving the existing (correct) behavior.
>
> Fixes scores of dEQP-GLES3.functional.fbo.blit.conversion.*srgb* tests.
>
> If you're from the future and are reading this, hi! Welcome to
> the "fun" of debugging sRGB problems! Best of luck!
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/common/meta_blit.c | 43
> +++--
> src/mesa/drivers/common/meta_copy_image.c | 3 ++
> src/mesa/drivers/common/meta_tex_subimage.c | 6
> 3 files changed, 43 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta_blit.c
> b/src/mesa/drivers/common/meta_blit.c
> index 5d80f7d..58205e7 100644
> --- a/src/mesa/drivers/common/meta_blit.c
> +++ b/src/mesa/drivers/common/meta_blit.c
> @@ -594,6 +594,7 @@ blitframebuffer_texture(struct gl_context *ctx,
> GLenum filter, GLint flipX, GLint flipY,
> GLboolean glsl_version, GLboolean do_depth)
> {
> + struct save_state *save = &ctx->Meta->Save[ctx->Meta->SaveStackDepth - 1];
> int att_index = do_depth ? BUFFER_DEPTH : readFb->_ColorReadBufferIndex;
> const struct gl_renderbuffer_attachment *readAtt =
>&readFb->Attachment[att_index];
> @@ -706,7 +707,7 @@ blitframebuffer_texture(struct gl_context *ctx,
> fb_tex_blit.samp_obj = _mesa_meta_setup_sampler(ctx, texObj, target,
> filter,
> srcLevel);
>
> - /* Always do our blits with no net sRGB decode or encode.
> + /* For desktop GL, we do our blits with no net sRGB decode or encode.
> *
> * However, if both the src and dst can be srgb decode/encoded, enable
> them
> * so that we do any blending (from scaling or from MSAA resolves) in the
> @@ -720,18 +721,42 @@ blitframebuffer_texture(struct gl_context *ctx,
> * scissor test."
> *
> * The GL 4.4 specification disagrees and says that the sRGB part of the
> -* fragment pipeline applies, but this was found to break applications.
> +* fragment pipeline applies, but this was found to break applications
> +* (such as Left 4 Dead 2).
> +*
> +* However, for ES 3.0, we follow the specification and perform sRGB
> +* decoding and encoding. The specification has always been clear in
> +* the ES world, and hasn't changed over time.
> */
> if (ctx->Extensions.EXT_texture_sRGB_decode) {
> - if (_mesa_get_format_color_encoding(rb->Format) == GL_SRGB &&
> - drawFb->Visual.sRGBCapable) {
> + bool src_srgb = _mesa_get_format_color_encoding(rb->Format) == GL_SRGB;
> + if (save->API == API_OPENGLES2 && ctx->Version >= 30) {
> + /* From the ES 3.0.4 specification, page 198:
> + * "When values are taken from the read buffer, if the value of
> + * FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer
> + * attachment corresponding to the read buffer is SRGB (see section
> + * 6.1.13), the red, green, and blue components are converted from
> + * the non-linear sRGB color space according to equation 3.24.
> + *
> + * When values are written to the draw buffers, blit operations
> + * bypass the fragment pipeline. The only fragment operations which
> + * affect a blit are the pixel ownership test, the scissor test,
> + * and sRGB conversion (see section 4.1.8)."
> + */
> _mesa_set_sampler_srgb_decode(ctx, fb_tex_blit.samp_obj,
> - GL_DECODE_EXT);
> - _mesa_set_framebuffer_srgb(ctx, GL_TRUE);
> + src_srgb ? GL_DECODE_EXT
> +: GL_SKIP_DECODE_EXT);
> + _mesa_set_framebuffer_srgb(ctx, drawFb->Visual.sRGBCapable);
>} else {
> - _mesa_set_sampler_srgb_decode(ctx, fb_tex_blit.samp_obj,
> - GL_SKIP_DECODE_EXT);
> - /* set_framebuffer_srgb was set by _mesa_meta_be
Re: [Mesa-dev] [PATCH] nv50,nvc0: Fix invalid constant.
On Mar 19, 2016 8:44 AM, "Pierre Moreau" wrote:
>
> On 06:34 PM - Mar 18 2016, Vinson Lee wrote:
> > Fix clang build error.
> >
> > CXX codegen/nv50_ir_lowering_nvc0.lo
> > codegen/nv50_ir_lowering_nvc0.cpp:1783:42: error: invalid suffix 'd' on
floating constant
> > Value *zero = bld.loadImm(NULL, 0.0d);
> > ^
> >
> > Fixes: c1e4a6bfbf01 ("nv50,nvc0: handle SQRT lowering inside the
driver")
> > Signed-off-by: Vinson Lee
> > ---
> > src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > index d0936d8..01364b3 100644
> > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > @@ -1780,7 +1780,7 @@ NVC0LoweringPass::handleSQRT(Instruction *i)
> > {
> > if (i->dType == TYPE_F64) {
> >Value *pred = bld.getSSA(1, FILE_PREDICATE);
> > - Value *zero = bld.loadImm(NULL, 0.0d);
> > + Value *zero = bld.loadImm(NULL, 0);
>
> Shouldn't it rather be: `Value *zero = bld.loadImm(NULL, 0.0);` as you
want a
> double, not an int?
E, right, yes it should be.
>
> >Value *dst = bld.getSSA(8);
> >bld.mkOp1(OP_RSQ, i->dType, dst, i->getSrc(0));
> >bld.mkCmp(OP_SET, CC_LE, i->dType, pred, i->dType, i->getSrc(0),
zero);
> > --
> > 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/17] gallium: Add PIPE_CAP_MSAA_MODES
Why not derive this information from is_format_supported with rgba8 format? Seems like that would do the trick. Look at how the st already does something similar in st_extensions.c iirc. Your scheme only enables power-of-two msaa levels, and is redundant wrt the function I mentioned earlier... As I said to you on a number of previous occasions, the "no attachments" cap should just be a boolean. -ilia On Mar 19, 2016 2:42 AM, "Edward O'Callaghan" wrote: > Add PIPE_CAP to determine the MSAA modes the hardware > supports so that values requested from the application > using GL_ARB_framebuffer_no_attachments may be quantized > to what the hardware expects. > > V.2: > Fix doc for a more detailed description of the PIPE_CAP > and the corresponding GL constant. > > Signed-off-by: Edward O'Callaghan > --- > src/gallium/docs/source/screen.rst | 7 +++ > src/gallium/drivers/freedreno/freedreno_screen.c | 1 + > src/gallium/drivers/i915/i915_screen.c | 1 + > src/gallium/drivers/ilo/ilo_screen.c | 1 + > src/gallium/drivers/llvmpipe/lp_screen.c | 1 + > src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + > src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + > src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + > src/gallium/drivers/r300/r300_screen.c | 1 + > src/gallium/drivers/r600/r600_pipe.c | 1 + > src/gallium/drivers/radeonsi/si_pipe.c | 1 + > src/gallium/drivers/softpipe/sp_screen.c | 1 + > src/gallium/drivers/svga/svga_screen.c | 1 + > src/gallium/drivers/vc4/vc4_screen.c | 1 + > src/gallium/drivers/virgl/virgl_screen.c | 1 + > src/gallium/include/pipe/p_defines.h | 1 + > src/mesa/state_tracker/st_extensions.c | 1 + > 17 files changed, 23 insertions(+) > > diff --git a/src/gallium/docs/source/screen.rst > b/src/gallium/docs/source/screen.rst > index 46ec381..d3d8dc4 100644 > --- a/src/gallium/docs/source/screen.rst > +++ b/src/gallium/docs/source/screen.rst > @@ -323,6 +323,13 @@ The integer capabilities: > * ``PIPE_CAP_PCI_BUS``: Return the PCI bus number. > * ``PIPE_CAP_PCI_DEVICE``: Return the PCI device number. > * ``PIPE_CAP_PCI_FUNCTION``: Return the PCI function number. > +* ``PIPE_CAP_MSAA_MODES``: > + A bitmask of the supported MSAA modes the hardware supports. e.g., > + (1 << 5) | .. | (1 << 1). If non-zero, rendering to framebuffers with no > + surface attachments is supported. N.B., The maximum number of layers > + supported for rasterizing a primitive on a layer is obtained from > + ``PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS`` even though it can be larger than > + the number of layers supported by either rendering or textures. > > > .. _pipe_capf: > diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c > b/src/gallium/drivers/freedreno/freedreno_screen.c > index d47cb07..8b6ebe8 100644 > --- a/src/gallium/drivers/freedreno/freedreno_screen.c > +++ b/src/gallium/drivers/freedreno/freedreno_screen.c > @@ -255,6 +255,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum > pipe_cap param) > case PIPE_CAP_INVALIDATE_BUFFER: > case PIPE_CAP_GENERATE_MIPMAP: > case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS: > + case PIPE_CAP_MSAA_MODES: > return 0; > > case PIPE_CAP_MAX_VIEWPORTS: > diff --git a/src/gallium/drivers/i915/i915_screen.c > b/src/gallium/drivers/i915/i915_screen.c > index f4aa310..02457c5 100644 > --- a/src/gallium/drivers/i915/i915_screen.c > +++ b/src/gallium/drivers/i915/i915_screen.c > @@ -269,6 +269,7 @@ i915_get_param(struct pipe_screen *screen, enum > pipe_cap cap) > case PIPE_CAP_PCI_BUS: > case PIPE_CAP_PCI_DEVICE: > case PIPE_CAP_PCI_FUNCTION: > + case PIPE_CAP_MSAA_MODES: >return 0; > > case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS: > diff --git a/src/gallium/drivers/ilo/ilo_screen.c > b/src/gallium/drivers/ilo/ilo_screen.c > index 548d215..49fe658 100644 > --- a/src/gallium/drivers/ilo/ilo_screen.c > +++ b/src/gallium/drivers/ilo/ilo_screen.c > @@ -497,6 +497,7 @@ ilo_get_param(struct pipe_screen *screen, enum > pipe_cap param) > case PIPE_CAP_PCI_BUS: > case PIPE_CAP_PCI_DEVICE: > case PIPE_CAP_PCI_FUNCTION: > + case PIPE_CAP_MSAA_MODES: >return 0; > > case PIPE_CAP_VENDOR_ID: > diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c > b/src/gallium/drivers/llvmpipe/lp_screen.c > index 2529b54..db3eff7 100644 > --- a/src/gallium/drivers/llvmpipe/lp_screen.c > +++ b/src/gallium/drivers/llvmpipe/lp_screen.c > @@ -319,6 +319,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum > pipe_cap param) > case PIPE_CAP_PCI_BUS: > case PIPE_CAP_PCI_DEVICE: > case PIPE_CAP_PCI_FUNCTION: > + case PIPE_CAP_MSAA_MODES: >return 0; > } > /* should only get here on unhandled cases */ > diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c > b/src/gallium/drivers/nouveau/nv30/nv30
Re: [Mesa-dev] [PATCH] i965: Fix stencil texturing in ES 3.1.
On Wed, Mar 16, 2016 at 07:25:56PM -0700, Kenneth Graunke wrote:
> Stencil texturing is required by ES 3.1. Apparently we never actually
> turned it on, and we missed some necessary code.
>
> Fixes nine dEQP-GLES31.functional tests:
>
> stencil_texturing.format.stencil_index8_2d
> texture.border_clamp.formats.stencil_index8.nearest_size_pot
> texture.border_clamp.formats.stencil_index8.nearest_size_npot
> texture.border_clamp.formats.stencil_index8.gather_size_pot
> texture.border_clamp.formats.stencil_index8.gather_size_npot
> texture.border_clamp.unused_channels.stencil_index8
> state_query.internal_format.renderbuffer.stencil_index8_samples
> state_query.internal_format.texture_2d_multisample.stencil_index8_samples
> state_query.internal_format.texture_2d_multisample_array.stencil_index8_samples
>
> For now, leave it turned off in desktop GL. There are still bugs with
> stencil array textures, and I suspect there are multisampling bugs too.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
> src/mesa/drivers/dri/i965/intel_extensions.c| 2 ++
> src/mesa/main/texformat.c | 5 +
> 3 files changed, 8 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
> b/src/mesa/drivers/dri/i965/brw_surface_formats.c
> index 3c0b23b..a1160d9 100644
> --- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
> +++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
> @@ -718,6 +718,7 @@ brw_init_surface_formats(struct brw_context *brw)
> ctx->TextureFormatSupported[MESA_FORMAT_Z24_UNORM_X8_UINT] = true;
> ctx->TextureFormatSupported[MESA_FORMAT_Z_FLOAT32] = true;
> ctx->TextureFormatSupported[MESA_FORMAT_Z32_FLOAT_S8X24_UINT] = true;
> + ctx->TextureFormatSupported[MESA_FORMAT_S_UINT8] = true;
>
> /* Benchmarking shows that Z16 is slower than Z24, so there's no reason to
> * use it unless you're under memory (not memory bandwidth) pressure.
> diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
> b/src/mesa/drivers/dri/i965/intel_extensions.c
> index 60ac124..8d9dab5 100644
> --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> @@ -367,6 +367,8 @@ intelInitExtensions(struct gl_context *ctx)
>
> if (brw->gen >= 8) {
>ctx->Extensions.ARB_stencil_texturing = true;
> + if (ctx->API == API_OPENGLES2)
> + ctx->Extensions.ARB_texture_stencil8 = true;
> }
>
We assert that this extension is disabled in brw_meta_stencil_blit().
Since one can call glBlitFramebuffer with a mask value of
GL_STENCIL_BUFFER_BIT in GLES, shouldn't we get rid of the assertion?
- Nanley
> if (brw->gen >= 9) {
> diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
> index 419fd78..be2581b 100644
> --- a/src/mesa/main/texformat.c
> +++ b/src/mesa/main/texformat.c
> @@ -765,6 +765,11 @@ _mesa_choose_tex_format(struct gl_context *ctx, GLenum
> target,
>RETURN_IF_SUPPORTED(MESA_FORMAT_B8G8R8A8_UNORM);
>break;
>
> + case GL_STENCIL_INDEX:
> + case GL_STENCIL_INDEX8:
> + RETURN_IF_SUPPORTED(MESA_FORMAT_S_UINT8);
> + break;
> +
> default:
>/* For non-generic compressed format we assert two things:
> *
> --
> 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
Re: [Mesa-dev] [PATCH 02/12] nir/builder: Add a flag for setting exact
On Thu, Mar 17, 2016 at 5:51 PM, Jason Ekstrand wrote:
> ---
> src/compiler/nir/nir_builder.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
> index d546e41..1d61ff9 100644
> --- a/src/compiler/nir/nir_builder.h
> +++ b/src/compiler/nir/nir_builder.h
> @@ -31,6 +31,9 @@ struct exec_list;
> typedef struct nir_builder {
> nir_cursor cursor;
>
> + /* Whether or not new ALU instructions will have exact results */
s/or not //
s/will have/must produce/ (???)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] st/mesa: emit sampler view declarations for ARB vert/frag programs
---
src/mesa/state_tracker/st_mesa_to_tgsi.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index 8a12ce4..7a686b1 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -297,6 +297,19 @@ st_translate_texture_target(GLuint textarget, GLboolean
shadow)
/**
+ * Translate a (1 << TEXTURE_x_INDEX) bit into a TGSI_TEXTURE_x enum.
+ */
+static unsigned
+translate_texture_index(GLbitfield texBit, bool shadow)
+{
+ int index = ffs(texBit);
+ assert(index > 0);
+ assert(index - 1 < NUM_TEXTURE_TARGETS);
+ return st_translate_texture_target(index - 1, shadow);
+}
+
+
+/**
* Create a TGSI ureg_dst register from a Mesa dest register.
*/
static struct ureg_dst
@@ -1147,7 +1160,16 @@ st_translate_mesa_program(
/* texture samplers */
for (i = 0; i <
ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits; i++) {
if (program->SamplersUsed & (1 << i)) {
+ unsigned target =
+translate_texture_index(program->TexturesUsed[i],
+!!(program->ShadowSamplers & (1 << i)));
t->samplers[i] = ureg_DECL_sampler( ureg, i );
+ ureg_DECL_sampler_view(ureg, i, target,
+TGSI_RETURN_TYPE_FLOAT,
+TGSI_RETURN_TYPE_FLOAT,
+TGSI_RETURN_TYPE_FLOAT,
+TGSI_RETURN_TYPE_FLOAT);
+
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] st/mesa: emit sampler view declaration in bitmap shader
In June 2015, Rob Clark started updating the tgsi utility code to emit SVIEW declarations in various shaders (for polygon stipple, blitting, etc). These patches do the same for the Mesa state tracker. The VMware driver will use this. --- src/mesa/state_tracker/st_cb_bitmap_shader.c | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/state_tracker/st_cb_bitmap_shader.c b/src/mesa/state_tracker/st_cb_bitmap_shader.c index 88779bc..5c02503 100644 --- a/src/mesa/state_tracker/st_cb_bitmap_shader.c +++ b/src/mesa/state_tracker/st_cb_bitmap_shader.c @@ -88,6 +88,10 @@ transform_instr(struct tgsi_transform_context *tctx, /* Declare the sampler. */ tgsi_transform_sampler_decl(tctx, ctx->sampler_index); + /* Declare the sampler view. */ + tgsi_transform_sampler_view_decl(tctx, ctx->sampler_index, +TGSI_TEXTURE_2D, TGSI_RETURN_TYPE_FLOAT); + /* TEX tmp0, fragment.texcoord[0], texture[0], 2D; */ tgsi_transform_tex_2d_inst(tctx, TGSI_FILE_TEMPORARY, 0, -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 13/17] radeonsi: Enable ARB_framebuffer_no_attachments
On Sat, Mar 19, 2016 at 7:41 AM, Edward O'Callaghan wrote: > Signed-off-by: Edward O'Callaghan > --- > src/gallium/drivers/radeonsi/si_pipe.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/radeonsi/si_pipe.c > b/src/gallium/drivers/radeonsi/si_pipe.c > index 46fa592..1472ccf 100644 > --- a/src/gallium/drivers/radeonsi/si_pipe.c > +++ b/src/gallium/drivers/radeonsi/si_pipe.c > @@ -357,7 +357,6 @@ static int si_get_param(struct pipe_screen* pscreen, enum > pipe_cap param) > case PIPE_CAP_GENERATE_MIPMAP: > case PIPE_CAP_STRING_MARKER: > case PIPE_CAP_QUERY_BUFFER_OBJECT: > - case PIPE_CAP_MSAA_MODES: > return 0; > > case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS: > @@ -397,6 +396,9 @@ static int si_get_param(struct pipe_screen* pscreen, enum > pipe_cap param) > /* textures support 8192, but layered rendering supports 2048 > */ > return 2048; > > + case PIPE_CAP_MSAA_MODES: > + return (1 << 5) | (1 << 4) | (1 << 3) | (1 << 2) | (1 << 1); > + Doesn't this need to be (1 << 4) | ... | (1 << 0) for 1 to 16 samples? - Bas > /* Render targets. */ > case PIPE_CAP_MAX_RENDER_TARGETS: > return 8; > -- > 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 01/17] gallium: Add PIPE_CAP_MSAA_MODES
That would limit us to supporting sample counts for which we have texture formats. As far as I understand with radeonsi we can support 16 samples without any attachments, but all formats are limited to <= 8 samples. - Bas On Sat, Mar 19, 2016 at 3:00 PM, Ilia Mirkin wrote: > Why not derive this information from is_format_supported with rgba8 format? > Seems like that would do the trick. Look at how the st already does > something similar in st_extensions.c iirc. > > Your scheme only enables power-of-two msaa levels, and is redundant wrt the > function I mentioned earlier... > > As I said to you on a number of previous occasions, the "no attachments" cap > should just be a boolean. > > -ilia > > On Mar 19, 2016 2:42 AM, "Edward O'Callaghan" > wrote: >> >> Add PIPE_CAP to determine the MSAA modes the hardware >> supports so that values requested from the application >> using GL_ARB_framebuffer_no_attachments may be quantized >> to what the hardware expects. >> >> V.2: >> Fix doc for a more detailed description of the PIPE_CAP >> and the corresponding GL constant. >> >> Signed-off-by: Edward O'Callaghan >> --- >> src/gallium/docs/source/screen.rst | 7 +++ >> src/gallium/drivers/freedreno/freedreno_screen.c | 1 + >> src/gallium/drivers/i915/i915_screen.c | 1 + >> src/gallium/drivers/ilo/ilo_screen.c | 1 + >> src/gallium/drivers/llvmpipe/lp_screen.c | 1 + >> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + >> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + >> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + >> src/gallium/drivers/r300/r300_screen.c | 1 + >> src/gallium/drivers/r600/r600_pipe.c | 1 + >> src/gallium/drivers/radeonsi/si_pipe.c | 1 + >> src/gallium/drivers/softpipe/sp_screen.c | 1 + >> src/gallium/drivers/svga/svga_screen.c | 1 + >> src/gallium/drivers/vc4/vc4_screen.c | 1 + >> src/gallium/drivers/virgl/virgl_screen.c | 1 + >> src/gallium/include/pipe/p_defines.h | 1 + >> src/mesa/state_tracker/st_extensions.c | 1 + >> 17 files changed, 23 insertions(+) >> >> diff --git a/src/gallium/docs/source/screen.rst >> b/src/gallium/docs/source/screen.rst >> index 46ec381..d3d8dc4 100644 >> --- a/src/gallium/docs/source/screen.rst >> +++ b/src/gallium/docs/source/screen.rst >> @@ -323,6 +323,13 @@ The integer capabilities: >> * ``PIPE_CAP_PCI_BUS``: Return the PCI bus number. >> * ``PIPE_CAP_PCI_DEVICE``: Return the PCI device number. >> * ``PIPE_CAP_PCI_FUNCTION``: Return the PCI function number. >> +* ``PIPE_CAP_MSAA_MODES``: >> + A bitmask of the supported MSAA modes the hardware supports. e.g., >> + (1 << 5) | .. | (1 << 1). If non-zero, rendering to framebuffers with >> no >> + surface attachments is supported. N.B., The maximum number of layers >> + supported for rasterizing a primitive on a layer is obtained from >> + ``PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS`` even though it can be larger than >> + the number of layers supported by either rendering or textures. >> >> >> .. _pipe_capf: >> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c >> b/src/gallium/drivers/freedreno/freedreno_screen.c >> index d47cb07..8b6ebe8 100644 >> --- a/src/gallium/drivers/freedreno/freedreno_screen.c >> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c >> @@ -255,6 +255,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum >> pipe_cap param) >> case PIPE_CAP_INVALIDATE_BUFFER: >> case PIPE_CAP_GENERATE_MIPMAP: >> case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS: >> + case PIPE_CAP_MSAA_MODES: >> return 0; >> >> case PIPE_CAP_MAX_VIEWPORTS: >> diff --git a/src/gallium/drivers/i915/i915_screen.c >> b/src/gallium/drivers/i915/i915_screen.c >> index f4aa310..02457c5 100644 >> --- a/src/gallium/drivers/i915/i915_screen.c >> +++ b/src/gallium/drivers/i915/i915_screen.c >> @@ -269,6 +269,7 @@ i915_get_param(struct pipe_screen *screen, enum >> pipe_cap cap) >> case PIPE_CAP_PCI_BUS: >> case PIPE_CAP_PCI_DEVICE: >> case PIPE_CAP_PCI_FUNCTION: >> + case PIPE_CAP_MSAA_MODES: >>return 0; >> >> case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS: >> diff --git a/src/gallium/drivers/ilo/ilo_screen.c >> b/src/gallium/drivers/ilo/ilo_screen.c >> index 548d215..49fe658 100644 >> --- a/src/gallium/drivers/ilo/ilo_screen.c >> +++ b/src/gallium/drivers/ilo/ilo_screen.c >> @@ -497,6 +497,7 @@ ilo_get_param(struct pipe_screen *screen, enum >> pipe_cap param) >> case PIPE_CAP_PCI_BUS: >> case PIPE_CAP_PCI_DEVICE: >> case PIPE_CAP_PCI_FUNCTION: >> + case PIPE_CAP_MSAA_MODES: >>return 0; >> >> case PIPE_CAP_VENDOR_ID: >> diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c >> b/src/gallium/drivers/llvmpipe/lp_screen.c >> index 2529b54..db3eff7 100644 >> --- a/src/gallium/drivers/llvmpipe/lp_screen.c >> +++ b/src/gallium/drivers/llvmpipe/lp_screen
Re: [Mesa-dev] [PATCH 01/17] gallium: Add PIPE_CAP_MSAA_MODES
On Sat, Mar 19, 2016 at 11:14 AM, Bas Nieuwenhuizen wrote: > That would limit us to supporting sample counts for which we have > texture formats. > > As far as I understand with radeonsi we can support 16 samples without > any attachments, but all formats are limited to <= 8 samples. So you're going to end up with a situation where GL_MAX_SAMPLES is less than GL_MAX_FRAMEBUFFER_SAMPLES? I don't know that that's a useful thing to have. This implementation still has the problem of only supporting POT MSAA levels (although tbh I'm not 100% sure there's hw out there that supports NPOT MSAA levels). If people really want this, I think the way to go would be to make is_format_supported() work with PIPE_FORMAT_NONE and do it that way. Also, are you *sure* that's the case on radeonsi? I find it very odd that the rasterizer would support a higher MSAA level than the highest attachment would... -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/17] nvc0: Enable ARB_framebuffer_no_attachment
On Sat, Mar 19, 2016 at 2:41 AM, Edward O'Callaghan
wrote:
> Signed-off-by: Edward O'Callaghan
> ---
> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> index 910143f..4a00d92 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> @@ -229,9 +229,11 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
> pipe_cap param)
> case PIPE_CAP_PCI_BUS:
> case PIPE_CAP_PCI_DEVICE:
> case PIPE_CAP_PCI_FUNCTION:
> - case PIPE_CAP_MSAA_MODES:
>return 0;
>
> + case PIPE_CAP_MSAA_MODES:
> + return (1 << 5) | (1 << 4) | (1 << 3) | (1 << 2) | (1 << 1);
NVIDIA hw only supports up to MSAA 8. Also this would have to go in
the section where the other "odd" valued values are defined, above the
"enabled" and "disabled" sections.
> +
> case PIPE_CAP_VENDOR_ID:
>return 0x10de;
> case PIPE_CAP_DEVICE_ID: {
> --
> 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 94522] llvmpipe crash in rendering on Atom
https://bugs.freedesktop.org/show_bug.cgi?id=94522 --- Comment #15 from comicfans44 --- (In reply to Pekka Paalanen from comment #14) > (In reply to Jose Fonseca from comment #13) > > I wonder if 0xa8ec01b0 is some sort of funky device memory, or if that > > device memory was destroyed before llvmpipe was done. > > > > After all this is SwapBuffers path. > > That's very likely, isn't it? > > comicfans44, can you confirm the dri module used, I would assume it is > kms_swrast_dri.so? EGL_LOG_LEVEL=debug environment variable will fish it out. > with EGL_LOG_LEVEL=debug weston print log as follows(maybe including weston log ) [22:11:38.630] weston 1.10.0 http://wayland.freedesktop.org Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.10.0 Build: 1.9.93-2-gd45de28 configure.ac: bump to version 1.10.0 for the official release (2016-02-16 12:37:43 -0800) [22:11:38.639] OS: Linux, 4.4.5-1-ARCH, #1 SMP PREEMPT Thu Mar 10 07:54:30 CET 2016, i686 [22:11:38.640] Starting with no config file. [22:11:38.643] Output repaint window is 7 ms maximum. [22:11:38.643] Loading module '/usr/lib/weston/drm-backend.so' [22:11:39.930] initializing drm backend [22:11:39.943] logind: session control granted [22:11:39.952] using /dev/dri/card0 [22:11:39.952] Loading module '/usr/lib/weston/gl-renderer.so' pci id for fd 14: 8086:8108, driver (null) [22:11:59.302] EGL client extensions: EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_wayland EGL_EXT_platform_x11 EGL_KHR_client_get_all_proc_addresses EGL_MESA_platform_gbm libEGL debug: added egl_dri2 to module array libEGL debug: the best driver is DRI2 [22:11:59.305] warning: EGL_EXT_swap_buffers_with_damage not supported. Performance could be affected. [22:11:59.344] input device 'Video Bus', /dev/input/event0 is tagged by udev as: Keyboard [22:11:59.344] input device 'Video Bus', /dev/input/event0 is a keyboard [22:11:59.348] input device 'Power Button', /dev/input/event5 is tagged by udev as: Keyboard [22:11:59.349] input device 'Power Button', /dev/input/event5 is a keyboard [22:11:59.354] input device 'Lid Switch', /dev/input/event3 not tagged as input device [22:11:59.354] failed to create input device '/dev/input/event3'. [22:11:59.361] input device 'Sleep Button', /dev/input/event4 is tagged by udev as: Keyboard [22:11:59.361] input device 'Sleep Button', /dev/input/event4 is a keyboard [22:11:59.365] input device 'HDA Intel MID Mic', /dev/input/event9 not tagged as input device [22:11:59.366] failed to create input device '/dev/input/event9'. [22:11:59.371] input device 'HDA Intel MID Headphone', /dev/input/event10 not tagged as input device [22:11:59.373] failed to create input device '/dev/input/event10'. [22:11:59.434] input device 'AsusTek, Inc. MultiTouch', /dev/input/event2 is tagged by udev as: Touchscreen [22:11:59.435] input device 'AsusTek, Inc. MultiTouch', /dev/input/event2 is a touch device [22:11:59.444] input device 'USB 2.0 Camera', /dev/input/event11 is tagged by udev as: Keyboard [22:11:59.444] input device 'USB 2.0 Camera', /dev/input/event11 is a keyboard [22:11:59.451] input device 'Eee PC WMI hotkeys', /dev/input/event7 is tagged by udev as: Keyboard [22:11:59.451] input device 'Eee PC WMI hotkeys', /dev/input/event7 is a keyboard [22:11:59.456] input device 'AT Translated Set 2 keyboard', /dev/input/event1 is tagged by udev as: Keyboard [22:11:59.456] input device 'AT Translated Set 2 keyboard', /dev/input/event1 is a keyboard [22:11:59.461] input device 'SynPS/2 Synaptics TouchPad', /dev/input/event8 is tagged by udev as: Touchpad Touchscreen [22:11:59.461] input device 'SynPS/2 Synaptics TouchPad', /dev/input/event8 is a touchpad [22:11:59.480] input device 'PC Speaker', /dev/input/event6 not tagged as input device [22:11:59.481] failed to create input device '/dev/input/event6'. [22:11:59.631] EGL version: 1.4 (DRI2) [22:11:59.632] EGL vendor: Mesa Project [22:11:59.632] EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3 [22:11:59.632] EGL extensions: EGL_EXT_buffer_age EGL_KHR_create_context EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_surfaceless_context EGL_MESA_configless_context EGL_MESA_image_dma_buf_export [22:11:59.632] GL version: OpenGL ES 3.0 Mesa 11.3.0-devel (git-b566317) [22:11:59.632] GLSL version: OpenGL ES GLSL ES 3.00 [22:11:59.632] GL vendor: VMware, Inc. [22:11:59.632] GL renderer: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits) [22:11:59.632] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24
Re: [Mesa-dev] [PATCH 3/9] i965/fs: Get rid of the sel.sat peephole
On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand wrote: > Shader-db results on Broadwell: > > total instructions in shared programs: 7517815 -> 7517816 (0.00%) > instructions in affected programs: 46 -> 47 (2.17%) > HURT: 1 > > The one hurt shader is a shader from "The Swapper" that writes to > gl_FrontColor and, as such, gets an implicit sat added to the output write. > Since this is invisible to NIR, the optimization in the previous commit > can't fix it for us. > --- How could this possibly cause problems? I don't understand why you're trying to remove it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
