Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

2016-11-14 Thread Jose Fonseca

On 10/11/16 17:27, Kyriazis, George wrote:




-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Thursday, November 10, 2016 8:14 AM
To: Kyriazis, George <george.kyria...@intel.com>
Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
Subject: Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

"gallium/targets: scons: wire swr support for libgl-gdi/libgl-xlib/osmesa"

... or alike ?


+import SCons.Script.SConscript
+



+if 'swr' in SCons.Script.ARGUMENTS and

SCons.Script.ARGUMENTS['swr']:
With the "move this to top level" suggestion this will read roughly as

if env['swr']:


The command line variables, however (like swr=1) are not part of the 
environment.  Even then, env['swr'] would fail for non-swr builds, since 'swr' 
is not in the env dictionary.  This works for env['llvm'] sincellvm.py 
initially sets it to False.  So, it will still be a 2-level test:   if 'swr' in 
env and env['swr']:, which is not a simplication really.

Is your point to move it to the environment, or to do a one-check test?

Thanks,

George


-Emil

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev




What you need is this:


diff --git a/common.py b/common.py
index fb0884e..179170b 100644
--- a/common.py
+++ b/common.py
@@ -110,5 +110,6 @@ def AddOptions(opts):
 opts.Add(BoolOption('texture_float',
 'enable floating-point textures and 
renderbuffers',

 'no'))
+opts.Add(BoolOption('swr', 'Build SWR', 'no'))
 if host_platform == 'windows':
 opts.Add('MSVC_VERSION', 'Microsoft Visual C/C++ version')

Then swr should always be part of the environment.


Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

2016-11-11 Thread Emil Velikov
On 10 November 2016 at 20:42, Emil Velikov  wrote:
> On 10 November 2016 at 20:18, Kyriazis, George
>  wrote:
>> Emil,
>>
>> I've followed the approach of trying to localize the swr changes to where 
>> they belong in order to avoid "polluting" upper-level files.  If you're 
>> talking about modifying some of the files in the scons/ directory, I don't 
>> see a place where swr fits in, conceptually.
>>
> Yes that's what I was thinking/mentioned - shove the lot to scons/*
> but haven't looked to closely were exactly.
> Jose any ideas ?
>
>> I do agree that using the full SCons.Script.ARGUMENTS is clunky, but I don't 
>> want to pollute top-level files with driver-specific things (swr in this 
>> case).
>>
>> Thoughts?
>>
> As long as Jose is happy with adding/using SCons.Script.ARGUMENTS for
> swr, it's all good.
>
In case I wasn't clear - don't let this [suggestions on how to make it
"perfect"] block any of your work. It's just an idea.

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

2016-11-10 Thread Emil Velikov
On 10 November 2016 at 20:18, Kyriazis, George
 wrote:
> Emil,
>
> I've followed the approach of trying to localize the swr changes to where 
> they belong in order to avoid "polluting" upper-level files.  If you're 
> talking about modifying some of the files in the scons/ directory, I don't 
> see a place where swr fits in, conceptually.
>
Yes that's what I was thinking/mentioned - shove the lot to scons/*
but haven't looked to closely were exactly.
Jose any ideas ?

> I do agree that using the full SCons.Script.ARGUMENTS is clunky, but I don't 
> want to pollute top-level files with driver-specific things (swr in this 
> case).
>
> Thoughts?
>
As long as Jose is happy with adding/using SCons.Script.ARGUMENTS for
swr, it's all good.

Thanks !
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

2016-11-10 Thread Kyriazis, George
Emil,

I've followed the approach of trying to localize the swr changes to where they 
belong in order to avoid "polluting" upper-level files.  If you're talking 
about modifying some of the files in the scons/ directory, I don't see a place 
where swr fits in, conceptually.

I do agree that using the full SCons.Script.ARGUMENTS is clunky, but I don't 
want to pollute top-level files with driver-specific things (swr in this case).

Thoughts?

