On Thu, Nov 12, 2015 at 03:38:51PM -0800, Kenneth Graunke wrote:
> I was going to add scalar_tcs and scalar_tes flags, and then thought
> better of it and decided to convert this to an array. Simpler.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_compiler.h |
On Thu, Nov 12, 2015 at 03:38:52PM -0800, Kenneth Graunke wrote:
> This was getting pretty out of hand, and with compute partially in place
> and tessellation on the way, it was only going to get worse.
>
> This patch makes a "stage exists?" predicate and a "number of stages"
> count and uses them
If a source operand in a MOV has source modifiers, then we cannot
copy-propagate it from the parent instruction and remove the MOV.
v2: remove the check for source modifiers from is_move() (Jason)
v3: Put the check for source modifiers back into is_move() since
this function is called from co
Hi Emil,
Emil Velikov wrote on 12.11.2015 18:45:
> On 12 November 2015 at 15:36, Samuel Iglesias Gonsálvez
> wrote:
>> On 12/11/15 15:28, Timothy Arceri wrote:
>>> On 13 November 2015 12:22:39 am AEDT, "Samuel Iglesias Gonsálvez"
>>> wrote:
'shared' was added in ARB_uniform_buffer_object an
On 12 November 2015 at 16:47, Jason Ekstrand wrote:
> On Thu, Nov 12, 2015 at 6:46 AM, Pekka Paalanen wrote:
>> Reviewed-by: Pekka Paalanen
>>
>> Perhaps a TODO comment referring to
>> https://bugs.freedesktop.org/show_bug.cgi?id=78190
>> would be nice.
>
> Yes, that would be good. One day, we
Patch adds additional mask for tracking which vertex buffer bindings
are set. This array can be directly compared to which vertex arrays
are enabled and should match when drawing.
Fixes following CTS tests:
ES31-CTS.draw_indirect.negative-noVBO-arrays
ES31-CTS.draw_indirect.negative-noVBO-e
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_eu_validate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_validate.c
b/src/mesa/drivers/dri/i965/brw_eu_validate.c
index eb57962..2de2ea1 100644
--- a/src/mesa/drivers/dr
Ben Widawsky writes:
> Here is one proposal to fix the issue. I noticed that only formats
> without alpha were failing. This sucks for RGBX formats (which
> technically aren't fast clearable based on the surface format). The
> hunk for moving the format should happen regardless of this patch.
If
On 11/13/2015 12:36 PM, Juha-Pekka Heikkila wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/drivers/dri/i965/brw_eu_validate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_eu_validate.c
> b/src/mesa/drivers/dri/i965/brw_eu_v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
I would like to have admin permissions to Mesa and Piglit projects in
patchwork [0] to change the status of patches that are mine but they
are not assigned to me.
I saw in previous emails than just asking for it here is enough. If I
need to
On Fri, 2015-11-06 at 12:21 -0800, Matt Turner wrote:
> On Fri, Nov 6, 2015 at 8:27 AM, Juan A. Suarez Romero
> Looks good to me, and we use _mesa_fls elsewhere to do this same
> calculation.
>
> Reviewed-by: Matt Turner
>
> Jason, was there some reason we weren't doing this? I'm confused why
>
On vie, 2015-11-13 at 13:26 +0100, Samuel Iglesias Gonsálvez wrote:
> Hello,
>
> I would like to have admin permissions to Mesa and Piglit projects in
> patchwork [0] to change the status of patches that are mine but they
> are not assigned to me.
As Samuel, I would like to have admin permissions
On 13 November 2015 at 12:34, Antía Puentes wrote:
> On vie, 2015-11-13 at 13:26 +0100, Samuel Iglesias Gonsálvez wrote:
>> Hello,
>>
>> I would like to have admin permissions to Mesa and Piglit projects in
>> patchwork [0] to change the status of patches that are mine but they
>> are not assigned
On Fri, Nov 13, 2015 at 7:40 AM, Emil Velikov wrote:
> On 13 November 2015 at 12:34, Antía Puentes wrote:
>> On vie, 2015-11-13 at 13:26 +0100, Samuel Iglesias Gonsálvez wrote:
>>> Hello,
>>>
>>> I would like to have admin permissions to Mesa and Piglit projects in
>>> patchwork [0] to change the
On 13/11/15 13:40, Emil Velikov wrote:
> On 13 November 2015 at 12:34, Antía Puentes wrote:
>> On vie, 2015-11-13 at 13:26 +0100, Samuel Iglesias Gonsálvez wrote:
>>> Hello,
>>>
>>> I would like to have admin permissions to Mesa and Piglit projects in
>>> patchwork [0] to change the status of pa
On 13 November 2015 at 09:14, Kai Wasserbäch
wrote:
> Hi Emil,
> Emil Velikov wrote on 12.11.2015 18:45:
>> On 12 November 2015 at 15:36, Samuel Iglesias Gonsálvez
>> wrote:
>>> On 12/11/15 15:28, Timothy Arceri wrote:
On 13 November 2015 12:22:39 am AEDT, "Samuel Iglesias Gonsálvez"
On 13 November 2015 at 12:56, Samuel Iglesias Gonsálvez
wrote:
> On 13/11/15 13:40, Emil Velikov wrote:
>> On 13 November 2015 at 12:34, Antía Puentes wrote:
>>> On vie, 2015-11-13 at 13:26 +0100, Samuel Iglesias Gonsálvez wrote:
Hello,
I would like to have admin permissions to Mes
On Wed, 2015-11-11 at 17:26 -0800, Jason Ekstrand wrote:
> ---
> src/glsl/nir/nir.h | 2 +-
> src/glsl/nir/nir_lower_tex.c | 19 +++
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index 41125b1..2299ece 100
Reviewed-by: Iago Toral Quiroga
On Wed, 2015-11-11 at 17:26 -0800, Jason Ekstrand wrote:
> ---
> src/glsl/nir/nir_lower_tex.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/glsl/nir/nir_lower_tex.c b/src/glsl/nir/nir_lower_tex.c
> index 21ed103..6dea837 100644
> --- a/src/glsl/nir
On 13/11/15 11:32, Tapani Pälli wrote:
> Patch adds additional mask for tracking which vertex buffer bindings
> are set. This array can be directly compared to which vertex arrays
> are enabled and should match when drawing.
>
> Fixes following CTS tests:
>
>ES31-CTS.draw_indirect.negative-
Hi All,
So as discussed I've started working on a TGSI backend for
llvm to use as a way to get compute going on nouveau (and other gpu-s).
I'm still learning all the ins and outs of llvm so I do not have
much to show yet.
I've rebased Francisco's (curro's) latest version on top of llvm
trunk, a
On Wed, 2015-11-11 at 17:26 -0800, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> i
On Wed, 2015-11-11 at 17:26 -0800, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 11 +--
> src/mesa/drivers/dri/i965/brw_nir.c | 1 -
> src/mesa/drivers/dri/i965/brw_vec4.cpp| 5 -
> src/mesa/drivers/dri/i965/brw_vec4_gs_v
On 10 November 2015 at 17:30, Martin Peres wrote:
> Here is an update to the v3, addressing almost all the comments I got during
> the previous round. The one item that is left to do is the handling of
> EGL_BUFFER_PRESERVED which will take some time since I need to write a piglit
> test for it.
>
Hello Hans,
Not to muddy the waters or anything, have you thought about the NIR
integration that Rob was thinking about ?
I'm pretty sure he'll be happy to have extra people helping him out.
Cheers,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesk
On Fri, Nov 13, 2015 at 9:25 AM, Emil Velikov wrote:
> Hello Hans,
>
> Not to muddy the waters or anything, have you thought about the NIR
> integration that Rob was thinking about ?
> I'm pretty sure he'll be happy to have extra people helping him out.
How would that in any way plug into llvm or
Hi Brian,
The updated instructions worked for me. Thank you = )
Regards,
Valera Rozuvan | http://valera.rozuvan.net/
Skype: valera.rozuvan
E-mail: valera.rozu...@gmail.com
Phone: +38 (050) 837-29-73
On Wed, Nov 11, 2015 at 11:18 PM, Emil Velikov wrote:
> On 11 November 2015 at 19:51, Brian P
Hi Emil,
Emil Velikov wrote on 13.11.2015 13:58:
> On 13 November 2015 at 09:14, Kai Wasserbäch
> wrote:
>> Emil Velikov wrote on 12.11.2015 18:45:
>>> On 12 November 2015 at 15:36, Samuel Iglesias Gonsálvez
>>> wrote:
On 12/11/15 15:28, Timothy Arceri wrote:
> On 13 November 2015 12:22
This should fix the issue described in
https://bugs.freedesktop.org/show_bug.cgi?id=92633
---
src/mesa/main/fbobject.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index fe6bdc2..6398ff6 100644
--- a/src/mesa
Hi Samuel,
The subject line should probably be something like:
"mesa: add locking in create_render_buffers() and create_framebuffers()"
Then, the comment body:
"""
This makes generation of framebuffer and renderbuffer id's threadsafe
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=9263
Great! Glad to hear it. I'll check in the updated documentation today.
-Brian
On 11/13/2015 03:03 AM, Valera Rozuvan wrote:
Hi Brian,
The updated instructions worked for me. Thank you = )
Regards,
Valera Rozuvan |
https://urldefense.proofpoint.com/v2/url?u=http-3A__valera.rozuvan.net_&d=BQ
On Nov 13, 2015 5:53 AM, "Iago Toral" wrote:
>
> On Wed, 2015-11-11 at 17:26 -0800, Jason Ekstrand wrote:
> > ---
> > src/mesa/drivers/dri/i965/brw_fs.cpp | 11 +--
> > src/mesa/drivers/dri/i965/brw_nir.c | 1 -
> > src/mesa/drivers/dri/i965/brw_vec4.cpp
On Nov 6, 2015 12:21 PM, "Matt Turner" wrote:
>
> On Fri, Nov 6, 2015 at 8:27 AM, Juan A. Suarez Romero
> wrote:
> > Replace the current loop by a direct call to _mesa_fls() function.
> >
> > It also fixes an implicit bug in the current code where num_textures
> > seems to be one value less than
On Fri, Nov 13, 2015 at 9:38 AM, Ilia Mirkin wrote:
> On Fri, Nov 13, 2015 at 9:25 AM, Emil Velikov
> wrote:
>> Hello Hans,
>>
>> Not to muddy the waters or anything, have you thought about the NIR
>> integration that Rob was thinking about ?
>> I'm pretty sure he'll be happy to have extra peopl
On Nov 13, 2015 5:25 AM, "Iago Toral" wrote:
>
> On Wed, 2015-11-11 at 17:26 -0800, Jason Ekstrand wrote:
> > ---
> > src/glsl/nir/nir.h | 2 +-
> > src/glsl/nir/nir_lower_tex.c | 19 +++
> > 2 files changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/gls
On Nov 13, 2015 5:49 AM, "Iago Toral" wrote:
>
> On Wed, 2015-11-11 at 17:26 -0800, Jason Ekstrand wrote:
> > ---
> > src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.
On Fri, 2015-11-13 at 07:37 -0800, Jason Ekstrand wrote:
> I didn't want to pull a non-inline mesa function into NIR and add a
> link dependency and I was too lazy to move it into util.
But at this moment _mesa_fls() is an inline function. So I guess it is
safe to push it, isn't it?
J.A
On 11/12/2015 05:47 PM, Ilia Mirkin wrote:
On Mon, Nov 2, 2015 at 6:36 AM, Tapani Pälli wrote:
Patch sets matrix_stride as 0 for non matrix uniforms that are in a
atomic counter buffer. Matrix stride calculation for actual matrix
uniforms is done during link_assign_uniform_locations.
From ARB
On 11/13/2015 03:40 PM, Samuel Iglesias Gonsálvez wrote:
On 13/11/15 11:32, Tapani Pälli wrote:
Patch adds additional mask for tracking which vertex buffer bindings
are set. This array can be directly compared to which vertex arrays
are enabled and should match when drawing.
Fixes following CT
Hi,
You don't seem to have included any of the suggestions I made in my
review. Was this deliberate? If not, the main points were:
• You don't need to call brw_fast_clear_init or use_rectlist in the
function because these are already called before entering it.
• I don't think it's worth creati
On Fri, Nov 13, 2015 at 10:53 AM, Tapani Pälli wrote:
> On 11/12/2015 05:47 PM, Ilia Mirkin wrote:
>>
>> On Mon, Nov 2, 2015 at 6:36 AM, Tapani Pälli
>> wrote:
>>>
>>> Patch sets matrix_stride as 0 for non matrix uniforms that are in a
>>> atomic counter buffer. Matrix stride calculation for actu
Previously, when a performance monitor was initialized, an inner loop through
all driver queries with string comparisons for each enabled performance
monitor counter was used. This hurts when a driver exposes lots of queries.
---
src/mesa/state_tracker/st_cb_perfmon.c | 74 +++-
---
src/mesa/state_tracker/st_cb_perfmon.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_perfmon.c
b/src/mesa/state_tracker/st_cb_perfmon.c
index 80ff170..ec12eb2 100644
--- a/src/mesa/state_tracker/st_cb_perfmon.c
+++ b/src/mesa/state_tra
Hi,
the main point of this patch series is to introduce batch query objects.
For AMD_performance_monitor, hardware may not be able to start and stop
performance counters independently of each other. The current query interface
does not fit such hardware well.
With this series, drivers can mark d
---
src/gallium/auxiliary/hud/hud_context.c | 24 ++-
src/gallium/auxiliary/hud/hud_driver_query.c | 248 +++
src/gallium/auxiliary/hud/hud_private.h | 13 +-
3 files changed, 240 insertions(+), 45 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context
It is easy enough to pre-determine the required size, and arrays are
generally better behaved especially when they get large.
---
src/mesa/state_tracker/st_cb_perfmon.c | 78 --
src/mesa/state_tracker/st_cb_perfmon.h | 18
2 files changed, 55 insertions(+),
---
src/gallium/include/pipe/p_defines.h | 2 ++
src/mesa/state_tracker/st_cb_perfmon.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 7f241c8..7ed9f6d 100644
--- a/src/gallium/include/pipe/p_defines.h
++
Some drivers (in particular radeon[si], but also freedreno judging from
a quick grep) may want to expose performance counters that cannot be
individually enabled or disabled.
Allow such drivers to mark driver-specific queries as requiring a new
type of batch query object that is used to start and
---
src/mesa/state_tracker/st_cb_perfmon.c | 75 ++
src/mesa/state_tracker/st_cb_perfmon.h | 6 +++
2 files changed, 74 insertions(+), 7 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_perfmon.c
b/src/mesa/state_tracker/st_cb_perfmon.c
index 6c71a13..078d2
---
src/gallium/auxiliary/hud/hud_driver_query.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_driver_query.c
b/src/gallium/auxiliary/hud/hud_driver_query.c
index f14305e..3198ab3 100644
--- a/src/gallium/auxiliary/hud/hud_driver_query.c
+++ b/src/gallium/auxili
This was only used to implement an unnecessarily restrictive interpretation
of the spec of AMD_performance_monitor. The spec says
A performance monitor consists of a number of hardware and software
counters that can be sampled by the GPU and reported back to the
application.
I guess one cou
On Fri, Nov 13, 2015 at 04:55:33PM +0100, Neil Roberts wrote:
> Hi,
>
> You don't seem to have included any of the suggestions I made in my
> review. Was this deliberate? If not, the main points were:
>
It was not intentional, I apologize. It just got lost on top of Chad's feedback
which conflic
Ben Widawsky writes:
> Thanks a lot, I will squash it in - and sorry again about ignoring your
> feedback.
Ok, no worries. Feel free to add
Reviewed-by: Neil Roberts
if you squash the changes in.
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@l
The idea here is that driver queries implemented outside of common code
will use the same query buffer handling with different logic for starting
and stopping the corresponding counters.
---
src/gallium/drivers/radeon/r600_query.c | 198 +++-
src/gallium/drivers/radeon/
---
src/gallium/drivers/radeon/r600_query.c | 30 +-
src/gallium/drivers/radeon/r600_query.h | 10 ++
2 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 59e2a5
---
src/gallium/drivers/radeon/r600_query.c | 84 +
1 file changed, 55 insertions(+), 29 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 8aa8774..60381b2 100644
--- a/src/gallium/drivers/radeon/r600
More query-related structures will have to be moved into their own
header file to support hardware-specific performance counters.
---
src/gallium/drivers/radeon/Makefile.sources | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 15
src/gallium/drivers/radeon/r600_query.c |
The goal here is to be able to move the implementation details of hardware-
specific queries (in particular, performance counters) out of the common code.
---
src/gallium/drivers/radeon/r600_query.c | 73 +
src/gallium/drivers/radeon/r600_query.h | 16
2 fi
---
src/gallium/drivers/radeon/r600_pipe_common.c | 46 +
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/drivers/radeon/r600_query.c | 49 +++
3 files changed, 51 insertions(+), 45 deletions(-)
diff --git a/src/gallium/drive
Move r600_query and r600_query_hw into the header because we will want to
reuse the buffer handling and suspend/resume logic outside of the common
radeon code.
---
src/gallium/drivers/radeon/r600_query.c | 281 +++-
src/gallium/drivers/radeon/r600_query.h | 39 +
2
This will be important for perfcounter queries.
---
src/gallium/drivers/radeon/r600_query.c | 33 +++--
src/gallium/drivers/radeon/r600_query.h | 3 ++-
2 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gall
We will need the clear_result override for the batch query implementation.
---
src/gallium/drivers/radeon/r600_query.c | 189 +++-
src/gallium/drivers/radeon/r600_query.h | 4 +
2 files changed, 94 insertions(+), 99 deletions(-)
diff --git a/src/gallium/drivers/radeo
Hi,
in preparation for performance counters, this series makes the implementation
of queries pluggable, and separates query buffer handling from CS emit and
result collection for hardware queries.
Aside from two PIPE_QUERY_GPU_FINISHED-related fixes (using context flush,
picked up from Marek, and
Software queries are all queries that do not require suspend/resume
and explicit handling of result buffers.
Note that this fixes a fence leak with PIPE_QUERY_GPU_FINISHED, and it
contains Marek's fix to GPU_FINISHED's end_query() handling.
---
src/gallium/drivers/radeon/r600_query.c | 366 ++
On 12 November 2015 at 22:53, Ian Romanick wrote:
> I'll try to swap the RV200 for the R200 next week. I'm not sure when
> Emil is planning the next stable release... I'll try to test before
> that... unless someone beats me to it. ;)
>
Next stable should be out a week from now.
-Emil
__
On Friday 13 November 2015, Tapani Pälli wrote:
> Patch adds additional mask for tracking which vertex buffer bindings
> are set. This array can be directly compared to which vertex arrays
> are enabled and should match when drawing.
>
> Fixes following CTS tests:
>
>ES31-CTS.draw_indirect.ne
On 11/13/2015 05:57 PM, Ilia Mirkin wrote:
On Fri, Nov 13, 2015 at 10:53 AM, Tapani Pälli wrote:
On 11/12/2015 05:47 PM, Ilia Mirkin wrote:
On Mon, Nov 2, 2015 at 6:36 AM, Tapani Pälli
wrote:
Patch sets matrix_stride as 0 for non matrix uniforms that are in a
atomic counter buffer. Matrix st
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
Previously, when a performance monitor was initialized, an inner loop through
all driver queries with string comparisons for each enabled performance
monitor counter was used. This hurts when a driver exposes lots of queries.
When I wrote this cod
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
It is easy enough to pre-determine the required size, and arrays are
generally better behaved especially when they get large.
---
src/mesa/state_tracker/st_cb_perfmon.c | 78 --
src/mesa/state_tracker/st_cb_perfmon
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
---
src/mesa/state_tracker/st_cb_perfmon.c | 75 ++
src/mesa/state_tracker/st_cb_perfmon.h | 6 +++
2 files changed, 74 insertions(+), 7 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_perfmon.c
b/src/me
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
Some drivers (in particular radeon[si], but also freedreno judging from
a quick grep) may want to expose performance counters that cannot be
individually enabled or disabled.
Allow such drivers to mark driver-specific queries as requiring a new
typ
Reviewed-by: Samuel Pitoiset
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
---
src/gallium/auxiliary/hud/hud_driver_query.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_driver_query.c
b/src/gallium/auxiliary/hud/hud_driver_query.c
index f14305e..3198ab3
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
---
src/gallium/include/pipe/p_defines.h | 2 ++
src/mesa/state_tracker/st_cb_perfmon.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 7f241c8..7ed9f6d
Reviewed-by: Samuel Pitoiset
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
---
src/mesa/state_tracker/st_cb_perfmon.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_perfmon.c
b/src/mesa/state_tracker/st_cb_perfmon.c
index 80ff170..ec
Hi Nicolai,
Did you run amd_performance_monitor piglit tests to make sure all of
your changes didn't break anything?
Did you test on nvc0 driver which is the only driver that currently
exposes GL_AMD_performance_monitor? In case you didn't, I'll test it
myself in the next few days. You might
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
This was only used to implement an unnecessarily restrictive interpretation
of the spec of AMD_performance_monitor. The spec says
A performance monitor consists of a number of hardware and software
counters that can be sampled by the GPU and
Some comments below.
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
---
src/gallium/auxiliary/hud/hud_context.c | 24 ++-
src/gallium/auxiliary/hud/hud_driver_query.c | 248 +++
src/gallium/auxiliary/hud/hud_private.h | 13 +-
3 files changed, 240 insertio
On Fri, Nov 13, 2015 at 7:44 AM, Juan A. Suarez Romero
wrote:
> On Fri, 2015-11-13 at 07:37 -0800, Jason Ekstrand wrote:
>> I didn't want to pull a non-inline mesa function into NIR and add a
>> link dependency and I was too lazy to move it into util.
>
>
> But at this moment _mesa_fls() is an inl
On 13.11.2015 00:14, Glenn Kennard wrote:
Signed-off-by: Glenn Kennard
---
Maybe there is a better way to check if a thread is a helper invocation?
Is ctx->face_gpr guaranteed to be initialized when
load_helper_invocation is called?
Aside, I'm not sure I understand correctly what this is su
On 11/13/2015 02:46 PM, Hans de Goede wrote:
Hi All,
Hey Hans,
So as discussed I've started working on a TGSI backend for
llvm to use as a way to get compute going on nouveau (and other gpu-s).
I'm still learning all the ins and outs of llvm so I do not have
much to show yet.
I've rebase
On Fri, Nov 13, 2015 at 12:48 AM, Iago Toral Quiroga wrote:
> If a source operand in a MOV has source modifiers, then we cannot
> copy-propagate it from the parent instruction and remove the MOV.
>
> v2: remove the check for source modifiers from is_move() (Jason)
>
> v3: Put the check for source
On Thu, Nov 12, 2015 at 04:54:08PM +0100, Neil Roberts wrote:
> It looks like the sampler hardware doesn't take into account the
> surface format when sampling a cleared color after a fast clear has
> been done. So for example if you clear a GL_RED surface to 1,1,1,1
> then the sampling instruction
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 4877504..61c63d4 100644
--- a/src/mesa/drivers/dri/i965/
On Fri, Nov 13, 2015 at 1:12 PM, Ben Widawsky wrote:
> On Thu, Nov 12, 2015 at 04:54:08PM +0100, Neil Roberts wrote:
>> + default:
>> + for (int i = 0; i < 3; i++) {
>> + if (!_mesa_format_has_color_component(format, i))
>> +override_color.ui[i] = 0;
>> + }
>
> Is t
Requires proper kernel tiling configurarion so check the tiling
config registers.
Signed-off-by: Alex Deucher
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_state.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/rad
On 13.11.2015 18:34, Samuel Pitoiset wrote:
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
---
src/gallium/include/pipe/p_defines.h | 2 ++
src/mesa/state_tracker/st_cb_perfmon.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/inc
On 13.11.2015 18:35, Samuel Pitoiset wrote:
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
This was only used to implement an unnecessarily restrictive
interpretation
of the spec of AMD_performance_monitor. The spec says
A performance monitor consists of a number of hardware and software
c
It is easy enough to pre-determine the required size, and arrays are
generally better behaved especially when they get large.
v2: make sure init_perf_monitor returns true when no counters are active
(spotted by Samuel Pitoiset)
---
Thanks Samuel, good catch! I did test with piglit and the tests pa
On Fri, Nov 13, 2015 at 1:23 PM, Nicolai Hähnle wrote:
> So really, this is a question for everybody who cares about nouveau, because
> nouveau is the only driver that (if a #define is enabled) advertises a CPU
> driver_query_group.
>
> Do you want that group to be accessible via AMD_performance_m
Hi Samuel,
thanks for taking a look!
On 13.11.2015 18:35, Samuel Pitoiset wrote:
Did you run amd_performance_monitor piglit tests to make sure all of
your changes didn't break anything?
Yes, everything passes here.
Did you test on nvc0 driver which is the only driver that currently
exposes
On 13.11.2015 19:27, Ilia Mirkin wrote:
On Fri, Nov 13, 2015 at 1:23 PM, Nicolai Hähnle wrote:
So really, this is a question for everybody who cares about nouveau, because
nouveau is the only driver that (if a #define is enabled) advertises a CPU
driver_query_group.
Do you want that group to b
https://bugs.freedesktop.org/show_bug.cgi?id=92706
--- Comment #5 from EoD ---
Is there any reason this is not getting merged? Is there any way to help
getting it merged?
It would be great to fix the aforementioned bugs before an 11.1 release.
--
You are receiving this mail because:
You are th
On Mon, Nov 9, 2015 at 4:56 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/common/meta.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
>
On Mon, Nov 9, 2015 at 4:56 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/common/meta.c | 23 ++-
> src/mesa/drivers/common/meta.h | 2 +-
> 2 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/d
On Mon, Nov 9, 2015 at 4:56 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
>
> In OpenGL ES (all versions!) and OpenGL compatibility profile,
> applications don't have to call Gen functions. The GL spec is very
> clear ab
On Mon, Nov 9, 2015 at 4:56 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/common/meta.c | 32
> 1 file changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/d
On Mon, Nov 9, 2015 at 4:56 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
>
> In OpenGL ES (all versions!) and OpenGL compatibility profile,
> applications don't have to call Gen functions. The GL spec is very
> clear ab
On Mon, Nov 9, 2015 at 4:56 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> This setting is only used by glTexCoordPointer and related glEnable
> calls. Since the preceeding commits removed all of those, it is not
> necessary to save, reset to default, or restore this state.
>
> Signed-off-by:
On Mon, Nov 9, 2015 at 4:56 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Nothing left in meta does anything with the VBO binding, so we don't
> need to save or restore it. The VAO binding is still modified.
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/common/meta.c | 6 --
>
On 11/13/2015 07:22 PM, Nicolai Hähnle wrote:
On 13.11.2015 18:34, Samuel Pitoiset wrote:
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
---
src/gallium/include/pipe/p_defines.h | 2 ++
src/mesa/state_tracker/st_cb_perfmon.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/src/g
1 - 100 of 152 matches
Mail list logo
