On Wed, 2015-09-02 at 17:53 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Wed, 2015-09-02 at 14:29 +0300, Francisco Jerez wrote:
> >> Iago Toral writes:
> >>
> >> > Hi Curro,
> >> >
> >> > I have been a couple of weeks on holidays and have just come back to
> >> > this:
> >> >
> >
commit 472ef9a02f2e5c5d0caa2809cb736a0f4f0d4693 introduced code to
change the types of SEL and MOV instructions for moves that simply
"copy bits around". It didn't account for type conversion moves,
however. So it would happily turn this:
mov(8) vgrf6:D, -vgrf5:D
mov(8) vgrf7:F, vgrf6:UD
On Wednesday, September 02, 2015 02:38:38 PM Matt Turner wrote:
> On Wed, Sep 2, 2015 at 1:43 PM, Kenneth Graunke wrote:
> > On Wednesday, September 02, 2015 02:26:55 AM Marek Olšák wrote:
> >> From: Marek Olšák
> >>
> >> People are having issues with apps because drirc wasn't installed
> >> into
From: Rob Clark
Like xa_surface_from_handle(), but takes a handle type, rather than
hard-coding 'shared' handle. This is needed to fix bugs seen with
xf86-video-freedreno with xrandr rotation, for example. The root issue
is that doing a GEM_OPEN ioctl on a bo that already has a GEM handle
assoc
https://bugs.freedesktop.org/show_bug.cgi?id=34495
--- Comment #78 from Kenneth Graunke ---
FWIW, it would be great if that could be made the default in blender - nobody's
found time to implement proper GL_SELECT or GL_FEEDBACK support in the last 4
years, and I don't see anybody getting around t
Tested-by: Mark Janes
Kenneth Graunke writes:
> In various versions of OpenGL and GLSL, it's possible to declare
> multiple VS input variables with aliasing attribute locations.
>
> So, when computing the storage requirements for vertex attributes,
> we can't simply add up the sizes. Instead,
As suggested by Marek Olšák, we can use single atom to track all scissor
states. This will allow to simplify dirty atom handling later.
---
v2: rebased, moved dirty_mask set out of the loop
src/gallium/drivers/r600/evergreen_state.c | 36 ++
src/gallium/drivers/r600/r600_bli
Now that R600_NUM_ATOMS is below 64, dirty atom tracking can be
simplified.
---
src/gallium/drivers/r600/r600_hw_context.c | 9 +++---
src/gallium/drivers/r600/r600_pipe.h | 45
src/gallium/drivers/r600/r600_state_common.c | 9 +++---
3 files changed, 14 in
Similarly to scissor states, we can use single atom to track all viewport
states. This will allow to simplify dirty atom handling later.
---
v2: rebased, moved dirty_mask set out of the loop
src/gallium/drivers/r600/evergreen_state.c | 7 ++---
src/gallium/drivers/r600/r600_blit.c | 2
It's no longer used by both r600 and radeonsi now.
---
src/gallium/drivers/r600/r600_pipe.h | 2 --
src/gallium/drivers/r600/r600_state_common.c | 1 -
src/gallium/drivers/radeon/r600_pipe_common.h | 3 +--
src/gallium/drivers/radeonsi/si_state.c | 1 -
4 files changed, 1 insertion
There doesn't seem any reason to start from 4.
Start from 1 instead (0 is left reserved to catch uninitialized atoms).
---
src/gallium/drivers/r600/evergreen_state.c | 2 +-
src/gallium/drivers/r600/r600_pipe.h | 2 +-
src/gallium/drivers/r600/r600_state.c | 2 +-
3 files changed, 3 ins
During review of the "r600g: make all scissor states use single atom" patch
Marek Olšák noticed that scissor disable workaround should be applied on
all scissor states and not just first one, so let's do so.
---
src/gallium/drivers/r600/r600_state.c| 22 +-
src/gallium/
On Wed, Sep 2, 2015 at 10:43 PM, Kenneth Graunke wrote:
> On Wednesday, September 02, 2015 02:26:55 AM Marek Olšák wrote:
>> From: Marek Olšák
>>
>> People are having issues with apps because drirc wasn't installed
>> into /etc. I've lost patience.
>> ---
>> src/mesa/drivers/dri/common/Makefile.
On Wed, Sep 2, 2015 at 10:56 PM, Kenneth Graunke wrote:
> On Wednesday, September 02, 2015 02:26:56 AM Marek Olšák wrote:
>> From: Marek Olšák
>>
>> A user can be using Mesa 11.0, but /etc/drirc can be from Mesa 10.5.
>> We don't want the old drirc to affect Mesa 11.0.
>>
>> There are 2 options:
On Wed, Sep 2, 2015 at 1:43 PM, Kenneth Graunke wrote:
> On Wednesday, September 02, 2015 02:26:55 AM Marek Olšák wrote:
>> From: Marek Olšák
>>
>> People are having issues with apps because drirc wasn't installed
>> into /etc. I've lost patience.
>> ---
>> src/mesa/drivers/dri/common/Makefile.a
https://bugs.freedesktop.org/show_bug.cgi?id=91747
Benjamin Bellec changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
See Also|
On Wednesday, September 02, 2015 04:47:13 PM Ilia Mirkin wrote:
> On Wed, Sep 2, 2015 at 4:43 PM, Kenneth Graunke wrote:
> > On Wednesday, September 02, 2015 02:26:55 AM Marek Olšák wrote:
> >> From: Marek Olšák
> >>
> >> People are having issues with apps because drirc wasn't installed
> >> into
On Wednesday, September 02, 2015 02:26:56 AM Marek Olšák wrote:
> From: Marek Olšák
>
> A user can be using Mesa 11.0, but /etc/drirc can be from Mesa 10.5.
> We don't want the old drirc to affect Mesa 11.0.
>
> There are 2 options:
> - use a different file name (e.g. /etc/drirc_global) for peop
On Wed, Sep 2, 2015 at 4:43 PM, Kenneth Graunke wrote:
> On Wednesday, September 02, 2015 02:26:55 AM Marek Olšák wrote:
>> From: Marek Olšák
>>
>> People are having issues with apps because drirc wasn't installed
>> into /etc. I've lost patience.
>> ---
>> src/mesa/drivers/dri/common/Makefile.a
On Wednesday, September 02, 2015 02:26:55 AM Marek Olšák wrote:
> From: Marek Olšák
>
> People are having issues with apps because drirc wasn't installed
> into /etc. I've lost patience.
> ---
> src/mesa/drivers/dri/common/Makefile.am | 4 +-
> src/mesa/drivers/dri/common/Makefile.sources
Some drivers do not support certain targets - for example nouveau
doesn't do VAAPI, while freedreno doesn't do of the video backends.
As such if we enter vdpau when building freedreno/ilo/etc, a vdpau/
folder will be created, empty library will be build and almost
immediately removed. Thus keeping
https://bugs.freedesktop.org/show_bug.cgi?id=91747
--- Comment #5 from Sinclair Yeh ---
Ooops, wrong window.
Meant to say that I created a new Unity bug here:
https://bugs.launchpad.net/unity/+bug/1491555
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the a
This is a very rudimentary script that checks if any of the applied
cherry-picks have been referenced (fixed?) by another patch(es) in
master. With the latter missing the stable tag.
This can be improved upon greatly, and/or extended to handle "Fixed"
tags. At this point I'd wanted to send it upst
https://bugs.freedesktop.org/show_bug.cgi?id=91747
--- Comment #4 from Sinclair Yeh ---
Done. Created "old_gpg_id.txt" to show the previous ID, and also added new
public key in my home directory.
thanks!
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the a
On Tue, Sep 1, 2015 at 3:04 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> This must be done before exporting a buffer as dmabuf fds, because
> we lose track of who is using it and can't trust the reference counter.
>
> Cc: 11.0
For the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/a
On 08/26/2015 10:36 AM, Ilia Mirkin wrote:
> *every* other callback takes a ctx... this feels really asymmetric.
> I'd kinda rather just keep the ctx's in and add (void) uses on them.
> Don't feel too strongly about it though.
What if I told you that I have patches to remove unused ctx parameters
On Thu, Aug 27, 2015 at 10:05:14AM -0700, Ben Widawsky wrote:
> On Thu, Aug 27, 2015 at 10:51:59AM +0300, Pohjolainen, Topi wrote:
> > On Wed, Aug 26, 2015 at 03:46:05PM -0700, Ben Widawsky wrote:
> > > This reverts commit 1bba29ed403e735ba0bf04ed8aa2e571884fcaaf
> > > Author: Topi Pohjolainen
> >
On Wed, Sep 2, 2015 at 12:03 AM, Matt Turner wrote:
> The lowered code reads from the destination, which isn't possible from
> message registers.
>
> Fixes the dEQP functional.shaders.precision.int.highp_mul_fragment test
> on SNB.
> ---
Thanks everyone for the reviews and tests. I've updated the
On Wed, Sep 2, 2015 at 2:40 PM, Kenneth Graunke wrote:
> On Wednesday, September 02, 2015 02:35:22 PM Ilia Mirkin wrote:
>> On Wed, Sep 2, 2015 at 2:20 PM, Kenneth Graunke
>> wrote:
>> > In various versions of OpenGL and GLSL, it's possible to declare
>> > multiple VS input variables with aliasi
On Wednesday, September 02, 2015 02:35:22 PM Ilia Mirkin wrote:
> On Wed, Sep 2, 2015 at 2:20 PM, Kenneth Graunke wrote:
> > In various versions of OpenGL and GLSL, it's possible to declare
> > multiple VS input variables with aliasing attribute locations.
> >
> > So, when computing the storage re
On Wed, Sep 2, 2015 at 2:20 PM, Kenneth Graunke wrote:
> In various versions of OpenGL and GLSL, it's possible to declare
> multiple VS input variables with aliasing attribute locations.
>
> So, when computing the storage requirements for vertex attributes,
> we can't simply add up the sizes. Ins
Mark Janes writes:
> I verified that this fixed the following tests on snb:
>
> dEQP-GLES3.functional.shaders.precision.int.highp_mul_fragment
> dEQP-GLES3.functional.shaders.precision.int.mediump_mul_fragment
> dEQP-GLES3.functional.shaders.precision.int.lowp_mul_fragment
>
> However
On Wed, Sep 2, 2015 at 5:57 PM, Ian Romanick wrote:
> For some reason the original patches and Ilia's response never showed up
> in my inbox.
>
> So... how does one have a Mesa driver that doesn't enable any work
> arounds? While this may work around the problem, it doesn't feel like
> the right
In various versions of OpenGL and GLSL, it's possible to declare
multiple VS input variables with aliasing attribute locations.
So, when computing the storage requirements for vertex attributes,
we can't simply add up the sizes. Instead, we need to look at the
enabled slots.
This patch begins tr
On Tuesday, September 01, 2015 07:03:58 PM Ilia Mirkin wrote:
> On Tue, Sep 1, 2015 at 6:53 PM, Matt Turner wrote:
> > On Tue, Sep 1, 2015 at 3:57 PM, Matt Turner wrote:
> >> ---
> >> I checked the uses of count_attribute_slots() and it looks like they're
> >> expecting this already, but these tw
On Tue, Sep 01, 2015 at 11:18:15PM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
Reviewed-by: Tom Stellard
> Just a cleanup I had made a long time ago and forgot about.
> ---
> src/gallium/drivers/radeonsi/si_shader.c | 468
> +--
> 1 file changed, 191 insertions
On Sep 2, 2015 10:43 AM, "Mark Janes" wrote:
>
> Kenneth Graunke writes:
>
> > On Wednesday, September 02, 2015 12:03:12 AM Matt Turner wrote:
> >> The lowered code reads from the destination, which isn't possible from
> >> message registers.
> >>
> >> Fixes the dEQP functional.shaders.precision.
I verified that this fixed the following tests on snb:
dEQP-GLES3.functional.shaders.precision.int.highp_mul_fragment
dEQP-GLES3.functional.shaders.precision.int.mediump_mul_fragment
dEQP-GLES3.functional.shaders.precision.int.lowp_mul_fragment
However, my testing showed the following
Kenneth Graunke writes:
> On Wednesday, September 02, 2015 12:03:12 AM Matt Turner wrote:
>> The lowered code reads from the destination, which isn't possible from
>> message registers.
>>
>> Fixes the dEQP functional.shaders.precision.int.highp_mul_fragment test
>> on SNB.
>> ---
>> src/mesa/d
On 2 September 2015 at 16:57, Ian Romanick wrote:
> For some reason the original patches and Ilia's response never showed up
> in my inbox.
>
> So... how does one have a Mesa driver that doesn't enable any work
> arounds?
Very good point, although I believe this limitation already exists
with /etc
On Sep 2, 2015 7:27 AM, "Ilia Mirkin" wrote:
>
> On Wed, Sep 2, 2015 at 6:29 AM, Neil Roberts wrote:
> > It's legal to call glTexSubImage with zero values for the width,
> > height or depth. Previously this was breaking the PBO access
> > validation because it tries to work out the last pixel acc
On Sep 1, 2015 11:58 PM, "Matt Turner" wrote:
>
> The lowered code reads from the destination, which isn't possible from
> message registers.
>
> Fixes the dEQP functional.shaders.precision.int.highp_mul_fragment test
> on SNB.
Reviewed-by: Jason Ekstrand
You should probably cc stable before yo
On Wednesday, September 02, 2015 12:03:12 AM Matt Turner wrote:
> The lowered code reads from the destination, which isn't possible from
> message registers.
>
> Fixes the dEQP functional.shaders.precision.int.highp_mul_fragment test
> on SNB.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 8
For some reason the original patches and Ilia's response never showed up
in my inbox.
So... how does one have a Mesa driver that doesn't enable any work
arounds? While this may work around the problem, it doesn't feel like
the right solution.
On 09/02/2015 06:55 AM, Iago Toral wrote:
> Both patc
Iago Toral writes:
> On Wed, 2015-09-02 at 14:29 +0300, Francisco Jerez wrote:
>> Iago Toral writes:
>>
>> > Hi Curro,
>> >
>> > I have been a couple of weeks on holidays and have just come back to
>> > this:
>> >
>> > On Thu, 2015-08-06 at 18:27 +0300, Francisco Jerez wrote:
>> >> Iago Toral Q
On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede wrote:
> Hi Ilia
>
> On 31-08-15 18:30, Ilia Mirkin wrote:
>>
>> On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede
>> wrote:
>
>
>
>
>
>>> Interestingly enough nv30_screen_get_param returns 0 for
>>> PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER
On Wed, 2015-09-02 at 14:29 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > Hi Curro,
> >
> > I have been a couple of weeks on holidays and have just come back to
> > this:
> >
> > On Thu, 2015-08-06 at 18:27 +0300, Francisco Jerez wrote:
> >> Iago Toral Quiroga writes:
> >>
> >> > If
On Wed, Sep 2, 2015 at 6:29 AM, Neil Roberts wrote:
> It's legal to call glTexSubImage with zero values for the width,
> height or depth. Previously this was breaking the PBO access
> validation because it tries to work out the last pixel accessed by
> getting the pixel at height-1 and depth-1 whi
From: Marek Olšák
This is probably the most called util function. It does almost nothing,
yet it can consume 10% of the CPU on the profile. This drops it down to 5%.
---
src/gallium/auxiliary/util/u_upload_mgr.c | 36 +++
1 file changed, 18 insertions(+), 18 deletions
From: Marek Olšák
The return buffer or the returned pointer can be used instead.
---
src/gallium/auxiliary/util/u_upload_mgr.c | 28 ++--
src/gallium/auxiliary/util/u_upload_mgr.h | 12 ++--
src/gallium/auxiliary/util/u_vbuf.c | 27 +-
On 09/02/2015 07:44 AM, Marek Olšák wrote:
From: Marek Olšák
This is probably the most called util function. It does almost nothing,
yet it can consume 10% of the CPU on the profile. This drops it down to 5%.
---
src/gallium/auxiliary/util/u_upload_mgr.c | 36 +++
On 09/02/2015 07:44 AM, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/auxiliary/util/u_upload_mgr.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c
b/src/gallium/auxiliary/util/u_upload_mgr.c
index 6c
On 09/02/2015 07:44 AM, Marek Olšák wrote:
From: Marek Olšák
The return buffer or the returned pointer can be used instead.
---
src/gallium/auxiliary/util/u_upload_mgr.c | 28 ++--
src/gallium/auxiliary/util/u_upload_mgr.h | 12 ++--
src/gallium/auxiliary/uti
Both patches do what they advertise and seem to work, so they are
Reviewed-by: Iago Toral Quiroga
That said, I imagine that probably you want to get at least a few ACKs
from other devs, like Illia did, to make sure that your changes have
enough support.
Iago
On Wed, 2015-09-02 at 02:26 +0200,
From: Marek Olšák
---
src/gallium/auxiliary/util/u_upload_mgr.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c
b/src/gallium/auxiliary/util/u_upload_mgr.c
index 6c8930f..f93de78 100644
--- a/src/gallium/auxilia
From: Marek Olšák
---
src/gallium/auxiliary/util/u_upload_mgr.c | 19 ---
src/gallium/auxiliary/util/u_upload_mgr.h | 12 ++--
src/gallium/auxiliary/util/u_vbuf.c | 9 -
src/mesa/state_tracker/st_draw.c | 7 ---
4 files changed, 22 insertions(
From: Marek Olšák
---
src/gallium/auxiliary/util/u_upload_mgr.c | 35 ++-
src/gallium/auxiliary/util/u_upload_mgr.h | 14 ++---
2 files changed, 18 insertions(+), 31 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c
b/src/gallium/auxiliary/
On Wed, Aug 26, 2015 at 10:52:58AM -0700, Ben Widawsky wrote:
> Docs suggest this is no longer required starting with Gen8.
>
> Perf (no regressions in n=20)
> OglMultithread 0.67%
> OglTerrainPanInst0.12%
> trex 0.45%
> warsow 0.64%
>
> I have a couple of
Iago Toral writes:
> On Thu, 2015-07-30 at 16:13 +0300, Francisco Jerez wrote:
>> Iago Toral writes:
>>
>> > On Thu, 2015-07-30 at 15:58 +0300, Francisco Jerez wrote:
>> >> Iago Toral Quiroga writes:
>> >>
>> >> > ---
>> >> > src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 2 +-
>> >> >
Iago Toral writes:
> Hi Curro,
>
> I have been a couple of weeks on holidays and have just come back to
> this:
>
> On Thu, 2015-08-06 at 18:27 +0300, Francisco Jerez wrote:
>> Iago Toral Quiroga writes:
>>
>> > If we have spilled/unspilled a register in the current instruction, avoid
>> > emit
On Tue, 2015-09-01 at 18:56 -0700, Ian Romanick wrote:
(...)
> diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
> index dd7804f..bd25f45 100644
> --- a/src/glsl/builtin_variables.cpp
> +++ b/src/glsl/builtin_variables.cpp
> @@ -383,8 +383,7 @@ private:
> ir_variable
On Thu, 2015-07-30 at 16:13 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Thu, 2015-07-30 at 15:58 +0300, Francisco Jerez wrote:
> >> Iago Toral Quiroga writes:
> >>
> >> > ---
> >> > src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 2 +-
> >> > src/mesa/drivers/dri/i965/brw_v
Hi Curro,
I have been a couple of weeks on holidays and have just come back to
this:
On Thu, 2015-08-06 at 18:27 +0300, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > If we have spilled/unspilled a register in the current instruction, avoid
> > emitting unspills for the same register
It's legal to call glTexSubImage with zero values for the width,
height or depth. Previously this was breaking the PBO access
validation because it tries to work out the last pixel accessed by
getting the pixel at height-1 and depth-1 which would end up with
bogus values.
This was causing GL error
Ilia Mirkin writes:
>> - end = _mesa_image_offset(dimensions, pack, width, height,
>> - format, type, depth-1, height-1, width);
>> + if (depth == 0 || height == 0)
>
> Why not width == 0 as well? You could probably just do
>
> return GL_TRUE;
>
> in that case a
Ian Romanick writes:
> It seems like it should be handled in the core, and it looks like
> _mesa_tex_sub_image is already doing that. Note the "if (width > 0 &&
> height > 0 && depth > 0)" check. What is the callstack that gets here
> with height or depth as zero? That seems fishy.
This funct
Hi Ilia
On 31-08-15 18:30, Ilia Mirkin wrote:
On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede wrote:
Interestingly enough nv30_screen_get_param returns 0 for
PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET
And this hack:
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen
https://bugs.freedesktop.org/show_bug.cgi?id=91840
--- Comment #3 from Boyan Ding ---
(In reply to Timothy Arceri from comment #2)
> There are patches on the list not sure if they still apply:
> http://lists.freedesktop.org/archives/mesa-dev/2014-August/066941.html
At least the first patch for E
https://bugs.freedesktop.org/show_bug.cgi?id=34495
--- Comment #77 from Fabio Pedretti ---
There is a workaround here:
https://bugs.launchpad.net/ubuntu/+source/blender/+bug/902618/comments/6
--
You are receiving this mail because:
You are the assignee for the bug.
_
69 matches
Mail list logo
