https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #22 from zefkerri...@gmail.com ---
Created attachment 142404
--> https://bugs.freedesktop.org/attachment.cgi?id=142404&action=edit
All minimal settings
--
You are receiving this mail because:
You are the QA Contact for the bug.
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #23 from Samuel Pitoiset ---
I'm having troubles to reproduce the problem on my Pitcairn card. Can you show
me the output of R600_DEBUG=info glxgears ?
--
You are receiving this mail because:
You are the assignee for the bug.
You a
On Thu, 2018-11-08 at 08:47 +0200, Tapani Pälli wrote:
> FYI there's a whole lot of tests that start to fail when this series
> running on Intel CI. It includes dEQP but also Piglit tests, can you
> do
> Intel CI run or do you want me to send you results?
If you mean mesa-ci.01.org, then I have
On 11/8/18 10:44 AM, Erik Faye-Lund wrote:
On Thu, 2018-11-08 at 08:47 +0200, Tapani Pälli wrote:
FYI there's a whole lot of tests that start to fail when this series
running on Intel CI. It includes dEQP but also Piglit tests, can you
do
Intel CI run or do you want me to send you results?
If
On Thu, 2018-11-08 at 10:47 +0200, Tapani Pälli wrote:
> On 11/8/18 10:44 AM, Erik Faye-Lund wrote:
> > On Thu, 2018-11-08 at 08:47 +0200, Tapani Pälli wrote:
> > > FYI there's a whole lot of tests that start to fail when this
> > > series
> > > running on Intel CI. It includes dEQP but also Piglit
I just noticed I never replied to this:
On Tue, 2018-10-30 at 10:18 -0500, Jason Ekstrand wrote:
> On Tue, Oct 30, 2018 at 2:50 AM Iago Toral wrote:
> > Some quick comments on this after experimenting with it:
> >
> >
> >
> > Intel hardware produces booleans of the same bit-size as the
> > oper
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #24 from zefkerri...@gmail.com ---
Created attachment 142405
--> https://bugs.freedesktop.org/attachment.cgi?id=142405&action=edit
The output of R600_DEBUG=info glxgears
(In reply to Samuel Pitoiset from comment #23)
> I'm having t
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #25 from Samuel Pitoiset ---
Well, you don't have the OpenGL driver installed? (ie. radeonsi)
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #26 from Samuel Pitoiset ---
RADV_DEBUG=info vulkaninfo please.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev m
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #27 from zefkerri...@gmail.com ---
(In reply to Samuel Pitoiset from comment #25)
> Well, you don't have the OpenGL driver installed? (ie. radeonsi)
I use Mesa-git, Wine Staging+DXVK, so RadeonSI not in use.
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #28 from zefkerri...@gmail.com ---
(In reply to Samuel Pitoiset from comment #25)
> Well, you don't have the OpenGL driver installed? (ie. radeonsi)
But I haven't this issue with WineD3D/RadeonSI, only with DXVK/RADV.
--
You are re
On Thu, 2018-11-08 at 09:54 +0100, Erik Faye-Lund wrote:
> On Thu, 2018-11-08 at 10:47 +0200, Tapani Pälli wrote:
> > On 11/8/18 10:44 AM, Erik Faye-Lund wrote:
> > > On Thu, 2018-11-08 at 08:47 +0200, Tapani Pälli wrote:
> > > > FYI there's a whole lot of tests that start to fail when this
> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #29 from zefkerri...@gmail.com ---
Created attachment 142406
--> https://bugs.freedesktop.org/attachment.cgi?id=142406&action=edit
RADV_DEBUG=info vulkaninfo
(In reply to Samuel Pitoiset from comment #26)
> RADV_DEBUG=info vulkanin
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #30 from Samuel Pitoiset ---
Well, the output doesn't help... It should look like
https://hastebin.com/ujuyujobon
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
Hello,
I don't know how we usually do in such cases.
Could I just restore back the 'review-by' tags here due to trivial changes
or this patch should pass review process once again?
Thanks,
Andrii.
On Mon, Nov 5, 2018 at 10:42 AM Jordan Justen
wrote:
> On 2018-11-05 00:11:52, andrey simiklit wr
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #31 from zefkerri...@gmail.com ---
Created attachment 142407
--> https://bugs.freedesktop.org/attachment.cgi?id=142407&action=edit
R600_DEBUG without the game starting
A try #2
--
You are receiving this mail because:
You are the
On 11/7/18 5:58 PM, Erik Faye-Lund wrote:
ctx->Extensions.EXT_timer_query is set based on the driver-
capabilities, not based on the context type. We need to check against
_mesa_has_EXT_timer_query(ctx) instead to figure out if the extension
is really supported.
This turns usage of GL_TIME_ELA
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #32 from Samuel Pitoiset ---
You have to run the native version of vulkaninfo, not via wine.
"RADV_DEBUG=info vulkaninfo" in a new terminal should just work.
--
You are receiving this mail because:
You are the QA Contact for the b
On Thu, 2018-11-08 at 11:40 +0200, Tapani Pälli wrote:
>
> On 11/7/18 5:58 PM, Erik Faye-Lund wrote:
> > ctx->Extensions.EXT_timer_query is set based on the driver-
> > capabilities, not based on the context type. We need to check
> > against
> > _mesa_has_EXT_timer_query(ctx) instead to figure ou
https://bugs.freedesktop.org/show_bug.cgi?id=107022
--- Comment #33 from zefkerri...@gmail.com ---
(In reply to Samuel Pitoiset from comment #32)
> You have to run the native version of vulkaninfo, not via wine.
>
> "RADV_DEBUG=info vulkaninfo" in a new terminal should just work.
This is exactly
On Thu, 2018-11-08 at 10:47 +0200, Tapani Pälli wrote:
> On 11/8/18 10:44 AM, Erik Faye-Lund wrote:
> > On Thu, 2018-11-08 at 08:47 +0200, Tapani Pälli wrote:
> > > FYI there's a whole lot of tests that start to fail when this
> > > series
> > > running on Intel CI. It includes dEQP but also Piglit
Reviewed-by: Lionel Landwerlin
On 07/11/2018 14:49, Toni Lönnberg wrote:
Preliminary work for adding handling of different pipes to gen_decoder. Each
instruction needs to have a definition describing which engine it is meant for.
If left undefined, by default, the instruction is defined for all
Reviewed-by: Lionel Landwerlin
On 07/11/2018 14:50, Toni Lönnberg wrote:
The engine to which the batch was sent to is now set to the decoder context when
decoding the batch. This is needed so that we can distinguish between
instructions as the render and video pipe share some of the instruction
Actually I take that back. Could you update
src/intel/tools/aubinator_viewer.cpp too?
To compile it with meson just pass the -Dtools=intel-ui option.
Thanks,
-
Lionel
On 06/11/2018 12:17, Lionel Landwerlin wrote:
Looks good, thanks!
Reviewed-by: Lionel Landwerlin
On 31/10/2018 13:57, Toni
It looks like you forgot URB_FENCE here.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, 2018-11-05 at 09:54 +0100, Samuel Pitoiset wrote:
> VK_EXT_conditional_rendering says that copy commands should not be
> affected by conditional rendering.
>
> Cc: 18.2 18.3
> Signed-off-by: Samuel Pitoiset
This patch didn't apply cleanly on 18.2, so I've resolved the trivial conflicts
Missing tag on :
CS_URB_STATE
CONSTANT_BUFFER
MI_FLUSH
URB_FENCE
XY_COLOR_BLT
XY_SETUP_BLT
XY_SRC_COPY_BLT
XY_TEXT_IMMEDIATE_BLT
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Same missing tags a gen4.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Missing render engine tag :
MEDIA_GATEWAY_STATE
MI_LOAD_SCAN_LINES_EXCL
MI_URB_CLEAR
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Good Morning,
I can confirm that the new build gcc-8.2.1-5 from jakub already
available in *-testing fixes the problem for me.
Thanks!!
Mathias
On Saturday, 3 November 2018 15:31:32 CET Mathias Fröhlich wrote:
> Hi,
>
> > > Before filing a bug report at gcc I wanted to verify that we are not
Just SWTESS_BASE_ADDRESS missing render engine
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Missing render engine :
SWTESS_BASE_ADDRESS
MI_RS_CONTEXT
MI_RS_CONTROL
MI_RS_STORE_DATA_IMM
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hello,
Please find my comment below:
On Wed, Nov 7, 2018 at 4:49 PM Toni Lönnberg
wrote:
> Preliminary work for adding handling of different pipes to gen_decoder.
> Each
> instruction needs to have a definition describing which engine it is meant
> for.
> If left undefined, by default, the inst
Missing render :
MI_TOPOLOGY_FILTER
MI_URB_CLEAR
SWTESS_BASE_ADDRESS
MI_RS_STORE_DATA_IMM
MI_RS_CONTROL
MI_RS_CONTEXT
MI_LOAD_URB_MEM
MI_STORE_URB_MEM
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailma
Missing render :
MI_LOAD_URB_MEM
MI_RS_CONTEXT
MI_RS_CONTROL
MI_RS_STORE_DATA_IMM
MI_URB_ATOMIC_ALLOC
MI_TOPOLOGY_FILTER
Render & blitter :
MI_DISPLAY_FLIP
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/
Probably same as Gen9 :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 11/8/18 11:53 AM, Erik Faye-Lund wrote:
On Thu, 2018-11-08 at 10:47 +0200, Tapani Pälli wrote:
On 11/8/18 10:44 AM, Erik Faye-Lund wrote:
On Thu, 2018-11-08 at 08:47 +0200, Tapani Pälli wrote:
FYI there's a whole lot of tests that start to fail when this
series
running on Intel CI. It inc
Same as Gen9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Nov 08, 2018 at 12:57:03PM +0200, andrey simiklit wrote:
> Hello,
>
> Please find my comment below:
>
> On Wed, Nov 7, 2018 at 4:49 PM Toni Lönnberg
> wrote:
>
> > Preliminary work for adding handling of different pipes to gen_decoder.
> > Each
> > instruction needs to have a definition
On Wed, 2018-10-31 at 13:29 +, Emil Velikov wrote:
> From: Emil Velikov
>
> We'll bump the number in the build systems shortly. Update the travis
> file, first, to avoid intermittent failures.
>
> This effectively removes LLVM 3.9 and 4.0 from the build matrix.
>
> Cc: Juan A. Suarez Romero
On Wed, 7 Nov 2018 at 21:23, Jan Vesely wrote:
> yes. as long as the setting survives reconfigure+rebuild I'm fine.
The provided option works in the usecase you're interested. I'm not
sure why we're debating this bth.
Emil
___
mesa-dev mailing list
mes
On 11/8/18 1:02 PM, Tapani Pälli wrote:
On 11/8/18 11:53 AM, Erik Faye-Lund wrote:
On Thu, 2018-11-08 at 10:47 +0200, Tapani Pälli wrote:
On 11/8/18 10:44 AM, Erik Faye-Lund wrote:
On Thu, 2018-11-08 at 08:47 +0200, Tapani Pälli wrote:
FYI there's a whole lot of tests that start to fail w
On 11/8/18 11:46 AM, Juan A. Suarez Romero wrote:
On Mon, 2018-11-05 at 09:54 +0100, Samuel Pitoiset wrote:
VK_EXT_conditional_rendering says that copy commands should not be
affected by conditional rendering.
Cc: 18.2 18.3
Signed-off-by: Samuel Pitoiset
This patch didn't apply cleanly o
Preliminary work for adding handling of different pipes to gen_decoder. Each
instruction needs to have a definition describing which engine it is meant for.
If left undefined, by default, the instruction is defined for all engines.
v2: Changed to use the engine class definitions from UAPI
v3: Cha
On Wed, 2018-11-07 at 16:02 +, Emil Velikov wrote:
> From: Emil Velikov
>
> A while back we agreed that having a live/staging branch is beneficial.
> Sadly we forgot to document that, so here is my first attempt.
>
> Document the caveat that the branch history is not stable.
>
> CC: Andres
On Thu, 2018-11-08 at 13:43 +0200, Tapani Pälli wrote:
>
> On 11/8/18 1:02 PM, Tapani Pälli wrote:
> >
> > On 11/8/18 11:53 AM, Erik Faye-Lund wrote:
> > > On Thu, 2018-11-08 at 10:47 +0200, Tapani Pälli wrote:
> > > > On 11/8/18 10:44 AM, Erik Faye-Lund wrote:
> > > > > On Thu, 2018-11-08 at 08:
On Wed, 2018-11-07 at 12:07 +, Emil Velikov wrote:
> From: Emil Velikov
>
> With later commits we'll fold all the different scripts into one.
> Add the explicit prefix, so that we know the origin of the nomination
>
> Signed-off-by: Emil Velikov
> ---
> bin/get-pick-list.sh | 21 ++
I forgot to Cc some people :)
On 07/11/2018 13:31, Lionel Landwerlin wrote:
CNL configurations where given in increments of 2Kb, while ICL are
given in increments of 4Kb. We seem to have missed some updates in the
internal documentation.
Signed-off-by: Lionel Landwerlin
BSpec: 21166
---
src/
Removed the gen_engine enum and changed the involved functions to use the
drm_i915_gem_engine_class enum from UAPI instead.
v3: Wrong engine was being used for blocks in video ring
v4: Fixed aubinator_viewer.cpp
---
src/intel/tools/aub_read.c | 22 +++---
src/intel/tool
According to the extension spec, this was initially released in 2011,
so let's set this to the correct value.
The value of 2001 could be a copy-paste mistake, as ARB_occlusion_query
which this is based on was released then.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/extensions_table.h | 2
ctx->Extensions.ARB_timer_query is set based on the driver-
capabilities, not based on the context type. We need to check
against _mesa_has_ARB_timer_query(ctx) instead to figure out
if the extension is really supported. We also need to check for
EXT_disjoint_timer_query for GLES-support.
This sho
EXT_occlusion_query_boolean require support for GL_ANY_SAMPLES_PASSED,
which ARB_occlusion_query doesn't supply. We need ARB_occlusion_query2
for this instead.
This is still not 100% accurate, as we also require support for the
GL_SAMPLES_PASSED_CONSERVATIVE target, which isn't guaranteed by eithe
ctx->Extensions.ARB_transform_feedback_overflow_query is set based on
the driver-capabilities, not based on the context type. We need to
check against _mesa_has_RB_transform_feedback_overflow_query(ctx)
instead to figure out if the extension is really supported.
This turns usage of GL_TRANSFORM_FE
Here's v2 of this series. Changes are as follows:
- 5/13: also check for ARB_occlusion_query2, for core-contexts
- 8/13: also check for EXT_disjoint_timer_query, for gles-contexts
- 9/13: also check for OES_geometry_shader, for gles-contexts
- 12/13: also check for EXT_disjoint_timer_query, for gl
ctx->Extensions.ARB_occlusion_query is set based on the driver-
capabilities, not based on the context type. We need to check against
_mesa_has_ARB_occlusion_query(ctx) instead to figure out if the
extension is really supported. We also need to check for
ARB_occlusion_query2, as ARB_occlusion_query
ctx->Extensions.ARB_query_buffer_object is set based on the driver-
capabilities, not based on the context type. We need to check against
_mesa_has_ARB_query_buffer_object(ctx) instead to figure out if the
extension is really supported.
This turns attempts to read queries into buffer objects on ES
ctx->Extensions.EXT_transform_feedback is set based on the driver-
capabilities, not based on the context type. We need to check against
_mesa_has_EXT_transform_feedback(ctx) instead to figure out if the
extension is really supported. We also need to check for
OES_geometry_shader.
This turns usage
The rules encoded in this code also applies to OpenGL ES 3.0 and up,
but the per-enum validation has already been taught about these rules.
So let's get rid of this duplicate, narrow version of the validation.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/queryobj.c | 14 --
1 file
The _mesa_has_ARB_pipeline_statistics_query(ctx)-helper will already
check the GLES-version according to the extension-table, so if this
extension would ever be back-ported to ES, we only need to update the
table to support this.
This shouln't have any functional effect.
Signed-off-by: Erik Faye-
ctx->Extensions.ARB_occlusion_query2 is set based on the driver-
capabilities, not based on the context type. We need to check against
_mesa_has_ARB_occlusion_query2(ctx) instead to figure out if the
extension is really supported.
In addition, EXT_occlusion_query_boolean should also allow this
beh
These enums all have the same values as their non-prefixed versions, and
there's several aliases for some of them. So let's switch to the
non-prefixed versions for simplicity.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/queryobj.c | 66
1 file changed
ctx->Extensions.EXT_timer_query is set based on the driver-
capabilities, not based on the context type. We need to check against
_mesa_has_EXT_timer_query(ctx) instead to figure out if the extension
is really supported. We also need to check for
EXT_disjoint_timer_query, which enables the same fun
ctx->Extensions.ARB_ES3_compatibility is set based on the driver-
capabilities, not based on the context type. We need to check against
_mesa_has_ARB_ES3_compatibility(ctx) instead to figure out if the
extension is really supported.
In addition, EXT_occlusion_query_boolean should also allow this
b
Preliminary work for adding handling of different pipes to gen_decoder. Each
instruction needs to have a definition describing which engine it is meant for.
If left undefined, by default, the instruction is defined for all engines.
v2: Changed to use the engine class definitions from UAPI
v3: Cha
Thanks a lot,
Reviewed-by: Lionel Landwerlin
On 08/11/2018 12:41, Toni Lönnberg wrote:
Removed the gen_engine enum and changed the involved functions to use the
drm_i915_gem_engine_class enum from UAPI instead.
v3: Wrong engine was being used for blocks in video ring
v4: Fixed aubinator_view
Only needed when the pipeline actually uses tessellation. I don't
think that changes anything, except improving readability.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/src/amd/vulkan/radv_pipel
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 92254bed2e..145be67c85 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vu
On Thu, Nov 08, 2018 at 10:47:20AM +, Lionel Landwerlin wrote:
> Missing tag on :
>
>
> CS_URB_STATE
> CONSTANT_BUFFER
> MI_FLUSH
> URB_FENCE
> XY_COLOR_BLT
> XY_SETUP_BLT
> XY_SRC_COPY_BLT
> XY_TEXT_IMMEDIATE_BLT
?!
+
+
+
+
+
+
+
+
__
On Thu, Nov 08, 2018 at 10:47:55AM +, Lionel Landwerlin wrote:
> Same missing tags a gen4.5
?!
+
+
+
+
+
+
+
+
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 08/11/2018 13:06, Toni Lönnberg wrote:
On Thu, Nov 08, 2018 at 10:47:20AM +, Lionel Landwerlin wrote:
Missing tag on :
CS_URB_STATE
CONSTANT_BUFFER
MI_FLUSH
URB_FENCE
XY_COLOR_BLT
XY_SETUP_BLT
XY_SRC_COPY_BLT
XY_TEXT_IMMEDIATE_BLT
?!
+
+
+
+
+
+
+
+
___
On Thu, Nov 08, 2018 at 10:54:17AM +, Lionel Landwerlin wrote:
> Just SWTESS_BASE_ADDRESS missing render engine
?!
+
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Nov 08, 2018 at 10:55:06AM +, Lionel Landwerlin wrote:
> Missing render engine :
>
>
> SWTESS_BASE_ADDRESS
>
> MI_RS_CONTEXT
>
> MI_RS_CONTROL
>
> MI_RS_STORE_DATA_IMM
?!
+
+
+
+
___
mesa-dev mailing list
mesa-dev@lists.freedes
ARB_gl_spirv has its own NIR-based xfb gathering info. Since
nir_gather_xfb_info landed on master, I have been trying to get to use
it, in order to reuse code.
Although I consider this series a WIP, I prefer to share what I have
right now, just in case the idea of adapt nir_gather_xfb_info is
disc
In order to allow nir_gather_xfb_info to be used on OpenGL,
specifically ARB_gl_spirv.
So, from OpenGL 4.6 spec, section 11.1.2.1, "Output Variables":
"outputs specifying both an *XfbBuffer* and an *Offset* are
captured, while outputs not specifying both of these are not
captured. V
On OpenGL, a array of a simple type adds just one varying. So
gl_transform_feedback_varying_info struct defined at mtypes.h includes
the parameters Type (base_type) and Size (number of elements).
This commit checks this when the recursive add_var_xfb_outputs call
handles arrays, to ensure that jus
Although it is true that Vulkan doesn't support transform feedback
yet, spirv to nir is handling it due ARB_gl_spirv support. Having said
so, those decorations are handled elsewhere.
---
src/compiler/spirv/spirv_to_nir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compi
In order to be used for OpenGL (right now for ARB_gl_spirv).
This commit adds two new structures:
* nir_xfb_varying_info: that identifies each individual varying. For
each one, we need to know the type, buffer and xfb_offset
* nir_xfb_buffer_info: as now for each buffer, in addition to the
The offset compute was working fine for the case of attrib_slots=1,
and updating the offset for the following varying.
But in the case of attrib_slots=2 (so dvec3/4), we are basically
splitting the comp_slots needed in two outputs. In that case we can't
add to the offset the full size of the type.
Instead of a custom ARB_gl_spirv xfb gather info pass.
In fact, this is not only about reusing code, but the current custom
code was not handling properly how many varyings are enumerated from
some complex types. So this change is also about fixing some corner
cases.
---
src/compiler/glsl/gl_nir_
Where component_offset here is the offset when accessing components of
a packed variable. Or in other words, location_frac on
nir.h. Different places of mesa use different names for it.
Technically nir_xfb_info consumer can get the same from the
component_mask, it seems somewhat forced to make it
On Thu, Nov 08, 2018 at 01:10:54PM +, Lionel Landwerlin wrote:
> On 08/11/2018 13:06, Toni Lönnberg wrote:
> > On Thu, Nov 08, 2018 at 10:47:20AM +, Lionel Landwerlin wrote:
> > > Missing tag on :
> > >
> > >
> > > CS_URB_STATE
> > > CONSTANT_BUFFER
> > > MI_FLUSH
> > > URB_FENCE
> > > XY
On 08/11/2018 13:38, Toni Lönnberg wrote:
Will post v4 as a series instead of replying to these ones if that's ok with
you.
That would great, thank you.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/li
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/si_cmd_buffer.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 7a0f4e914d..a9f2572541 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_
Ported from RadeonSI.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 7 +++
src/amd/vulkan/radv_device.c | 12
src/amd/vulkan/radv_private.h| 2 ++
src/amd/vulkan/si_cmd_buffer.c | 3 ---
4 files changed, 21 insertions(+), 3 deletions(-)
diff
Good find.
On 08/11/2018 01:54, srol...@vmware.com wrote:
From: Roland Scheidegger
Because we only have one file_max for the (2d) gs input file, the value
actually represents the max of attrib and vertex index (although I'm
not entirely sure if we really want the max, since the max valid value
On Thu, 8 Nov 2018 at 11:54, Juan A. Suarez Romero wrote:
>
> On Wed, 2018-11-07 at 16:02 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > A while back we agreed that having a live/staging branch is beneficial.
> > Sadly we forgot to document that, so here is my first attempt.
> >
> > Do
On Thu, 8 Nov 2018 at 12:20, Juan A. Suarez Romero wrote:
>
> On Wed, 2018-11-07 at 12:07 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > With later commits we'll fold all the different scripts into one.
> > Add the explicit prefix, so that we know the origin of the nomination
> >
> > S
On Thu, 2018-11-08 at 14:48 +, Emil Velikov wrote:
> On Thu, 8 Nov 2018 at 11:54, Juan A. Suarez Romero
> wrote:
> > On Wed, 2018-11-07 at 16:02 +, Emil Velikov wrote:
> > > From: Emil Velikov
> > >
> > > A while back we agreed that having a live/staging branch is beneficial.
> > > Sadl
From: Emil Velikov
With later commits we'll fold all the different scripts into one.
Add the explicit prefix, so that we know the origin of the nomination
v2:
- pass the sha as argument to the function
- drop $tag = none an else statment (Juan)
- grep -q instead of using a variable (Eric)
-
From: Emil Velikov
Refactor is_fixes_nomination into a is_sha_nomination helper. This way
we can reuse it for more than the usual "Fixes:" tag.
Signed-off-by: Emil Velikov
---
bin/get-pick-list.sh | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/bin/get-pick-list
From: Emil Velikov
Every so often, we forget to add the colon after "fixes". Trivially
tweak the script to catch it.
Signed-off-by: Emil Velikov
---
bin/get-pick-list.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
index 1
From: Emil Velikov
Currently we match on:
- any arbitrary length of,
- any a-z A-Z and 0-9 characters
At the same time, a commit sha consists of lowercase hexadecimal
numbers. Any sha shorter than 8 characters is ambiguous - in some cases
even 11+ are required.
So change the pattern to a-f0-9
From: Emil Velikov
Latter is rather picky wrt surrounding white space. The explicit `test`
doesn't have that problem, plus the statements read a bit easier.
Signed-off-by: Emil Velikov
---
bin/get-pick-list.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bin/get-
From: Emil Velikov
Having a separate script to handle the fixes tag, brings a number of
issues, so let's fold it in get-pick-list.sh.
v2:
- pass the sha as argument to the function
- Keep original sed pattern
Signed-off-by: Emil Velikov
---
bin/get-fixes-pick-list.sh | 81 --
From: Emil Velikov
As the comment in get-typod-pick-list.sh says, there's little point in
having a duplicate file.
Add the new pattern + tag to get-pick-list.sh and nuke this file.
v2:
- pass the sha as argument to the function
- grep -q instead of using a variable (Eric)
Signed-off-by: Emil
Hi all,
This is a v2 of the earlier series "Fold typod/fixes scripts within
get-pick-list.sh" with updates, few tweaks and extra typos/mistakes
that we've been doing.
Patches 1-4: original (with comments addressed) and $sha passed as
argument to the functions
Patch 5: fixups the sed pattern to c
From: Emil Velikov
We have a number of cases were devs will use a tag "broken by".
While it's not something officially documented or recommended, checking
for it is trivial enough.
Signed-off-by: Emil Velikov
---
bin/get-pick-list.sh | 9 -
1 file changed, 8 insertions(+), 1 deletion(-
From: Emil Velikov
Currently we force disable the pager via "|cat" where --no-pager
exists. Additionally we could use git show instead of git log -n1.
Use those for a slightly more understandable code.
Signed-off-by: Emil Velikov
Reviewed-by: Eric Engestrom
---
bin/get-pick-list.sh | 2 +-
1
From: Nicolai Hähnle
Helpful for debugging compiler backend problems: this allows us to
easily retrieve the LLVM IR from RenderDoc.
--
For the peanut gallery: AMD's official stance on radv hasn't changed.
But we take regressions for radv caused by our changes in LLVM seriously.
After all, they mi
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
v3: Added additional engine definitions.
---
src/intel/genxml/gen4.xml | 50 ++
1 - 100 of 192 matches
Mail list logo
