On Thu, Oct 24, 2013 at 2:19 AM, Matt Turner wrote:
> No shader-db changes, but seems like a good idea.
> ---
> src/glsl/opt_algebraic.cpp | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index 3bf0689..1ce9e2d 100644
> --
Why is this tagged as i965/fs, when everything seems to happen in the
glsl-optimizer?
On Thu, Oct 24, 2013 at 5:53 PM, Eric Anholt wrote:
> I noticed this in a shader in Unigine Heaven that was spilling. While it
> doesn't really reduce register pressure, it shaves a few instructions
> anyway (7
On Fri, Nov 1, 2013 at 10:16 AM, Tapani Pälli wrote:
> Signed-off-by: Tapani Pälli
> ---
> src/mesa/main/shaderapi.c | 46 +++---
> 1 file changed, 39 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> in
On Fri, Nov 1, 2013 at 11:35 AM, Tapani Pälli wrote:
> On 11/01/2013 12:21 PM, Erik Faye-Lund wrote:
>>
>> On Fri, Nov 1, 2013 at 10:16 AM, Tapani Pälli
>> wrote:
>>>
>>> Signed-off-by: Tapani Pälli
>&
On Fri, Nov 1, 2013 at 1:08 PM, Tapani Pälli wrote:
> On 11/01/2013 12:38 PM, Erik Faye-Lund wrote:
>>
>> On Fri, Nov 1, 2013 at 11:35 AM, Tapani Pälli
>> wrote:
>>>
>>> On 11/01/2013 12:21 PM, Erik Faye-Lund wrote:
>>>>
>>>
Sorry for the late reply.
On Fri, Nov 1, 2013 at 4:14 PM, Tapani wrote:
> On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:
>>
>>
>> Won't using the git-sha1 as a compatibility-criteria cause issues for
>> developers with local changes? I'm not so worried abo
On Wed, Nov 6, 2013 at 7:49 PM, Paul Berry wrote:
> On 6 November 2013 09:35, Erik Faye-Lund wrote:
>>
>> Sorry for the late reply.
>>
>> On Fri, Nov 1, 2013 at 4:14 PM, Tapani wrote:
>> > On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:
>> &g
On Wed, Nov 6, 2013 at 9:19 PM, Paul Berry wrote:
> On 6 November 2013 11:24, Erik Faye-Lund wrote:
>>
>> On Wed, Nov 6, 2013 at 7:49 PM, Paul Berry
>> wrote:
>> > On 6 November 2013 09:35, Erik Faye-Lund wrote:
>> >>
>> >> Sorry for the
On Mon, Nov 18, 2013 at 9:04 PM, Paul Berry wrote:
> On 17 November 2013 00:24, Victor Luchitz wrote:
>> If compiler actually attempted to unroll the loop above, it would notice
>> that the does compile correctly. Instead it just emits and error and in my
>> opinion, contradicts the comment above
On Thu, Jun 12, 2014 at 3:11 AM, Carl Worth wrote:
> Previously, the test suite was expecting the compiler to allow a redefintion
> of a macro with whitespace added, but gcc is more strict and allows only for
> changes in the amounts of whitespace, (but insists that whitespace exist or
> not in ex
On Mon, Jul 7, 2014 at 7:18 PM, Matt Turner wrote:
> On Mon, Jul 7, 2014 at 6:57 AM, Abdiel Janulgue
> wrote:
>> v2: Check that the base type is float (Ian Romanick)
>>
>> Signed-off-by: Abdiel Janulgue
>> ---
>> src/glsl/opt_algebraic.cpp | 34 ++
>> 1 file chan
On Tue, Jul 8, 2014 at 8:22 AM, Matt Turner wrote:
> On Mon, Jul 7, 2014 at 11:00 PM, Erik Faye-Lund wrote:
>> On Mon, Jul 7, 2014 at 7:18 PM, Matt Turner wrote:
>>> This comment tripped me up for a second. This really means that you've
>>> found either
>&
On Tue, Jul 8, 2014 at 5:44 PM, Roland Scheidegger wrote:
> Am 08.07.2014 08:22, schrieb Matt Turner:
>> On Mon, Jul 7, 2014 at 11:00 PM, Erik Faye-Lund wrote:
>>> On Mon, Jul 7, 2014 at 7:18 PM, Matt Turner wrote:
>>>> This comment tripped me up for a second.
On Sat, Jul 19, 2014 at 4:59 PM, Ilia Mirkin wrote:
> +TGSI_SEMANTIC_TESSCOORD
> +"""
> +
> +For tessellation evaluation shaders, this semantic label indicates the
> +coordinates of the vertex being processed. This is available in XYZ; W is
> +undefined.
> +
+ "This correspond
On Thu, Sep 5, 2013 at 12:22 AM, Kenneth Graunke wrote:
> +#define B0(X) ir_function_signature *_##X();
> +#define B1(X) ir_function_signature *_##X(const glsl_type *);
> +#define B2(X) ir_function_signature *_##X(const glsl_type *, const glsl_type
> *);
> +#define B3(X) ir_function_signature *_#
> diff --git a/src/glsl/ir_builder.cpp b/src/glsl/ir_builder.cpp
> index e12ae3c..31a457d 100644
> --- a/src/glsl/ir_builder.cpp
> +++ b/src/glsl/ir_builder.cpp
> @@ -264,6 +264,46 @@ abs(operand a)
> return expr(ir_unop_abs, a);
> }
>
> +ir_expression *neg(operand a)
> +{
> + return expr(ir
On Mon, Sep 9, 2013 at 1:31 PM, Roland Scheidegger wrote:
> I'm not really convinced of this idea.
> There's already PIPE_CAP_MIXED_COLORBUFFER_FORMATS which is sort of
> similar - a "requirement" of ARB_fbo, but it isn't used to determine
> support of ARB_fbo or not (my guess is drivers want to a
The preprocessor currently eats multiple #else directives
int the same #if(def) ... #endif block. While I haven't been able
to find anything that explicitly disallows it, it's nonsensical
and should probably not be allowed.
Add checks to reject the code.
---
I'm not entirely sure why parser->skip
On Mon, Sep 23, 2013 at 10:35 PM, Erik Faye-Lund wrote:
> The preprocessor currently eats multiple #else directives
> int the same #if(def) ... #endif block. While I haven't been able
> to find anything that explicitly disallows it, it's nonsensical
> and should probably n
Signed-off-by: Erik Faye-Lund
---
I just peeked into the freedreno code, and noticed that it had some
undocumented debug-code. Perhaps it could make sense to document it,
like this?
src/gallium/docs/source/debugging.rst | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/docs
On Mon, Mar 25, 2013 at 6:25 PM, Erik Faye-Lund wrote:
> Signed-off-by: Erik Faye-Lund
> ---
>
> I just peeked into the freedreno code, and noticed that it had some
> undocumented debug-code. Perhaps it could make sense to document it,
> like this?
>
> src/gallium/docs/
On Mon, Mar 25, 2013 at 6:36 PM, Erik Faye-Lund wrote:
> On Mon, Mar 25, 2013 at 6:25 PM, Erik Faye-Lund wrote:
>> Signed-off-by: Erik Faye-Lund
>> ---
>>
>> I just peeked into the freedreno code, and noticed that it had some
>> undocumented debug-code. Perhap
On Mon, Mar 25, 2013 at 9:28 PM, Rob Clark wrote:
> On Mon, Mar 25, 2013 at 3:27 PM, Erik Faye-Lund wrote:
>> On Mon, Mar 25, 2013 at 6:36 PM, Erik Faye-Lund wrote:
>>> On Mon, Mar 25, 2013 at 6:25 PM, Erik Faye-Lund wrote:
>>>> Signed-off-by: Erik Faye-Lund
&g
Signed-off-by: Erik Faye-Lund
---
Here you go, a version of the patch prepared for git-am
src/gallium/docs/source/debugging.rst | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/docs/source/debugging.rst
b/src/gallium/docs/source/debugging.rst
index e081cbf..dc308e5 100644
Ping? Anything wrong with it?
On Tue, Mar 26, 2013 at 2:48 PM, Erik Faye-Lund wrote:
> Signed-off-by: Erik Faye-Lund
> ---
>
> Here you go, a version of the patch prepared for git-am
>
> src/gallium/docs/source/debugging.rst | 4
> 1 file changed, 4 insertions(+)
On Thu, Apr 4, 2013 at 4:32 PM, Brian Paul wrote:
>
> On 04/04/2013 05:20 AM, Erik Faye-Lund wrote:
>>
>> Ping? Anything wrong with it?
>
>
> Looks OK to me. Do you need someone to commit for you?
>
Well, I don't have commit access. But I was expecting to see
On Mon, Dec 2, 2013 at 11:08 PM, Andreas Hartmetz wrote:
> Hello,
>
> I've been lurking for a while, this seems to be my first post.
>
> While trying to make some "easy" (ha) improvements in radeonsi I looked
> around in all the surrounding code to get a good picture of how things
> work. So I not
On Tue, Dec 10, 2013 at 1:41 AM, Christopher Corsi wrote:
> Currently it can do rasterize with T&L,
> texturing, bit-blits, and handle a subset of functionality needed for OpenGL
> (scissor, blend modes, etc.). Shader support is planned.
AFAIK, Gallium3D requires support for vertex and fragment s
guess "slow" doesn't mean *this* slow? :)
Should I resend the patch, with the #elseif fix squashed in?
> On 09/23/2013 01:35 PM, Erik Faye-Lund wrote:
>> The preprocessor currently eats multiple #else directives
>> int the same #if(def) ... #endif block. While
The preprocessor currently accepts multiple else/elif-groups
per if-section. The GLSL-preprocessor is defined by the C++
specification, which defines the following parse-rule:
if-section:
if-group elif-groups(opt) else-group(opt) endif-line
This clearly only allows a single else-group, th
or
GBM, and the result still works fine. So:
Tested-by: Erik Faye-Lund
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Jan 1, 2014 at 3:57 PM, Lauri Kasanen wrote:
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index 28921be..2c33ddf 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_co
On Fri, Jan 3, 2014 at 4:49 PM, Lauri Kasanen wrote:
> No measurable overhead when off (glxgears within 0.5%).
>
> Signed-off-by: Lauri Kasanen
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 32
> +++
> src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
> src
On Sun, Jan 5, 2014 at 12:42 AM, Maxence Le Doré
wrote:
> From: Maxence Le Doré
Huh, user.email not configured properly?
> static void
> +micro_fma(union tgsi_exec_channel *dst,
> + const union tgsi_exec_channel *src0,
> + const union tgsi_exec_channel *src1,
> + con
On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul wrote:
> Evidently, there's some other definition of "min" and "max" that
> causes MSVC to choke on these function names. Renaming to min2()
> and max2() fixes things.
Wouldn't it be easier to just make sure NOMINMAX is defined before
including any sys
On Tue, Jan 7, 2014 at 3:59 PM, Brian Paul wrote:
> On 01/06/2014 05:22 PM, Erik Faye-Lund wrote:
>>
>> On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul wrote:
>>>
>>> Evidently, there's some other definition of "min" and "max" that
>>&
On Tue, Jan 7, 2014 at 4:11 PM, Brian Paul wrote:
> On 01/07/2014 08:03 AM, Erik Faye-Lund wrote:
>> Why was this pushed out prematurely, then? Reviewing within two hours
>> seems to be reasonable, no?
>
>
> I got Kenneth's R-b so I pushed it. I saw no reason to wait
On Tue, Jan 7, 2014 at 6:46 PM, Maxence Le Doré
wrote:
> Indeed, this patch compiles on linux but may break complilation at
> least on MSVC version < 1400.
> I'm planing to install visual studio 2005 on a ms xp or seven virtual
> machine to check the behavior when compiling in microsoft windows
>
On Wed, Jan 8, 2014 at 6:27 PM, wrote:
> }
> -
> +
> + if (0) {
> + debug_printf(" bbox: (%i, %i) - (%i, %i)\n",
> + bbox.x0, bbox.y0,
> + bbox.x1, bbox.y1);
> + }
> +
> if (!u_rect_test_intersection(&setup->draw_regions[viewport_index],
> &b
On Wed, Jan 8, 2014 at 6:30 PM, wrote:
> From: José Fonseca
>
> This example is very useful to understand the rasterization of lines.
> And with this change, points too.
>
> Adding a key / command-line option to switch modes is left for a future
> opportunity though.
> ---
> src/demos/pixeltest
On Fri, Jan 10, 2014 at 10:33 AM, Lauri Kasanen wrote:
> On Fri, 10 Jan 2014 03:57:45 +0100
> srol...@vmware.com wrote:
>
>> From: Roland Scheidegger
>>
>> OpenGL does whole-point clipping, that is a large point is either fully
>> clipped or fully unclipped (the latter means it may extend beyond
On Wed, Jan 15, 2014 at 7:07 AM, Michel Dänzer wrote:
> On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote:
>> I think the format conversion functions should look like:
>>
>> #ifdef BIG_ENDIAN
>>case PIPE_FORMAT_A8B8G8R8_UNORM:
>> return hw_format_for_R8G8B8A8_UNORM;
>> ...
>> #else
>>
On Fri, Jan 17, 2014 at 9:22 AM, Christian König
wrote:
> But as a general note on writing patches: Please limit the subject line to a
> sane length! Something between 60 and 80 chars should be ok.
Indeed. The regex patterns are nice to have. But please, put them in
the *body* of the commit messa
On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt wrote:
> ---
> src/glsl/opt_algebraic.cpp | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index 6b0d992..4aa49e5 100644
> --- a/src/glsl/opt_algebr
On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt wrote:
> ---
> src/glsl/opt_algebraic.cpp | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index 332f0b7..6b0d992 100644
> --- a/src/glsl/opt_algebraic.cpp
> +++ b/src/glsl
On Mon, Jan 20, 2014 at 5:39 PM, Eric Anholt wrote:
> Erik Faye-Lund writes:
>
>> On Mon, Jan 20, 2014 at 8:18 AM, Eric Anholt wrote:
>>> ---
>>> src/glsl/opt_algebraic.cpp | 36
>>> 1 file changed, 36 inse
On Mon, Jan 27, 2014 at 5:13 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> The caller can use this boolean to parameter to tell the pipe-loader
Boolean to parameter? A superfluous "to", perhaps?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.o
On Tue, May 6, 2014 at 6:51 AM, Patrick McMunn wrote:
> I'm using some older hardware - an ATI Radeon 9200 - which can only handle
> up to OpenGL 1.2. I was wondering if it's possible to use the hardware
> renderer generally and have the driver hand off the handling of functions
> which my video c
On Fri, May 30, 2014 at 9:22 PM, Eric Anholt wrote:
> However, talking yesterday about SSA and vector representations, we
> again failed to come up with anything that sounded compelling -- it
> appears that SSA is going to make obvious optimizations like dead code
> elimination in a vec4 IR harder
2^-64 and the binary version equals
2^+64, let's assume the value in scientific notation is a typo
and implement this using the value from the binary version
instead.
Signed-off-by: Erik Faye-Lund
---
I've also e-mailed NVIDIA's contact as listed in the specification,
but I hav
Signed-off-by: Erik Faye-Lund
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 26 --
1 file changed, 4 insertions(+), 22 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 3d37eaa..96809cd 100644
--- a/src
2^-64 and the binary version equals
2^+64, let's assume the value in scientific notation is a typo
and implement this using the value from the binary version
instead.
Signed-off-by: Erik Faye-Lund
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 4 ++--
src/gallium/docs/source/tgsi.rst
On Thu, Feb 6, 2014 at 5:30 PM, Brian Paul wrote:
> On 02/06/2014 09:09 AM, Erik Faye-Lund wrote:
>>
>> In the specification text of NV_vertex_program1_1, the upper
>> limit of the RCC instruction is written as 1.884467e+19 in
>> scientific notation, but as 0x5F8
On Fri, Feb 7, 2014 at 4:15 PM, Brian Paul wrote:
> On 02/07/2014 05:45 AM, Erik Faye-Lund wrote:
>>
>> Signed-off-by: Erik Faye-Lund
>> ---
>> src/gallium/auxiliary/tgsi/tgsi_exec.c | 26 --
>> 1 file changed, 4 insertions(+), 22 de
On Fri, Feb 7, 2014 at 6:34 AM, Connor Abbott wrote:
> - It turns out that the original advantage of a tree-based IR, to be
> able to automatically generate pattern-matching code for optimizing
> certain code patterns, only really matters for CPU's with weird
> instruction sets with lots of exotic
On Sat, Feb 22, 2014 at 1:34 AM, Ian Romanick wrote:
> On 02/21/2014 03:15 PM, Marek Olšák wrote:
>>
>> The main reason _min exists is that it evaluates each parameter once,
>> while MIN2 evaluates each parameter twice, so in this case, MIN2 calls
>> the get_param function twice, which may not be
On Tue, Feb 25, 2014 at 12:41 AM, Ian Romanick wrote:
> On 02/24/2014 03:36 PM, Roland Scheidegger wrote:
>>
>> Am 25.02.2014 00:00, schrieb Matt Turner:
>>>
>>> ---
>>> src/glsl/opt_algebraic.cpp | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/src/glsl/opt_algebraic.cpp b/src
On Thu, Feb 6, 2014 at 5:09 PM, Erik Faye-Lund wrote:
> In the specification text of NV_vertex_program1_1, the upper
> limit of the RCC instruction is written as 1.884467e+19 in
> scientific notation, but as 0x5F80 in binary. But the binary
> version translates to 1.84467e+19
On Tue, Mar 4, 2014 at 10:12 PM, Emil Velikov wrote:
> There is little gain in printing whenever a folder is created.
>
> Signed-off-by: Emil Velikov
> ---
> src/gallium/auxiliary/Makefile.am | 8
> src/glsl/Makefile.am | 4 ++--
> src/mesa/Makefile.am | 4 ++--
On Tue, Mar 4, 2014 at 10:12 PM, Emil Velikov wrote:
> There is little point in echoing everything that the script does
> to stdout. Wrap it in AM_V_GEN so that a reasonable message is
> printed as a indication of it's invocation.
>
> Signed-off-by: Emil Velikov
> ---
> install-lib-links.mk | 2
On Wed, Mar 5, 2014 at 12:42 PM, Emil Velikov wrote:
> On 05/03/14 10:13, Erik Faye-Lund wrote:
>> On Tue, Mar 4, 2014 at 10:12 PM, Emil Velikov
>> wrote:
>>> There is little point in echoing everything that the script does
>>> to stdout. Wrap it in AM_V_GE
On Mon, Mar 10, 2014 at 11:54 PM, Matt Turner wrote:
> Cuts two instructions out of SynMark's Gl32VSInstancing benchmark.
> ---
> src/glsl/opt_algebraic.cpp | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index 5c49a78..84
On Tue, Mar 11, 2014 at 2:50 PM, Erik Faye-Lund wrote:
> On Mon, Mar 10, 2014 at 11:54 PM, Matt Turner wrote:
>> Cuts two instructions out of SynMark's Gl32VSInstancing benchmark.
>> ---
>> src/glsl/opt_algebraic.cpp | 8
>> 1 file changed, 8 insertion
On Tue, Mar 11, 2014 at 7:27 PM, Eric Anholt wrote:
> Erik Faye-Lund writes:
>
>> On Tue, Mar 11, 2014 at 2:50 PM, Erik Faye-Lund wrote:
>>> On Mon, Mar 10, 2014 at 11:54 PM, Matt Turner wrote:
>>>> Cuts two instructions out of SynMark's Gl32VSInstanc
On Wed, Mar 12, 2014 at 12:00 AM, Eric Anholt wrote:
> Erik Faye-Lund writes:
>
>> On Tue, Mar 11, 2014 at 7:27 PM, Eric Anholt wrote:
>>> Erik Faye-Lund writes:
>>>
>>>> On Tue, Mar 11, 2014 at 2:50 PM, Erik Faye-Lund
>>>> wrote:
>
On Wed, Mar 12, 2014 at 1:32 AM, Eric Anholt wrote:
> Erik Faye-Lund writes:
>
>> On Wed, Mar 12, 2014 at 12:00 AM, Eric Anholt wrote:
>>> Erik Faye-Lund writes:
>>>
>>>> On Tue, Mar 11, 2014 at 7:27 PM, Eric Anholt wrote:
>>>>> Erik
On Fri, Mar 14, 2014 at 7:57 PM, David Heidelberger
wrote:
> ---
> src/gallium/include/pipe/p_config.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/include/pipe/p_config.h
> b/src/gallium/include/pipe/p_config.h
> index d603681..cd6f560 100644
> --- a/src/g
On Tue, Mar 18, 2014 at 3:18 PM, David Heidelberger
wrote:
> Dne 2014-03-18 13:43, Erik Faye-Lund napsal:
>
>> On Fri, Mar 14, 2014 at 7:57 PM, David Heidelberger
>> wrote:
>>>
>>> ---
>>> src/gallium/include/pipe/p_config.h | 2 +-
>>> 1 fi
It seems the subject has a typo, and "ARG" -> "ARB" would be appropriate.
On Wed, Mar 19, 2014 at 10:30 PM, Rafal Mielniczuk
wrote:
> Signed-off-by: Rafal Mielniczuk
> ---
> src/mesa/main/extensions.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/main/extensions.c b/src/mesa
On Fri, Mar 28, 2014 at 8:25 AM, Eric Anholt wrote:
> I was looking at a bug report about old software, and wanted to see what
> development branch a quoted commit was on:
>
> anholt@eliezer:anholt/src/mesa-release% git describe
> 97217a40f97cdeae0304798b607f704deb0c3558
> snb-magic-15797-g97217a
On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev wrote:
> The manual page for glGetAttachedShaders, glGetShaderSource,
> glGetActiveUniform and
> glGetActiveUniform state that a GL_INVALID_VALUE is returned if the maximum
> length
> argument is less than zero. For reference, see:
> https://w
On Mon, Jan 19, 2015 at 1:31 PM, Erik Faye-Lund wrote:
> On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev wrote:
>> The manual page for glGetAttachedShaders, glGetShaderSource,
>> glGetActiveUniform and
>> glGetActiveUniform state that a GL_INVALID_VALUE is re
On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> Fixes the following 2 dEQP tests:
> dEQP-GLES3.functional.shaders.keywords.invalid_identifiers.max_length_vertex
> dEQP-GLES3.functional.shaders.keywords.invalid_identifiers.max_length_fragment
> ---
> src
On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> So far we have only been emitting a warning.
>
> Fixes the following 2 dEQP tests:
> dEQP-GLES3.functional.shaders.arrays.invalid.empty_declaration_without_var_name_vertex
> dEQP-GLES3.functional.shaders.ar
On Tue, Jan 20, 2015 at 3:54 AM, Ian Romanick wrote:
> On 01/19/2015 04:35 AM, Erik Faye-Lund wrote:
>> On Mon, Jan 19, 2015 at 1:31 PM, Erik Faye-Lund wrote:
>>> On Mon, Jan 19, 2015 at 12:32 PM, Eduardo Lima Mitev
>>> wrote:
>>>> The manual page for
On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
> All,
>
> The mesa project has now hit 100 merge requests (36 are still open).
> I (and I'm sure others) would be curious to hear people's initial
> thoughts on the process. What's working well? What's not working?
> Is it total fail an
On Thu, 2019-01-17 at 10:00 +0100, Michel Dänzer wrote:
> On 2019-01-17 8:38 a.m., Erik Faye-Lund wrote:
> > 3. There's some browsing-pain with the commit list. For instance, I
> > always second-guess if the latest commit is at the top or bottom.
>
> At the top, same a
On Thu, 2019-01-17 at 14:37 +, Daniel Stone wrote:
> Hi,
>
> On Thu, 17 Jan 2019 at 07:38, Erik Faye-Lund
> wrote:
> > 1. New MRs should probably get their cover-letter automatically
> > sent to
> > the mailing list for incrased visibility.
> >
> >
> Currently this is done via MAX_OFFSETS constant, although a better
> solution is in the works.
>
> v2: add FramebufferTexture2DMultisampleEXT
> v3: add MAX_OFFSETS guard
>
> Signed-off-by: Emil Velikov
> Reviewed-by: Erik Faye-Lund (v1)
Consider this version also:
Revi
r drivers that support
transform feedback."
I also think this should have a Fixes tag:
Fixes: d644698b443 ("gallium: Add the ability to query a single
pipeline statistics counter")
With those things changed:
Reviewed-by: Erik Faye-Lund
Also, I added Kenneth Grauke who wr
Sending MRs from the main Mesa repository increase clutter in the
repository, and decrease visibility of project-wide branches. So it's
better if MRs are sent from forks instead.
Let's add a note about this, in case its not obvious to everyone.
Signed-off-by: Erik Faye-Lund
On Thu, 2019-01-17 at 08:38 +0100, Erik Faye-Lund wrote:
> On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
> > All,
> >
> > The mesa project has now hit 100 merge requests (36 are still
> > open).
> > I (and I'm sure others) would be curious to hea
On Wed, 2019-01-23 at 10:14 +, Daniel Stone wrote:
> Hi,
>
> On Wed, 23 Jan 2019 at 10:09, Eric Engestrom <
> eric.engest...@intel.com> wrote:
> > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > > Sending MRs from the main Mesa r
On Wed, 2019-01-23 at 10:08 +, Eric Engestrom wrote:
> On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > Sending MRs from the main Mesa repository increase clutter in the
> > repository, and decrease visibility of project-wide branches. So
> > it's
On Wed, 2019-01-23 at 10:42 +, Eric Engestrom wrote:
> On Wednesday, 2019-01-23 11:21:27 +0100, Erik Faye-Lund wrote:
> > On Wed, 2019-01-23 at 10:14 +, Daniel Stone wrote:
> > > Hi,
> > >
> > > On Wed, 23 Jan 2019 at 10:09, Eric Engestrom <
On Wed, 2019-01-23 at 17:03 +, Emil Velikov wrote:
> Hi all,
>
> In case the patch is still outstanding, feel free to add
> Reviewed-by: Emil Velikov
>
Thanks, pushed.
> On Wed, 23 Jan 2019 at 11:20, Erik Faye-Lund
> wrote:
> > On Wed, 2019-01-23 at 10:42
On Wed, 2019-01-23 at 14:47 +, Eric Engestrom wrote:
> On Thursday, 2019-01-17 15:55:44 +0100, Erik Faye-Lund wrote:
> > It could have been made obvious for instance by showing the commit-
> > graph next to the commit-list, decorating it with the branch head
> > in
On Fri, 2019-01-25 at 13:41 -0800, Eric Anholt wrote:
> Nick Kreeger writes:
>
> > The OES_texture* extensions for float and half-float are valid when
> > GLES2 is present w/ the matching
> > OES_texture_float/OES_texture_half_float extensions. This fix
> > ensures
> > that these formats are vali
On Mon, 2019-01-28 at 09:22 -0800, Eric Anholt wrote:
> Erik Faye-Lund writes:
>
> > On Fri, 2019-01-25 at 13:41 -0800, Eric Anholt wrote:
> > > Nick Kreeger writes:
> > >
> > > > The OES_texture* extensions for float and half-float are valid
&g
On Mon, 2019-01-28 at 09:31 -0800, Matt Turner wrote:
> Use the trick of adding and then subtracting 2**52 (52 is the number
> of
> explicit mantissa bits a double-precision floating-point value has)
> to
> implement round-to-even.
>
> Cuts the number of instructions on SKL of the piglit test
> fs
On Mon, 2019-01-28 at 17:20 -0500, Rob Clark wrote:
> On Mon, Jan 28, 2019 at 2:29 PM Ilia Mirkin
> wrote:
> > 2. I've seen a bunch of things land where I would have had comments
> > beforehand. Once the patch is in, I don't really have an easy way
> > to
> > provide feedback. In the past if such
On Tue, 2019-01-29 at 14:41 +, Roland Scheidegger wrote:
> Am 29.01.19 um 10:10 schrieb Erik Faye-Lund:
> > On Mon, 2019-01-28 at 09:31 -0800, Matt Turner wrote:
> > > Use the trick of adding and then subtracting 2**52 (52 is the
> > > number
> > > of
&
On Wed, 2019-01-30 at 12:32 -0500, Marek Olšák wrote:
> ping
>
Probably worth including Keith, who added this line...
But yeah, I tend to think that this makes sense. The autotools-build
doesn't seem to tie this to a specific version, and seems to have been
used without problems for almost a yea
>
> Ok. I use old xcb-xrandr on some of my systems, one of them used to
> be my main system. Not being able to use meson on those systems
> without this patch is a big deal for me.
This sounds like you have indeed tested on xcb-randr < 1.12, so I
suppose the answer to the quest
On Tue, 2019-02-05 at 06:26 +, Alyssa Rosenzweig wrote:
> In addition to the DRM interface in active development, for legacy
> kernels Panfrost has a small, optional, out-of-tree glue repository.
> For
> various reasons, this legacy code should not be included in Mesa
> proper,
> but this commi
Reviewed-by: Erik Faye-Lund
And just for the record, I think this is the right "compromise" between
checking all possible formats and facilitating fallbacks.
On Tue, 2019-02-12 at 22:40 -0500, Ilia Mirkin wrote:
> If the driver supports PIPE_BIND_BLENABLE on RGBA32F, flip
> EX
On Thu, 2019-02-14 at 08:53 +1000, Dave Airlie wrote:
> On Thu, 14 Feb 2019 at 06:04, Stéphane Marchesin
> wrote:
> > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > tournier.e...@gmail.com> wrote:
> > >
> > >
> > > On Wednesday, 13 February 2019, Stéphane Marchesin <
> > > stephane.marche.
On Wed, 2019-02-13 at 11:53 -0800, Ian Romanick wrote:
> On 2/13/19 9:59 AM, Juan A. Suarez Romero wrote:
> > On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote:
> > > On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote:
> > > > On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> > > > > On 2/1
On Thu, 2019-02-14 at 16:25 +0100, Gert Wollny wrote:
> > > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > > > tournier.e...@gmail.com> wrote:
> [...]
> > > > > A solution would be to inline the
> > > > > function in GLSL but I'm scared than the following shader
> > > > > will
> > > > > be
Yeah, good move!
Reivewed-by: Erik Faye-Lund
On Mon, 2019-02-25 at 11:57 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Mention the tick-box otherwise only the MR author can rebase the
> series.
>
> Cc: Jordan Justen
> Cc: Dylan Baker
> Cc: Erik Faye-Lu
101 - 200 of 768 matches
Mail list logo
