On Fri, Feb 26, 2016 at 9:35 AM, Oded Gabbay wrote:
> On Fri, Feb 26, 2016 at 9:32 AM, Michel Dänzer wrote:
>> On 26.02.2016 16:14, Oded Gabbay wrote:
>>> On Fri, Feb 26, 2016 at 5:01 AM, Michel Dänzer wrote:
[ Dropping mesa-stable list from Cc, since sending patches there by
e-ma
Series is:
Reviewed-by: Iago Toral Quiroga
On Thu, 2016-02-25 at 11:01 -0800, Kenneth Graunke wrote:
> From: Jason Ekstrand
>
> The Vulkan driver wants to be able to delete fragment outputs that are
> beyond key.nr_color_regions; this is a lot easier if we lower outputs at
> specialization tim
Ok, I can tell you that 3DSTATE_DEPTH_BUFFER and
3DSTATE_STENCIL_BUFFER seem perfectly correct (assuming the gem
address-patching-in works for the depth buffer address). I'll see if
I can find a past version that works.
OG.
On Wed, Feb 17, 2016 at 4:31 PM, Jason Ekstrand wrote:
> On Tue, Feb
On Thu, 2016-02-25 at 18:20 -0500, Ilia Mirkin wrote:
> On Thu, Feb 25, 2016 at 6:16 PM, Francisco Jerez
> wrote:
> > Ian Romanick writes:
> >
> >> On 02/25/2016 12:13 PM, Francisco Jerez wrote:
> >>> Ian Romanick writes:
> >>>
> On 02/25/2016 08:46 AM, Roland Scheidegger wrote:
> > A
On Fri, Feb 26, 2016 at 4:27 AM, Michel Dänzer wrote:
>
> What's the purpose of this change? Unless I'm missing something, only
> stderr is ever passed in.
The second patch uses it.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https:/
On Thu, Feb 25, 2016 at 10:09 PM, Oded Gabbay wrote:
> After further testing, it appears there is no need for
> separate BE path in r600_translate_colorswap()
>
> The only fix remaining is the change of the last if statement, in the 4
> channels case. Originally, it contained an invalid swizzle co
https://bugs.freedesktop.org/show_bug.cgi?id=94295
--- Comment #1 from Plamena Manolova ---
Created attachment 121982
--> https://bugs.freedesktop.org/attachment.cgi?id=121982&action=edit
Proposed Patch
--
You are receiving this mail because:
You are the QA Contact for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=94295
--- Comment #2 from Plamena Manolova ---
(In reply to Vinson Lee from comment #0)
> mesa: d1509a5848dee57b933139ad2610e99ae09cb5ec (master 11.3.0-devel)
>
> $ ./bin/shader_runner tests/fast_color_clear/all-colors.shader_test -auto
> Segmentation
On Fri, Feb 26, 2016 at 12:51 PM, Marek Olšák wrote:
> On Thu, Feb 25, 2016 at 10:09 PM, Oded Gabbay wrote:
>> After further testing, it appears there is no need for
>> separate BE path in r600_translate_colorswap()
>>
>> The only fix remaining is the change of the last if statement, in the 4
>>
On Fri, Feb 26, 2016 at 5:03 AM, Michel Dänzer wrote:
> On 26.02.2016 06:09, Oded Gabbay wrote:
>> After further testing, it appears there is no need for
>> separate BE path in r600_translate_colorswap()
>>
>> The only fix remaining is the change of the last if statement, in the 4
>> channels case
On Fri, Feb 26, 2016 at 12:38 PM, Oded Gabbay wrote:
> On Fri, Feb 26, 2016 at 12:51 PM, Marek Olšák wrote:
>> On Thu, Feb 25, 2016 at 10:09 PM, Oded Gabbay wrote:
>>> After further testing, it appears there is no need for
>>> separate BE path in r600_translate_colorswap()
>>>
>>> The only fix r
Reviewed-by: Marek Olšák
Marek
On Thu, Feb 25, 2016 at 10:09 PM, Oded Gabbay wrote:
> This function is currently broken for BE. I assume it's because of
> util_pack_color(). Until I fix this path, I prefer to disable it so users
> would be able to see correct colors on their desktop and applica
On Fri, Feb 19, 2016 at 07:10:24PM -0500, Ilia Mirkin wrote:
> The two extensions are identical, and are largely taking bits of already
> existing desktop functionality. We continue to do a poor job of
> supporting the 'precise' keyword, just like we do on desktop.
>
> This passes the relevant dEQ
Reviewed-by: Samuel Iglesias Gonsálvez
On Sat, Feb 20, 2016 at 04:00:49PM -0500, Ilia Mirkin wrote:
> Could be exposed on earlier GLES versions if we supported EXT_sRGB, but
> we don't, for now.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> Passes all the relevant dEQP tests (although they only tes
On Fri, Feb 26, 2016 at 01:01:28PM +0100, Samuel Iglesias Gonsálvez wrote:
> Reviewed-by: Samuel Iglesias Gonsálvez
>
I forgot one comment... See below.
> On Sat, Feb 20, 2016 at 04:00:49PM -0500, Ilia Mirkin wrote:
> > Could be exposed on earlier GLES versions if we supported EXT_sRGB, but
> >
https://bugs.freedesktop.org/show_bug.cgi?id=91556
--- Comment #7 from Serge Martin ---
This simple change should fix the size calculation.
However the kernel still receive garbage, but we are working on it since
GROMACS have the same problem.
Also the serie found at
https://lists.freedesktop.or
On 26 February 2016 at 07:35, Oded Gabbay wrote:
> On Fri, Feb 26, 2016 at 9:32 AM, Michel Dänzer wrote:
>> On 26.02.2016 16:14, Oded Gabbay wrote:
>>> On Fri, Feb 26, 2016 at 5:01 AM, Michel Dänzer wrote:
[ Dropping mesa-stable list from Cc, since sending patches there by
e-mail
On 26 February 2016 at 07:09, Chih-Wei Huang wrote:
> The git_sha1.h has to depend on the git HEAD
> otherwise it will never be updated.
>
> Signed-off-by: Chih-Wei Huang
> ---
> src/mesa/Android.gen.mk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/Android.gen
On Fri, Feb 26, 2016 at 7:27 AM, Samuel Iglesias Gonsálvez
wrote:
> On Fri, Feb 26, 2016 at 01:01:28PM +0100, Samuel Iglesias Gonsálvez wrote:
>> Reviewed-by: Samuel Iglesias Gonsálvez
>>
>
> I forgot one comment... See below.
>
>> On Sat, Feb 20, 2016 at 04:00:49PM -0500, Ilia Mirkin wrote:
>> >
On Fri, Feb 26, 2016 at 6:55 AM, Samuel Iglesias Gonsálvez
wrote:
> On Fri, Feb 19, 2016 at 07:10:24PM -0500, Ilia Mirkin wrote:
>> The two extensions are identical, and are largely taking bits of already
>> existing desktop functionality. We continue to do a poor job of
>> supporting the 'precise
As I reference, this week I sent a RFC series for this feature:
https://lists.freedesktop.org/archives/mesa-dev/2016-February/108442.html
This new series uses the feedback provided by Timothy Arceri (thanks!), in
order to handle the doubts I had to consider the original series as an RFC,
and handl
v2:
* Take into account out varyings too (Timothy Arceri)
* Fix style (Timothy Arceri)
* Use a new ast_expression variable, instead of an
ast_expression::hir new parameter (Timothy Arceri)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94129
---
src/compiler/glsl/ast_to_hir.cpp | 7
https://bugs.freedesktop.org/show_bug.cgi?id=94291
--- Comment #1 from Roland Scheidegger ---
Could you show the instruction where it crashed (and the disassembly)?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._
Useful to know if a expression is the recipient of an assignment
or not, that would be used to (for example) raise warnings of
"use of uninitialized variable" without getting a false positive
when assigning first a variable.
By default the value is false, and it is assigned to true on
the followin
Am 26.02.2016 um 11:25 schrieb Iago Toral:
>
> On Thu, 2016-02-25 at 18:20 -0500, Ilia Mirkin wrote:
>> On Thu, Feb 25, 2016 at 6:16 PM, Francisco Jerez
>> wrote:
>>> Ian Romanick writes:
>>>
On 02/25/2016 12:13 PM, Francisco Jerez wrote:
> Ian Romanick writes:
>
>> On 02/25/2
On Fri, 2016-02-26 at 16:28 +0100, Roland Scheidegger wrote:
> Am 26.02.2016 um 11:25 schrieb Iago Toral:
> >
> > On Thu, 2016-02-25 at 18:20 -0500, Ilia Mirkin wrote:
> >> On Thu, Feb 25, 2016 at 6:16 PM, Francisco Jerez
> >> wrote:
> >>> Ian Romanick writes:
> >>>
> On 02/25/2016 12:13 P
On 2016-02-26 15:32, Ilia Mirkin wrote:
On Fri, Feb 26, 2016 at 6:55 AM, Samuel Iglesias Gonsálvez
wrote:
On Fri, Feb 19, 2016 at 07:10:24PM -0500, Ilia Mirkin wrote:
The two extensions are identical, and are largely taking bits of
already
existing desktop functionality. We continue to do a p
On 2016-02-26 15:30, Ilia Mirkin wrote:
On Fri, Feb 26, 2016 at 7:27 AM, Samuel Iglesias Gonsálvez
wrote:
On Fri, Feb 26, 2016 at 01:01:28PM +0100, Samuel Iglesias Gonsálvez
wrote:
Reviewed-by: Samuel Iglesias Gonsálvez
I forgot one comment... See below.
On Sat, Feb 20, 2016 at 04:00:49P
After further testing, it appears there is no need for
separate BE path in r600_translate_colorswap()
The only fix remaining is the change of the last if statement, in the 4
channels case. Originally, it contained an invalid swizzle configuration
that never got hit, in LE or BE. So the fix is rele
This function is currently broken for BE. I assume it's because of
util_pack_color(). Until I fix this path, I prefer to disable it so users
would be able to see correct colors on their desktop and applications.
Together with the two following patches:
- gallium/r600: Don't let h/w do endian swap
Since the rework on gallium pipe formats, there is no more need to do
endian swap of the colorformat in the h/w, because the conversion between
mesa format and gallium (pipe) format takes endianess into account (see
the big #if in p_format.h).
v2: return ENDIAN_NONE only for four 8-bits components
On Fri, Feb 26, 2016 at 10:39 AM, Iago Toral wrote:
> On Fri, 2016-02-26 at 16:28 +0100, Roland Scheidegger wrote:
>> Am 26.02.2016 um 11:25 schrieb Iago Toral:
>> >
>> > On Thu, 2016-02-25 at 18:20 -0500, Ilia Mirkin wrote:
>> >> On Thu, Feb 25, 2016 at 6:16 PM, Francisco Jerez
>> >> wrote:
>>
On Thu, Feb 25, 2016 at 5:56 PM, Francisco Jerez wrote:
> Ian Romanick writes:
>
>> From: Ian Romanick
>>
>> On BDW,
>>
>> total instructions in shared programs: 8448571 -> 8448367 (-0.00%)
>> instructions in affected programs: 21000 -> 20796 (-0.97%)
>> helped: 116
>> HURT: 0
>>
>> Signed-off-b
On Thu, Feb 25, 2016 at 2:40 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> On BDW,
>
> total instructions in shared programs: 8448571 -> 8448367 (-0.00%)
> instructions in affected programs: 21000 -> 20796 (-0.97%)
> helped: 116
> HURT: 0
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/driv
https://bugs.freedesktop.org/show_bug.cgi?id=91556
--- Comment #8 from Pavan Yalamanchili ---
@serge won't this break the original intent of the padding size ? For example
float3 would be broken in this case.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are th
On 02/26/2016 09:32 AM, Matt Turner wrote:
> On Thu, Feb 25, 2016 at 2:40 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> On BDW,
>>
>> total instructions in shared programs: 8448571 -> 8448367 (-0.00%)
>> instructions in affected programs: 21000 -> 20796 (-0.97%)
>> helped: 116
>> HURT: 0
>>
On Fri, Feb 26, 2016 at 10:58 AM, Ian Romanick wrote:
> Ok. Also... is there a reason 'else in else/endif' starts with .
> instead of a -?
Oops. Just a mistake :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/ma
On 2016-02-22 18:52:13, Francisco Jerez wrote:
> Jordan Justen writes:
>
> > Without this, on SIMD 16 the send instruction destination will appear
> > to write more than one destination register, causing the simulator to
> > report an error.
> >
> > Of course, the send instruction can actually wr
Jordan Justen writes:
> On 2016-02-22 18:52:13, Francisco Jerez wrote:
>> Jordan Justen writes:
>>
>> > Without this, on SIMD 16 the send instruction destination will appear
>> > to write more than one destination register, causing the simulator to
>> > report an error.
>> >
>> > Of course, the
https://bugs.freedesktop.org/show_bug.cgi?id=94295
--- Comment #3 from Vinson Lee ---
(In reply to Plamena Manolova from comment #2)
> Could you verify whether this patch fixes this issue for you?
Test still segfaults with patch id=121982.
#0 find_empty_block (uniform=, prog=) at
glsl/link_un
According to the Vulkan 1.0 spec section 9.4:
“When an application attempts to create many pipelines in a single
command, it is possible that some subset may fail creation. In that
case, the corresponding entries in the pPipelines output array will
be filled with VK_NULL_HANDLE values. If any p
Iago Toral writes:
> On Fri, 2016-02-26 at 16:28 +0100, Roland Scheidegger wrote:
>> Am 26.02.2016 um 11:25 schrieb Iago Toral:
>> >
>> > On Thu, 2016-02-25 at 18:20 -0500, Ilia Mirkin wrote:
>> >> On Thu, Feb 25, 2016 at 6:16 PM, Francisco Jerez
>> >> wrote:
>> >>> Ian Romanick writes:
>> >>
On Sat, Feb 6, 2016 at 6:53 PM, Jason Ekstrand wrote:
> I'm adding Chad to the Cc. At some point, it would be good to get Beignet
> playing well with mesa. Personally, I have substantial reservations about
> getting the kernel involved in surface layout for anything more than 2-D
> non-mipmapped
On 02/26/2016 07:09 AM, Alejandro Piñeiro wrote:
> Useful to know if a expression is the recipient of an assignment
> or not, that would be used to (for example) raise warnings of
> "use of uninitialized variable" without getting a false positive
> when assigning first a variable.
>
> By default t
On 02/26/2016 07:09 AM, Alejandro Piñeiro wrote:
> v2:
> * Take into account out varyings too (Timothy Arceri)
> * Fix style (Timothy Arceri)
> * Use a new ast_expression variable, instead of an
>ast_expression::hir new parameter (Timothy Arceri)
>
> Bugzilla: https://bugs.freedesktop.org/s
On Fri, Feb 26, 2016 at 7:54 AM, Jason Ekstrand
wrote:
>
> On Feb 25, 2016 5:33 PM, "Matt Turner" wrote:
> >
> > Indeed, that looks like a mistake.
>
> Yes, yes it is. Good catch.
>
> Reviewed-by: Jason Ekstrand
>
Thanks. Can I ask one of you to push it?
__
On Thu, 2016-02-25 at 18:32 -0800, Kenneth Graunke wrote:
> On Tuesday, December 29, 2015 4:00:26 PM PST Timothy Arceri wrote:
> > For tessellation shaders we cannot just copy everything to the
> > packed
> > varyings like we do in other stages as tessellation uses shared
> > memory for
> > varying
On Fri, Feb 26, 2016 at 1:28 PM, Thomas H.P. Andersen
wrote:
>
>
> On Fri, Feb 26, 2016 at 7:54 AM, Jason Ekstrand
> wrote:
>
>>
>> On Feb 25, 2016 5:33 PM, "Matt Turner" wrote:
>> >
>> > Indeed, that looks like a mistake.
>>
>> Yes, yes it is. Good catch.
>>
>> Reviewed-by: Jason Ekstrand
>>
https://bugs.freedesktop.org/show_bug.cgi?id=92850
Konstantin A. Lepikhov changed:
What|Removed |Added
CC||lakos...@altlinux.org
--
You a
And replace brw_swizzle1() with brw_swizzle(). Seems slightly cleaner
and will allow reusing brw_swizzle() in the vec4 back-end more easily.
---
src/mesa/drivers/dri/i965/brw_clip_unfilled.c | 6 --
src/mesa/drivers/dri/i965/brw_clip_util.c | 13 +++--
src/mesa/drivers/dri/i965/b
swizzle() works for vector immediates other than VF.
---
.../drivers/dri/i965/brw_vec4_copy_propagation.cpp| 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_copy_
Scalar immediates used to be handled correctly by swizzle() (as the
identity) but since commit 58fa9d47b536403c4e3ca5d6a2495691338388fd it
will corrupt the contents of the immediate. Vector immediates were
never handled correctly, but we had ad-hoc code to swizzle VF
immediates in the vec4 copy pr
It cannot get any better.
---
src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
b/src/mesa/drivers/dri
This simplifies the code that iterates over the per-component values
found in the matching copy_entry struct and checks whether the
register regions that were copied to each component are similar enough
to be treated as a single (reswizzled) value which can be propagated
into the current instructio
54 matches
Mail list logo
