Two extra instructions in some heroesofnewerth shaders, but a win for
everything else.
total instructions in shared programs: 1531352 -> 1530815 (-0.04%)
instructions in affected programs: 121898 -> 121361 (-0.44%)
---
src/glsl/opt_algebraic.cpp | 23 +++
1 file changed, 2
On Wed, Oct 16, 2013 at 2:08 AM, Ian Romanick wrote:
> On 10/09/2013 12:06 AM, Chia-I Wu wrote:
>> From: Chia-I Wu
>>
>> FS_OPCODE_OVERWRITE_DST is used to indicate that the destination register is
>> (completely) overwritten. No code is emitted, but the liveness analysis can
>> use it as a hint
From: Chia-I Wu
When two partial writes write the first and second halves of a variable
respectively before the variable is used, the variable can be added to the def
bitset.
v2: no change
v3: no longer rely on hints from by the visitor
Signed-off-by: Chia-I Wu
---
.../drivers/dri/i965/brw_fs
From: Chia-I Wu
Add fs_visitor::emit_texture, which is used to emit the texture instruction
after the message payload has been set up.
v2: rebased because of texture gather changes
v3: rebased because of texture-from-GRF changes
Signed-off-by: Chia-I Wu
---
src/mesa/drivers/dri/i965/brw_fs.h
From: Chia-I Wu
Add fs_visitor::emit_dual_texture_gen7 that emulate SIMD16 sample_d with dual
SIMD8 sample_d on gen7+.
No piglit quick.tests regression on Ivy Bridge and Haswell.
Improved Xonotic with Ultra effects by 6.0209% +/- 0.396586% (N=11) on
Haswell.
v2: no change
v3: reworked because
On Wed, Oct 16, 2013 at 6:26 AM, Eric Anholt wrote:
> Chia-I Wu writes:
>
>> From: Chia-I Wu
>>
>> FS_OPCODE_OVERWRITE_DST is used to indicate that the destination register is
>> (completely) overwritten. No code is emitted, but the liveness analysis can
>> use it as a hint to add the destinati
On 10/15/2013 11:55 PM, Matt Turner wrote:
> Two extra instructions in some heroesofnewerth shaders, but a win for
> everything else.
>
> total instructions in shared programs: 1531352 -> 1530815 (-0.04%)
> instructions in affected programs: 121898 -> 121361 (-0.44%)
> ---
> src/glsl/opt_alge
On Wed, Oct 16, 2013 at 4:23 AM, Emil Velikov wrote:
> On 08/10/13 01:23, Brian Paul wrote:
>> The new function replaces four old functions: set_fragment/vertex/
>> geometry/compute_sampler_views().
>>
>> Note: at this time, it's expected that the 'start' parameter will
>> always be zero.
>>
>> --
On Tuesday, October 15, 2013 10:29:16 AM Eric Anholt wrote:
> Abdiel Janulgue writes:
> > On Monday, October 14, 2013 10:50:24 AM Eric Anholt wrote:
> >> Abdiel Janulgue writes:
> >> > One optimization idea that I had in mind a few months ago was to find a
> >> > way to reduce emission of surface
From: Ander Conselvan de Oliveira
---
src/egl/wayland/wayland-drm/wayland-drm.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c
b/src/egl/wayland/wayland-drm/wayland-drm.c
index 06bd18c..2f5acb2 100644
--- a/src/egl/wayland
Pretty sure though we only implement half of it, as we should clamp
incoming depth values at depth buffer time (either coming from
interpolated depth or fragment shader output) to the near and far depth
range. So we only implement the part affecting the clipping, but don't
consider the consequences
Am 15.10.2013 19:46, schrieb Ian Romanick:
On 10/15/2013 03:45 AM, Christian König wrote:
Hi Marek,
for the past few days I've been working on solving
https://bugs.freedesktop.org/show_bug.cgi?id=70123.
The basic problem is that compton forks itself into the background after
initializing the X
https://bugs.freedesktop.org/show_bug.cgi?id=70123
Christian König changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On 10/16/2013 08:45 AM, Brian Paul wrote:
Module: Mesa
Branch: master
Commit: 2273b04c6198d591c3dc5123c4d100da5bcc0e18
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=2273b04c6198d591c3dc5123c4d100da5bcc0e18
Author: Brian Paul
Date: Wed Oct 16 08:43:21 2013 -0600
mesa: change glTex
On 10/15/2013 07:54 PM, Kenneth Graunke wrote:
> I'm glad to see a unit test for this. It would be great if it was a bit
> more complete...but...
I had planned to be more complete, but that was when I thought the code
being tested was broken. :) Once I realized that it was my reading of
the code
There already was a bug, and this change was the fix. :) I *think* GL
4.4 says GLenum, and I guess the man pages just haven't been updated yet.
On 10/16/2013 07:45 AM, Brian Paul wrote:
> Module: Mesa
> Branch: master
> Commit: 2273b04c6198d591c3dc5123c4d100da5bcc0e18
> URL:
> http://cgit.fre
---
I'm not 100% sure this is the right way to go, and here's why:
Taken together, all the GLSL specs except GLSL 4.30 and GLSL 4.40 tell
a consistent story: desktop shader versions 1.10 and 1.20 may be
linked together, and desktop shader versions 1.40 and above may be
linked together. No other
- Original Message -
> Pretty sure though we only implement half of it, as we should clamp
> incoming depth values at depth buffer time (either coming from
> interpolated depth or fragment shader output) to the near and far depth
> range.
We kind of already do that, src/gallium/drivers/
On Tue, Oct 15, 2013 at 1:54 PM, Ian Romanick wrote:
> On 10/15/2013 09:53 AM, Ian Romanick wrote:
>> On 10/14/2013 10:12 AM, Anuj Phogat wrote:
>>> @@ -852,6 +858,9 @@ append_token(char *dst, gl_state_index k)
>>> case STATE_TEXENV_COLOR:
>>>append(dst, "texenv");
>>>break;
>>
On 10/15/2013 07:50 PM, Kenneth Graunke wrote:
> On 10/15/2013 01:58 PM, Ian Romanick wrote:
>> On 10/15/2013 01:50 PM, Anuj Phogat wrote:
>>> On Tue, Oct 15, 2013 at 10:02 AM, Ian Romanick wrote:
On 10/14/2013 10:12 AM, Anuj Phogat wrote:
> @@ -789,6 +794,12 @@
> builtin_variable_ge
On 10/16/2013 11:27 AM, Ian Romanick wrote:
There already was a bug, and this change was the fix. :) I *think* GL
4.4 says GLenum, and I guess the man pages just haven't been updated yet.
Yeah, it looks like it was changed to GLenum in the 4.3 spec. The man
page I found via google was from G
Matt Turner writes:
> Useful for tracking down problems in dependency calculations.
>
> Scheduling debugging now prints:
>
> clock2, scheduled: linterp vgrf5, hw_reg2, hw_reg3, hw_reg0,
> child 0, 53 parents: fb_write (null), (null), (null), (null),
> child 1, 2 parents: tex v
Kenneth Graunke writes:
> Since the i915/i965 split, there's only one implementation of this
> virtual function. We may as well just call it directly.
This is all:
Reviewed-by: Eric Anholt
pgpFnjYBgNVOJ.pgp
Description: PGP signature
___
mesa-dev
The queries GEOMETRY_VERTICES_OUT, GEOMETRY_INPUT_TYPE, and
GEOMETRY_OUTPUT_TYPE (defined by GL 3.2) differ from the corresponding
queries in ARB_geometry_shader4 in the following ways:
- They use different enum values
- They can only be queried; they cannot be set.
- Attempting to query them yi
Matt Turner writes:
> Two extra instructions in some heroesofnewerth shaders, but a win for
> everything else.
>
> total instructions in shared programs: 1531352 -> 1530815 (-0.04%)
> instructions in affected programs: 121898 -> 121361 (-0.44%)
Reviewed-by: Eric Anholt
pgpEz5feR03uK.pgp
D
On 10/15/2013 11:55 PM, Matt Turner wrote:
> Two extra instructions in some heroesofnewerth shaders, but a win for
> everything else.
>
> total instructions in shared programs: 1531352 -> 1530815 (-0.04%)
> instructions in affected programs: 121898 -> 121361 (-0.44%)
Just curious... what caus
Abdiel Janulgue writes:
> On Tuesday, October 15, 2013 10:29:16 AM Eric Anholt wrote:
>> Abdiel Janulgue writes:
>> > On Monday, October 14, 2013 10:50:24 AM Eric Anholt wrote:
>> >> Abdiel Janulgue writes:
>> >> > One optimization idea that I had in mind a few months ago was to find a
>> >> >
On 10/16/2013 10:40 AM, Ian Romanick wrote:
> On 10/15/2013 07:50 PM, Kenneth Graunke wrote:
[snip]
>> Right, but gl_SampleMask is not an unsized array. It's statically sized
>> based on your implementation's maximum supported number of color samples
>> (ceil(samples/32)), and this is totally know
On 10/16/2013 11:29 AM, Kenneth Graunke wrote:
> * Smaller than ceil(float(gl_NumSamples)/32.0):
I misspoke here. gl_NumSamples is a uniform, and is the number of
samples in the framebuffer. It isn't the implementation's maximum
number of color samples, which is what actually goes in that formul
On Wed, Oct 16, 2013 at 10:40 AM, Ian Romanick wrote:
> On 10/15/2013 07:50 PM, Kenneth Graunke wrote:
>> On 10/15/2013 01:58 PM, Ian Romanick wrote:
>>> On 10/15/2013 01:50 PM, Anuj Phogat wrote:
On Tue, Oct 15, 2013 at 10:02 AM, Ian Romanick
wrote:
> On 10/14/2013 10:12 AM, Anuj
---
src/mapi/glapi/gen/Makefile.am | 8
1 file changed, 8 insertions(+)
diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
index 6bb2f1e..d71d5d2 100644
--- a/src/mapi/glapi/gen/Makefile.am
+++ b/src/mapi/glapi/gen/Makefile.am
@@ -89,11 +89,13 @@ XORG_OUTPUTS =
https://bugs.freedesktop.org/show_bug.cgi?id=70546
Priority: medium
Bug ID: 70546
Keywords: regression
CC: bri...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: glext.h:412:25: error: redefinition of typedef
https://bugs.freedesktop.org/show_bug.cgi?id=70546
--- Comment #1 from Brian Paul ---
Hi Vinson,
If you remove lines 1739-1740 in gl.h does that fix this?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing
On Mon, Oct 14, 2013 at 4:14 PM, Eric Anholt wrote:
> Previously, the best thing we had was to schedule the things unblocked by
> the current instruction, on the hope that it would be consuming two values
> at the end of their live intervals while only producing one new value.
> Sometimes that was
Am Dienstag, 15. Oktober 2013, 17:22:54 schrieb Alexander von Gluck:
> On Tue, 2013-10-15 at 15:05 -0700, Francisco Jerez wrote:
> > Johannes Obermayr writes:
> >
> > > Am Dienstag, 15. Oktober 2013, 12:19:40 schrieben Sie:
> > >> On Tue, 15 Oct 2013 17:04:26 +0200
> > >> Johannes Obermayr wrote
On 10/16/2013 11:14 AM, Ian Romanick wrote:
> On 10/15/2013 11:55 PM, Matt Turner wrote:
>> Two extra instructions in some heroesofnewerth shaders, but a win for
>> everything else.
>>
>> total instructions in shared programs: 1531352 -> 1530815 (-0.04%)
>> instructions in affected programs: 12
On 10/16/2013 12:01 PM, Matt Turner wrote:
> ---
> src/mapi/glapi/gen/Makefile.am | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> index 6bb2f1e..d71d5d2 100644
> --- a/src/mapi/glapi/gen/Makefile.am
> +++ b/src/map
On Wed, Oct 16, 2013 at 11:14 AM, Ian Romanick wrote:
> On 10/15/2013 11:55 PM, Matt Turner wrote:
>> Two extra instructions in some heroesofnewerth shaders, but a win for
>> everything else.
>>
>> total instructions in shared programs: 1531352 -> 1530815 (-0.04%)
>> instructions in affected progr
Reviewed-by: Andreas Boll
2013/10/16 Matt Turner :
> ---
> src/mapi/glapi/gen/Makefile.am | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> index 6bb2f1e..d71d5d2 100644
> --- a/src/mapi/glapi/gen/Makefile.am
> +++
On 10/16/2013 01:57 PM, Matt Turner wrote:
> On Wed, Oct 16, 2013 at 11:14 AM, Ian Romanick wrote:
>> On 10/15/2013 11:55 PM, Matt Turner wrote:
>>> Two extra instructions in some heroesofnewerth shaders, but a win for
>>> everything else.
>>>
>>> total instructions in shared programs: 1531352 ->
On Wed, 2013-10-16 at 22:09 +0200, Johannes Obermayr wrote:
> Am Dienstag, 15. Oktober 2013, 17:22:54 schrieb Alexander von Gluck:
> > On Tue, 2013-10-15 at 15:05 -0700, Francisco Jerez wrote:
> > > Johannes Obermayr writes:
> > >
> > > > Am Dienstag, 15. Oktober 2013, 12:19:40 schrieben Sie:
> >
On Tue, Oct 15, 2013 at 3:48 PM, Kenneth Graunke wrote:
> On 10/14/2013 10:12 AM, Anuj Phogat wrote:
>> - Enable GEN7_WM_MSDISPMODE_PERSAMPLE, GEN7_WM_POSOFFSET_SAMPLE,
>> GEN7_WM_OMASK_TO_RENDER_TARGET as per extension's specification.
>> - Don't enable GEN7_WM_16_DISPATCH_ENABLE when GEN7_WM_M
I'm going to have to revert this as this patches has a few problems:
- it breaks windows builds becuase env[LLVM_CXXFLAGS] is never set there
- it is merging not only rtti, but the whole cxxflags (defines etc) which has
proven to be a source of troubles (breaks debugging etc.)
Jose
- Origin
On 10/16/2013 02:57 PM, Anuj Phogat wrote:
> On Tue, Oct 15, 2013 at 3:48 PM, Kenneth Graunke
> wrote:
>> On 10/14/2013 10:12 AM, Anuj Phogat wrote:
>>> - Enable GEN7_WM_MSDISPMODE_PERSAMPLE, GEN7_WM_POSOFFSET_SAMPLE,
>>> GEN7_WM_OMASK_TO_RENDER_TARGET as per extension's specification.
>>> - Do
I think this patch does what you need, but with much less unintended
side-effects:
$ git diff
diff --git a/scons/llvm.py b/scons/llvm.py
index c1c3736..8388d8e 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -190,6 +190,11 @@ def generate(env):
pass
env.MergeFlags(
On Tue, Oct 15, 2013 at 3:38 PM, Kenneth Graunke wrote:
> On 10/14/2013 10:12 AM, Anuj Phogat wrote:
>> - Enable GEN6_WM_MSDISPMODE_PERSAMPLE, GEN6_WM_POSOFFSET_SAMPLE,
>> GEN6_WM_OMASK_TO_RENDER_TARGET as per extension's specification.
>> - Don't enable GEN6_WM_16_DISPATCH_ENABLE when GEN6_WM_M
On 10/16/2013 01:56 PM, Kenneth Graunke wrote:
> On 10/16/2013 12:01 PM, Matt Turner wrote:
>> ---
>> src/mapi/glapi/gen/Makefile.am | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
>> index 6bb2f1e..d71d5d2 100644
On Wed, 2013-10-16 at 16:58 -0500, Alexander von Gluck wrote:
> On Wed, 2013-10-16 at 22:09 +0200, Johannes Obermayr wrote:
> > Am Dienstag, 15. Oktober 2013, 17:22:54 schrieb Alexander von Gluck:
> > > On Tue, 2013-10-15 at 15:05 -0700, Francisco Jerez wrote:
> > > > Johannes Obermayr writes:
> >
On Wed, Oct 16, 2013 at 1:56 PM, Kenneth Graunke wrote:
> Is there some way we can use globbing? It would be great if we could
> just use *.xml or ARB*.xml...
Maybe? See http://www.gnu.org/software/automake/manual/html_node/Wildcards.html
I'm already three build system patches over my allotment
On Wed, Oct 16, 2013 at 3:20 PM, Ian Romanick wrote:
> On 10/16/2013 02:57 PM, Anuj Phogat wrote:
>> On Tue, Oct 15, 2013 at 3:48 PM, Kenneth Graunke
>> wrote:
>>> On 10/14/2013 10:12 AM, Anuj Phogat wrote:
- Enable GEN7_WM_MSDISPMODE_PERSAMPLE, GEN7_WM_POSOFFSET_SAMPLE,
GEN7_WM_OMAS
On 10/16/2013 11:29 AM, Kenneth Graunke wrote:
> On 10/16/2013 10:40 AM, Ian Romanick wrote:
>> On 10/15/2013 07:50 PM, Kenneth Graunke wrote:
> [snip]
>>> Right, but gl_SampleMask is not an unsized array. It's statically sized
>>> based on your implementation's maximum supported number of color s
On Wed, 2013-10-16 at 18:34 -0400, Jan Vesely wrote:
> On Wed, 2013-10-16 at 16:58 -0500, Alexander von Gluck wrote:
> > On Wed, 2013-10-16 at 22:09 +0200, Johannes Obermayr wrote:
> > > Am Dienstag, 15. Oktober 2013, 17:22:54 schrieb Alexander von Gluck:
> > > > On Tue, 2013-10-15 at 15:05 -0700,
On Wed, 2013-10-16 at 15:20 -0700, Jose Fonseca wrote:
> +# Match llvm --fno-rtti flag
> +cxxflags = env.backtick('llvm-config --cxxflags').split()
> +if '-fno-rtti' in cxxflags:
> +env.Append(CXXFLAGS = ['-fno-rtti'])
Ah, thats a good idea. I d
On Wed, Oct 16, 2013 at 3:49 PM, Ian Romanick wrote:
> On 10/16/2013 11:29 AM, Kenneth Graunke wrote:
>> On 10/16/2013 10:40 AM, Ian Romanick wrote:
>>> On 10/15/2013 07:50 PM, Kenneth Graunke wrote:
>> [snip]
Right, but gl_SampleMask is not an unsized array. It's statically sized
based
On 10/11/2013 06:03 PM, Eric Anholt wrote:
Previously, we've split things such that mesa core is in libdricore,
exposing the whole Mesa core interface in the global namespace, and the
i965_dri.so code all links against that. Along with polluting application
namespace terribly, it requires extra
Patches 1-6 are
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 10/11/2013 06:03 PM, Eric Anholt wrote:
This will allow a megadrivers build to reference the actual driver being
loaded from the shared dri_util screen creation code.
Clever, but not too clever.
Reviewed-by: Chad Versace
___
mesa-dev mailing list
Patch 8 is
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
The bits about globalDriverAPI and megadriver_stub.c feel strongly
logically disjoint from the rest of the patch. And, they really aren't
related to i965. It looks like they should get separated out into a
separate patch the immediately precedes this one.
Also, as I said in my first reply, this p
On 10/16/2013 10:29 AM, Paul Berry wrote:
> ---
>
> I'm not 100% sure this is the right way to go, and here's why:
>
> Taken together, all the GLSL specs except GLSL 4.30 and GLSL 4.40 tell
> a consistent story: desktop shader versions 1.10 and 1.20 may be
> linked together, and desktop shader ve
---
src/glsl/opt_algebraic.cpp | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 3e5802e..b915f3c 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -257,11 +257,9 @@ ir_algebraic_
---
src/glsl/opt_algebraic.cpp | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index b915f3c..9b0596c 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -210,6 +210,24 @@ ir_algebraic_visitor::
---
src/glsl/opt_algebraic.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 9b0596c..37b2f02 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -228,6 +228,16 @@ ir_algebraic_visitor::handle_e
On Wed, 2013-10-16 at 18:32 -0500, Alexander von Gluck wrote:
> > Jan Vesely wrote:
> > > We've seen no other complaints on this issue, so likely it is
> something
> > > environmental on your end. (unless an older version of LLVM has an
> > > issue... which is what i'm trying to figure out)
> >
>
* Based on ideas of Jose Fonseca
* A rework of ce8eadb6e8
---
scons/llvm.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/scons/llvm.py b/scons/llvm.py
index c1c3736..8388d8e 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -190,6 +190,11 @@ def generate(env):
pass
On 10/16/2013 04:56 PM, Ian Romanick wrote:
> On 10/16/2013 10:29 AM, Paul Berry wrote:
>> ---
>>
>> I'm not 100% sure this is the right way to go, and here's why:
>>
>> Taken together, all the GLSL specs except GLSL 4.30 and GLSL 4.40 tell
>> a consistent story: desktop shader versions 1.10 and 1.
Hi Eric,
On Sat, Oct 12, 2013 at 3:18 AM, Eric Anholt wrote:
> Chia-I Wu writes:
>
>> Hi Eric,
>> The frame rate of Unigine Tropics (with low shader quality) dropped
>> from 40.8 to 23.5 after this change.
>
> Thanks for the note. I see the regression as well, and I see a shader
> that's starte
On Wed, Oct 16, 2013 at 6:26 PM, Alexander von Gluck IV
wrote:
> * Based on ideas of Jose Fonseca
> * A rework of ce8eadb6e8
> ---
> scons/llvm.py | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/scons/llvm.py b/scons/llvm.py
> index c1c3736..8388d8e 100644
> --- a/scons/llvm.py
> ++
On 10/16/2013 03:49 PM, Ian Romanick wrote:
[snip]
> You are completely correct here. We should check what other vendors do.
> I think 5 tests will tell us everything we need to know (then we'll
> probably submit some spec bugs). I don't have any non-Intel hardware
> that supports either extensi
On Wed, Oct 16, 2013 at 11:13:33AM -0700, Paul Berry wrote:
> The queries GEOMETRY_VERTICES_OUT, GEOMETRY_INPUT_TYPE, and
> GEOMETRY_OUTPUT_TYPE (defined by GL 3.2) differ from the corresponding
> queries in ARB_geometry_shader4 in the following ways:
>
> - They use different enum values
>
> - Th
On 16 October 2013 16:56, Ian Romanick wrote:
> On 10/16/2013 10:29 AM, Paul Berry wrote:
> > ---
> >
> > I'm not 100% sure this is the right way to go, and here's why:
> >
> > Taken together, all the GLSL specs except GLSL 4.30 and GLSL 4.40 tell
> > a consistent story: desktop shader versions 1
71 matches
Mail list logo
