With this fix, we can load the constants in NIR-vec4 as integers,
as it is done in the FS backend.
This is related to:
http://lists.freedesktop.org/archives/mesa-dev/2015-July/089899.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://l
If the register types do not match and the instruction
that contains the final destination is saturated, register
coalescing generated non-equivalent code.
This did not happen when using IR because types usually
matched, but it is visible in nir-vec4.
For example,
mov vgrf7:D vgrf2:D
m
Loads constants using integer as their register type, this is done
for consistency with the FS backend.
---
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
b/src/mesa/drivers/dri/i965/brw
Loads constants using integer as their register type, this is done
for consistency with the FS backend.
---
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
b/src/mesa/drivers/dri/i965/brw
ARRAY,
it fixes assertion in GL44-CTS.texture_view.gettexparameter
due to the original patch (Antia).
Signed-off-by: Dave Airlie
Signed-off-by: Antia Puentes
---
I have not taken a deep look to the test so take this with a grain of salt.
As I said in a previous email, this patch raises an as
: Remove the loop. Do not shift height either for 1D textures.
Use an explicit switch and add an assertion (levels == 0) for
multisampled textures (Jason).
Signed-off-by: Dave Airlie
Signed-off-by: Antia Puentes
---
src/mesa/drivers/dri/i965/intel_tex_image.c | 27 +--
1 file
: Remove the loop. Do not shift height either for 1D textures.
Use an explicit switch and add an assertion (levels == 0) for
multisampled textures (Jason).
v4: Rectangle textures can not have levels either (Ilia Mirkin).
Signed-off-by: Dave Airlie
Signed-off-by: Antia Puentes
---
src/mesa/drivers/dri
The emission of vertex attributes corresponding to dvec3 and dvec4
vertex shader input variables was not correct when the passed
to the VertexAttribL* commands was <= 2.
This was because we were using the vertex array size when emitting vertices
to decide if we uploaded a 64-bit floating point at
Math operations in SandyBridge do not support source swizzling
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92033
---
src/mesa/drivers/dri/i965/brw_ir_vec4.h | 3 ++-
src/mesa/drivers/dri/i965/brw_vec4.cpp | 11 +--
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git
Gen6 MATH instructions can not execute in align16 mode, so swizzles or
writemasking are not allowed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92033
---
I have tried to find an example where the writemask check is strictly needed
in order to avoid an incorrect register coalescing, bu
IvyBridge and Haswell PRM say that the JIP should be emitted
with type W but we were using UD. The previous implementation
did not show adverse effects, however changing the type to
D caused a GPU hang, see bug 84557; IMHO it is safer to
follow the specification thoroughly.
---
src/mesa/drivers/dr
From GLSL 1.30.10, section 3.3 (Preprocessor):
"#line line source-string-number ... After processing this directive
(including its new-line), the implementation will behave as if it is
compiling at ... source string number source-string-number. Subsequent
source strings will be numbered sequentiall
From GLSL 3.30 and GLSL ES 1.00 on, after processing the line
directive (including its new-line), the implementation should
behave as if it is compiling at the line number passed as
argument. In previous versions, it behaved as if compiling
at the passed line number + 1.
Partially fixes https://bu
Thanks for fixing this.
Reviewed-by: Antia Puentes
On 27/10/17 11:18, Alejandro Piñeiro wrote:
From the spec:
"IMAGE_FORMAT_COMPATIBILITY_TYPE: The matching criteria use for the
resource when used as an image textures is returned in
. This is equivalent to ca
Reviewed-by: Neil Roberts
---
src/compiler/nir/nir.c | 4
src/compiler/nir/nir_gather_info.c | 1 +
src/compiler/nir/nir_intrinsics.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 7380bf436a8..6f0477b0676 100644
--- a
This VS system value will contain the value passed as
for indexed draw calls or the value passed as for non-indexed
draw calls. It will be used to calculate the gl_VertexID as
SYSTEM_VALUE_VERTEX_ID_ZERO_BASE plus SYSTEM_VALUE_BASE_VERTEX_ID.
Note that the current calculation which uses SYSTEM_VA
h element transferred is the sum of basevertex and the
value stored in the currently bound element 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
i96
The gl_BaseVertex is in a new location now, and the new basevertexid occupies
the old gl_BaseVertex place.
Reviewed-by: Neil Roberts
---
src/intel/compiler/brw_nir.c| 12
src/intel/compiler/brw_vec4.cpp | 14 --
2 files changed, 16 insertions(+), 10 deletions(-)
dif
From: Neil Roberts
base_vertex will be zero for non-indexed calls, but we need it to
include the ‘first’ parameter. This is true for both GL and Vulkan.
I think this patch will also affect freedreno and radeonsi. I believe
if they are relying on this lowering then they are currently already
brok
From: Neil Roberts
---
src/intel/compiler/brw_compiler.h | 1 +
src/intel/compiler/brw_vec4.cpp | 4
2 files changed, 5 insertions(+)
diff --git a/src/intel/compiler/brw_compiler.h
b/src/intel/compiler/brw_compiler.h
index df6ee018546..6b5b73a54f0 100644
--- a/src/intel/compiler/brw_com
The new basevertexid will be emitted in the position previously occupied by
gl_BaseVertex. This way we can keep pointing the indirect buffer for indirect
draw calls. The gl_BaseVertex is now emited as part of the draw_id
VERTEX_ELEMENT.
Reviewed-by: Neil Roberts
---
src/mesa/drivers/dri/i965/brw
- From the OpenGL 4.6 (11.1.3.9 Shader Inputs) specification:
"gl_BaseVertex holds the integer value passed to the baseVertex parameter to the
command that resulted in the current shader invocation. In the case where the
command has no baseVertex parameter, the value of gl_BaseVertex is zero."
-
From: Neil Roberts
The base vertex in Vulkan is different from GL in that for non-indexed
primitives the value is taken from the firstVertex parameter instead
of being set to zero. This coincides with the new
SYSTEM_VALUE_BASE_VERTEX_ID instead of BASE_VERTEX.
---
src/compiler/spirv/vtn_variable
From: Neil Roberts
---
src/mesa/drivers/dri/i965/brw_context.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 19d5a2e3503..01c8e8cb3cf 100644
--- a/src/mesa/drivers/dri/i965/brw_contex
rred to as its vertex ID, and may be read by a vertex shader as gl_VertexID.
The vertex ID of the ith element transferred is the sum of basevertex and the
value stored in the currently bound element array buffer at offset indices + i."
Antia Puentes (3):
compiler: Add SYSTEM_VALUE_FIRST_VE
From: Neil Roberts
Reviewed-by: Kenneth Graunke
---
src/intel/compiler/brw_compiler.h | 1 +
src/intel/compiler/brw_vec4.cpp | 4
2 files changed, 5 insertions(+)
diff --git a/src/intel/compiler/brw_compiler.h
b/src/intel/compiler/brw_compiler.h
index 28aed833245..6661427e982 100644
--
The new order is:
* VE 1:
* VE 2:
Previously it was:
* VE 1:
* VE 2:
The gl_BaseVertex is in a new location now, and firstvertex occupies
the old gl_BaseVertex place. This way we can keep pointing to the
indirect buffer for indirect draw calls.
Reviewed-by: Neil Roberts
---
src/intel/compi
- From the OpenGL 4.6 (11.1.3.9 Shader Inputs) specification:
"gl_BaseVertex holds the integer value passed to the baseVertex parameter to the
command that resulted in the current shader invocation. In the case where the
command has no baseVertex parameter, the value of gl_BaseVertex is zero."
-
From: Neil Roberts
The base vertex in Vulkan is different from GL in that for non-indexed
primitives the value is taken from the firstVertex parameter instead
of being set to zero. This coincides with the new SYSTEM_VALUE_FIRST_VERTEX
instead of BASE_VERTEX.
---
src/compiler/spirv/vtn_variables.
From: Neil Roberts
---
src/mesa/drivers/dri/i965/brw_context.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index b62852d90c8..249f62847b9 100644
--- a/src/mesa/drivers/dri/i965/brw_contex
From: Neil Roberts
base_vertex will be zero for non-indexed calls, but we need it to
include the ‘first’ parameter. This is true for both GL and Vulkan.
I think this patch will also affect freedreno and radeonsi. I believe
if they are relying on this lowering then they are currently already
brok
This VS system value will contain the value passed as
for indexed draw calls or the value passed as for non-indexed
draw calls. It will be used to calculate the gl_VertexID as
SYSTEM_VALUE_VERTEX_ID_ZERO_BASE plus SYSTEM_VALUE_FIRST_VERTEX.
Note that the current calculation which uses SYSTEM_VALU
Hi,
On 30/11/17 21:43, Neil Roberts wrote:
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, an
Reviewed-by: Antia Puentes
On 09/10/17 16:37, Lionel Landwerlin wrote:
Also makes this statement a bit clearer.
CID: 1418920
Signed-off-by: Lionel Landwerlin
---
src/mesa/drivers/dri/i965/brw_draw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri
Reviewed-by: Antia Puentes
On 09/10/17 16:37, Lionel Landwerlin wrote:
CID: 1418616, 1418607
Signed-off-by: Lionel Landwerlin
---
src/intel/blorp/blorp_blit.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/intel/blorp/blorp_blit.c b/src/intel
Reviewed-by: Antia Puentes
On 12/10/17 13:24, Elie Tournier wrote:
Signed-off-by: Elie Tournier
---
src/intel/isl/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/isl/meson.build b/src/intel/isl/meson.build
index 789175e256..54024b4d11 100644
--- a
---
src/intel/compiler/brw_compiler.h | 1 +
src/intel/compiler/brw_vec4.cpp | 4
2 files changed, 5 insertions(+)
diff --git a/src/intel/compiler/brw_compiler.h
b/src/intel/compiler/brw_compiler.h
index 24196248b8e..e3bf535a519 100644
--- a/src/intel/compiler/brw_compiler.h
+++ b/src/int
Surplus code related to the basevertex is removed.
The Vertex Elements contain now:
* VE 1:
* VE 2:
Also fixes unreachable message.
Fixes OpenGL CTS tests:
* KHR-GL46.shader_draw_parameters_tests.ShaderDrawArraysInstancedParameters
* KHR-GL46.shader_draw_parameters_tests.ShaderMultiDrawArraysP
This VS system value contains if the draw command used to start the
rendering was an indexed draw command or a non-indexed one
(~0/0 respectively). Useful to calculate the gl_BaseVertex as:
(SYSTEM_VALUE_IS_INDEXED_DRAW & SYSTEM_VALUE_FIRST_VERTEX).
---
src/compiler/nir/nir.c | 4
. No regressions found.
Antia Puentes (5):
compiler: Add SYSTEM_VALUE_IS_INDEXED_DRAW and instrinsics
intel/compiler: Add uses_is_indexed_draw flag
intel: emit is_indexed_draw in the same VE than gl_DrawID
compiler/nir: Add conditional lowering for gl_BaseVertex
intel: activate the gl_BaseVe
---
src/compiler/nir/nir.h | 6 ++
src/compiler/nir/nir_lower_system_values.c | 15 +++
2 files changed, 21 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index f3326e6df94..1b1dd4dd31b 100644
--- a/src/compiler/nir/nir.h
+++ b/src/
The Vertex Elements are now:
* VE 1:
* VE 2:
VE1 is it kept as it was before, VE2 additionally contains the new
system value.
---
src/intel/compiler/brw_fs_nir.cpp | 2 ++
src/intel/compiler/brw_nir.c | 11 +--
src/intel/compiler/brw_vec4.cpp | 14
On 26/01/18 11:31, Antia Puentes wrote:
On 25/01/18 18:56, Roland Scheidegger wrote:
Am 25.01.2018 um 17:56 schrieb Roland Scheidegger:
Am 25.01.2018 um 16:30 schrieb Michel Dänzer:
On 2018-01-24 05:38 PM, Juan A. Suarez Romero wrote:
This fixes KHR-GL45
From: Iago Toral Quiroga
Although on gen8+ platforms we can in theory use 3DSTATE_VF_SGVS
to put these beyond the last vertex element it seems that we still
need to allocate the SVGS element, otherwise we have observed cases
where we end up reading garbage. Specifically, the CTS test mentioned
be
Until we set gl_BaseVertex to zero for non-indexed draw calls
both have an identical value.
The Vertex Elements are kept like that:
* VE 1:
* VE 2:
---
src/intel/compiler/brw_nir.c | 3 +++
src/intel/compiler/brw_vec4.cpp | 1 +
src/mesa/drivers/dri/i965/brw_con
From: Neil Roberts
base_vertex will be zero for non-indexed calls and in that case we
need vertex_id to be offset by the ‘first’ parameter instead. That is
what we get with first_vertex. This is true for both GL and Vulkan.
The freedreno driver is also setting vertex_id_zero_based on
nir_options
From: Neil Roberts
The base vertex in Vulkan is different from GL in that for non-indexed
primitives the value is taken from the firstVertex parameter instead
of being set to zero. This coincides with the new SYSTEM_VALUE_FIRST_VERTEX
instead of BASE_VERTEX.
---
src/compiler/spirv/vtn_variables.
412 -> 416 (0.97%)
helped: 0
HURT: 2
Signed-off-by: Ian Romanick
Reviewed-by: Antia Puentes
---
src/mesa/drivers/dri/i965/brw_context.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 9ed8bc64bb3..77754
From: Neil Roberts
Reviewed-by: Kenneth Graunke
---
src/intel/compiler/brw_compiler.h | 1 +
src/intel/compiler/brw_vec4.cpp | 4
2 files changed, 5 insertions(+)
diff --git a/src/intel/compiler/brw_compiler.h
b/src/intel/compiler/brw_compiler.h
index b1086bbcee5..0afe5757945 100644
--
This VS system value will contain the value passed as
for indexed draw calls or the value passed as for non-indexed
draw calls. It can be used to calculate the gl_VertexID as
SYSTEM_VALUE_VERTEX_ID_ZERO_BASE plus SYSTEM_VALUE_FIRST_VERTEX.
From the OpenGL 4.6 spec, 10.4 "Drawing Commands Using V
We keep 'firstvertex' as it is and move gl_BaseVertex to the drawID vertex
element. The previous Vertex Elements order was:
* VE 1:
* VE 2:
and now it is:
* VE 1:
* VE 2:
To move the BaseVertex keeping VE1 as it is, allows to keep pointing the vertex
buffer associated to VE 1 to the
On 25/01/18 18:56, Roland Scheidegger wrote:
Am 25.01.2018 um 17:56 schrieb Roland Scheidegger:
Am 25.01.2018 um 16:30 schrieb Michel Dänzer:
On 2018-01-24 05:38 PM, Juan A. Suarez Romero wrote:
This fixes KHR-GL45.internalformat.renderbuffer.rgb9_e5.
---
src/mesa/main/fbobject.c | 3 +++
This reverts commit 513c2263cbff45edb105c7b46e58f316e06746ab.
_mesa_base_fbo_format_ is used to validate the internalformat
passed to RenderbufferStorage, which in the OpenGL 4.6 is said:
"An INVALID_ENUM error is generated if internalformat is not one of the
color-renderable, depth-renderable, o
Hi Roland,
On 26/01/18 13:57, Roland Scheidegger wrote:
Am 26.01.2018 um 11:31 schrieb Antia Puentes:
On 25/01/18 18:56, Roland Scheidegger wrote:
Am 25.01.2018 um 17:56 schrieb Roland Scheidegger:
Am 25.01.2018 um 16:30 schrieb Michel Dänzer:
On 2018-01-24 05:38 PM, Juan A. Suarez Romero
On 26/01/18 14:19, Roland Scheidegger wrote:
Am 26.01.2018 um 14:13 schrieb Antia Puentes:
Hi Roland,
On 26/01/18 13:57, Roland Scheidegger wrote:
Am 26.01.2018 um 11:31 schrieb Antia Puentes:
On 25/01/18 18:56, Roland Scheidegger wrote:
Am 25.01.2018 um 17:56 schrieb Roland Scheidegger
es the following test on Haswell:
KHR-GL46.vertex_attrib_binding.basic-inputL-case1
Fixes: 75968a668e4 ("i965/gen7: expose OpenGL 4.2 on Haswell when
supported")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103006
Cc: Alejandro Piñeiro
Cc: Juan A. Suarez Romero
Cc: Antia Puen
This series is still waiting for review.
On 25/01/18 19:15, Antia Puentes wrote:
This VS system value will contain the value passed as
for indexed draw calls or the value passed as for non-indexed
draw calls. It can be used to calculate the gl_VertexID as
SYSTEM_VALUE_VERTEX_ID_ZERO_BASE
From: "Juan A. Suarez Romero"
VS Thread Payload handles attributes in URB as vec4, no matter if they
are actually single or double precision.
So with double-precision types, value ends up in the registers split in
32bits chunks, in different positions.
We need to shuffle the chunks to get the d
From: "Juan A. Suarez Romero"
When computing where the first non-payload GRF starts, we can't rely on
the number of attributes, as each attribute can be using 1 or 2 slots
depending on whether they are a dvec3/4 or other.
Instead, we need to use the number of slots used by the attributes.
---
s
From: "Juan A. Suarez Romero"
This bitmap tracks which input attributes are double-precision.
---
src/compiler/nir/glsl_to_nir.cpp | 1 +
src/compiler/nir/nir.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/src/compiler/nir/glsl_to_nir.cpp b/src/compiler/nir/glsl_to_nir.cpp
in
From: Alejandro Piñeiro
Add an assertion to detect this case.
---
src/mesa/drivers/dri/i965/gen8_draw_upload.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen8_draw_upload.c
b/src/mesa/drivers/dri/i965/gen8_draw_upload.c
index 14f7091..17a
From: "Juan A. Suarez Romero"
Do not use total attributes because a dvec3/dvec4 attribute requires two
slots. So rather use total attribute slots.
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/mesa/driver
From: Alejandro Piñeiro
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 412dea0..d3905d0 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions
From: "Juan A. Suarez Romero"
Even when the number of vertex attributes is under the limit, for
shaders that use a high number of them, we can quickly exhaust the
number of hardware registers.
In this case, just abort the linking.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 6 ++
1 file chan
From: Alejandro Piñeiro
This commit adds support for PASSTHRU format when pushing
double-precision attributes.
Check glarray->Doubles in order to know if we should choose a format
that does a conversion to float, or just passthru the 64-bit double.
---
src/mesa/drivers/dri/i965/brw_draw_upload.
From: Alejandro Piñeiro
ARB_vertex_attrib_64bit was the only feature missing.
---
src/mesa/drivers/dri/i965/intel_extensions.c | 2 +-
src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
edge flag enabled
i965/fs: half exec_size when dealing with 64 bits attributes
i965: Enable ARB_vertex_attrib_64bit for gen8+
docs: Mark ARB_vertex_attrib_64bit as done for i965
i965: Expose OpenGL 4.1 for gen8+
Antia Puentes (1):
i965: Configure how to store *64*PASSTHRU vertex
From: "Juan A. Suarez Romero"
In scalar mode, URB read length limit is 15. Abort if we go beyond it.
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 9816f
From: Alejandro Piñeiro
---
docs/GL3.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 95ee508..3f1f7a3 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -142,7 +142,7 @@ GL 4.1, GLSL 4.10 --- all DONE: nvc0, r600, radeonsi
GL_ARB_get_prog
From: Alejandro Piñeiro
The HW has a restriction that only vertical stride may cross register
boundaries. Until now this was only handled on VGRFs at
rw_reg_from_fs_reg, but it is also needed for attributes.
This can be seen as the equivalent of commit 552cfa9 but for
attributes. Take a look to
From: "Juan A. Suarez Romero"
Double-precision types require 1 slot in VUE for double and dvec2, and 2 slots
for
anything else.
---
src/mesa/drivers/dri/i965/brw_nir.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_
ments, and 256-bits for
dvec3 and dvec4 vertex elements.
Signed-off-by: Juan A. Suarez Romero
Signed-off-by: Antia Puentes
---
src/mesa/drivers/dri/i965/gen8_draw_upload.c | 34
1 file changed, 34 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen8_draw_uploa
From: "Juan A. Suarez Romero"
Input attributes can require 2 vec4 or 1 vec4 depending on whether they
are double-precision or not.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
src/mesa/drivers/dri/i965/brw_nir.c| 3 ++-
src/mesa/drivers/dri/i965/brw_shader.h | 1 +
3 file
From: "Juan A. Suarez Romero"
Input attributes can require 2 vec4 or 1 vec4 depending on whether they
are double-precision or not.
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
src/mesa/drivers/dri/i965/brw_nir.c| 3 ++-
src/mesa/drivers/dri/i
From: Alejandro Piñeiro
ARB_vertex_attrib_64bit was the only feature missing.
v2: we can expose 4.2 instead of 4.1 (Ian Romanick)
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_extensions.c | 2 +-
src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
2 files changed, 2 inser
From: "Juan A. Suarez Romero"
From the GL 4.5 core spec, section 11.1.1 (Vertex Attributes):
"A program with more than the value of MAX_VERTEX_ATTRIBS
active attribute variables may fail to link, unless
device-dependent optimizations are able to make the program
fit within available hardware res
From: "Juan A. Suarez Romero"
When computing where the first non-payload GRF starts, we can't rely on
the number of attributes, as each attribute can be using 1 or 2 slots
depending on whether they are a dvec3/4 or other.
Instead, we need to use the number of slots used by the attributes.
Revie
From: Alejandro Piñeiro
This commit adds support for PASSTHRU format when pushing
double-precision attributes.
Check glarray->Doubles in order to know if we should choose a format
that does a conversion to float, or just passthru the 64-bit double.
Reviewed-by: Kenneth Graunke
---
src/mesa/dr
From: Alejandro Piñeiro
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index dcb9831..1c3e8bd 100644
--- a/src/mesa/dri
ments, and 256-bits for
dvec3 and dvec4 vertex elements.
Signed-off-by: Juan A. Suarez Romero
Signed-off-by: Antia Puentes
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen8_draw_upload.c | 35
1 file changed, 35 insertions(+)
diff --git a/src/mesa/d
From: Alejandro Piñeiro
Add an assertion to detect this case.
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen8_draw_upload.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen8_draw_upload.c
b/src/mesa/drivers/dri/i965/gen8_d
From: "Juan A. Suarez Romero"
Double-precision types require 1 slot in VUE for double and dvec2, and 2 slots
for
anything else.
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_nir.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a
From: "Juan A. Suarez Romero"
This bitmap tracks which input attributes are double-precision.
Reviewed-by: Kenneth Graunke
---
src/compiler/nir/glsl_to_nir.cpp | 1 +
src/compiler/nir/nir.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/src/compiler/nir/glsl_to_nir.cpp b/src/
From: "Juan A. Suarez Romero"
Do not use total attributes because a dvec3/dvec4 attribute requires two
slots. So rather use total attribute slots.
v2: do not use loop to calculate required attribute slots (Kenneth
Graunke)
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.cp
From: "Juan A. Suarez Romero"
From the GL 4.5 core spec, section 11.1.1 (Vertex Attributes):
"A program with more than the value of MAX_VERTEX_ATTRIBS
active attribute variables may fail to link, unless
device-dependent optimizations are able to make the program
fit within available hardware res
From: Alejandro Piñeiro
v2: label as done for i965/gen8+ instead of i965 (Kenneth Graunke)
Reviewed-by: Kenneth Graunke
---
docs/GL3.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index c957604..a5ab7ee 100644
--- a/docs/GL3.txt
+++ b/docs/G
From: Alejandro Piñeiro
The HW has a restriction that only vertical stride may cross register
boundaries. Until now this was only handled on VGRFs at
rw_reg_from_fs_reg, but it is also needed for attributes.
v2:
* Remove reference to commit id on commit message (Juan Suarez)
* Simplify code th
for gen8+
docs: Mark ARB_vertex_attrib_64bit as done for i965/gen8+
i965: Expose OpenGL 4.2 for gen8+
Antia Puentes (1):
i965: Configure how to store *64*PASSTHRU vertex components
Juan A. Suarez Romero (8):
i965/fs: shuffle 32bits into 64bits for doubles
nir: add double input bitmap
From: "Juan A. Suarez Romero"
VS Thread Payload handles attributes in URB as vec4, no matter if they
are actually single or double precision.
So with double-precision types, value ends up in the registers split in
32bits chunks, in different positions.
We need to shuffle the chunks to get the d
8 10:15 AM, Antia Puentes wrote:
Until we set gl_BaseVertex to zero for non-indexed draw calls
both have an identical value.
The Vertex Elements are kept like that:
* VE 1:
* VE 2:
---
src/intel/compiler/brw_nir.c | 3 +++
src/intel/compiler/brw_vec4.cpp | 1 +
On 07/04/18 08:21, Jason Ekstrand wrote:
On Fri, Apr 6, 2018 at 2:53 PM, Ian Romanick <mailto:i...@freedesktop.org>> wrote:
From: Antia Puentes mailto:apuen...@igalia.com>>
We keep 'firstvertex' as it is and move gl_BaseVertex to the drawID
vertex ele
On 10/04/18 18:26, Jason Ekstrand wrote:
On Tue, Apr 10, 2018 at 1:28 AM, Antia Puentes <mailto:apuen...@igalia.com>> wrote:
On 07/04/18 08:21, Jason Ekstrand wrote:
On Fri, Apr 6, 2018 at 2:53 PM, Ian Romanick mailto:i...@freedesktop.org>> wrote:
From
92 matches
Mail list logo