George

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Thursday, November 10, 2016 12:13 PM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver
> 
> On 10 November 2016 at 17:27, Kyriazis, George <george.kyria...@intel.com>
> wrote:
> >> -Original Message-
> >> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> >> Sent: Thursday, November 10, 2016 8:14 AM
> >> To: Kyriazis, George <george.kyria...@intel.com>
> >> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> >> Subject: Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver
> >>
> >> "gallium/targets: scons: wire swr support for libgl-gdi/libgl-xlib/osmesa"
> >>
> >> ... or alike ?
> >>
> >> > +import SCons.Script.SConscript
> >> > +
> >>
> >> > +if 'swr' in SCons.Script.ARGUMENTS and
> >> SCons.Script.ARGUMENTS['swr']:
> >> With the "move this to top level" suggestion this will read roughly
> >> as
> >>
> >> if env['swr']:
> >>
> > The command line variables, however (like swr=1) are not part of the
> environment.  Even then, env['swr'] would fail for non-swr builds, since 'swr'
> is not in the env dictionary.  This works for env['llvm'] sincellvm.py 
> initially
> sets it to False.  So, it will still be a 2-level test:   if 'swr' in env and 
> env['swr']:,
> which is not a simplication really.
> >
> > Is your point to move it to the environment, or to do a one-check test?
> >
> To consolidate the 'clunky' SCons.Script.ARGUMENTS + requirements [only
> llvm?] checking in a single place. Thus the [newly added in the env 
> dictionary]
> swr can be used throughout without even import(ing)
> SCons.Script.SConscript.
> 
> Thanks !
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

2016-11-10 Thread Emil Velikov
On 10 November 2016 at 17:27, Kyriazis, George
<george.kyria...@intel.com> wrote:
>> -Original Message-
>> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>> Sent: Thursday, November 10, 2016 8:14 AM
>> To: Kyriazis, George <george.kyria...@intel.com>
>> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
>> Subject: Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver
>>
>> "gallium/targets: scons: wire swr support for libgl-gdi/libgl-xlib/osmesa"
>>
>> ... or alike ?
>>
>> > +import SCons.Script.SConscript
>> > +
>>
>> > +if 'swr' in SCons.Script.ARGUMENTS and
>> SCons.Script.ARGUMENTS['swr']:
>> With the "move this to top level" suggestion this will read roughly as
>>
>> if env['swr']:
>>
> The command line variables, however (like swr=1) are not part of the 
> environment.  Even then, env['swr'] would fail for non-swr builds, since 
> 'swr' is not in the env dictionary.  This works for env['llvm'] sincellvm.py 
> initially sets it to False.  So, it will still be a 2-level test:   if 'swr' 
> in env and env['swr']:, which is not a simplication really.
>
> Is your point to move it to the environment, or to do a one-check test?
>
To consolidate the 'clunky' SCons.Script.ARGUMENTS + requirements
[only llvm?] checking in a single place. Thus the [newly added in the
env dictionary] swr can be used throughout without even import(ing)
SCons.Script.SConscript.

Thanks !
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

2016-11-10 Thread Kyriazis, George


> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Thursday, November 10, 2016 8:14 AM
> To: Kyriazis, George <george.kyria...@intel.com>
> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver
> 
> "gallium/targets: scons: wire swr support for libgl-gdi/libgl-xlib/osmesa"
> 
> ... or alike ?
> 
> > +import SCons.Script.SConscript
> > +
> 
> > +if 'swr' in SCons.Script.ARGUMENTS and
> SCons.Script.ARGUMENTS['swr']:
> With the "move this to top level" suggestion this will read roughly as
> 
> if env['swr']:
> 
The command line variables, however (like swr=1) are not part of the 
environment.  Even then, env['swr'] would fail for non-swr builds, since 'swr' 
is not in the env dictionary.  This works for env['llvm'] sincellvm.py 
initially sets it to False.  So, it will still be a 2-level test:   if 'swr' in 
env and env['swr']:, which is not a simplication really.

Is your point to move it to the environment, or to do a one-check test?

Thanks,

George

> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

