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 tha
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.
Anyway
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 attache
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.
---
src/freedreno/ir3/ir3_compi
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 src/freedreno
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 ha
> 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
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 +-
src/gallium/drivers/radeonsi/
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 g
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' \
$(fi
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
b/src/gallium/drivers/freedreno/.dir-
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
.dir
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:' {} \+)
---
src/gallium/drivers/freedreno/a2xx/fd2_blend.
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 =
>
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
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 pl
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 direct
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 =
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 longe
merge it into one function then of
course I don’t mind.
Regards,
- Neil
Timothy Arceri writes:
> On 18/04/18 00:36, Alejandro Piñeiro wrote:
>> From: Neil Roberts
>>
>> Previously when setting up a uniform it would try to walk the uniform
>> storage slots and find o
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 == SpvBuiltInFragCoo
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. u2u32, etc) so that if the
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
Patches 2-6 are:
Reviewed-by: Neil Roberts
Thanks a lot for fixing this.
Regards,
- Neil
Brian Paul writes:
> Fixes warning that "negation of an unsigned value results in an
> unsigned value".
> ---
> src/compiler/spirv/vtn_private.h | 2 +-
> 1 file changed, 1
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 o
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 d
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 examples/double-vertex-input-bloc
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 should
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 th
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
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.
---
src/com
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 a/src/compiler/ni
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 a
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
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 to
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 deleti
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:
https://patchwork
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
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
feedbac
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
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 GL_ARB_
---
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
--- a/src/mapi/glapi/gen/GL4x.x
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 gl_VertexID, and 0 shaders th
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
> either one seems like it
---
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 @@
+
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
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 gener
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
+
> 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_BaseVertex must be zer
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
Regard
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 state than just the uniform
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 e.g [1].
>
> [1]
> https
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 declare
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 thi
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 writes:
> On Tue, Oct 31, 2017 at 10:55 AM, Neil Roberts wrote:
>
>> Previously the values were calculated by just shifti
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 sti
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 low
680#c3
Signed-off-by: Neil Roberts
---
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..d5fdc51 100644
--- a/src/compil
with more
experience of nir can recommend a better way to do it.
I will also post a patch for the Piglit test.
- Neil
Neil Roberts (3):
nir/opt_intrinsics: Fix values for gl_SubGroupG{e,t}MaskARB
nir: Add an intrinsic for a bitmask of the whole subgroup
i965/fs/nir: Don’t let nir lower
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 Mitev
Signed-off-by: Neil Roberts
clare 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_PerVertex in the symbol ta
From: Eduardo Lima Mitev
This effectively factorizes a couple of similar routines.
v2 (Neil Roberts): Non-trivial rebase on master
Signed-off-by: Eduardo Lima Mitev
Signed-off-by: Neil Roberts
---
src/compiler/glsl/glsl_parser_extras.cpp | 25 +++--
src/compiler/glsl
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 more
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
> acquired (i.e. images acq
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 application to
> recreate the
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
> +*/
> caps->minImageCount = 2;
>
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 allocatio
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 std::vecto
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 p
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 be interpolated
> a
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 glClea
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
- Neil
Ilia Mirkin writes:
> From ARB_sample_shading:
>
> "gl_NumSamples is the total number of
Looks good to me. Sorry about breaking it.
Reviewed-by: Neil Roberts
- Neil
Rob Herring writes:
> Commit 5fd848f6c9ee ("program: Use _mesa_geometric_samples to calculate
> gl_NumSamples") broken Android builds. Add the missing include path "main"
> to framebu
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 1
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 307059
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 s
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 04348
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 p
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.
• The
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 an
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 writes:
> When programming the fast clear color there was previously a chunk of
> code
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
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
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 matter even more there, a
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 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/d
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
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"
Cc: Ilia Mirkin
---
src/me
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);
>> - dri2InvalidateDrawable(driContext->driReadablePriv);
>> + if (driContex
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: https://bugs.freedesktop
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)),
> (('inot', ('ieq', a,
"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 is set. How about something li
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
+++ b/src/util/format_srgb.
> 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
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 renderbuf
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 c
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 buff
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 supp
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.
---
src/mesa/drivers/dri/i965/brw_m
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 ma
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
1 - 100 of 506 matches
Mail list logo
