On Monday, February 22, 2016 8:06:35 AM PST Tapani Pälli wrote:
> Hi Marek;
>
> Was this commit fixing some issues/problems? Why would we not expose
> configs with accumulation buffer?
>
> --- 8< ---
> commit 396cbabbefaae64deac6d33c79898bb07db8a621
> Author: Marek Olšák
> Date: Thu Apr 9 23:
On 02/22/2016 11:41 AM, Kenneth Graunke wrote:
On Monday, February 22, 2016 8:06:35 AM PST Tapani Pälli wrote:
Hi Marek;
Was this commit fixing some issues/problems? Why would we not expose
configs with accumulation buffer?
--- 8< ---
commit 396cbabbefaae64deac6d33c79898bb07db8a621
Author: Ma
Hello.
I'm working on providing piglit with tests for the
GL_ARB_gpu_shader_fp64 extension[1].
One of the modifications it does is referring uniform variables:
"Modify Section 2.14.4, Uniform Variables, p. 89
(modify third paragraph, p. 90) ... uniform variable storage for vertex
shader. A un
On 02/22/2016 01:39 PM, Juan A. Suarez Romero wrote:
Hello.
I'm working on providing piglit with tests for the
GL_ARB_gpu_shader_fp64 extension[1].
One of the modifications it does is referring uniform variables:
"Modify Section 2.14.4, Uniform Variables, p. 89
(modify third paragraph, p.
On Mon, Feb 22, 2016 at 7:06 AM, Tapani Pälli wrote:
> Hi Marek;
>
> Was this commit fixing some issues/problems? Why would we not expose configs
> with accumulation buffer?
EGL doesn't support accumulation buffers.
Marek
___
mesa-dev mailing list
mesa
On Mon, 2016-02-22 at 13:47 +0200, Tapani Pälli wrote:
> Maybe one way would be to include these matrices in UBO or SSBO and
> then
> query BUFFER_DATA_SIZE for that buffer. That should return
> "implementation-dependent minimum total buffer object size".
>
> https://www.opengl.org/registry/spec
On 02/22/2016 02:01 PM, Marek Olšák wrote:
On Mon, Feb 22, 2016 at 7:06 AM, Tapani Pälli wrote:
Hi Marek;
Was this commit fixing some issues/problems? Why would we not expose configs
with accumulation buffer?
EGL doesn't support accumulation buffers.
So EGL would not expose such capabil
On 02/22/2016 02:02 PM, Juan A. Suarez Romero wrote:
On Mon, 2016-02-22 at 13:47 +0200, Tapani Pälli wrote:
Maybe one way would be to include these matrices in UBO or SSBO and
then
query BUFFER_DATA_SIZE for that buffer. That should return
"implementation-dependent minimum total buffer object
On 22/02/16 02:59, Eric Anholt wrote:
Brian Paul writes:
On Sat, Feb 20, 2016 at 2:41 PM, Jason Ekstrand
wrote:
On Feb 20, 2016 1:19 PM, "Rob Clark" wrote:
fwiw, I think a *small* number of topic branches in certain cases
makes sense.. I'm definitely in support of a TTL limit (ie.
auto
On Mon, Feb 22, 2016 at 1:10 PM, Tapani Pälli wrote:
>
>
> On 02/22/2016 02:01 PM, Marek Olšák wrote:
>>
>> On Mon, Feb 22, 2016 at 7:06 AM, Tapani Pälli
>> wrote:
>>>
>>> Hi Marek;
>>>
>>> Was this commit fixing some issues/problems? Why would we not expose
>>> configs
>>> with accumulation buff
The first release candidate for Mesa 11.2.0 is now available.
The plan is to have one release candidate every Friday, until the final
release on March 11th 2016.
As a reminder, with the 11.2 branch now created, patches nominated with:
CC:
will now be candidates only for the new 11.2 br
On 02/22/2016 02:27 PM, Marek Olšák wrote:
On Mon, Feb 22, 2016 at 1:10 PM, Tapani Pälli wrote:
On 02/22/2016 02:01 PM, Marek Olšák wrote:
On Mon, Feb 22, 2016 at 7:06 AM, Tapani Pälli
wrote:
Hi Marek;
Was this commit fixing some issues/problems? Why would we not expose
configs
with ac
On Mon, Feb 22, 2016 at 1:48 PM, Tapani Pälli wrote:
>
> On 02/22/2016 02:27 PM, Marek Olšák wrote:
>>
>> On Mon, Feb 22, 2016 at 1:10 PM, Tapani Pälli
>> wrote:
>>>
>>>
>>>
>>> On 02/22/2016 02:01 PM, Marek Olšák wrote:
On Mon, Feb 22, 2016 at 7:06 AM, Tapani Pälli
wrote:
>>
On 02/22/2016 03:01 PM, Marek Olšák wrote:
On Mon, Feb 22, 2016 at 1:48 PM, Tapani Pälli wrote:
On 02/22/2016 02:27 PM, Marek Olšák wrote:
On Mon, Feb 22, 2016 at 1:10 PM, Tapani Pälli
wrote:
On 02/22/2016 02:01 PM, Marek Olšák wrote:
On Mon, Feb 22, 2016 at 7:06 AM, Tapani Pälli
On Mon, 2016-02-22 at 14:13 +0200, Tapani Pälli wrote:
> > So rather than reporting the number of uniform components it is
> > consuming, is reporting the bytes used in the layout.
> >
>
> Ah right, I see. Maybe you can query OFFSET then, this should differ
> then when matrix has a different type
Reviewed-by: Samuel Iglesias Gonsálvez
On Sun, 2016-02-14 at 20:28 +1100, Timothy Arceri wrote:
> If the following patch we will stop setting these layouts by default
> on interface blocks, so we need to do this to avoid hitting the
> assert.
> ---
> src/compiler/glsl/ast_to_hir.cpp | 13 +++
Reviewed-by: Samuel Iglesias Gonsálvez
On Sun, 2016-02-14 at 20:28 +1100, Timothy Arceri wrote:
> Previously interface blocks were giving the global default flags of
> uniform blocks. This meant we could not check for invalid qualifiers
> on interface blocks because they always contained invalid
On Sun, 2016-02-14 at 20:28 +1100, Timothy Arceri wrote:
> Global in validation is already handled, this will do the validation
> for variables, blocks and block members.
>
> This fixes some CTS tests for the new enhanced layouts transform
> feedback qualifiers.
>
> V2: add some more valid input
11.2 has been branched, we're on 11.3 now.
Signed-off-by: Ilia Mirkin
---
VERSION | 2 +-
docs/relnotes/11.3.0.html | 59 +++
2 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 docs/relnotes/11.3.0.html
diff --git
On Thu, Feb 18, 2016 at 11:11 AM, Emil Velikov wrote:
> Hi Rob,
>
> On 2 February 2016 at 20:23, Rob Herring wrote:
>> This is used by Android to select an eglconfig compatible with HWComposer.
>>
>> Signed-off-by: Rob Herring
>> ---
>> v2:
>> - Also add reporting the extension string
>>
>> src
On Thu, Feb 18, 2016 at 1:15 PM, Emil Velikov wrote:
> On 18 February 2016 at 17:47, Rob Clark wrote:
>> On Thu, Feb 18, 2016 at 11:48 AM, Emil Velikov
>> wrote:
>>> Hi Rob,
>>>
>>> On 10 February 2016 at 22:56, Rob Herring wrote:
Introduce load_pipe_screen() public entry point for other
On Thu, Feb 18, 2016 at 11:40 AM, Emil Velikov wrote:
> Hi Rob,
>
> On 2 February 2016 at 20:45, Rob Herring wrote:
>> Android builds with -Wunused-parameter enabled which results in spewing
>> lots of warnings. Disable it so more meaningful warnings are more visible.
>>
>> Signed-off-by: Rob Her
https://bugs.freedesktop.org/show_bug.cgi?id=94232
--- Comment #1 from Brian Paul ---
Exactly what/where is the compiler error?
Someone familiar with the gbm code should review this.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.__
On 22 February 2016 at 15:48, Rob Herring wrote:
> On Thu, Feb 18, 2016 at 1:15 PM, Emil Velikov
> wrote:
>> On 18 February 2016 at 17:47, Rob Clark wrote:
>>> On Thu, Feb 18, 2016 at 11:48 AM, Emil Velikov
>>> wrote:
Hi Rob,
On 10 February 2016 at 22:56, Rob Herring wrote:
>>
On Thu, Feb 18, 2016 at 11:25 AM, Emil Velikov wrote:
> Hi Rob,
>
> On 2 February 2016 at 20:45, Rob Herring wrote:
>> Builds with gallium enabled fail on x86 with linker error:
>>
>> external/mesa3d/src/mesa/vbo/vbo_exec_array.c:127: error: undefined
>> reference to '_mesa_uint_array_min_max'
>
https://bugs.freedesktop.org/show_bug.cgi?id=94232
Emil Velikov changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
Unclear to me whether it actually is a horizontal operation that cannot
be vectorized, but the fact that i965 generates the same code in either
case makes me less interested in finding out.
Cc: mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94199
---
src/
On Sun, Feb 21, 2016 at 9:28 AM, Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> ---
> .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 35
> +++---
> 1 file changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emi
Hi Tim,
Please try and add prefix/section for the patch summary - here we can
use "gallium/targets: add OpenSWR support" or alike.
On 19 February 2016 at 04:23, Tim Rowley wrote:
> ---
> .../auxiliary/target-helpers/inline_sw_helper.h| 11 +
> .../target-helpers/inline_wrapper_sw_h
On Monday, February 22, 2016 12:25:45 PM PST Tapani Pälli wrote:
>
> On 02/22/2016 11:41 AM, Kenneth Graunke wrote:
> > On Monday, February 22, 2016 8:06:35 AM PST Tapani Pälli wrote:
> >> Hi Marek;
> >>
> >> Was this commit fixing some issues/problems? Why would we not expose
> >> configs with ac
On Monday, February 22, 2016 2:48:01 PM PST Tapani Pälli wrote:
>
> On 02/22/2016 02:27 PM, Marek Olšák wrote:
> > On Mon, Feb 22, 2016 at 1:10 PM, Tapani Pälli
wrote:
> >>
> >>
> >> On 02/22/2016 02:01 PM, Marek Olšák wrote:
> >>>
> >>> On Mon, Feb 22, 2016 at 7:06 AM, Tapani Pälli
> >>> wrote
On 18 February 2016 at 01:53, Tim Rowley wrote:
Don't be shy to mention something in the commit message - which of the
tree targets has been tested. Do they all build/work on linux,
windows, BSD, other. Pretty much anything that you believe it's
important. You might also include something that is
Hi Marc,
On 12 February 2016 at 21:11, Marc-André Lureau
wrote:
> From: Marc-André Lureau
>
> Add the virtio-gpu PCI ID for virtio 1.0 (according to the
> specification, "the PCI Device ID is calculated by adding 0x1040 to the
> Virtio Device ID")
>
Which versions of qemu + kernel work with the
On Monday, February 22, 2016 12:20:02 PM PST Jose Fonseca wrote:
> On 22/02/16 02:59, Eric Anholt wrote:
> > Brian Paul writes:
> >
> >> On Sat, Feb 20, 2016 at 2:41 PM, Jason Ekstrand
> >> wrote:
> >>
> >>>
> >>> On Feb 20, 2016 1:19 PM, "Rob Clark" wrote:
>
> fwiw, I think a *small*
On Monday, February 22, 2016 9:39:34 AM PST Matt Turner wrote:
> Unclear to me whether it actually is a horizontal operation that cannot
> be vectorized, but the fact that i965 generates the same code in either
> case makes me less interested in finding out.
>
> Cc: mesa-sta...@lists.freedesktop.o
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 write more than one
destination register regardless of the type set for the destination,
so this
For Haswell, we need to initialize the SLM index in the state
register. This can be copied out of the CS header dword 0.
Fixes piglit: arb_compute_shader/execution/shared-atomics.shader_test
Signed-off-by: Jordan Justen
Cc: Ilia Mirkin
Cc: "11.2"
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 7
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94081
Tested-by: Ilia Mirkin
Seems to fix all the shared_var fails in dEQP here!
On Mon, Feb 22, 2016 at 2:35 PM, Jordan Justen
wrote:
> For Haswell, we need to initialize the SLM index in the state
> register. This can be copied out of the
From: Ian Romanick
Previously loops like
do {
// ...
} while (false);
that did not have any other loop-branch instructions would not be
unrolled. This is commonly used to wrap multiline preprocessor macros.
This produces IR like
(loop (
...
break
))
Since l
On 02/22/2016 04:48 AM, Tapani Pälli wrote:
>
> On 02/22/2016 02:27 PM, Marek Olšák wrote:
>> On Mon, Feb 22, 2016 at 1:10 PM, Tapani Pälli
>> wrote:
>>>
>>>
>>> On 02/22/2016 02:01 PM, Marek Olšák wrote:
On Mon, Feb 22, 2016 at 7:06 AM, Tapani Pälli
wrote:
>
> Hi Marek;
>
Steven Newbury writes:
> On Sun, 2016-02-21 at 12:01 +, Steven Newbury wrote:
>> On Sun, 2016-02-21 at 11:28 +, Steven Newbury wrote:
>> > On Sun, 2016-02-21 at 10:56 +, Steven Newbury wrote:
>> > > On Sun, 2016-02-21 at 10:16 +, Steven Newbury wrote:
>> > > > Hi Jason,
>> > > >
NAK.
The purpose of the dynamic entries is to allow a newer version of the GL
driver to work with a slightly older libGL. There is no reason to
support more than 256 new functions... update your libGL. If there are
functions that libGL doesn't support, just add them.
On 02/11/2016 04:03 AM, Tap
On 02/11/2016 04:03 AM, Tapani Pälli wrote:
> From: Daniel Czarnowski
>
> Signed-off-by: Matt Roper
> Cc: "11.0 11.1" ---
> src/egl/drivers/dri2/platform_x11.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/egl/drivers/dri2/platform_x11.c
> b/src/egl/driver
There are 17 total occurrences of
grep -r '[(]!gc[)]' src/glx/
and
grep -r 'gc[[:space:]]*==[[:space:]]*NULL' src/glx/
None of these check for dummyContext. This is all very suspicious.
Looking at the implementation(s) of __glXGetCurrentContext, I don't
think it can ever return NULL.
On 02/11/2016 04:03 AM, Tapani Pälli wrote:
> From: Daniel Czarnowski
>
> Without the check, unsuccessful xcb_dri2_get_buffers_reply(...) causes
> segmentation fault in dri2_get_buffers.
>
> Signed-off-by: Matt Roper
> Cc: "11.0 11.1" ---
> src/egl/drivers/dri2/platform_x11.c | 2 ++
> 1 file
Thanks for taking the time to dig into this patch. Figured I’d address a few
of the comments now, and work on all your points for the next revision.
> On Feb 22, 2016, at 12:53 PM, Emil Velikov wrote:
>
> On 18 February 2016 at 01:53, Tim Rowley wrote:
>
> Don't be shy to mention something i
Signed-off-by: Ilia Mirkin
---
Note that this relies on my earlier patches which add core
ARB_ES3_1_compatibility support.
docs/GL3.txt | 2 +-
src/compiler/glsl/builtin_functions.cpp | 4 +++-
src/compiler/glsl/glsl_parser_extras.cpp | 1 +
src/compiler/glsl/glsl_
This fixes atomic exchange with a r32f image, as needed by
GL_OES_shader_atomic_exchange.
Signed-off-by: Ilia Mirkin
---
src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_surface_builder
On Mon, Feb 22, 2016 at 3:52 PM, Ilia Mirkin wrote:
> This fixes atomic exchange with a r32f image, as needed by
> GL_OES_shader_atomic_exchange.
Sorry, that should be GL_OES_shader_image_atomic of course.
>
> Signed-off-by: Ilia Mirkin
> ---
> src/mesa/drivers/dri/i965/brw_fs_surface_builder.
On 02/19/2016 02:57 AM, Iago Toral wrote:
> I don't know much about this, but using shader_samples_identical should
> only give a benefit if we actually get identical samples, otherwise it
> means more work, right?
It is possible to do more work. Assuming the backend compiler does
everything righ
On 02/19/2016 01:55 AM, Iago Toral wrote:
> On Wed, 2016-02-17 at 17:58 -0800, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Just include all 3 versions in the shader. The GLSL type system will
>> pick the correct one. This simplifies the code a bit, and it helps pave
>> the way for additional
On Mon, 2016-02-22 at 14:25 +0100, Samuel Iglesias Gonsálvez wrote:
> On Sun, 2016-02-14 at 20:28 +1100, Timothy Arceri wrote:
> > Global in validation is already handled, this will do the
> > validation
> > for variables, blocks and block members.
> >
> > This fixes some CTS tests for the new enh
On Mon, Feb 22, 2016 at 3:53 PM, Ilia Mirkin wrote:
> On Mon, Feb 22, 2016 at 3:52 PM, Ilia Mirkin wrote:
>> This fixes atomic exchange with a r32f image, as needed by
>> GL_OES_shader_atomic_exchange.
>
> Sorry, that should be GL_OES_shader_image_atomic of course.
>
>>
>> Signed-off-by: Ilia Mir
On Mon, Feb 22, 2016 at 1:05 PM, Ian Romanick wrote:
> On 02/19/2016 02:57 AM, Iago Toral wrote:
>> I don't know much about this, but using shader_samples_identical should
>> only give a benefit if we actually get identical samples, otherwise it
>> means more work, right?
>
> It is possible to do
https://bugs.freedesktop.org/show_bug.cgi?id=94253
Bug ID: 94253
Summary: [llvmpipe] piglit gl-1.0-swapbuffers-behavior
regression
Product: Mesa
Version: 11.2
Hardware: x86-64 (AMD64)
OS: Linux (All)
On 22 February 2016 at 20:39, Rowley, Timothy O
wrote:
> Thanks for taking the time to dig into this patch. Figured I’d address a few
> of the comments now, and work on all your points for the next revision.
>
>> On Feb 22, 2016, at 12:53 PM, Emil Velikov wrote:
>>
>> On 18 February 2016 at 01:
Ilia Mirkin writes:
> On Mon, Feb 22, 2016 at 3:53 PM, Ilia Mirkin wrote:
>> On Mon, Feb 22, 2016 at 3:52 PM, Ilia Mirkin wrote:
>>> This fixes atomic exchange with a r32f image, as needed by
>>> GL_OES_shader_atomic_exchange.
>>
>> Sorry, that should be GL_OES_shader_image_atomic of course.
>>
On Mon, Feb 22, 2016 at 5:21 PM, Francisco Jerez wrote:
> Ilia Mirkin writes:
>
>> On Mon, Feb 22, 2016 at 3:53 PM, Ilia Mirkin wrote:
>>> On Mon, Feb 22, 2016 at 3:52 PM, Ilia Mirkin wrote:
This fixes atomic exchange with a r32f image, as needed by
GL_OES_shader_atomic_exchange.
>>>
Ilia Mirkin writes:
> On Mon, Feb 22, 2016 at 5:21 PM, Francisco Jerez
> wrote:
>> Ilia Mirkin writes:
>>
>>> On Mon, Feb 22, 2016 at 3:53 PM, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 3:52 PM, Ilia Mirkin wrote:
> This fixes atomic exchange with a r32f image, as needed by
> GL
On Mon, Feb 22, 2016 at 5:38 PM, Francisco Jerez wrote:
> Ilia Mirkin writes:
>
>> On Mon, Feb 22, 2016 at 5:21 PM, Francisco Jerez
>> wrote:
>>> Ilia Mirkin writes:
>>>
On Mon, Feb 22, 2016 at 3:53 PM, Ilia Mirkin wrote:
> On Mon, Feb 22, 2016 at 3:52 PM, Ilia Mirkin wrote:
>>
https://bugs.freedesktop.org/show_bug.cgi?id=94254
Bug ID: 94254
Summary: [llvmpipe] [softpipe] piglit read-front regression
Product: Mesa
Version: 11.2
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Ilia Mirkin writes:
> On Mon, Feb 22, 2016 at 5:38 PM, Francisco Jerez
> wrote:
>> Ilia Mirkin writes:
>>
>>> On Mon, Feb 22, 2016 at 5:21 PM, Francisco Jerez
>>> wrote:
Ilia Mirkin writes:
> On Mon, Feb 22, 2016 at 3:53 PM, Ilia Mirkin wrote:
>> On Mon, Feb 22, 2016 at 3
On Mon, Feb 22, 2016 at 6:13 PM, Francisco Jerez wrote:
> Ilia Mirkin writes:
>
>> On Mon, Feb 22, 2016 at 5:38 PM, Francisco Jerez
>> wrote:
>>> Ilia Mirkin writes:
>>>
On Mon, Feb 22, 2016 at 5:21 PM, Francisco Jerez
wrote:
>>> IIRC the series I sent already enabled the built-ins
On Mon, 2016-02-22 at 11:42 -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> Previously loops like
>
> do {
> // ...
> } while (false);
>
> that did not have any other loop-branch instructions would not be
> unrolled. This is commonly used to wrap multiline preprocessor
> macros
On 02/22/2016 02:10 PM, Matt Turner wrote:
> On Mon, Feb 22, 2016 at 1:05 PM, Ian Romanick wrote:
>> On 02/19/2016 02:57 AM, Iago Toral wrote:
>>> I don't know much about this, but using shader_samples_identical should
>>> only give a benefit if we actually get identical samples, otherwise it
>>>
Before the luminance stride was based on the size of GL_FLOAT
which is just the type constant (0x1406). Change it to use the
size of GLfloat.
---
src/mesa/main/readpix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 4701
On 02/22/2016 03:58 PM, Thomas Hindoe Paaboel Andersen wrote:
Before the luminance stride was based on the size of GL_FLOAT
which is just the type constant (0x1406). Change it to use the
size of GLfloat.
---
src/mesa/main/readpix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On Mon, Feb 22, 2016 at 11:42 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> Previously loops like
>
>do {
> // ...
>} while (false);
>
> that did not have any other loop-branch instructions would not be
> unrolled. This is commonly used to wrap multiline preprocessor macros.
>
>
Allows us to transform
mad res src0 src1 src2
mov.sat dst -res
into
mad.sat dst -src0 -src1 src2
instructions in affected programs: 3712 -> 3688 (-0.65%)
helped: 24
---
src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp | 4
1 file changed, 4 insertions(+)
total instructions in shared programs: 7127270 -> 7103195 (-0.34%)
instructions in affected programs: 1376832 -> 1352757 (-1.75%)
helped: 7394
HURT: 622
GAINED: 4
LOST: 2
---
src/compiler/nir/nir_opt_algebraic.py | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/nir/nir_opt_a
Allows us to transform
mul res src0 src1
mov.sat dst -res
into
mul.sat dst src0 -src1
instructions in affected programs: 45246 -> 45054 (-0.42%)
helped: 162
---
.../dri/i965/brw_fs_saturate_propagation.cpp | 17 ++-
.../dri/i965/test_fs_saturate_propagation.cpp
Allows us to transform
add res src0 src1
mov.sat dst -res
into
add.sat dst -src0 -src1
No shader-db changes.
---
.../dri/i965/brw_fs_saturate_propagation.cpp | 11 ++
.../dri/i965/test_fs_saturate_propagation.cpp | 45 --
2 files changed,
It's not correct to CSE these multiplies
mul.sat dst1, -a, b
mul.sat dst2, a, b
by emitting a negated MOV from dst1 to dst2:
mul.sat dst1, -a, b
mov dst2, -dst1
Take 2.0*2.0 for example. The first multiply would produce 0.0 and the
second would produce 1.0.
Fixes bad generated
On 02/22/2016 04:05 PM, Matt Turner wrote:
> On Mon, Feb 22, 2016 at 11:42 AM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Previously loops like
>>
>>do {
>> // ...
>>} while (false);
>>
>> that did not have any other loop-branch instructions would not be
>> unrolled. This is c
On Mon, Feb 22, 2016 at 7:13 PM, Matt Turner wrote:
Unless there's something unexpected going on, let's say
src0 = 0, src1 = 0, src2 = -0.5
> Allows us to transform
>
>mad res src0 src1 src2
res = -0.5
>mov.sat dst -res
dst = 0.5
>
> into
>
>mad.sat dst -src0 -src1
From: Marek Olšák
"st/mesa: overhaul vertex setup for clearing, glDrawPixels, glBitmap"
added a vertex shader declaring IN[0] and IN[2], but not IN[1].
Drivers relying on tgsi_shader_info can't handle holes in declarations,
because tgsi_shader_info doesn't track that.
This is just a quick worka
On Mon, Feb 22, 2016 at 4:39 PM, Ilia Mirkin wrote:
> On Mon, Feb 22, 2016 at 7:13 PM, Matt Turner wrote:
>
> Unless there's something unexpected going on, let's say
>
> src0 = 0, src1 = 0, src2 = -0.5
>
>> Allows us to transform
>>
>>mad res src0 src1 src2
>
> res = -0.5
I think y
On 02/22/2016 05:46 PM, Marek Olšák wrote:
From: Marek Olšák
"st/mesa: overhaul vertex setup for clearing, glDrawPixels, glBitmap"
added a vertex shader declaring IN[0] and IN[2], but not IN[1].
Drivers relying on tgsi_shader_info can't handle holes in declarations,
because tgsi_shader_info do
On Mon, Feb 22, 2016 at 7:58 PM, Matt Turner wrote:
> On Mon, Feb 22, 2016 at 4:39 PM, Ilia Mirkin wrote:
>> On Mon, Feb 22, 2016 at 7:13 PM, Matt Turner wrote:
>>
>> Unless there's something unexpected going on, let's say
>>
>> src0 = 0, src1 = 0, src2 = -0.5
>>
>>> Allows us to transform
>>>
>
https://bugs.freedesktop.org/show_bug.cgi?id=94257
Bug ID: 94257
Summary: [softpipe] piglit glx-copy-sub-buffer regression
Product: Mesa
Version: 11.2
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
K
On 02/22/2016 04:16 PM, Ian Romanick wrote:
> On 02/22/2016 04:05 PM, Matt Turner wrote:
>> On Mon, Feb 22, 2016 at 11:42 AM, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> Previously loops like
>>>
>>>do {
>>> // ...
>>>} while (false);
>>>
>>> that did not have any other loop-
Patches 1 - 4 are
Reviewed-by: Ian Romanick
Patch 5 probably is too, but I have a question or two.
On 02/22/2016 04:13 PM, Matt Turner wrote:
> It's not correct to CSE these multiplies
>
>mul.sat dst1, -a, b
>mul.sat dst2, a, b
>
> by emitting a negated MOV from dst1 to dst2:
>
>
v2: No need for extension enable bits (Ilia).
---
src/compiler/glsl/glcpp/glcpp-parse.y| 3 +++
src/compiler/glsl/glsl_parser_extras.cpp | 1 +
src/compiler/glsl/glsl_parser_extras.h | 2 ++
3 files changed, 6 insertions(+)
diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y
b/src/compiler/
v2: No need for extension enable bits (Ilia).
---
src/mesa/main/extensions_table.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index dcbde2d..68f3617 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extens
This is basically just the same atomic functions exposed by
ARB_shader_image_load_store, with one exception:
"highp float imageAtomicExchange(
coherent IMAGE_PARAMS,
float data);"
There's no float atomic exchange overload in the original
ARB_shader_image_load_store or GL 4.2
So the result is of float type if we're implementing the float
overload of imageAtomicExchange. This is the only back-end change
required to support OES_shader_image_atomic AFAICT.
---
src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
---
docs/GL3.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 76f40e4..d2b5cc6 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -249,7 +249,7 @@ GLES3.2, GLSL ES 3.2
GL_OES_primitive_bounding boxnot started
GL_OE
On Mon, Feb 22, 2016 at 9:40 PM, Francisco Jerez wrote:
> This is basically just the same atomic functions exposed by
> ARB_shader_image_load_store, with one exception:
>
> "highp float imageAtomicExchange(
> coherent IMAGE_PARAMS,
> float data);"
>
> There's no float atomic
On Mon, Feb 22, 2016 at 9:40 PM, Francisco Jerez wrote:
> So the result is of float type if we're implementing the float
> overload of imageAtomicExchange. This is the only back-end change
> required to support OES_shader_image_atomic AFAICT.
> ---
> src/mesa/drivers/dri/i965/brw_fs_surface_buil
On Mon, Feb 22, 2016 at 9:40 PM, Francisco Jerez wrote:
> ---
> docs/GL3.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index 76f40e4..d2b5cc6 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -249,7 +249,7 @@ GLES3.2, GLSL ES 3.2
>
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 write more than one
> destination register regardless of the ty
Ilia Mirkin writes:
> On Mon, Feb 22, 2016 at 9:40 PM, Francisco Jerez
> wrote:
>> So the result is of float type if we're implementing the float
>> overload of imageAtomicExchange. This is the only back-end change
>> required to support OES_shader_image_atomic AFAICT.
>> ---
>> src/mesa/driv
On Mon, Feb 22, 2016 at 10:09 PM, Francisco Jerez wrote:
> Ilia Mirkin writes:
>
>> On Mon, Feb 22, 2016 at 9:40 PM, Francisco Jerez
>> wrote:
>>> So the result is of float type if we're implementing the float
>>> overload of imageAtomicExchange. This is the only back-end change
>>> required t
Ilia Mirkin writes:
> On Mon, Feb 22, 2016 at 9:40 PM, Francisco Jerez
> wrote:
>> This is basically just the same atomic functions exposed by
>> ARB_shader_image_load_store, with one exception:
>>
>> "highp float imageAtomicExchange(
>> coherent IMAGE_PARAMS,
>> float dat
This is basically just the same atomic functions exposed by
ARB_shader_image_load_store, with one exception:
"highp float imageAtomicExchange(
coherent IMAGE_PARAMS,
float data);"
There's no float atomic exchange overload in the original
ARB_shader_image_load_store or GL 4.2
On Mon, Feb 22, 2016 at 10:31 PM, Francisco Jerez wrote:
> This is basically just the same atomic functions exposed by
> ARB_shader_image_load_store, with one exception:
>
> "highp float imageAtomicExchange(
> coherent IMAGE_PARAMS,
> float data);"
>
> There's no float atomic
Ilia Mirkin writes:
> On Mon, Feb 22, 2016 at 10:31 PM, Francisco Jerez
> wrote:
>> This is basically just the same atomic functions exposed by
>> ARB_shader_image_load_store, with one exception:
>>
>> "highp float imageAtomicExchange(
>> coherent IMAGE_PARAMS,
>> float da
> On Feb 17, 2016, at 7:07 PM, Roland Scheidegger wrote:
>
> You could use different functions for avx and avx2 code, and plug the
> right ones in at runtime, as you can link them both just fine. It just
> requires that your code containing avx2 code is in a different compile
> unit to the one c
On 02/22/2016 08:23 PM, Kenneth Graunke wrote:
On Monday, February 22, 2016 12:25:45 PM PST Tapani Pälli wrote:
On 02/22/2016 11:41 AM, Kenneth Graunke wrote:
On Monday, February 22, 2016 8:06:35 AM PST Tapani Pälli wrote:
Hi Marek;
Was this commit fixing some issues/problems? Why would we
On 02/22/2016 09:54 PM, Ian Romanick wrote:
NAK.
The purpose of the dynamic entries is to allow a newer version of the GL
driver to work with a slightly older libGL. There is no reason to
support more than 256 new functions... update your libGL. If there are
functions that libGL doesn't supp
1 - 100 of 103 matches
Mail list logo