2016-11-10 Thread Emil Velikov
"gallium/targets: scons: wire swr support for libgl-gdi/libgl-xlib/osmesa"

... or alike ?

> +import SCons.Script.SConscript
> +

> +if 'swr' in SCons.Script.ARGUMENTS and SCons.Script.ARGUMENTS['swr']:
With the "move this to top level" suggestion this will read roughly as

if env['swr']:

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver

2016-11-09 Thread George Kyriazis
---
 src/gallium/targets/libgl-gdi/SConscript  | 6 ++
 src/gallium/targets/libgl-xlib/SConscript | 6 ++
 src/gallium/targets/osmesa/SConscript | 6 ++
 3 files changed, 18 insertions(+)

diff --git a/src/gallium/targets/libgl-gdi/SConscript 
b/src/gallium/targets/libgl-gdi/SConscript
index 2a52363..0cedc8b 100644
--- a/src/gallium/targets/libgl-gdi/SConscript
+++ b/src/gallium/targets/libgl-gdi/SConscript
@@ -3,6 +3,8 @@
 
 Import('*')
 
+import SCons.Script.SConscript
+
 env = env.Clone()
 
 env.Append(CPPPATH = [
@@ -30,6 +32,10 @@ if env['llvm']:
 env.Append(CPPDEFINES = 'HAVE_LLVMPIPE')
 drivers += [llvmpipe]
 
+if 'swr' in SCons.Script.ARGUMENTS and SCons.Script.ARGUMENTS['swr']:
+env.Append(CPPDEFINES = 'HAVE_SWR')
+drivers += [swr]
+
 if env['gcc'] and env['machine'] != 'x86_64':
 # DEF parser in certain versions of MinGW is busted, as does not behave as
 # MSVC.  mingw-w64 works fine.
diff --git a/src/gallium/targets/libgl-xlib/SConscript 
b/src/gallium/targets/libgl-xlib/SConscript
index 0a4f31b..c66a751 100644
--- a/src/gallium/targets/libgl-xlib/SConscript
+++ b/src/gallium/targets/libgl-xlib/SConscript
@@ -3,6 +3,8 @@
 
 Import('*')
 
+import SCons.Script.SConscript
+
 env = env.Clone()
 
 env.Append(CPPPATH = [
@@ -48,6 +50,10 @@ if env['llvm']:
 env.Append(CPPDEFINES = ['GALLIUM_LLVMPIPE'])
 env.Prepend(LIBS = [llvmpipe])
 
+if 'swr' in SCons.Script.ARGUMENTS and not SCons.Script.ARGUMENTS['swr']:
+env.Append(CPPDEFINES = 'HAVE_SWR')
+env.Prepend(LIBS = [swr])
+
 if env['platform'] != 'darwin':
 # Disallow undefined symbols, except with Address Sanitizer, since libasan
 # is not linked on shared libs, as it should be LD_PRELOAD'ed instead
diff --git a/src/gallium/targets/osmesa/SConscript 
b/src/gallium/targets/osmesa/SConscript
index 7a2a00c..f390d1e 100644
--- a/src/gallium/targets/osmesa/SConscript
+++ b/src/gallium/targets/osmesa/SConscript
@@ -1,5 +1,7 @@
 Import('*')
 
+import SCons.Script.SConscript
+
 env = env.Clone()
 
 env.Prepend(CPPPATH = [
@@ -30,6 +32,10 @@ if env['llvm']:
 env.Append(CPPDEFINES = 'GALLIUM_LLVMPIPE')
 env.Prepend(LIBS = [llvmpipe])
 
+if 'swr' in SCons.Script.ARGUMENTS and not SCons.Script.ARGUMENTS['swr']:
+env.Append(CPPDEFINES = 'HAVE_SWR')
+env.Prepend(LIBS = [swr])
+
 if env['platform'] == 'windows':
 if env['gcc'] and env['machine'] != 'x86_64':
 sources += ['osmesa.mingw.def']
-- 
2.10.0.windows.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev