Re: VkRunner ported to Rust

Alejandro Piñeiro writes: > I have been trying to find a time slot to learn Rust too. If you have > issues around with pending features perhaps one of these days I join > your initiative. Great! I’ll have to have a brainstorm for things that need implementing. The main thing at the moment is

VkRunner ported to Rust

Hi folks, Does anybody remember VkRunner? It’s a little tool to help write shader-based tests for Vulkan. It’s the same concept as Piglit’s shader_runner but for Vulkan instead of OpenGL. There are a couple of tests using it in Piglit but apart from that it never really got off the ground.

[Mesa-dev] [MR] glsl: Use default precision on struct/interface members when nothing specified

Mesa already keeps track of the GLES precision for variables and stores it in the ir_variable. When no precision is explicitly specified it takes the default precision for the corresponding type. However, when the variable is a struct or interface, the precision of each individual member is

[Mesa-dev] [PATCH] freedreno: Fix loading half-float immediate vectors

Previously the code to load from a constant instruction was always using the u32 pointer. If the constant is actually a 16-bit source this would end up with the wrong values because the pointer would be offset by the wrong size. This fixes it to use the u16 pointer. ---

[Mesa-dev] [PATCH] freedreno: Add .dir-locals to the common directory

The commit aa0fed10d35 moved a bunch of Freedreno code to a common directory. The previous directory had a .dir-locals file for Emacs. This patch copies it to the new directory as well. --- src/freedreno/.dir-locals.el | 8 1 file changed, 8 insertions(+) create mode 100644

Re: [Mesa-dev] [PATCH] freedreno: Fix emacs modeline

Eric Engestrom writes: > That's absolutely fair :) > > I wanted to ack your patch earlier, since fixing it is good regardless, > but freedreno isn't my area so I didn't feel comfortable doing so; > I changed my mind in the mean time though, so here you go :P > Acked-by: Eric Engestrom > > You

Re: [Mesa-dev] [PATCH 1/2] freedreno: Fix the Emacs indentation configuration file

> On Wed, Oct 17, 2018 at 12:45 PM Neil Roberts wrote: > >> I wonder if you have something else in your setup that is setting it? Ilia Mirkin writes: > Perhaps. It's the default, right? It is the default but the toplevel .dir-locals.el sets it to nil. These lower-level f

[Mesa-dev] [PATCH v2] Fix setting indent-tabs-mode in the Emacs .dir-locals.el files

Some of the .dir-locals.el had the wrong name for the truthy value so it wasn’t setting indent-tabs-mode. --- src/gallium/drivers/freedreno/.dir-locals.el | 2 +- src/gallium/drivers/r600/.dir-locals.el | 2 +- src/gallium/drivers/radeon/.dir-locals.el| 2 +-

Re: [Mesa-dev] [PATCH 1/2] freedreno: Fix the Emacs indentation configuration file

Ilia Mirkin writes: > Are you sure? It works fine for me... I'm not against fixing it to be > "t", but the current contents definitely worked fine for me. (As I > recall, I may be the one who checked this file in.) Yes, I’m sure. If you type “true” and then do C-x C-e to evaluate it then Emacs

[Mesa-dev] [PATCH 2/2] freedreno: Remove the Emacs mode lines

These are not necessary because the corresponding settings are set via the .dir-locals.el file anyway. Most of them were missing a ‘:’ after “tab-width” which was making Emacs display an annoying warning whenever you open the file. This patch was made with: sed -ri '/-\*- mode:/,/^$/d' \

[Mesa-dev] [PATCH 1/2] freedreno: Fix the Emacs indentation configuration file

The .dir-locals.el had the wrong name for the truthy value so it wasn’t setting indent-tabs-mode. --- src/gallium/drivers/freedreno/.dir-locals.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/freedreno/.dir-locals.el

Re: [Mesa-dev] [PATCH] freedreno: Fix emacs modeline

Eric Engestrom writes: > You might want to remove these instead, and use the .editorconfig [1] > already present at src/gallium/drivers/freedreno/.editorconfig This is > much easier to maintain than per-files settings ;) Either fixing it or removing it is fine by me. I now notice there is a

[Mesa-dev] [PATCH] freedreno: Fix emacs modeline

The modeline was missing a ‘:’ after the tab-width and Emacs was complaining every time you open a file. This patch was made with: sed -ri '1 s/; tab-width ([0-9])/; tab-width: \1/' \ $(find -name \*.\[ch\] -exec grep -l -- '-\*- mode:' {} \+) ---

Re: [Mesa-dev] [PATCH 04/15] mesa/glspirv: Set last_vert_prog

