Thanks, R-b and committed.
Thanks for the Austin Group citations too.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Jonathan Gray
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
The M_PI*f macros used a preprocessor paste to append 'f'
to M_PI defines, which works if the values are only numbers
but breaks on OpenBSD where M_PI definitions have casts
and brackets to meet requirements of a future version of POSIX,
http://austingroupbugs.net/view.php?id=801
http://austingrou
Hi Jose,
On Tuesday, May 13, 2014 08:16:34 Jose Fonseca wrote:
> I tweaked the comment (was below) but indeed did a poor job. I think I'll
> just put the original back:
>
>"We must never free LLVM contexts, because LLVM has several global caches
>which pointing/derived from objects own
https://bugs.freedesktop.org/show_bug.cgi?id=78666
Michel Dänzer changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
From: Roland Scheidegger
When there's an error, also need to flush the stream, otherwise an assertion
is hit (meaning you don't actually see the error neither).
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/auxiliary/galli
From: Roland Scheidegger
In 1d35f77228ad540a551a8e09e062b764a6e31f5e support for multiple constant
buffers was introduced. This meant we had another indirection, and we did
resolve the indirection for each constant buffer access. This looks very
reasonable since llvm can figure out if it's the sa
On Tue, May 13, 2014 at 7:04 PM, Kenneth Graunke wrote:
> On 05/13/2014 02:52 PM, Matt Turner wrote:
>> gen8_dump_compile will be called indirectly by code common used by
>> generations before and after the gen8 instruction format change.
>> ---
>> src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
On 05/13/2014 02:52 PM, Matt Turner wrote:
> gen8_dump_compile will be called indirectly by code common used by
> generations before and after the gen8 instruction format change.
> ---
> src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 4 ++--
> src/mesa/drivers/dri/i965/gen8_generator.cpp
Kenneth Graunke writes:
> It's not properly implemented in the meta code, and we don't have time
> to fix it for 10.2.
Reviewed-by: Eric Anholt
pgpCGV_PgBzE1.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
htt
It's not properly implemented in the meta code, and we don't have time
to fix it for 10.2.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_extensions.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mes
Ilia Mirkin writes:
> Cc: "10.1 10.2"
...
> /* Sample position pairs for the current output MS level */
> -#define NV50_CB_AUX_SAMPLE_OFFSET 0x980
> +#define NV50_CB_AUX_SAMPLE_OFFSET 0x300
> #define NV50_CB_AUX_SAMPLE_OFFSET_SIZE (4 * 8 * 2)
> -/* next spot: 0x9c0 */
> +/* next spot: 0x340 */
From: Rob Clark
It wasn't completely clear from the docs, so I had to figure out by
looking at piglit results. Hopefully this saves the next driver writer
implementing queries some time.
Signed-off-by: Rob Clark
---
src/gallium/docs/source/context.rst | 2 ++
1 file changed, 2 insertions(+)
gen8_dump_compile will be called indirectly by code common used by
generations before and after the gen8 instruction format change.
---
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 4 ++--
src/mesa/drivers/dri/i965/gen8_generator.cpp | 7 ---
src/mesa/drivers/dri/i965/gen8_generato
Has been misaligned since we added instruction offset prefixes.
---
src/mesa/drivers/dri/i965/brw_disasm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
b/src/mesa/drivers/dri/i965/brw_disasm.c
index b9654a3..1de02e9 100644
--- a/src/mesa/drivers/dri/i
brw_dump_compile will be called indirectly by code common used by
generations before and after the gen8 instruction format change.
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp| 2 +-
src/mesa/drivers/dri/i965/brw_eu.c | 8 +++-
src/mesa/drivers/dri/i965/brw_eu.h
Lets us see actual jump targets, instruction locations, and compaction
information.
---
src/mesa/drivers/dri/i965/Makefile.sources| 1 +
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_clip.c | 2 +-
src/mesa/drivers/dri/i965/brw_e
---
src/mesa/drivers/dri/i965/brw_cfg.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 7bd3e24..5911107 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -25,6 +2
Only bblock_link's inheritance left.
---
src/mesa/drivers/dri/i965/brw_cfg.h | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 5911107..0a88d25 100644
--- a/src
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp| 2 ++
src/mesa/drivers/dri/i965/brw_clip.c | 2 +-
src/mesa/drivers/dri/i965/brw_eu.c | 2 --
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 8 ++--
src/mesa/drivers/dri/i965/brw_gs.c | 2 ++
src
brw_disasm doesn't disassemble compacted instructions, so we uncompact
before disassembling them which would unset the compaction control bit.
Instead pass it as a separate argument.
---
src/mesa/drivers/dri/i965/brw_clip.c| 2 +-
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mes
In order to remove bblock_link's inheritance of exec_node. Also makes
linked list walk code much nicer.
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 32 --
src/mesa/drivers/dri/i965/brw_cfg.h| 3 +-
.../drivers/dri/i965/brw_fs_copy_propagation.cpp
---
src/glsl/ir.h | 3 +++
src/glsl/ir_print_visitor.cpp | 7 +++
2 files changed, 10 insertions(+)
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 6c7c60a..ef4a12d 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -2348,6 +2348,9 @@ extern "C" {
extern void _mesa_print_ir(F
From: Marek Olšák
It works just fine.
This fixes a crash in:
piglit/spec/glsl-1.20/execution/fs-const-array-of-struct-of-array
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78666
Cc: 10.2 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 1 -
1
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, May 13, 2014 at 01:36:28 +0100, Emil Velikov wrote:
> Commit 11623be934f85 was meant to have this hunk, which
> I accidently dropped during git rebase.
>
> Cc: 10.2
> Signed-off-by: Emil Velikov
Reviewed-by: Julien Cristau
Thanks for the quick fix.
Cheers,
Julien
___
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #17 from Tobias Droste ---
a little bit more detailed (btw. this is with r600g, no glamor involved). So
while the original problem is that neither r600 nor swrast can be loaded this
still shouldn't crash X:
Program received signal SI
On Tue, May 13, 2014 at 4:57 PM, Marek Olšák wrote:
> Hi Rob,
>
> Roland is right.
>
> The function which resets the query result is begin_query.
ahh, ok.. it seemed from piglit tests that *something* (other than
destroy) should be resetting the query, but I wasn't quite sure what.
I'll fix my w
Hi Rob,
Roland is right.
The function which resets the query result is begin_query.
Marek
On Tue, May 13, 2014 at 4:21 AM, Rob Clark wrote:
> From: Rob Clark
>
> It wasn't completely clear from the docs, so I had to figure out by
> looking at piglit results. Hopefully this saves the next dri
https://bugs.freedesktop.org/show_bug.cgi?id=77288
--- Comment #2 from Brian Paul ---
This patch silences the assertion, but I'm really not sure if it's the right
thing to do.
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -1797,7 +1797,8 @@ ir_to_mesa_visitor::v
Reviewed-by: Chris Forbes
On Wed, May 14, 2014 at 6:19 AM, Jordan Justen
wrote:
> The depth extent field is used to limit the allowed slice range that
> can be rendered to.
>
> With the previous setting, only slice 0 could be rendered.
>
> This fixes piglit amd_vertex_shader_layer-layered-depth-
On Tue, May 13, 2014 at 1:36 AM, Iago Toral wrote:
> Hi Matt, are you okay with excluding FS_OPCODE_CINTERP from the list of
> virtual instructions to consider in Gen < 6? As far as I can see it is
> implemented as a single MOV instruction and the accumulator does not
> seem to be used but maybe I
The depth extent field is used to limit the allowed slice range that
can be rendered to.
With the previous setting, only slice 0 could be rendered.
This fixes piglit amd_vertex_shader_layer-layered-depth-texture-render.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen8_depth_stat
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #16 from Tobias Droste ---
Program received signal SIGSEGV, Segmentation fault.
_mesa_GenProgramPipelines (n=, pipelines=) at
main/pipelineobj.c:531
531 pipelines[i] = first + i;
#0 _mesa_GenProgramPipelines (n=, pipelines=
Reviewed-by: Roland Scheidegger
Am 13.05.2014 19:12, schrieb Ilia Mirkin:
> ping? ran into this when trying to feed text shaders into
> nouveau_compiler that had texture offsets...
>
> On Wed, May 7, 2014 at 9:25 PM, Ilia Mirkin wrote:
>> Signed-off-by: Ilia Mirkin
>> ---
>> src/gallium/auxil
On Mon, Apr 21, 2014 at 12:10 PM, Brian Paul wrote:
> On 04/19/2014 08:51 PM, Ilia Mirkin wrote:
>>
>> Hi Brian,
>>
>> I bisected a nv50/nvc0 regression in fbo-generatemipmap-array to
>> commit 5a2f8b2c48a14. The commit itself seems correct, but I
>> double-checked my bisection results (at least o
- Original Message -
> Am 13.05.2014 14:01, schrieb jfons...@vmware.com:
> > From: Frank Henigman
> >
> > Provide a JITMemoryManager derivative which puts all generated code into
> > one memory pool instead of creating a new one each time code is generated.
> > This saves significant me
Am 13.05.2014 19:10, schrieb Ilia Mirkin:
> On Thu, May 8, 2014 at 7:52 PM, Ilia Mirkin wrote:
>> Previously, ir_unop_any was implemented via a dot-product call, which
>> uses floating point multiplication and addition. The multiplication was
>> completely pointless, and the addition can just as w
ping? ran into this when trying to feed text shaders into
nouveau_compiler that had texture offsets...
On Wed, May 7, 2014 at 9:25 PM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/auxiliary/tgsi/tgsi_text.c | 53
> ++
> 1 file changed, 48
On Thu, May 8, 2014 at 7:52 PM, Ilia Mirkin wrote:
> Previously, ir_unop_any was implemented via a dot-product call, which
> uses floating point multiplication and addition. The multiplication was
> completely pointless, and the addition can just as well be done with an
> or. Since we know that th
Am 13.05.2014 14:01, schrieb jfons...@vmware.com:
> From: Frank Henigman
>
> Provide a JITMemoryManager derivative which puts all generated code into
> one memory pool instead of creating a new one each time code is generated.
> This saves significant memory per shader as the pool size is 512K an
- Original Message -
> Am 13.05.2014 14:01, schrieb jfons...@vmware.com:
> > From: Frank Henigman
> >
> > Split free_gallivm_state() into two steps. First step is
> > gallivm_free_ir() which cleans up the LLVM scaffolding used to generate
> > code while preserving the code itself. Sec
Tom Stellard writes:
> On Tue, May 13, 2014 at 11:35:36AM +0200, Francisco Jerez wrote:
>> Tom Stellard writes:
>>
>> > On Tue, May 13, 2014 at 01:23:03AM +0200, Francisco Jerez wrote:
>> >> Tom Stellard writes:
>> >>
>> >> > https://bugs.freedesktop.org/show_bug.cgi?id=78581
>> >> >
>> >> >
Am 13.05.2014 14:01, schrieb jfons...@vmware.com:
> From: Frank Henigman
>
> Split free_gallivm_state() into two steps. First step is
> gallivm_free_ir() which cleans up the LLVM scaffolding used to generate
> code while preserving the code itself. Second step is
> gallivm_free_code() to free t
Am 13.05.2014 14:01, schrieb jfons...@vmware.com:
> From: José Fonseca
>
> This is how it is meant to be done nowadays.
> ---
> src/gallium/auxiliary/gallivm/lp_bld_init.c | 47
> -
> 1 file changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/src/gallium/aux
Am 13.05.2014 14:01, schrieb jfons...@vmware.com:
> From: José Fonseca
>
> Older versions haven't been tested probably don't work anyway. But more
> importantly, code supporting it is hindering further work.
> ---
> src/gallium/auxiliary/draw/draw_llvm.c| 48 --
> src/gallium/a
On Tue, May 13, 2014 at 11:35:36AM +0200, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > On Tue, May 13, 2014 at 01:23:03AM +0200, Francisco Jerez wrote:
> >> Tom Stellard writes:
> >>
> >> > https://bugs.freedesktop.org/show_bug.cgi?id=78581
> >> >
> >> > CC: "10.1 10.2"
> >> > ---
> >>
Am 13.05.2014 04:21, schrieb Rob Clark:
> From: Rob Clark
>
> It wasn't completely clear from the docs, so I had to figure out by
> looking at piglit results. Hopefully this saves the next driver writer
> implementing queries some time.
>
> Signed-off-by: Rob Clark
> ---
> src/gallium/docs/so
Signed-off-by: Ilia Mirkin
Cc: "10.2"
---
Not 100% sure of the significance of this code, but this seems like the
correct thing to do... will definitely run it through a full piglit run before
pushing out.
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 2 ++
1 file changed, 2 insertions(
UNION appears to expect that all of its defines are conditional.
Otherwise it inserts a mov instruction which overwrites the desired
result. This fixes tests that use UMUL_HI, and much less directly,
unsigned integer division by a constant, which uses this functionality
in its lowering.
Signed-off
- Original Message -
> On 05/13/2014 06:01 AM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > I saw that LLVM internally uses its global context for some things, even
> > when we use our own. Given ours is also global, might as well use
> > LLVM's.
> >
> > However, sepearate
On 05/13/2014 06:01 AM, jfons...@vmware.com wrote:
From: José Fonseca
I saw that LLVM internally uses its global context for some things, even
when we use our own. Given ours is also global, might as well use
LLVM's.
However, sepearate contexts can still be enabled with a simple source
code m
https://bugs.freedesktop.org/show_bug.cgi?id=78604
smoki changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #13 from smoki ---
I tried to exclude some cases and this clearly happens only when micro_imsb
case is there :). So i guess this math logic util_last_bit_signed is wrong and
causes it:
http://cgit.freedesktop.org/mesa/mesa/commit/
- Original Message -
> On 05/09/2014 02:55 AM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > That information misleads source code auditing tools to think that
> > ralloc itself is released under LGPL v3.
> >
> > Instead, simply state talloc is not licensed under a permissive
- Original Message -
> From: Roland Scheidegger
>
> The setup shaders were composed of both a fs shader number and a variant
> number. But since they aren't tied to a particular fragment shader, the
> former was a fixed zero while the latter was also always zero because
> it was never a
My recent patch series removes this function altogether.
Jose
- Original Message -
> From: Roland Scheidegger
>
> gallivm_verify_function is the only caller of gallivm_optimize_function
> and it already does this (except it's enabled there).
> ---
> src/gallium/auxiliary/gallivm/lp_bld
Define GLX_USE_APPLEGL, as config/darwin used to, to turn on specific code to
use the applegl direct renderer
Convert src/glx/apple/Makefile to automake
Since the applegl libGL is now built by linking libappleglx into libGL, rather
than by linking selected files into a special libGL:
- Remove du
- Don't require xcb-dri[23] etc. if we aren't building for a target with DRM, as
we won't be using dri[23]
- Enable a more fine-grained control of what DRI code is built, so that a libGL
using direct swrast can be built on targets which don't have DRM.
The HAVE_DRI automake conditional is retired
Fix build for darwin, when ./configured --disable-driglx-direct
- darwin ld doesn't support -Bsymbolic or --version-script, so check if ld
supports those options before using them
- define GLX_ALIAS_UNSUPPORTED as config/darwin used to, as aliasing of non-weak
symbols isn't supported
- default to
On 16/02/2014 02:00, Jeremy Huddleston Sequoia wrote:
> Mesa master hasn't built for OSX for over a year now, unfortunately,
> but I agree excluding in Makefile.am is preferable to cpp-guards.
> Hopefully "someone" will have the time and patience to get it working
> again in the near future.
On 18
From: José Fonseca
I saw that LLVM internally uses its global context for some things, even
when we use our own. Given ours is also global, might as well use
LLVM's.
However, sepearate contexts can still be enabled with a simple source
code modification, for when the need/benefit arises.
---
s
From: José Fonseca
---
configure.ac | 6 ++
1 file changed, 6 insertions(+)
diff --git a/configure.ac b/configure.ac
index 99a761a..b4a1606 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1624,6 +1624,12 @@ if test "x$enable_gallium_llvm" = xyes; then
LLVM_VERSION_INT=`echo $L
From: José Fonseca
Older versions haven't been tested probably don't work anyway. But more
importantly, code supporting it is hindering further work.
---
src/gallium/auxiliary/draw/draw_llvm.c| 48 --
src/gallium/auxiliary/gallivm/lp_bld.h| 3 +
src/gallium/auxili
From: José Fonseca
Support for prior versions will be removed in the following change.
---
scons/llvm.py | 57 +
1 file changed, 13 insertions(+), 44 deletions(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index 134a072..cdfbe43 100644
---
From: Frank Henigman
Free up unneeded LLVM stuff immediately after generating vertex shader
code. Saves about 500K per shader.
v2: Don't bother calling gallivm_free_function (Jose)
Signed-off-by: José Fonseca
---
src/gallium/auxiliary/draw/draw_llvm.c | 19 ---
1 file changed
From: José Fonseca
Not necessary, now that we will free the whole module (hence all
function bodies) immediately after compiling.
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 3 ---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 8
src/gallium/auxiliary/gallivm/lp_bld_misc.h |
From: Frank Henigman
Provide a JITMemoryManager derivative which puts all generated code into
one memory pool instead of creating a new one each time code is generated.
This saves significant memory per shader as the pool size is 512K and
a small shader occupies just several K.
This memory manag
From: José Fonseca
This is how it is meant to be done nowadays.
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 47 -
1 file changed, 19 insertions(+), 28 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_
From: José Fonseca
Same as Frank's change to draw module but for llvmpipe module.
---
src/gallium/drivers/llvmpipe/lp_state_fs.c| 13 ++---
src/gallium/drivers/llvmpipe/lp_state_setup.c | 13 ++---
src/gallium/drivers/llvmpipe/lp_test_arit.c | 4 ++--
src/gallium/drivers/l
From: José Fonseca
Unused. Deprecated by gallivm_free_ir().
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 18 --
src/gallium/auxiliary/gallivm/lp_bld_init.h | 5 -
2 files changed, 23 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/
From: Frank Henigman
Split free_gallivm_state() into two steps. First step is
gallivm_free_ir() which cleans up the LLVM scaffolding used to generate
code while preserving the code itself. Second step is
gallivm_free_code() to free the memory occupied by the code.
v2: s/gallivm_teardown/galliv
From: José Fonseca
Nowadays LLVMModuleProviderRef is just an alias for LLVMModuleRef, so
its use just causes unnecessary confusion.
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 33 ++---
src/gallium/auxiliary/gallivm/lp_bld_init.h | 1 -
2 files changed, 7 insertion
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #12 from Benjamin Bellec ---
(In reply to comment #11)
> (In reply to comment #6)
> > libGL error: dlopen /usr/lib/dri/r600_dri.so failed (./bin/libgcc_s.so.1:
> > version `GCC_4.7.0' not found (required by /usr/lib/dri/r600_dri.so))
https://bugs.freedesktop.org/show_bug.cgi?id=57018
themas...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Tom Stellard writes:
> On Tue, May 13, 2014 at 01:23:03AM +0200, Francisco Jerez wrote:
>> Tom Stellard writes:
>>
>> > https://bugs.freedesktop.org/show_bug.cgi?id=78581
>> >
>> > CC: "10.1 10.2"
>> > ---
>> > src/gallium/state_trackers/clover/llvm/invocation.cpp | 4
>> > 1 file change
https://bugs.freedesktop.org/show_bug.cgi?id=78604
--- Comment #11 from Michel Dänzer ---
(In reply to comment #6)
> libGL error: dlopen /usr/lib/dri/r600_dri.so failed (./bin/libgcc_s.so.1:
> version `GCC_4.7.0' not found (required by /usr/lib/dri/r600_dri.so))
> libGL error: unable to load driv
Hi Matt, are you okay with excluding FS_OPCODE_CINTERP from the list of
virtual instructions to consider in Gen < 6? As far as I can see it is
implemented as a single MOV instruction and the accumulator does not
seem to be used but maybe I am missing something.
Iago
On Wed, 2014-05-07 at 09:58 +0
Hi Daniel,
We need a solution for this.
Without correct L3 config setting, all the OpenCL programs that use SLM
will fail.
We cannot set a default L3 config for all OCL programs, because L3
config for SLM will slowdown kernel that are not using SLM.
When do you th
79 matches
Mail list logo
