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 |
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
https://bugs.freedesktop.org/show_bug.cgi?id=85419
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
Summary|As
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
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
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
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
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
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 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 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
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 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
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 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
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 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
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
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
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
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
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 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: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 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 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 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 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,..
32 matches
Mail list logo