Timothy Arceri writes: >> + >> + int last_vert_stage = >> + util_last_bit(prog->data->linked_stages & >> +(((1 << (MESA_SHADER_GEOMETRY + 1)) - 1) ^ >> + ((1 << MESA_SHADER_VERTEX) - 1))); > > Isn't this the same as: > > int last_vert_stage = >

Re: [Mesa-dev] [PATCH v2 13/21] nir/linker: Add gl_nir_link_uniforms()

Timothy Arceri writes: > I still think you might be able to drop the tree without using a hash > table. Can't you just add an offset field to the state struct and use > this? You would increment it as you recurse down the arrays/structs via > nir_link_uniform() and you could detect the first

Re: [Mesa-dev] [PATCH v2 10/21] anv/nir: Use nir_variable's type if interface_type is null

Timothy Arceri writes: > > glsl_get_sampler_dim() contains the following: > > assert(glsl_type_is_sampler(type) || glsl_type_is_image(type)); > > Which leads me to believe the code above should just be: > > const struct glsl_type *glsl_type = glsl_without_array(var->type); > > If you agree

Re: [Mesa-dev] [PATCH v2 13/21] nir/linker: Add gl_nir_link_uniforms()

Timothy Arceri writes: >> +static struct type_tree_entry * >> +build_type_tree_for_type(const struct glsl_type *type) >> +{ > > Do we really need this? As far as I can tell we walk the types here to > build a tree then in nir_link_uniform() we walk the tree. Why not just > walk the types

[Mesa-dev] [PATCH] i965: Fix output register sizes when variable ranges are interleaved

In 6f5abf31466aed this code was fixed to calculate the maximum size of an attribute in a seperate pass and then allocate the registers to that size. However this wasn’t taking into account ranges that overlap but don’t have the same starting location. For example: layout(location = 0, component =

[Mesa-dev] [PATCH] spirv: Fix InterpolateAt* instructions for vecs with dynamic index

If the glsl is something like this: in vec4 some_input; interpolateAtCentroid(some_input[idx]) then it now gets generated as if it were: interpolateAtCentroid(some_input)[idx] This is necessary because the index will get generated as a series of nir_bcsel instructions so it would no

Re: [Mesa-dev] [PATCH 21/22] i965: Setup glsl uniforms by index rather than name matching

to merge it into one function then of course I don’t mind. Regards, - Neil Timothy Arceri <tarc...@itsqueeze.com> writes: > On 18/04/18 00:36, Alejandro Piñeiro wrote: >> From: Neil Roberts <nrobe...@igalia.com> >> >> Previously when setting up a uniform it would t

[Mesa-dev] [PATCH] spirv: Apply OriginUpperLeft to FragCoord

This behaviour was changed in 1e5b09f42f694687ac. The commit message for that says it is just a “tidy up” so my assumption is that the behaviour change was a mistake. It’s a little hard to decipher looking at the diff, but the previous code before that patch was: if (builtin ==

Re: [Mesa-dev] NIR issue with SPIRV ops that have operands with different bit-size

Rob Clark writes: > Karol hit the same thing (with for example, shift instructions) with > the work for spv compute/kernel support. I *think* the number of > special cases isn't too high, so probably vtn should just insert the > appropriate conversion instruction (ie.

[Mesa-dev] [PATCH] spirv: Don’t check for NaN for most OpFOrd* comparisons

For all of the OpFOrd* comparisons except OpFOrdNotEqual the hardware should probably already return false if one of the operands is NaN so we don’t need to have an explicit check for it. This seems to at least work on Intel hardware. This should reduce the number of instructions generated for the

Re: [Mesa-dev] [PATCH 2/6] nir/spirv: fix MSVC warning in vtn_align_u32()

Patches 2-6 are: Reviewed-by: Neil Roberts <nrobe...@igalia.com> Thanks a lot for fixing this. Regards, - Neil Brian Paul <bri...@vmware.com> writes: > Fixes warning that "negation of an unsigned value results in an > unsigned value". > --- > src/compiler/sp

[Mesa-dev] [PATCH] spirv: Fix building with SCons

The SCons build broke with commit ba975140d3c9 because a SPIR-V function is called from Mesa main. This adds a convenience library for SPIR-V and adds it to everything that was including nir. It also adds both nir and spirv to drivers/x11/SConscript. --- It would be great if someone who depends

[Mesa-dev] [PATCH 1/3] spirv: Handle location decorations on block interface members

Previously the code was taking any location decoration on the block and using that to calculate the member locations for all of the members. I think this was assuming that there would only be one location decoration for the entire block. According to the Vulkan spec it is possible to add location

[Mesa-dev] [PATCH 3/3] spirv: Don’t use special semantics when counting vertex attribute size

Under Vulkan, the double vertex attributes take up the same size regardless of whether they are vertex inputs or any other stage interface. --- There is a test for this on the tests branch of VkRunner: https://github.com/Igalia/vkrunner/tree/tests ./src/vkrunner

[Mesa-dev] [PATCH 2/3] glsl_types: Rename parameter of glsl_count_attribute_slots

glsl_count_attribute_slots takes a parameter to specify whether the type is being used as a vertex input because on GL double attributes only take up one slot. Vulkan doesn’t make this distinction so this patch renames the argument to is_gl_vertex_input in order to make it more clear that it

[Mesa-dev] [PATCH v2 4/4] spirv: Accept doubles in FaceForward, Reflect and Refract

The SPIR-V spec doesn’t specify a size requirement for these and the equivalent functions in the GLSL spec have explicit alternatives for doubles. Refract is a little bit more complicated due to the fact that the final argument is always supposed to be a scalar 32- or 16- bit float regardless of

[Mesa-dev] [PATCH v2 3/4] spirv: Add a 64-bit implementation of OpIsInf

The only change neccessary is to change the type of the constant used to compare against. This has been tested against the arb_gpu_shader_fp64/execution/ fs-isinf-dvec tests using the ARB_gl_spirv branch. v2: Use nir_imm_floatN_t for the constant. --- src/compiler/spirv/vtn_alu.c | 7 --- 1

[Mesa-dev] [PATCH 2/4] spirv: Use nir_imm_floatN_t for constants for GLSL450 builtins

There is an existing macro that is used to choose between either a float or a double immediate constant based on the bit size of the first operand to the builtin. This is now changed to use the new nir_imm_floatN_t helper function to reduce the number of places that make this decision. ---

[Mesa-dev] [PATCH 1/4] nir/builder: Add a nir_imm_floatN_t helper

This lets you easily build float immediates just given the bit size. If we have this single place here to handle this then it will be easier to add support for 16-bit floats later. --- src/compiler/nir/nir_builder.h | 13 + 1 file changed, 13 insertions(+) diff --git

[Mesa-dev] [PATCH 0/4] spirv: Support doubles in some builtin functions

using the test branch here: https://github.com/Igalia/vkrunner/tree/tests The corresponding tests can be run with: ./src/vkrunner \ examples/{face-forward,reflect,refract,isinf}-double.shader_test \ examples/refract-double-exp32.shader_test Neil Roberts (4): nir/builder: Add

[Mesa-dev] [PATCH] spirv: Handle doubles when multiplying a mat by a scalar

The code to handle mat multipication by a scalar tries to pick either imul or fmul depending on whether the matrix is float or integer. However it was doing this by checking whether the base type is float. This was making it choose the int path for doubles (and presumably float16s). --- This was

[Mesa-dev] Vulkan version of shader_runner

Hi, I’ve made a start on a Vulkan version of Piglit’s shader_runner. I mostly just wanted it as a quick way to compare problems on Vulkan and GL_ARB_gl_spirv but maybe one day it could become part of a Vulkan testing suite. I just thought I’d announce it here in case anyone else finds it useful

[Mesa-dev] [PATCH 1/2] spirv: Add a 64-bit implementation of OpIsInf

The only change neccessary is to change the type of the constant used to compare against. This has been tested against the arb_gpu_shader_fp64/execution/ fs-isinf-dvec tests using the ARB_gl_spirv branch. --- src/compiler/spirv/vtn_alu.c | 11 --- 1 file changed, 8 insertions(+), 3

[Mesa-dev] [PATCH 2/2] spirv: Add a 64-bit implementation of Frexp

The implementation is inspired by lower_instructions_visitor::dfrexp_sig_to_arith. This has been tested against the arb_gpu_shader_fp64/fs-frexp-dvec4 test using the ARB_gl_spirv branch. --- Please also see this related patch which I probably should have bundled in this series:

[Mesa-dev] [PATCH] spirv: Accept doubles in FaceForward, Reflect and Refract

The SPIR-V spec doesn’t specify a size requirement for these and the equivalent functions in the GLSL spec have explicit alternatives for doubles. Refract is a little bit more complicated due to the fact that the final argument is always supposed to be a scalar 32-bit float regardless of the other

[Mesa-dev] [PATCH] spirv/nir: Fix the stream ID when emitting a primitive or vertex

According to the SPIR-V spec: “Stream must be an of a constant instruction with a scalar integer type. That constant is the output-primitive stream number.” The previous code was treating it as an integer literal. --- This is part of the GL SPIR-V branch to enable streams for transform

[Mesa-dev] [PATCH v2] i965/meta-util: Convert the clear color through the surf format

When programming the fast clear color there was previously a chunk of code to try to make the color match the constraints of the surface format such as by filling in missing components and handling luminance formats. These cases are not handled by the hardware. There are some additional possible

[Mesa-dev] [PATCH] mesa: Tidy up the 4.6 section of GL4x.xml

The enums are moved to the top and indented like the rest of the file. Comments are added to split up the function aliases by corresponding extension. This should make no functional difference. --- This was requested by Ian Romanick as part of the review of the patch to add the aliases for

[Mesa-dev] [PATCH v2] mesa: Add GL4.6 aliases of functions from GL_ARB_indirect_parameters

--- This is just a rebase of the patch with a minor conflict resolution. src/mapi/glapi/gen/GL4x.xml | 22 ++ 1 file changed, 22 insertions(+) diff --git a/src/mapi/glapi/gen/GL4x.xml b/src/mapi/glapi/gen/GL4x.xml index 0a80941..4b2703c 100644 ---

Re: [Mesa-dev] [PATCH 0/9] Fix shader_draw_parameters CTS tests

Kenneth Graunke writes: > Neil, in case you were wondering, I suggested the above organization > of vertex elements because it would let us only upload 1 in the common > case. Looking in shader-db, there are 3579 shaders that use > gl_InstanceID, 186 shaders that use

Re: [Mesa-dev] [PATCH 1/9] compiler: Add new system value SYSTEM_VALUE_BASE_VERTEX_ID

Kenneth Graunke writes: > We have a number of similar names now: > >SYSTEM_VALUE_BASE_VERTEX >SYSTEM_VALUE_BASE_VERTEX_ID >SYSTEM_VALUE_VERTEX_ID >SYSTEM_VALUE_VERTEX_ID_ZERO_BASE > > BASE_VERTEX and BASE_VERTEX_ID are really similar names, and honestly >

[Mesa-dev] [PATCH] mesa: Add GL4.6 aliases of functions from GL_ARB_indirect_parameters

--- src/mapi/glapi/gen/GL4x.xml | 22 ++ 1 file changed, 22 insertions(+) diff --git a/src/mapi/glapi/gen/GL4x.xml b/src/mapi/glapi/gen/GL4x.xml index 88dba5c..ea28d8e 100644 --- a/src/mapi/glapi/gen/GL4x.xml +++ b/src/mapi/glapi/gen/GL4x.xml @@ -73,6 +73,28 @@

[Mesa-dev] [PATCH 2/2] st/glsl_to_tgsi: Add support for SYSTEM_VALUE_BASE_VERTEX_ID

SYSTEM_VALUE_BASE_VERTEX has changed to be the correct value for gl_BaseVertex, which means it will be zero when used with a non-indexed call. The new BASE_VERTEX_ID value can be used as before as an offset to calculate a value for gl_VertexID. These values should be different, but this patch just

[Mesa-dev] [PATCH 1/2] freedreno: Update to handle rename of the base vertex ID intrinsic

The old intrinsic called base_vertex that is used to add to gl_VertexID is now called base_vertex_id so that base_vertex can be used for the value of gl_BaseVertex, which is different. As far as I can tell freedreno doesn’t support GL_ARB_shader_draw_parameters so it won’t need any changes to

[Mesa-dev] [PATCH 0/2] Fix radeonsi and freedreno for the BaseVertex patches

either patch so this is more of a request for comments. Neil Roberts (2): freedreno: Update to handle rename of the base vertex ID intrinsic st/glsl_to_tgsi: Add support for SYSTEM_VALUE_BASE_VERTEX_ID src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 4 ++-- src/mesa/state_tracker

Re: [Mesa-dev] [PATCH 0/9] Fix shader_draw_parameters CTS tests

ent array buffer at offset indices + > i." > > Regards, > Antia. > > Antia Puentes (5): > compiler: Add new system value SYSTEM_VALUE_BASE_VERTEX_ID > nir: Add SYSTEM_VALUE_BASE_VERTEX_ID instrinsics > i965: emit basevertexid as a vertex element component > i965: gl_Bas

Re: [Mesa-dev] [PATCH 3/3] mesa: rework how we free gl_shader_program_data

to just crash immediately anyway. I’m not sure what the policy is supposed to be but a quick grep finds other places in the compiler that seem to assume that ralloc can not fail, so it might be nice to just remove the if. Reviewed-by: Neil Roberts <nrobe...@igalia.com>

Re: [Mesa-dev] [PATCH] mesa/shaderapi: Do a dry run of linking an in-use program

Timothy Arceri writes: >> You’re right, I think that would be a better way to handle it. I guess >> if this was done then you don’t really need the second link. There are >> several pointers for the uniform state that you would need to keep and I >> think there is more

Re: [Mesa-dev] [PATCH] mesa/shaderapi: Do a dry run of linking an in-use program

Timothy Arceri writes: > I think I'd rather see this handled by releasing the uniforms only after > the second link is successful and using a temp/fallback pointer to hold > it until then. We need to do a similar type of thing with shader source > and the shader cache

[Mesa-dev] [PATCH] glsl: Transform fb buffers are only active if a variable uses them

The GL spec will soon be revised to clarify that a buffer binding for a transform feedback buffer is only required if a variable is actually defined to use the buffer binding point. Previously a declaration for the default transform buffer would make it require a binding even if nothing was

[Mesa-dev] [PATCH] mesa/shaderapi: Do a dry run of linking an in-use program

If an in-use program is unsuccessfully linked, the GL spec requires that the executable and the uniform state of the program should remain until a new program is bound. Previously this sort of worked in Mesa except that it would free the uniform state before attempting to link. At least on i965

Re: [Mesa-dev] [PATCH 1/3] nir/opt_intrinsics: Fix values for gl_SubGroupG{e, t}MaskARB

Thanks for the review. I’ve pushed this first patch to master and I’ll drop the rest. I’ve also pushed the piglit patch. Regards, - Neil Jason Ekstrand <ja...@jlekstrand.net> writes: > On Tue, Oct 31, 2017 at 10:55 AM, Neil Roberts <nrobe...@igalia.com> wrote: > >> Pr

[Mesa-dev] [PATCH 3/3] i965/fs/nir: Don’t let nir lower nir_intrinsic_load_subgroup_all_mask

Instead of letting nir lower nir_intrinsic_load_subgroup_all_mask this is now generated directly. This is more efficient because it can be calculated in the compiler based on the dispatch width. Sadly it’s still not totally ideal because the constant doesn’t seem to get propagated and there is

[Mesa-dev] [PATCH 2/3] nir: Add an intrinsic for a bitmask of the whole subgroup

Similar to nir_intrinsic_load_subgroup_eq_mask and friends, this adds an intrinsic which contains a bit for every member of the group. This doesn’t have a corresponding GLSL builtin but it will be used to calculate nir_intrinsic_load_subgroup_g{t,e}_mask. It has its own nir option on whether to

[Mesa-dev] [PATCH 1/3] nir/opt_intrinsics: Fix values for gl_SubGroupG{e, t}MaskARB

680#c3 Signed-off-by: Neil Roberts <nrobe...@igalia.com> --- src/compiler/nir/nir_opt_intrinsics.c | 24 ++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/src/compiler/nir/nir_opt_intrinsics.c b/src/compiler/nir/nir_opt_intrinsics.c index 26a0f96..d5

[Mesa-dev] [PATCH v2 1/3] glsl_parser_extra: Add utility to copy symbols between symbol tables

dition will copy explicitly declared gl_PerVertex blocks too. The function will be used in a subsequent patch. v2 (Neil Roberts): Allow the src symbol table to be NULL and explicitly copy the gl_PerVertex symbols in case they are not referenced in the exec_list. Signed-off-by: Eduardo Lima Mit

[Mesa-dev] [PATCH v2 3/3] glsl/linker: Check that re-declared, inter-shader built-in blocks match

gram, they must all redeclare the built-in block in the same way, as described in section 4.3.9 “Interface Blocks” for interface-block matching, or a link-time error will result." Fixes: * GL45-CTS.CommonBugs.CommonBug_PerVertexValidation v2 (Neil Roberts): Explicitly look for gl_P

[Mesa-dev] [PATCH v2 2/3] glsl: Use the utility function to copy symbols between symbol tables

From: Eduardo Lima Mitev <el...@igalia.com> This effectively factorizes a couple of similar routines. v2 (Neil Roberts): Non-trivial rebase on master Signed-off-by: Eduardo Lima Mitev <el...@igalia.com> Signed-off-by: Neil Roberts <nrobe...@igalia.com> ---

[Mesa-dev] [PATCH v2 0/3] Fix for PerVertexValidation CTS test

Hi, Here is a v2 of Eduardo’s patches to fix the PerVertexValidation CTS test. They were originally posted here: https://lists.freedesktop.org/archives/mesa-dev/2017-March/146667.html The patches needed a non-trivial rebase. The previous discussion was left with a note saying that there are

Re: [Mesa-dev] [PATCH v2 2/3] vulkan/wsi: Report the correct min/maxImageCount

Jason Ekstrand writes: > I wish... Unfortunately, the spec says: > > Let *n* be the total number of images in the swapchain, *m* be the > value of VkSurfaceCapabilitiesKHR::minImageCount, and *a* be the > number of presentable images that the application has currently >

Re: [Mesa-dev] [PATCH v2 2/3] vulkan/wsi: Report the correct min/maxImageCount

Jason Ekstrand writes: > Hey, Neil! Hey Jason :) > Yeah... That's a bit unfortunate. The problem is that we have no way of > returning a different number of images depending on the mode. In theory, > we could start out at 2 and return SUBOPTIMAL and force the

Re: [Mesa-dev] [PATCH v2 2/3] vulkan/wsi: Report the correct min/maxImageCount

Jason Ekstrand writes: > + /* For true mailbox mode, we need at least 4 images: > +* 1) One to scan out from > +* 2) One to have queued for scan-out > +* 3) One to be currently held by the Wayland compositor > +* 4) One to render to > +*/ >

[Mesa-dev] [PATCH 2/2] intel/compiler: Use emit_emplace in the builders

Replaces all calls of the form emit(instruction(…)) with emit_emplace(…). This should avoid a redundant copy of the stack-allocated temporary instruction. Although the temporary would have been stack-allocated so it might not seem like a big deal, the instructions do also have an internal

[Mesa-dev] [PATCH 1/2] intel/compiler: Add a placement version of emit to the builders

Adds “emit_emplace” to emit an instruction that is constructed inplace with the parameters given. This will be used instead of the pattern of doing emit(instruction(…)) because that ends up calling emit(const instruction&) which implies doing a copy. The “emplace” terminology comes from

[Mesa-dev] [PATCH vulkan] anv/pipeline: Try to create all pipelines

According to the Vulkan 1.0 spec section 9.4: “When an application attempts to create many pipelines in a single command, it is possible that some subset may fail creation. In that case, the corresponding entries in the pPipelines output array will be filled with VK_NULL_HANDLE values. If any

Re: [Mesa-dev] [PATCH 22/22] meta/blit: Use GL_EXT_shader_samples_identical in MSAA-SS resolve blit

Iago Toral writes: > I don't know much about this, but using shader_samples_identical > should only give a benefit if we actually get identical samples, > otherwise it means more work, right? I noticed that the test renders a > quad with random colors for each vertex that will

Re: [Mesa-dev] [PATCH 22/22] meta/blit: Use GL_EXT_shader_samples_identical in MSAA-SS resolve blit

I made a pathological test case (attached) which repeatedly renders into an MSAA FBO and then blits it to the screen and measures the framerate. It checks it with a range of different sample counts. The rendering is done either by rendering two triangles to fill the framebuffer or by calling

Re: [Mesa-dev] [PATCH 1/4] mesa: gl_NumSamples should always be at least one

Looks good to me. Interestingly we have a test for it in Piglit which gets run with samples=0 and it is currently passing so presumably it is broken. Reviewed-by: Neil Roberts <n...@linux.intel.com> - Neil Ilia Mirkin <imir...@alum.mit.edu> writes: > From ARB

Re: [Mesa-dev] [PATCH v2] Android: fix build break in libmesa_program

Looks good to me. Sorry about breaking it. Reviewed-by: Neil Roberts <n...@linux.intel.com> - Neil Rob Herring <r...@kernel.org> writes: > Commit 5fd848f6c9ee ("program: Use _mesa_geometric_samples to calculate > gl_NumSamples") broken Android builds. Add th

[Mesa-dev] [PATCH 4/4] main: Use a derived value for the default sample count

Previously the framebuffer default sample count was taken directly from the value given by the application. On the i965 driver on HSW if the value wasn't one that is supported by the hardware it would hit an assert when it tried to program the state for it. This patch fixes it by adding a derived

[Mesa-dev] [PATCH 3/4] program: Use _mesa_geometric_samples to calculate gl_NumSamples

Otherwise it won't take into account the default samples for framebuffers with no attachments. --- src/mesa/program/prog_statevars.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mesa/program/prog_statevars.c b/src/mesa/program/prog_statevars.c index 12490d0..eed2412

[Mesa-dev] [PATCH 2/4] main: Use _mesa_geometric_samples to calculate GL_SAMPLE_BUFFERS

Otherwise it won't take into account the default samples for framebuffers with no attachments. --- src/mesa/main/get.c | 3 +++ src/mesa/main/get_hash_params.py | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c index

[Mesa-dev] [PATCH 1/4] main: Use _mesa_geometric_samples to calculate the value of GL_SAMPLES

Otherwise it won't take into account the default samples for framebuffers with no attachments. --- src/mesa/main/get.c | 4 src/mesa/main/get_hash_params.py | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c index

[Mesa-dev] [PATCH 1/2] texobj: Fix the completeness checks for cube textures

According to the GL 1.4 spec section 3.8.10, a cubemap texture is only complete if: • The level base arrays of each of the six texture images making up the cube map have identical, positive, and square dimensions. • The level base arrays were each specified with the same internal format. •

[Mesa-dev] [PATCH 2/2] texobj: Remove redundant checks that the texture cube faces match size

The texture mipmap completeness checking code was checking whether all of the faces have the same size. However this is pointless because the code just above it checks whether the face has the expected size calculated for the mipmap level anyway so the error condition could never be reached. This

Re: [Mesa-dev] [PATCH] i965/meta-fast-clear: Convert the clear color through the surf format

Bump. Anyone fancy reviewing this small patch? I think it would be good to have because it makes the code a bit simpler as well as fixing a corner case and making it more robust. - Neil Neil Roberts <n...@linux.intel.com> writes: > When programming the fast clear color there was p

[Mesa-dev] [PATCH] texobj: Check completeness with InternalFormat rather than Mesa format

The internal Mesa format used for a texture might not match the one requested in the internalFormat when the texture was created, for example if the driver is internally remapping RGB textures to RGBA. Otherwise it can cause false positives for completeness if one mipmap image is created as RGBA

[Mesa-dev] [PATCH] Revert "i965: Use MESA_FORMAT_B8G8R8X8_SRGB for RGB visuals"

This reverts commit 839793680f99b8387bee9489733d5071c10f3ace. The patch was breaking DRI3 because driGLFormatToImageFormat does not handle MESA_FORMAT_B8G8R8X8_SRGB which ended up making it fail to create the renderbuffer and it would later crash. It's not trivial to add this format because there

Re: [Mesa-dev] [PATCH] i965: handle stencil_bits parameter for MESA_FORMAT_B8G8R8X8_UNORM format.

Ilia Mirkin writes: > I suspect that something like this may be the right thing for the > intel driver... no reason not to expose sRGB-capable visuals when it > so happens that alpha == 0. Also probably the same treatment should be > done for BGR565... sRGB encoding will

[Mesa-dev] [PATCH 1/3] i965: Add MESA_FORMAT_B8G8R8X8_SRGB to brw_format_for_mesa_format

This will be used in a subsequent patch as the format for RGB visuals. Cc: "11.0 11.1" Cc: Ilia Mirkin Suggested-by: Ilia Mirkin --- src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 + 1 file changed, 1

[Mesa-dev] [PATCH 3/3] i965: Use MESA_FORMAT_B8G8R8X8_SRGB for RGB visuals

Previously if the visual didn't have an alpha channel then it would pick a format that is not sRGB-capable. I don't think there's any reason not to always have an sRGB-capable visual. Since 28090b30 there are now visuals advertised without an alpha channel which means that games that don't request

[Mesa-dev] [PATCH 2/3] i965: Add B8G8R8X8_SRGB to the alpha format override

brw_init_surface_formats overrides the render format for RGBX formats which aren't supported for rendering so that they internally use RGBA instead. However, B8G8R8X8_SRGB was missing so it wasn't marked as a renderable format. This patch just adds it. Cc: "11.0 11.1"

[Mesa-dev] [PATCH] i965/meta-fast-clear: Convert the clear color through the surf format

When programming the fast clear color there was previously a chunk of code to try to make the color match the constraints of the surface format such as by filling in missing components and handling luminance formats. These cases are not handled by the hardware. There are some additional possible

Re: [Mesa-dev] [Mesa-stable] [PATCH] i965: Fix crash when calling glViewport with no surface bound

Emil Velikov writes: > Worth throwing in 11.0 as well ? Yeah, that would probably be sensible. >> if (_mesa_is_winsys_fbo(ctx->DrawBuffer)) { >> - dri2InvalidateDrawable(driContext->driDrawablePriv); >> -

[Mesa-dev] [PATCH] i965: Fix crash when calling glViewport with no surface bound

If EGL_KHR_surfaceless_context is used then glViewport can be called with NULL for the draw and read surfaces. This was previously causing a crash because the i965 driver tries to use this point to invalidate the surfaces and it was derferencing the NULL pointer. Bugzilla:

Re: [Mesa-dev] [PATCH] nir: Optimize useless comparisons against true/false.

Matt Turner writes: > # Written in the form (, ) where is an expression > # and is either an expression or a value. An expression is > # defined as a tuple of the form (, , , , ) > @@ -94,6 +97,8 @@ optimizations = [ > (('inot', ('ige', a, b)), ('ilt', a, b)), >

Re: [Mesa-dev] [PATCH 0.5/5] i965/gen9/fast-clear: Handle linear???SRGB conversion

"Pohjolainen, Topi" writes: >> + /* Handle linear→SRGB conversion */ >> + if (brw->ctx.Color.sRGBEnabled && >> + _mesa_get_srgb_format_linear(mt->format) != mt->format) { > > Patch five disables fast clear for single-sampled if > brw->ctx.Color.sRGBEnabled

Re: [Mesa-dev] [PATCH 2/5] i965/gen8+: Don't upload the MCS buffer for single-sampled textures

> On Thu, Nov 26, 2015 at 11:18:34AM +0200, Pohjolainen, Topi wrote: >> On Wed, Nov 25, 2015 at 11:01:18AM -0800, Ben Widawsky wrote: >> > On Wed, Nov 25, 2015 at 06:36:36PM +0100, Neil Roberts wrote: >> > > For single-sampled textures the MCS buffer is only used t

[Mesa-dev] [PATCH] util: Tiny optimisation for the linear→srgb conversion

When converting 0.0 it would be nice if it didn't do any arithmetic. --- src/util/format_srgb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/format_srgb.h b/src/util/format_srgb.h index 4a8d73f..34b50af 100644 --- a/src/util/format_srgb.h +++

[Mesa-dev] [PATCH 1/5] i965/meta-fast-clear: Disable GL_FRAMEBUFFER_SRGB during clear

Adds MESA_META_FRAMEBUFFER_SRGB to the meta save state so that GL_FRAMEBUFFER_SRGB will be disabled when performing the fast clear. That way the render surface state will be programmed with the linear equivalent format during the clear. This is important for Gen9 because the SRGB formats are not

[Mesa-dev] [PATCH 5/5] i965/gen9: Don't do fast clears when GL_FRAMEBUFFER_SRGB is enabled

When GL_FRAMEBUFFER_SRGB is enabled any single-sampled renderbuffers are resolved in intel_update_state because the hardware can't cope with fast clears on SRGB buffers. In that case it's pointless to do a fast clear because it will just be immediately resolved. ---

[Mesa-dev] [PATCH 4/5] i965/gen9: Allow fast clears for non-MSRT SRGB buffers

SRGB buffers are not marked as losslessly compressible so previously they would not be used for fast clears. However in practice the hardware will never actually see that we are using SRGB buffers for fast clears if we use the linear equivalent format when clearing and make sure to resolve the

[Mesa-dev] [PATCH 2/5] i965/gen8+: Don't upload the MCS buffer for single-sampled textures

For single-sampled textures the MCS buffer is only used to implement fast clears. However the surface always needs to be resolved before being used as a texture anyway so the the MCS buffer doesn't actually achieve anything. This is important for Gen9 because in that case SRGB surfaces are not

[Mesa-dev] [PATCH 0.5/5] i965/gen9/fast-clear: Handle linear→SRGB conversion

If GL_FRAMEBUFFER_SRGB is enabled when writing to an SRGB-capable framebuffer then the color will be converted from linear to SRGB before being written. There is no chance for the hardware to do this itself because it can't modify the clear color that is programmed in the surface state so it seems

[Mesa-dev] [PATCH 0/5] i965/gen9: Support fast clear on SRGB buffers

Currently fast clears are disabled on SKL with SRGB buffers because they are not marked as losslessly compressible in the formats table. This is less than ideal because by default the window system buffers are created as SRGB so in practice it means an application is unlikely to end up using fast

[Mesa-dev] [PATCH 3/5] i965/gen9: Resolve SRGB color buffers when GL_FRAMEBUFFER_SRGB enabled

SKL can't cope with the CCS buffer for SRGB buffers. Normally the hardware won't see the SRGB formats because when GL_FRAMEBUFFER_SRGB is disabled these get mapped to their linear equivalents. In order to avoid relying on the CCS buffer when it is enabled this patch now makes it flush the

Re: [Mesa-dev] [PATCH] i965: Always use Y-tiled buffers on SKL+

Hi, Has this situation changed at all? It's probably quite important to get this working because we have to disable fast clears for X-tiled buffers on SKL which effectively means we currently can't do it for window system buffers. Regards, - Neil Chris Wilson writes:

  1   2   3   4   5   >