On 11/08/2014 10:30 AM, Matt Turner wrote:
On Fri, Nov 7, 2014 at 10:43 PM, Siavash Eliasi wrote:
This will remove the need for unnecessary runtime checks for CPU features if
already supported by target CPU, resulting in smaller and less branchy code.
---
src/mesa/x86/common_x86_features.h |
On Fri, Nov 7, 2014 at 10:43 PM, Siavash Eliasi wrote:
> This will remove the need for unnecessary runtime checks for CPU features if
> already supported by target CPU, resulting in smaller and less branchy code.
> ---
> src/mesa/x86/common_x86_features.h | 25 +
> 1 file
This will remove the need for unnecessary runtime checks for CPU features if
already supported by target CPU, resulting in smaller and less branchy code.
---
src/mesa/x86/common_x86_features.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/src/mesa/x86/common_x86_fe
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Nov 7, 2014 at 8:57 PM, Connor Abbott wrote:
> FWIW, Ian commented on my patch to add foreach_list_typed_reverse that
> we shouldn't merge it until it had users so people wouldn't try to
> remove it -- it seems like this has the same issue. So either merge
> both of them at the same time,
FWIW, Ian commented on my patch to add foreach_list_typed_reverse that
we shouldn't merge it until it had users so people wouldn't try to
remove it -- it seems like this has the same issue. So either merge
both of them at the same time, or neither until NIR gets merged...
Connor
On Fri, Nov 7, 2
On 11/07/2014 10:56 PM, Matt Turner wrote:
On Fri, Nov 7, 2014 at 12:31 AM, Siavash Eliasi wrote:
Being more strict about pushing and quality assurance of these kind of
patches will save hours of bisecting and hair-pulling to find the root cause
of performance degrades.
You say this as if it
Sounds okay to me, thanks!
Best regards,
Siavash Eliasi.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, 2014-10-29 at 19:00 +, Emil Velikov wrote:
> On 27/10/14 21:03, Jan Vesely wrote:
> > On Mon, 2014-10-27 at 20:22 +, Emil Velikov wrote:
> >> On 27/10/14 18:05, Jan Vesely wrote:
> >>> On Mon, 2014-10-27 at 02:24 +, Emil Velikov wrote:
> On 26/10/14 19:36, Jan Vesely wrote:
---
src/glsl/list.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index 1d18ec9..1fb9178 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -673,4 +673,13 @@ inline void exec_node::insert_before(exec_list *before)
__node = __next, __next
Ian Romanick writes:
> On 11/06/2014 06:16 PM, Michel Dänzer wrote:
>> On 06.11.2014 19:18, Joonas Lahtinen wrote:
>>> On to, 2014-11-06 at 18:12 +0900, Michel Dänzer wrote:
On 05.11.2014 20:14, Joonas Lahtinen wrote:
>
> Modified not refer to DRI3, just uses the present extension to
https://bugs.freedesktop.org/show_bug.cgi?id=86025
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=86025
Bug ID: 86025
Summary: src\glsl\list.h(535) : error C2143: syntax error :
missing ';' before 'type'
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=76252
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
> I guess ideally you'd generate code which actually clamps to the max int
value representable instead
Yes, that would be more complex to generate.
Jose
From: Roland Scheidegger
Sent: 07 November 2014 21:40
To: Jose Fonseca; mesa-dev@lists.freedesktop.or
Looks good to me though I barely understand the code there...
I guess ideally you'd generate code which actually clamps to the max int
value representable instead, but that probably would get even more messy
(something like:
val = MAX(src[0], -2147483648.0f)
if (src[0] >= 2147483648.0f) val = 21474
From: José Fonseca
Use clamping constants that guarantee no integer overflows.
As spotted by Chris Forbes.
This causes the code to change as:
- value |= (uint32_t)CLAMP(src[0], 0.0f, 4294967295.0f);
+ value |= (uint32_t)CLAMP(src[0], 0.0f, 4294967040.0f);
- value |= (u
On Fri, Nov 7, 2014 at 12:31 AM, Siavash Eliasi wrote:
> Being more strict about pushing and quality assurance of these kind of
> patches will save hours of bisecting and hair-pulling to find the root cause
> of performance degrades.
You say this as if it has happened...?
Pekka Paalanen writes:
> On Thu, 06 Nov 2014 13:01:03 -0800
> Ian Romanick wrote:
>
>> I thought Eric and Chad already NAKed it in bugzilla. The problem is
>> that applications ask for an RGBA visual for GL blending. They use the
>> alpha channel to generate their images, but the final alpha v
On Friday, November 07, 2014 06:52:59 PM Neil Roberts wrote:
> In order to detect whether the predicate source registers can be used in a
> later patch we will need to know the version number for the command parser.
> This patch just adds a member to intel_screen and does an ioctl to get the
> vers
In order to detect whether the predicate source registers can be used in a
later patch we will need to know the version number for the command parser.
This patch just adds a member to intel_screen and does an ioctl to get the
version.
---
src/mesa/drivers/dri/i965/intel_screen.c | 7 +++
src/m
Previously whenever a primitive is drawn the driver would call
_mesa_check_conditional_render which blocks waiting for the result of the
query to determine whether to render. On Gen7+ there is a bit in the
3DPRIMITIVE command which can be used to disable the primitive based on the
value of a state
On Friday, November 07, 2014 12:01:20 PM Siavash Eliasi wrote:
> I know that this might sound troublesome but since there is no
> benchmarks done by reviewers before pushing the performance optimization
> oriented patches into master branch, I think it's as important as piglit
> tests and necess
On Friday, November 07, 2014 01:52:13 PM Marek Olšák wrote:
> On Fri, Nov 7, 2014 at 1:10 PM, Steven Newbury
wrote:
> > On Wed, 2014-11-05 at 00:46 +, Emil Velikov wrote:
> >> On 04/11/14 22:42, Marek Olšák wrote:
> >> > Hi everybody,
> >> >
> >> > I'm about to address this long-standing issu
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #53 from Jason Ekstrand ---
(In reply to Samuel Iglesias from comment #52)
> (In reply to Jason Ekstrand from comment #51)
> > (In reply to Samuel Iglesias from comment #48)
> > > (In reply to Jason Ekstrand from comment #34)
> > > >
On 11/07/2014 07:31 PM, Ian Romanick wrote:
On 11/07/2014 06:09 AM, Siavash Eliasi wrote:
On 11/07/2014 03:14 PM, Steven Newbury wrote:
On Thu, 2014-11-06 at 21:00 -0800, Matt Turner wrote:
On Thu, Nov 6, 2014 at 8:56 PM, Siavash Eliasi <
siavashser...@gmail.com> wrote:
Then I do recommend r
Reviewed-by: Roland Scheidegger
Am 07.11.2014 um 17:52 schrieb jfons...@vmware.com:
> From: José Fonseca
>
> On Windows, DllMain calls and thread creation/destruction are
> serialized, so when llvmpipe is destroyed from DllMain waiting for the
> rasterizer threads to finish will deadlock.
>
>
From: José Fonseca
On Windows, DllMain calls and thread creation/destruction are
serialized, so when llvmpipe is destroyed from DllMain waiting for the
rasterizer threads to finish will deadlock.
So, instead of waiting for rasterizer threads to have finished, simply wait for
the
rasterizer thre
On 5 November 2014 04:44, Matt Turner wrote:
I tried to reproduce this today and couldn't.
(...)
>>> Thanks. Maybe you could give a little more information, like an error
>>> message or something?
>>
>> Same error as Thierry reported in this thread in August:
>
> Unfortunately Thierry's was
Then I do recommend removing the "if (cpu_has_sse4_1)" from this patch
and similar places, because there is no runtime CPU dispatching
happening for SSE optimized code paths in action and just adds extra
overhead (unnecessary branches) to the generated code.
Same must be applied to these patch
https://bugs.freedesktop.org/show_bug.cgi?id=54080
Eero Tamminen changed:
What|Removed |Added
CC||eero.t.tammi...@intel.com
--
You are re
Ah yes I forgot about that, even though I have fixed this same problem
elsewhere in the past...
It is indeed an annoying problem, luckily only affects 32bit numbers.
Am 07.11.2014 um 16:35 schrieb Jose Fonseca:
> Great point.
>
>
> The source values, src[], are already in floating point, so it's
On 11/07/2014 06:09 AM, Siavash Eliasi wrote:
>
> On 11/07/2014 03:14 PM, Steven Newbury wrote:
>> On Thu, 2014-11-06 at 21:00 -0800, Matt Turner wrote:
>>> On Thu, Nov 6, 2014 at 8:56 PM, Siavash Eliasi <
>>> siavashser...@gmail.com> wrote:
Then I do recommend removing the "if (cpu_has_sse4_
Surprising indeed...
Reviewed-by: Roland Scheidegger
Am 07.11.2014 um 15:32 schrieb jfons...@vmware.com:
> From: José Fonseca
>
> This commit causes the generated C code to change as
>
> union util_format_r32g32b32a32_sscaled pixel;
> - pixel.chan.r = (int32_t)CLAMP(src[
Great point.
The source values, src[], are already in floating point, so it's OK not to
represent 2147483647 exactly, however, if the compiler 2147483647.0f upwards to
2147483648 then indeed the clamping won't work properly, as 2147483648 will
overflow when converted to int32.
I've confirmed
Previously whenever a primitive is drawn the driver would call
_mesa_check_conditional_render which blocks waiting for the result of the
query to determine whether to render. On Gen7+ there is a bit in the
3DPRIMITIVE command which can be used to disable the primitive based on the
value of a state
On Fri Nov 7 14:09:09 2014 GMT, Siavash Eliasi wrote:
>
> On 11/07/2014 03:14 PM, Steven Newbury wrote:
> > On Thu, 2014-11-06 at 21:00 -0800, Matt Turner wrote:
> >> On Thu, Nov 6, 2014 at 8:56 PM, Siavash Eliasi <
> >> siavashser...@gmail.com> wrote:
> >>> Then I do recommend removing the "if (c
A possible wrinkle here is that 2147483647 isn't exactly representable
as a float (the adjacent floats are 2147483520 and 2147483648). Is the
clamp actually doing the right thing at the top end?
On Sat, Nov 8, 2014 at 3:32 AM, wrote:
> From: José Fonseca
>
> This commit causes the generated C c
https://bugs.freedesktop.org/show_bug.cgi?id=61312
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: José Fonseca
This commit causes the generated C code to change as
union util_format_r32g32b32a32_sscaled pixel;
- pixel.chan.r = (int32_t)CLAMP(src[0], -2147483648, 2147483647);
- pixel.chan.g = (int32_t)CLAMP(src[1], -2147483648, 2147483647);
- pi
On 11/07/2014 03:14 PM, Steven Newbury wrote:
On Thu, 2014-11-06 at 21:00 -0800, Matt Turner wrote:
On Thu, Nov 6, 2014 at 8:56 PM, Siavash Eliasi <
siavashser...@gmail.com> wrote:
Then I do recommend removing the "if (cpu_has_sse4_1)" from this
patch and similar places, because there is no ru
On Fri, Nov 7, 2014 at 1:10 PM, Steven Newbury wrote:
> On Wed, 2014-11-05 at 00:46 +, Emil Velikov wrote:
>> On 04/11/14 22:42, Marek Olšák wrote:
>> > Hi everybody,
>> >
>> > I'm about to address this long-standing issue: The EGL state
>> > tracker is redundant. It duplicates what st/dri doe
On Fri, 2014-11-07 at 11:44 +, Steven Newbury wrote:
> On Thu, 2014-11-06 at 21:00 -0800, Matt Turner wrote:
> > On Thu, Nov 6, 2014 at 8:56 PM, Siavash Eliasi <
> > siavashser...@gmail.com> wrote:
> > > Then I do recommend removing the "if (cpu_has_sse4_1)" from this
> > > patch and similar p
V2:
- remove unrequired #ifdef bit_SSSE3
- order flag check in config
Signed-off-by: Timothy Arceri
---
configure.ac | 6 ++
src/mesa/x86/common_x86.c | 2 ++
src/mesa/x86/common_x86_features.h | 4 +++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --
Callgrind cpu usage results from pts benchmarks:
For ytile_copy_faster()
Nexuiz 1.6.1: 2.16% -> 1.20%
V2:
- put back the if statements and add one for the SSSE3 rgba8_copy
- move some header files out of the header
- don't indent the preprocessor tests
- changed copyright to Google and add autho
On Wed, 2014-11-05 at 00:46 +, Emil Velikov wrote:
> On 04/11/14 22:42, Marek Olšák wrote:
> > Hi everybody,
> >
> > I'm about to address this long-standing issue: The EGL state
> > tracker is redundant. It duplicates what st/dri does and it also
> > duplicates what the common loader egl_dri
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #52 from Samuel Iglesias ---
(In reply to Jason Ekstrand from comment #51)
> (In reply to Samuel Iglesias from comment #48)
> > (In reply to Jason Ekstrand from comment #34)
> > > (In reply to Samuel Iglesias from comment #33)
> > > >
On Thu, 2014-11-06 at 19:30 -0500, Frank Henigman wrote:
> I tested your patch with the "teximage" program in mesa demos, the
> same thing I used to benchmark when I developed this code.
> As Matt and Chad point out, the odd-looking _faster functions are
> there for a reason. Your change causes a
On Thu, 2014-11-06 at 21:00 -0800, Matt Turner wrote:
> On Thu, Nov 6, 2014 at 8:56 PM, Siavash Eliasi <
> siavashser...@gmail.com> wrote:
> > Then I do recommend removing the "if (cpu_has_sse4_1)" from this
> > patch and similar places, because there is no runtime CPU
> > dispatching happening f
On Thu, 2014-11-06 at 14:39 -0800, Matt Turner wrote:
> On Thu, Nov 6, 2014 at 2:33 PM, Marc Dietrich
> wrote:
> > So this is only a problem with Link-Time-Opt.
>
> I don't actually know how you're getting to this point in the build
> with LTO. It fails for me in src/mapi.
>
> I think LTO is s
https://bugs.freedesktop.org/show_bug.cgi?id=85918
--- Comment #7 from José Fonseca ---
(In reply to Emil Velikov from comment #2)
> Roland,
> Can we encourage "newcomers" to use MSVC 2013 and later (if ever available)
> ? This way once you guys (and others) are over to 2013 we can just go with -
Patch adds additional validation for GLSL ES 1.00 that specifies
cross stage variance requirements for a set of specified builtins.
Fixes failures in WebGL conformance test 'shaders-with-invariance'.
Signed-off-by: Tapani Pälli
---
src/glsl/linker.cpp | 43 ++
clCompileProgram should return CL_INVALID_COMPILER_OPTIONS
instead of CL_INVALID_BUILD_OPTIONS
---
src/gallium/state_trackers/clover/api/program.cpp | 2 ++
src/gallium/state_trackers/clover/llvm/invocation.cpp | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/s
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 3a4fcf0..d29f5a6 100644
--- a/src/gallium/state_t
When I added clCompileProgram, I forgot to made the change to
trigger CL_INVALID_COMPILER_OPTIONS instead of CL_INVALID_BUILD_OPTIONS
when invalid option are pass to compiler.
This have been catched by the yet to be reviewed Pigilt test
The first patch remove some spaces inconsistency in
llvm/invo
On Fri, Nov 7, 2014 at 1:07 AM, Thierry Vignaud
wrote:
> On 5 November 2014 04:44, Matt Turner wrote:
>I tried to reproduce this today and couldn't.
>
> (...)
>
Thanks. Maybe you could give a little more information, like an error
message or something?
>>>
>>> Same error as Thierry
I know that this might sound troublesome but since there is no
benchmarks done by reviewers before pushing the performance optimization
oriented patches into master branch, I think it's as important as piglit
tests and necessary to ask the patch provider for simple OpenGL micro
benchmarks trigg
On Thu, 06 Nov 2014 13:01:03 -0800
Ian Romanick wrote:
> I thought Eric and Chad already NAKed it in bugzilla. The problem is
> that applications ask for an RGBA visual for GL blending. They use the
> alpha channel to generate their images, but the final alpha values are,
> basically, random...
58 matches
Mail list logo
