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
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
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
Jason Ekstrand writes:
> Done. Other than that, does this count as a R-B?
Yeah, with the cleanup step it looks good to me.
Reviewed-by: Neil Roberts
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
h
One case where the memcpy path won't work is if the source and
destination are the same buffer. In that case it tries to map the
texture twice and hits an assert. I think this could be a legitimate use
case if the source and destination rectangles don't overlap. The
extension spec isn't very clear
Kenneth Graunke
>> > Reviewed-by: Anuj Phogat
>> > Reviewed-by: Eric Anholt
>>
>> Quoting this commit message is a bit confusing - usually, when people quote
>> other commits, it's referring to a regression...and the regression was from
>> 05b52
According to the GL spec the only fragment operations that should affect
glBlitFramebuffer are “the pixel ownership test, the scissor test, and sRGB
conversion”. That implies that dithering should not be performed so we need to
disable it when implementing the blit with a render.
Before commit 05b
This adds a boolean in the gl_extensions struct for
GL_ARB_texture_compression_bptc as well as an entry in extension_table.
---
src/mesa/main/extensions.c | 1 +
src/mesa/main/mtypes.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
Adds the ‘bptc’ layout to get_channel_bits. The channel bits for BPTC depend
on the mode but as it only has to be an approximation we can set it to 4 like
for S3TC.
---
src/mesa/main/format_info.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/format_info.py b/s
If the name of a compressed texture format has ‘FLOAT’ in it it will now set
the data type of the format to GL_FLOAT. This will be needed for the BPTC
half-float formats.
---
src/mesa/main/format_info.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/format_in
Enables BPTC texture compression on the software rasterizer.
---
src/mesa/main/extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index f3197f9..7732249 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@
Here is a v2 of the BPTC texture compression series. The main
difference is that instead of going via DXT3 for the UNORM formats it
now always uses the custom naïve compressor for all formats. This
doesn't give very good-looking results but it is fast and doesn't add
any dependencies. There was som
Adds functions to fetch from any of the four BPTC-compressed formats.
v2: Set the alpha component to 1.0 when fetching from the half-float formats
instead of leaving it uninitialised. Don't linearize the alpha component
when fetching from sRGB.
---
src/mesa/Makefile.sources| 1 +
Once we add BPTC texture support we will need to generate mipmaps for
compressed floating point textures too. Most of the code seems to already be
there but it just needs a few extra lines to get it to use GL_FLOAT instead of
GL_UNSIGNED_BYTE as the type for the temporary buffers.
---
src/mesa/mai
This adds the following four Mesa image format enums which correspond to the
four BPTC compressed texture formats:
MESA_FORMAT_BPTC_RGBA_UNORM
MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM
MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT
MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT
It also updates the format information functio
The signed and unsigned half-float BPTC-compressed formats were being reported
as having a base format of GL_RGBA but they don't store an alpha channel so it
should be GL_RGB.
---
src/mesa/main/texcompress.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/texc
---
docs/GL3.txt| 2 +-
docs/relnotes/10.3.html | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index e241257..973495c 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -138,7 +138,7 @@ GL 4.1:
GL 4.2:
GLSL 4.2
Previously the Meta implementation of glGetTexImage would fall back to
_mesa_get_teximage if the texturing is not using an unsigned normalised
format. However in order to support the half-float formats of BPTC textures we
can make it render to a floating-point renderbuffer instead. This patch makes
This adds compressors for all four of the BPTC compressed-texture formats. The
compressor is written from scratch and takes a very simple approach. It always
uses a single mode of the BPTC format (4 for unorm and 3 for half-floats) and
picks the two endpoints by dividing the texels into those which
Enables the BPTC extension on Gen>=7 and adds the necessary format mappings to
get the right surface type value.
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 5 +
src/mesa/drivers/dri/i965/intel_extensions.c| 2 ++
2 files changed, 7 insertions(+)
diff --git a/src/mesa/drivers/dr
I'd just liked to point out that I made a nearly identical patch before
this patch was posted but I didn't get any review despite prodding
people a few times on #dri-devel. Maybe we should try to get into the
habit of searching patchwork for existing patches before posting to the
list. Does anyone
Chris Forbes writes:
> Does this actually work on all Gen7?
>
> The IVB PRM Vol 4 Part 1 Page 83 says:
>
>Errata: BC6H_SF16, BC6H_UF16, and BC7_SRGB are not supported and
> may result in data corruption if used.
I'm pretty sure this is referring to pre-production hardware and
unfortunately t
Jason Ekstrand writes:
> Sorry, said that just a little early. Do we really want 4 bits for a
> floating-point format? How many bits does nvidia report?
NVidia reports the RGB components as 8/8/8 for the two normalized
formats and 32/32/32 for the two half-float formats. I think the 8 makes
so
Kristian Høgsberg writes:
> That's a great reference image. Do you have a version of the image
> compressed with nVidias online compressor?
I finally got access to an NVidia card last night so I've added an image
from their online compressor to the bottom of that page.
http://busydoingnothing.
Jason Ekstrand writes:
> + if (src_mt == dst_mt && src_level == dst_level && src_z == dst_z) {
> + /* If we are on the same miptree, same level, and same slice, then
> + * intel_miptree_map won't let us map it twice. We have to do a
> + * single map in read-write mode.
> +
The i965 driver uses a float pointer to point to the value of a uniform and
also as the destination within the batch buffer. However the same locations
can also be used to store values for integer uniforms. Previously the value
was being copied into the batch buffer with a regular assignment. This
Thanks for the review. I've pushed the Mesa patch and I'll have a look
at adding more formats to the Piglit test.
Regards,
- Neil
Kenneth Graunke writes:
> On Tuesday, July 01, 2014 04:04:56 PM Neil Roberts wrote:
>> > FWIW, I relaxed the format restrictions in
>>
wise looks great to me.
Reviewed-by: Neil Roberts
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I'm not sure if we came to a decision about what to do with the
channel bits. I guess it's not really that important because probably
nothing uses it for compressed formats except to check for the
existence of the channels. Here is a v2 patch which picks 8/8/8/8 for
the RGBA formats and 16/16/16 fo
Hi,
Here is a replacement patch for the one to use memcpy when copying
uniform values into the batch buffer here:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/065179.html
Eric Anholt suggested instead of using memcpy we should change the
type of the pointer to uint32_t. I started t
Hi,
After the looking at the problem in bug 81150 I was wondering if we
have the same problem when using glClear with integer values. Sure
enough I can trigger a similar bug on 32-bit builds with optimisations
using a piglit test which I've posted here:
http://lists.freedesktop.org/archives/pigli
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
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
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
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
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
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
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
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
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
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
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
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
+
> 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
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
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
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
---
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 @@
+
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
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
---
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
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_
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
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
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
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;
>
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:
> 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
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
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:
> 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
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
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
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
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
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
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 =
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
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 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
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 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
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 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
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
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.
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 .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-
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
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
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/
> 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
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
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 =
>
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
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
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
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
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
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
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
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
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
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
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
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
Hi,
Chad Versace wrote:
> [chad]: Make comments more concise. Change the if-condition to be
> compatible with a core context, which may not advertise old extensions.
The change to the if-condition breaks the patch. The problem is this bit
of code in fbobject.c:
static struct gl_framebuffer *
g
401 - 500 of 506 matches
Mail list logo
