Reviewed-by: Tapani Pälli
On 09/03/2018 09:22 PM, Jason Ekstrand wrote:
As of 07a2098a708a2, brw_nir_optimize calls nir_remove_dead_variables as
the last optimization. Doing it again is just pointless.
---
src/intel/compiler/brw_nir.c | 2 --
1 file changed, 2 deletions(-)
diff --git
On Saturday, September 1, 2018 9:24:53 AM PDT Jason Ekstrand wrote:
> This appears to hang broadwell; we should probably think twice before
> enabling it so broadly. I'll adjust it to be gen9 only or we can just can
> the patch entirely.
There a bunch of workarounds and they're tricky to get
Previously, all needed pipe controls were flushed out right before
either 3DPRIMITIVE or GPGPU_WALKER. This commit moves pipeline flushes
to the beginning of state emit for a given draw or dispatch call rather
than the end. The result is that any previously pending state is now
flushed before we
Talking with Ken about this, it seems we might not actually coherent use
GTT maps because those are just for buffer (which are allocated linear).
GTT maps are only used with tiled buffers.
So we most likely don't even need this patch.
The code is confusing though.
-
Lionel
On 31/08/2018
This patch causes the corruptions to return in No Mans Sky.
On 04/09/18 04:36, Marek Olšák wrote:
From: Marek Olšák
This includes reused buffers. Prefer DCC clear if DCC is enabled.
---
src/gallium/drivers/radeonsi/si_buffer.c | 8
src/gallium/drivers/radeonsi/si_pipe.c
Mauro Rossi writes:
> Fixes the following building error, happening when building both intel and
> broadcom:
I wish someone maintaining android Mesa would work on making the meson
build work for them instead of just continuing to maintain the
Android.mk mess. However, whatever it takes to
Am Montag, den 03.09.2018, 14:42 +0100 schrieb Emil Velikov:
>
> struct virgl_hw_res **new_bo =
>
> > +new_nres * sizeof(struct
> > virgl_hw_buf*));
> > + if (!new_ptr) {
> > + fprintf(stderr,"failure to add relocation %d, %d\n",
> > cbuf->cres,
Hi,
Could you please merge patch to master?
On Wed, Aug 1, 2018 at 10:33 PM Denis Pauk wrote:
> Hi Bruce,
>
> Thank you. Best wishes to Alok.
>
> Could someone also update docs/features.txt with bptc/astc support? Look
> like we can mark bptc as done for all gallium software renders and
On Mon, Sep 3, 2018 at 6:29 AM, Timothy Arceri wrote:
>
>
> On 28/08/18 04:26, Marek Olšák wrote:
>>
>> On Fri, Aug 24, 2018 at 10:33 AM, Michel Dänzer
>> wrote:
>>>
>>> On 2018-08-24 1:06 p.m., Timothy Arceri wrote:
More and more games seem to require this so lets make it a config
From: Marek Olšák
This includes reused buffers. Prefer DCC clear if DCC is enabled.
---
src/gallium/drivers/radeonsi/si_buffer.c | 8
src/gallium/drivers/radeonsi/si_pipe.c| 3 ++-
src/gallium/drivers/radeonsi/si_texture.c | 5 -
As of 07a2098a708a2, brw_nir_optimize calls nir_remove_dead_variables as
the last optimization. Doing it again is just pointless.
---
src/intel/compiler/brw_nir.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index
Acked-by: Jason Ekstrand
On Mon, Sep 3, 2018 at 12:08 PM Eric Engestrom wrote:
> Unused since 09f1de97a76a4990fd7c "anv,i965: Lower away image derefs in
> the driver".
>
> Cc: Jason Ekstrand
> Signed-off-by: Eric Engestrom
> ---
> src/intel/compiler/brw_fs_nir.cpp | 19 ---
>
On Monday, 2018-09-03 13:05:22 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> As the spec says, the function is a no-op when the surface is not a
> window one.
>
> That spec implies that EGL_TRUE should be returned in that case, yet
> the ARM driver seems to return EGL_FALSE +
Unused since 09f1de97a76a4990fd7c "anv,i965: Lower away image derefs in
the driver".
Cc: Jason Ekstrand
Signed-off-by: Eric Engestrom
---
src/intel/compiler/brw_fs_nir.cpp | 19 ---
1 file changed, 19 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
On ma., sep. 3, 2018 at 11:50 AM, andrey simiklit
wrote:
Hi,
One more small think here:
> +int virgl_encode_set_hw_atomic_buffers(struct virgl_context *ctx,
> + unsigned start_slot,
unsigned count,
> + const struct
On 03/09/2018 17:15, Jason Ekstrand wrote:
On September 3, 2018 10:47:11 Lionel Landwerlin
wrote:
We're hitting an assert in gfxbench because one of the local variable
is a sampler (according to Jason this isn't valid) :
testfw_app: ../src/compiler/nir_types.cpp:551: void
On fr., aug. 31, 2018 at 7:44 PM, Gurchetan Singh
wrote:
On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
wrote:
This moves the evergreen-specific max-sizes out as a driver-cap, so
other drivers with less strict requirements also can use hw-atomics.
Remove ssbo_atomic as it's no longer
On September 3, 2018 10:47:11 Lionel Landwerlin
wrote:
We're hitting an assert in gfxbench because one of the local variable
is a sampler (according to Jason this isn't valid) :
testfw_app: ../src/compiler/nir_types.cpp:551: void
glsl_get_natural_size_align_bytes(const glsl_type*, unsigned
On fr., aug. 31, 2018 at 7:35 PM, Gurchetan Singh
wrote:
On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
wrote:
From: Tomeu Vizoso
Emulating atomics on top of ssbos can lead to too small max SSBO
count,
so let's use the hw-atomics mechanism to expose atomic buffers
instead.
On 03/09/2018 16:47, Lionel Landwerlin wrote:
We're hitting an assert in gfxbench because one of the local variable
is a sampler (according to Jason this isn't valid) :
testfw_app: ../src/compiler/nir_types.cpp:551: void
glsl_get_natural_size_align_bytes(const glsl_type*, unsigned int*,
We're hitting an assert in gfxbench because one of the local variable
is a sampler (according to Jason this isn't valid) :
testfw_app: ../src/compiler/nir_types.cpp:551: void
glsl_get_natural_size_align_bytes(const glsl_type*, unsigned int*, unsigned
int*): Assertion `!"type does not have a
Quoting Emil Velikov (2018-09-03 07:18:31)
> On 24 August 2018 at 19:45, Dylan Baker wrote:
> > Quoting Emil Velikov (2018-08-24 08:57:29)
> >> On Fri, 24 Aug 2018 at 15:16, Dylan Baker wrote:
> >> >
> >> > Meson won't put the .gmo files in the layout that python's
> >> > gettext.translation()
https://bugs.freedesktop.org/show_bug.cgi?id=107670
--- Comment #12 from Emil Velikov ---
Why are we even discussing a potential optimisation where the user is
_unknown_?
It contradicts with the principles that we've been using in Mesa for years.
--
You are receiving this mail because:
You are
On 3 September 2018 at 15:49, wrote:
> From: Andrii Simiklit
>
> MSDN:
> "va_end must be called on each argument list that's initialized
> with va_start or va_copy before the function returns."
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107810
> Signed-off-by: Andrii Simiklit
https://bugs.freedesktop.org/show_bug.cgi?id=107670
--- Comment #11 from Eero Tamminen ---
Libc memcpy() obviously won't be optimized for PCI bus transfers, it's way too
rare use-case for it.
E.g. libpciaccess would seem more suitable place for PCI bus transfer optimized
memory copy function,
https://bugs.freedesktop.org/show_bug.cgi?id=107810
--- Comment #1 from asimiklit ---
Solution is suggested:
https://patchwork.freedesktop.org/patch/246968/
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
From: Andrii Simiklit
MSDN:
"va_end must be called on each argument list that's initialized
with va_start or va_copy before the function returns."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107810
Signed-off-by: Andrii Simiklit
---
src/util/u_string.h | 1 +
1 file changed, 1
https://bugs.freedesktop.org/show_bug.cgi?id=107670
--- Comment #10 from Emil Velikov ---
My personal train of though:
Details such as WC are left to the kernel module. Even on the case where
userspace can provide hints, it's ultimately up-to the kernel to manage it.
Optimising w/o saying the
https://bugs.freedesktop.org/show_bug.cgi?id=107810
Bug ID: 107810
Summary: The 'va_end' call is missed after 'va_copy' in
'util_vsnprintf' function under windows
Product: Mesa
Version: git
Hardware: Other
On 24 August 2018 at 19:45, Dylan Baker wrote:
> Quoting Emil Velikov (2018-08-24 08:57:29)
>> On Fri, 24 Aug 2018 at 15:16, Dylan Baker wrote:
>> >
>> > Meson won't put the .gmo files in the layout that python's
>> > gettext.translation() expects, so we need to handle them differently,
>> >
On Thu, Aug 23, 2018 at 8:38 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> We're hitting an assert in gfxbench because one of the local variable
> is a sampler (according to Jason this isn't valid) :
>
> testfw_app: ../src/compiler/nir_types.cpp:551: void
>
On 24 August 2018 at 19:51, Dylan Baker wrote:
> Can we just change the script to write a file instead of sending it's output
> through the shell? That should fix any encoding problems since the shell wont
> touch it and the LANG settings (no matter what they are) shouldn't matter.
>
Seems like I
Hi Eric,
On 24 August 2018 at 14:11, Emil Velikov wrote:
> From: Emil Velikov
>
> As the comment above globalDriverAPI (in dri_util.c) says, if the loader
> is unaware of createNewScreen2 there is a race condition.
>
> In which globalDriverAPI, will be set in the driver driDriverGetExtensions*
On 3 September 2018 at 13:57, Gert Wollny wrote:
> Fixes crash with
> piglit/bin/map_buffer_range-invalidate CopyBufferSubData \
>increment-offset -auto -fbo
>
> * Resize the resource storage already when the count is equal to the
> allocated size, fixes:
>
>
On Fri, 2018-08-31 at 13:24 -0700, Mark Janes wrote:
> Hi Andres,
>
> The final blockers have been resolved. You should be able to make an RC
> that passes all Intel validation, if you pick up:
>
> 904c2a617d8 * i965/gen7_urb: Re-emit PUSH_CONSTANT_ALLOC on some gen9
> d9cf4308cee *
> That sounds reasonable - I would squash the off-by-one in both drm
> and vtest at once. Or keep it them separate if you prefer.
I guess I was a bit lost there, was searching in virglrender. I'll send
out the vtest patch shortly as a separate patch.
best,
Gert
Fixes crash with
piglit/bin/map_buffer_range-invalidate CopyBufferSubData \
increment-offset -auto -fbo
* Resize the resource storage already when the count is equal to the
allocated size, fixes:
Invalid write of size 8
at 0xB72E4CF: virgl_drm_add_res
From: Emil Velikov
Unlike the other platforms, here we aim do guess if the device that we
somewhat arbitrarily picked, is supported or not.
In particular: when a vendor is _not_ requested we loop through all
devices, picking the first one which can create a DRI screen.
When a vendor is
On 3 September 2018 at 12:39, Gert Wollny wrote:
> Am Montag, den 03.09.2018, 10:52 +0100 schrieb Emil Velikov:
>> Hi Gert,
>>
>> On 3 September 2018 at 09:17, Gert Wollny
>> wrote:
>> > The ressource storage must already be resized when the count is
>> > equal to
>> > the allocated size and the
On 03/09/18 22:00, Eero Tamminen wrote:
Hi,
Seems a lot of replicated code to deal with regression from few line
line patch,
That's because the previous patch didn't cause the regression. It fixed
another bug which happened to be hiding this problem we are seeing now.
but at least it
From: Emil Velikov
Already handled further up in eglapi.c
Cc: samiuddi
Cc: Eric Engestrom
Cc: Erik Faye-Lund
Cc: Tomasz Figa
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/platform_drm.c | 30 ++---
1 file changed, 14 insertions(+), 16 deletions(-)
diff
From: Emil Velikov
Already handled further up in eglapi.c.
To make things a tiny bit strange, X11+DRI3 was doing the wrong thing by
returning EGL_FALSE (+ no error), while X11+DRI2 was returning EGL_TRUE.
Cc: samiuddi
Cc: Eric Engestrom
Cc: Erik Faye-Lund
Cc: Tomasz Figa
Signed-off-by:
From: Emil Velikov
As the spec says, the function is a no-op when the surface is not a
window one.
That spec implies that EGL_TRUE should be returned in that case, yet
the ARM driver seems to return EGL_FALSE + EGL_BAD_SURFACE.
The Nvidia driver returns EGL_TRUE. We follow that behaviour until
From: Emil Velikov
Analogous to the previous commit - the spec says the function is a
no-op when a pbuffer or pixmap surface is used.
Cc: samiuddi
Cc: Eric Engestrom
Cc: Erik Faye-Lund
Cc: Tomasz Figa
Cc:
Signed-off-by: Emil Velikov
---
src/egl/main/eglapi.c | 6 ++
1 file changed, 6
From: Emil Velikov
Already handled further up in eglapi.c
Cc: samiuddi
Cc: Eric Engestrom
Cc: Erik Faye-Lund
Cc: Tomasz Figa
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/platform_android.c | 4
1 file changed, 4 deletions(-)
diff --git
From: Emil Velikov
The API validation in eglapi.c already returns if the surface type is
!window.
Cc: samiuddi
Cc: Eric Engestrom
Cc: Erik Faye-Lund
Cc: Tomasz Figa
Cc: Gurchetan Singh
Cc: Chad Versace
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/platform_surfaceless.c | 13
Hi,
Seems a lot of replicated code to deal with regression from few line
line patch, but at least it fixed the failing GfxBench ALU2 test. :-)
Tested-By: Eero Tamminen
- Eero
On 01.09.2018 16:57, Timothy Arceri wrote:
If we have something like:
#ifdef NOT_DEFINED
#define
Am Montag, den 03.09.2018, 10:52 +0100 schrieb Emil Velikov:
> Hi Gert,
>
> On 3 September 2018 at 09:17, Gert Wollny
> wrote:
> > The ressource storage must already be resized when the count is
> > equal to
> > the allocated size and the space for the handles must be resized
> > accordingly.
>
On 3 September 2018 at 08:14, Eric Engestrom wrote:
> On Monday, 2018-09-03 14:59:49 +0900, Tomasz Figa wrote:
>> On Thu, Aug 30, 2018 at 11:23 PM Emil Velikov
>> wrote:
>> >
>> > On 30 August 2018 at 11:41, Eric Engestrom
>> > wrote:
>> > > On Thursday, 2018-08-30 17:55:14 +0900, Tomasz Figa
On 28/08/18 04:26, Marek Olšák wrote:
On Fri, Aug 24, 2018 at 10:33 AM, Michel Dänzer wrote:
On 2018-08-24 1:06 p.m., Timothy Arceri wrote:
More and more games seem to require this so lets make it a config
option.
---
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 1 +
Hi,
Thanks a lot.
Regards,
Andrii.
On Mon, Sep 3, 2018 at 1:16 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Done.
>
> -
> Lionel
>
> On 03/09/2018 08:55, andrey simiklit wrote:
>
> Hi all,
>
> Could somebody push this small patch to mesa?
>
> Regards,
> Andrii.
> On Mon, Aug
Hi,
I guess it is just a small mistake in description that:
'z' was before:
z = y - x;
and became after:
z = x - y;
I think you inadvertently misspelled in the description and you mean:
>
> This pass attempts to dectect code sequences like
>
> if (x < y) {
> z = y - x;
>
Done.
-
Lionel
On 03/09/2018 08:55, andrey simiklit wrote:
Hi all,
Could somebody push this small patch to mesa?
Regards,
Andrii.
On Mon, Aug 20, 2018 at 9:13 PM Lionel Landwerlin
mailto:lionel.g.landwer...@intel.com>>
wrote:
On 20/08/2018 17:20, asimiklit.w...@gmail.com
On 2018-09-01 8:54 a.m., Marek Olšák wrote:
> From: Marek Olšák
>
> +41% performance in debug builds
> (testing piglit/drawoverhead + u_threaded_context)
Nice, but please include ministat output.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software
On 2018-09-01 8:54 a.m., Marek Olšák wrote:
> From: Marek Olšák
Nice cleanup. This patch and patch 4 are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-09-01 8:54 a.m., Marek Olšák wrote:
> From: Marek Olšák
>
> +1.2% performance
Please either state what you tested with, and include ministat output,
or don't make any statement about performance impact.
--
Earthling Michel Dänzer | http://www.amd.com
Libre
On 3 September 2018 at 09:17, Gert Wollny wrote:
> Silences:
>
> Conditional jump or move depends on uninitialised value(s)
> at 0xB72F2C0: virgl_drm_winsys_create (virgl_drm_winsys.c:854)
> by 0xB72F2C0: virgl_drm_screen_create (virgl_drm_winsys.c:926)
> by 0xB21C885:
Hi Gert,
On 3 September 2018 at 09:17, Gert Wollny wrote:
> The ressource storage must already be resized when the count is equal to
> the allocated size and the space for the handles must be resized
> accordingly.
>
s/ressource/resource/
> Fixes:
> Crashes with
>
Hi,
One more small think here:
> +int virgl_encode_set_hw_atomic_buffers(struct virgl_context *ctx,
> + unsigned start_slot, unsigned
count,
> + const struct pipe_shader_buffer
*buffers)
> +{
> + int i;
I believe that
Hello,
I believe that this check already added inside _mesa_lookup_vao:
>_mesa_lookup_vao(struct gl_context *ctx, GLuint id)
>{
> if (id == 0) {
> return NULL;
> } else {
> ...
>}
I guess that the '_mesa_lookup_vao' function returns NULL for zero indexes.
So we will never pass
On Mon, Sep 3, 2018 at 10:41 AM Alexander Larsson wrote:
>
> On Fri, Aug 31, 2018 at 4:05 PM Emil Velikov wrote:
> >
> > Valid point - I forgot about that.
> >
> > A couple of ideas come to mind:
> > - static link LLVM (Flatpak already does it)
> > No LLVM changes needed.
> >
> > - shared link
I picked up a bunch of the pieces from wayland's version:
https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md
The weston one is fairly similar. Then I rather massively trimmed it
down since in reality libdrm is a bit a dumping ground with very few
real rules. The commit
With my comments addressed, the first 5 patches are:
Reviewed-by: Marek Olšák
Marek
On Mon, Sep 3, 2018 at 4:44 AM, Marek Olšák wrote:
> Same answer as before - the screen.rst documentation is missing.
>
> Marek
>
> On Thu, Aug 30, 2018 at 9:40 AM, Erik Faye-Lund
> wrote:
>> This moves the
Same answer as before - the screen.rst documentation is missing.
Marek
On Thu, Aug 30, 2018 at 9:40 AM, Erik Faye-Lund
wrote:
> This moves the evergreen-specific max-sizes out as a driver-cap, so
> other drivers with less strict requirements also can use hw-atomics.
>
> Remove ssbo_atomic as
On Fri, Aug 31, 2018 at 4:05 PM Emil Velikov wrote:
>
> Valid point - I forgot about that.
>
> A couple of ideas come to mind:
> - static link LLVM (Flatpak already does it)
> No LLVM changes needed.
>
> - shared link LLVM
> LLVM add -Wl,--build-id=sha1
As a very very simple workaround, can
The ressource storage must already be resized when the count is equal to
the allocated size and the space for the handles must be resized
accordingly.
Fixes:
Crashes with
piglit/bin/map_buffer_range-invalidate CopyBufferSubData \
increment-offset -auto -fbo
Silences:
Conditional jump or move depends on uninitialised value(s)
at 0xB72F2C0: virgl_drm_winsys_create (virgl_drm_winsys.c:854)
by 0xB72F2C0: virgl_drm_screen_create (virgl_drm_winsys.c:926)
by 0xB21C885: pipe_virgl_create_screen (drm_helper.h:275)
by 0xB7201F0:
I've tested that Android Celadon continues to work with these changes ..
Tested-by: Tapani Pälli
On 08/31/2018 07:59 PM, Emil Velikov wrote:
From: Emil Velikov
Unlike the other platforms, here we aim do guess if the device that we
somewhat arbitrarily picked, is supported or not.
In
https://bugs.freedesktop.org/show_bug.cgi?id=107734
--- Comment #2 from Tapani Pälli ---
Seems a bit like : https://patchwork.freedesktop.org/patch/36417/
IIRC there was some issue with that patch ... or not. Vadym, please check if
this fixes the WebGL tests also?
--
You are receiving this
Hi all,
Could somebody push this small patch to mesa?
Regards,
Andrii.
On Mon, Aug 20, 2018 at 9:13 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> On 20/08/2018 17:20, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit
> >
> > The "gen_group_get_length" function can
On Monday, 2018-09-03 08:40:47 +0100, Eric Engestrom wrote:
> On Friday, 2018-08-31 17:59:10 +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Unlike the other platforms, here we aim do guess if the device that we
> > somewhat arbitrarily picked, is supported or not.
> >
> > In
On Friday, 2018-08-31 17:59:10 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Unlike the other platforms, here we aim do guess if the device that we
> somewhat arbitrarily picked, is supported or not.
>
> In particular: when a vendor is _not_ requested we loop through all
> devices,
On 9/3/18 2:35 AM, Bas Nieuwenhuizen wrote:
No clue what gets fixed by this but both radeonsi and amdvlk do it.
CC:
---
src/amd/vulkan/radv_device.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c
On Monday, 2018-09-03 14:59:49 +0900, Tomasz Figa wrote:
> On Thu, Aug 30, 2018 at 11:23 PM Emil Velikov
> wrote:
> >
> > On 30 August 2018 at 11:41, Eric Engestrom wrote:
> > > On Thursday, 2018-08-30 17:55:14 +0900, Tomasz Figa wrote:
> > >> Hi Erik, Emil, Eric,
> > >>
> > >> On Tue, Jul 10,
On Sat, 2018-09-01 at 02:14 +0300, Andres Gomez wrote:
> Juan, should we also include this in the stable queues ?
>
Unless Daniel has a different opinion, yes, it should be included. Forgot to CC
to stable.
Thanks!
J.A.
>
> On Thu, 2018-08-30 at 13:59 +0200, Juan A. Suarez Romero
On Mon, Sep 3, 2018 at 2:45 PM Tomasz Figa wrote:
>
> Hi Emil,
>
> On Sat, Sep 1, 2018 at 2:03 AM Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
>
> Thanks for the patch! Please see my comments below.
>
> [snip]
> > @@ -1214,10 +1215,13 @@ droid_open_device_drm_gralloc(struct
> >
On Thu, Aug 30, 2018 at 11:23 PM Emil Velikov wrote:
>
> On 30 August 2018 at 11:41, Eric Engestrom wrote:
> > On Thursday, 2018-08-30 17:55:14 +0900, Tomasz Figa wrote:
> >> Hi Erik, Emil, Eric,
> >>
> >> On Tue, Jul 10, 2018 at 12:41 AM Erik Faye-Lund
> >> wrote:
> >> >
> >> > On Thu, Jul 5,
77 matches
Mail list logo
