On 02/23/2016 03:23 AM, Ian Romanick wrote:
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
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
>>>
On 02/22/2016 04:13 PM, Matt Turner wrote:
> 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 ch
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
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 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
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 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
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
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
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:
>> 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
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
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
>
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:
> 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
---
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
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
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
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/
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
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:
>
>
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-
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 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
>>>
>
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 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
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 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
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
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
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,
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
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.
>
>
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 --
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 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
>>>
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 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
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
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
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:
>>
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: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 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 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:
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 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
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, 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 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 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 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.
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
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_
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
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
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
>
> 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
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
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,
>> > > >
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;
>
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
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
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
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
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
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*
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 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
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 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
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 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
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/
https://bugs.freedesktop.org/show_bug.cgi?id=94232
Emil Velikov changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
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'
>
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:
>>
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 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
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: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
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 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
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
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 +++
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
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, 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 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
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 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
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 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 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 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 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 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.
1 - 100 of 103 matches
Mail list logo
