On Sun, 2014-11-09 at 07:48 +0330, Siavash Eliasi wrote:
> I know that's a time saver for developer (gcc function multi
> versioning), however I still do prefer the approach (my own ^^ ) which
> works on all setups regardless of hardware and compiler (well, any sane
> compiler ICC, GCC, Clang,..
On Monday, November 03, 2014 01:34:49 PM Matt Turner wrote:
> Improves 359 shaders by >=10%
> 114 shaders by >=20%
> 91 shaders by >=30%
> 82 shaders by >=40%
> 22 shaders by >=50%
>4 shaders by >=60%
>2 shaders by >=80%
>
> total inst
On Monday, November 03, 2014 01:34:48 PM Matt Turner wrote:
> ---
> .../drivers/dri/i965/brw_vec4_live_variables.cpp | 28
++
> .../drivers/dri/i965/brw_vec4_live_variables.h | 5
> 2 files changed, 33 insertions(+)
Patch 1 is:
Reviewed-by: Kenneth Graunke
signa
On Monday, November 03, 2014 11:58:06 AM Matt Turner wrote:
> Dead code elimination now handles this.
> ---
> Depends on the previously sent 5 patch series.
Nice!
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
On Wednesday, October 29, 2014 02:10:13 PM Matt Turner wrote:
> Also while we're touching var_from_reg, just make it an inline function.
> ---
> src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 8
> src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp | 14
--
On Wednesday, October 29, 2014 03:58:13 PM Matt Turner wrote:
> On Wed, Oct 29, 2014 at 2:10 PM, Matt Turner wrote:
> > ---
> > .../drivers/dri/i965/brw_fs_live_variables.cpp | 35
++
> > src/mesa/drivers/dri/i965/brw_fs_live_variables.h | 5
> > 2 files changed, 4
On Wednesday, October 29, 2014 02:10:12 PM Matt Turner wrote:
> Most prominently helps Natural Selection 2, which has a surprising
> number shaders that do very complicated things before drawing black.
>
> instructions in affected programs: 23824 -> 19570 (-17.86%)
> ---
> .../dri/i965/brw_fs
On Sun, 2014-11-09 at 08:59 +1100, Timothy Arceri wrote:
> On Sat, 2014-11-08 at 18:13 +, Emil Velikov wrote:
> > On 08/11/14 11:12, Timothy Arceri wrote:
> > > Signed-off-by: Timothy Arceri
> > As long as it fixes odd combinations such as this the following I'm all
> > in favour of using such
Or we might end up where automatically enable the build, only to error
out a couple of lines after that.
Cc: Christian König
Signed-off-by: Emil Velikov
---
configure.ac | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index fc7d372..d0
Set a single VL_{CFLAG,LIBS} for xcb and friends, and let each target
check for it's relevant library alone. Required as with follow up
commits we'll build aux/vl into a separate module, which needs VL_CFLAGS
Cleanup add a couple of explicit LIBDRM_LIBS linking, as aux/vl itself
requires libdrm, d
Hello all,
Here is a reworked version of a patch I've send a while back - it
creates a stub for the vl functions used directly by the gallium
drivers. At link time we use it for non-vl targets, while for vdpau and
friends we use a galliumvl static lib, which is split out of auxiliary.
Resulting
Will be used by the non-VL targets, to stub out the functions called
by the drivers. The entry point to those are within the VL
state-trackers, yet the compiler cannot determine that at link time.
Thus we'll need to stub them out to prevent unresolved symbols in the
dri, egl, gbm and pipe-loader ta
Rather than shoving all the VL code for non-VL targets, increasing
their size, just split it out and use it when needed. This gives us
the side effect of building vl_winsys_dri.c once, dropping a few
automake warnings, and reducing the size of the dri modules as below
textdata bss d
With follow up commit we'll split vl static lib from the auxiliary one,
and choose the appropriate vl (galliumvl or galliumvl_stub) for the
respective targets to link against.
Cc: Christian König
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/Android.mk | 4 +++-
src/gallium/auxil
On 11/08/2014 09:55 PM, Emil Velikov wrote:
A comment I could not withheld based on your earlier post - "We require
micro-benchmark for this code. It will take me hours to find why mesa is
so slow now :P"
Which brings the question why didn't you post to that thread/topic in
first place instea
I know that's a time saver for developer (gcc function multi
versioning), however I still do prefer the approach (my own ^^ ) which
works on all setups regardless of hardware and compiler (well, any sane
compiler ICC, GCC, Clang,...).
Best regards,
Siavash Eliasi.
_
On Sat, 2014-11-08 at 18:25 +, Emil Velikov wrote:
> On 08/11/14 08:35, 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.
> >
> A comment I could not withheld b
On 06/11/14 21:29, Frank Henigman wrote:
> From: Frank Henigman
>
> Dri driver libs are not linked to pull in libglapi so gbm_create_device()
> fails when it tries to dlopen them (unless the application is linked
> with something that does pull in libglapi, like libGL).
> Until dri drivers can be
On Sat, 2014-11-08 at 16:29 +0330, Siavash Eliasi wrote:
> I rather to not use compiler specific hacks in mesa. If it was a
> personal pet project it would make sense.
>
> Best regards,
> Siavash Eliasi.
Having to work around compiler differences is a real world problem. As
has been pointed out
Requires evergreen/cayman, and updated radeon kernel module.
Signed-off-by: Glenn Kennard
---
See also kernel side patch sent to dri-de...@lists.freedesktop.org
docs/GL3.txt | 4 +-
docs/relnotes/10.4.html | 1 +
src/gallium/drivers/r600/ev
On Sat, 2014-11-08 at 18:13 +, Emil Velikov wrote:
> On 08/11/14 11:12, Timothy Arceri wrote:
> > Signed-off-by: Timothy Arceri
> As long as it fixes odd combinations such as this the following I'm all
> in favour of using such an approach. It will save us quite a few
> "lovely" details - spli
On 08/11/14 08:35, 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.
>
A comment I could not withheld based on your earlier post - "We require
micro-benchmark for this
On 08/11/14 11:12, Timothy Arceri wrote:
> Signed-off-by: Timothy Arceri
As long as it fixes odd combinations such as this the following I'm all
in favour of using such an approach. It will save us quite a few
"lovely" details - split the file, configure checks etc...
https://bugs.freedesktop.org
On Sat, Nov 8, 2014 at 4:59 AM, Siavash Eliasi wrote:
> I rather to not use compiler specific hacks in mesa. If it was a personal
> pet project it would make sense.
We use compiler-specific things all the time. That's not going to change.
___
mesa-dev m
Mesa 10.3.3 has been released. Mesa 10.3.3 is a bug fix release
fixing bugs since the 10.3.2 release, (see below for a list of
changes).
The tag in the git repository for Mesa 10.3.3 is 'mesa-10.3.3'.
Mesa 10.3.3 is available for download at
ftp://freedesktop.org/pub/mesa/10.3.3/
SHA-256 checksu
I rather to not use compiler specific hacks in mesa. If it was a
personal pet project it would make sense.
Best regards,
Siavash Eliasi.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Callgrind cpu usage results from pts benchmarks:
For ytile_copy_faster()
Nexuiz 1.6.1: 2.48% -> 0.97%
V3:
- rather than putting the ssse3 code in a different file
in order to compile make use of gcc pragma for per
function optimisations. Results in improved performace and less
impact on those
Signed-off-by: Timothy Arceri
---
src/mesa/x86/x86_function_opt.h | 42 +
1 file changed, 42 insertions(+)
create mode 100644 src/mesa/x86/x86_function_opt.h
Using a macro like this means we can easily enable runtime support in clang
once it also suppor
V3:
- remove flag check from config
V2:
- remove unrequired #ifdef bit_SSSE3
- order flag check in config
Signed-off-by: Timothy Arceri
---
src/mesa/x86/common_x86.c | 2 ++
src/mesa/x86/common_x86_features.h | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/m
https://bugs.freedesktop.org/show_bug.cgi?id=85419
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
Summary|As
On Fri, 07 Nov 2014 11:32:04 -0800
Eric Anholt wrote:
> 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 us
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.
V2:
- Removed the SSSE3 related part for the not yet merged patch.
- Avoiding redefinition of macros.
---
src/mesa/x86/common_x86_features.h |
32 matches
Mail list logo
