Remove unused variables from clear_state and use a hardcoded location
for color uniform to get rid of 2 more variables. Modify shaders to use
explicit location for vertex attribute too as extension is enabled.
Signed-off-by: Tapani Pälli
---
src/mesa/drivers/common/meta.c | 27 --
This is brw_gs_surface_state.c copy and pasted twice with search and
replace.
brw_binding_table.c code is similarly copy and pasted.
v2: Drop dword_pitch related fields.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/Makefile.sources| 2 +
src/mesa/drivers/dri/i965/brw_
For the series:
Reviewed-by: Marek Olšák
On Thu, Dec 10, 2015 at 2:11 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This helps in the use of GALLIUM_DDEBUG_SKIP: first run a target application
> with skip set to a very large number and note how many draw calls happen
> before the bug. Th
I have to NAK this series, but I was able to find something about the issue.
If oViewport is used, VGT_REUSE_OFF must disable reuse. That's the correct fix.
If oViewport is constant, reuse can be enabled, but
VTE_VPORT_PROVOKE_DISABLE must be set.
Marek
On Fri, Dec 11, 2015 at 3:11 AM, Dave Air
On Wednesday, December 09, 2015 01:40:37 PM Jordan Justen wrote:
> On 2015-12-02 16:15:55, Kenneth Graunke wrote:
[snip]
> > + OUT_BATCH(GEN7_DS_ENABLE |
> > +GEN7_DS_STATISTICS_ENABLE |
> > +(brw->max_ds_threads - 1) << HSW_DS_MAX_THREADS_SHIFT |
>
> SET_FIELD
On Wednesday, December 09, 2015 01:44:39 PM Jordan Justen wrote:
> On 2015-12-02 16:15:56, Kenneth Graunke wrote:
> > Signed-off-by: Kenneth Graunke
> > ---
> > src/mesa/drivers/dri/i965/gen7_te_state.c | 36
> > ---
> > 1 file changed, 28 insertions(+), 8 deletions(-
Mostly related to making sure the rasterizer can correctly
pick out the correct scissor box for the current viewport.
Signed-off-by: Edward O'Callaghan
---
src/gallium/drivers/softpipe/sp_context.h | 9 ++-
src/gallium/drivers/softpipe/sp_quad.h| 1 +
src/gallium/drivers/so
Signed-off-by: Edward O'Callaghan
---
docs/GL3.txt | 2 +-
src/gallium/drivers/softpipe/sp_screen.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 7eda002..84b5a17 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@
https://bugs.freedesktop.org/show_bug.cgi?id=93261
poma changed:
What|Removed |Added
Component|GLX |Server/General
Assignee|mesa-dev@lists.
From: Christian König
It's nonsense to drain the pipeline like this.
Signed-off-by: Christian König
---
src/gallium/state_trackers/va/buffer.c | 5 -
src/gallium/state_trackers/va/image.c | 1 -
src/gallium/state_trackers/va/postproc.c | 6 --
src/gallium/state_trackers/v
From: Christian König
Tested with MPV.
Signed-off-by: Christian König
---
src/gallium/state_trackers/va/postproc.c | 72
src/gallium/state_trackers/va/surface.c | 16 ++-
2 files changed, 78 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_tr
From: Christian König
The picture id in this case is a VA-API surface handle, checking
for a certain value can't be correct.
Signed-off-by: Christian König
---
src/gallium/state_trackers/va/picture_hevc.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/gallium/state_trackers/va/pic
From: Christian König
Signed-off-by: Christian König
---
src/gallium/state_trackers/va/postproc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/src/gallium/state_trackers/va/postproc.c
b/src/gallium/state_trackers/va/postproc.c
index 1fdb4e7..2d17694 100644
--- a/src/gallium/state_t
From: Christian König
Signed-off-by: Christian König
---
src/gallium/state_trackers/va/picture.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index 8623139..7b30bf8 100644
--- a/src/gallium/state_trackers/v
From: Christian König
Signed-off-by: Christian König
---
src/gallium/state_trackers/va/surface.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
index c052c8f..4a18a6f 100644
--- a/src
From: Christian König
Usefull for mpv and GStreamer.
Signed-off-by: Indrajit-kumar Das
Signed-off-by: Christian König
---
src/gallium/state_trackers/va/picture.c | 10 +-
src/gallium/state_trackers/va/postproc.c | 152 ---
2 files changed, 125 insertions(+), 37 d
From: Christian König
Avoid referencing NULL pointers.
Signed-off-by: Christian König
---
src/gallium/state_trackers/va/postproc.c | 36 +---
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/va/postproc.c
b/src/gallium/state
Previously if the visual didn't have an alpha channel then it would
pick a format that is not sRGB-capable. I don't think there's any
reason not to always have an sRGB-capable visual. Since 28090b30 there
are now visuals advertised without an alpha channel which means that
games that don't request
brw_init_surface_formats overrides the render format for RGBX formats
which aren't supported for rendering so that they internally use RGBA
instead. However, B8G8R8X8_SRGB was missing so it wasn't marked as a
renderable format. This patch just adds it.
Cc: "11.0 11.1"
Cc: Ilia Mirkin
---
src/me
This will be used in a subsequent patch as the format for RGB visuals.
Cc: "11.0 11.1"
Cc: Ilia Mirkin
Suggested-by: Ilia Mirkin
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/d
Ilia Mirkin writes:
> I suspect that something like this may be the right thing for the
> intel driver... no reason not to expose sRGB-capable visuals when it
> so happens that alpha == 0. Also probably the same treatment should be
> done for BGR565... sRGB encoding will matter even more there, a
Jason Ekstrand writes:
> On Dec 10, 2015 6:58 AM, "Francisco Jerez" wrote:
>>
>> Jason Ekstrand writes:
>>
>> > We aren't using it anymore.
>>
>> It seems useful to me to be able to represent indirect access as part of
>> any instruction source or destination register.
>>
>> The following:
>>
>
Jason Ekstrand writes:
> On Dec 10, 2015 9:06 AM, "Francisco Jerez" wrote:
>>
>> Michael Schellenberger Costa
>> writes:
>>
>> > Hi,
>> >
>> > Am 10.12.2015 um 05:23 schrieb Jason Ekstrand:
>> >> Now that we have MOV_INDIRECT opcodes, we have all of the size
> information
>> >> we need directly
Ahh actually I suspect this really isn't right, and probably the root
cause of https://bugs.freedesktop.org/show_bug.cgi?id=80183 (which I
hack-fixed with 6d2ecdb4a63350cfeee803c00ac283ee013a5ee5 but did not
understand the reasons).
So I believe (regardless of this patch) for the ordinary xyz clipp
On 10/12/15 21:09, Brian Paul wrote:
---
src/gallium/drivers/svga/svga_context.h | 4
src/gallium/drivers/svga/svga_draw.c| 17 -
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_context.h
b/src/gallium/drivers/svga/svga_
On 11/12/15 04:43, srol...@vmware.com wrote:
From: Roland Scheidegger
Otherwise, if struct vertex_info is changed, you're in for some surprises...
---
src/gallium/auxiliary/draw/draw_pt_fetch.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/
When programming the fast clear color there was previously a chunk of
code to try to make the color match the constraints of the surface
format such as by filling in missing components and handling luminance
formats. These cases are not handled by the hardware. There are some
additional possible re
On Fri, Dec 11, 2015 at 7:32 AM, Neil Roberts wrote:
> Previously if the visual didn't have an alpha channel then it would
> pick a format that is not sRGB-capable. I don't think there's any
> reason not to always have an sRGB-capable visual. Since 28090b30 there
> are now visuals advertised witho
On Dec 11, 2015 5:44 AM, "Francisco Jerez" wrote:
>
> Jason Ekstrand writes:
>
> > On Dec 10, 2015 6:58 AM, "Francisco Jerez"
wrote:
> >>
> >> Jason Ekstrand writes:
> >>
> >> > We aren't using it anymore.
> >>
> >> It seems useful to me to be able to represent indirect access as part
of
> >> a
Neil Roberts writes:
> Previously if the visual didn't have an alpha channel then it would
> pick a format that is not sRGB-capable. I don't think there's any
> reason not to always have an sRGB-capable visual. Since 28090b30 there
> are now visuals advertised without an alpha channel which means
On Fri, Dec 11, 2015 at 1:02 PM, Kristian Høgsberg wrote:
> Neil Roberts writes:
>
>> Previously if the visual didn't have an alpha channel then it would
>> pick a format that is not sRGB-capable. I don't think there's any
>> reason not to always have an sRGB-capable visual. Since 28090b30 there
Tapani Pälli writes:
> Remove unused variables from clear_state and use a hardcoded location
> for color uniform to get rid of 2 more variables. Modify shaders to use
> explicit location for vertex attribute too as extension is enabled.
>
> Signed-off-by: Tapani Pälli
Reviewed-by: Kristian Høgs
Reviewed-by: Jordan Justen
On 2015-12-02 16:15:57, Kenneth Graunke wrote:
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/gen8_hs_state.c | 64
> ---
> 1 file changed, 51 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/g
Pushed, thanks!
Roland
Am 11.12.2015 um 12:43 schrieb Edward O'Callaghan:
> Mostly related to making sure the rasterizer can correctly
> pick out the correct scissor box for the current viewport.
>
> Signed-off-by: Edward O'Callaghan
> ---
> src/gallium/drivers/softpipe/sp_context.h |
This is a helper function for setting up the local invocation ID
payload according to the cs_prog_data generated by the compiler. It's
intended to be available to users of libi965_compiler so move it there.
---
src/mesa/drivers/dri/i965/brw_compiler.h | 7 +++
src/mesa/drivers/dri/i965/brw_cs
At some point, we need to stop shoving stuff in brw_fs.cpp. Howevver,
this doesn't really make it any worse, and does move it to the
compiler.
Acked-by: Jason Ekstrand
On Fri, Dec 11, 2015 at 11:22 AM, Kristian Høgsberg Kristensen
wrote:
> This is a helper function for setting up the local inv
On Fri, Dec 11, 2015 at 11:22 AM, Kristian Høgsberg Kristensen
wrote:
> This is a helper function for setting up the local invocation ID
> payload according to the cs_prog_data generated by the compiler. It's
> intended to be available to users of libi965_compiler so move it there.
I moved this t
The offset for loads is in src[0]. This was a copy+paste error in the
nir_intrinsic_load/store refactoring. This commit fixes a segfault in
ES31-CTS.compute_shader.work-group-size. I have no idea how piglit failed
to catch this...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93348
---
On 2015-12-11 11:58:41, Matt Turner wrote:
> On Fri, Dec 11, 2015 at 11:22 AM, Kristian Høgsberg Kristensen
> wrote:
> > This is a helper function for setting up the local invocation ID
> > payload according to the cs_prog_data generated by the compiler. It's
> > intended to be available to users
On Fri, Dec 11, 2015 at 12:17 PM, Jordan Justen
wrote:
> On 2015-12-11 11:58:41, Matt Turner wrote:
>> On Fri, Dec 11, 2015 at 11:22 AM, Kristian Høgsberg Kristensen
>> wrote:
>> > This is a helper function for setting up the local invocation ID
>> > payload according to the cs_prog_data generate
Matt Turner writes:
> On Fri, Dec 11, 2015 at 11:22 AM, Kristian Høgsberg Kristensen
> wrote:
>> This is a helper function for setting up the local invocation ID
>> payload according to the cs_prog_data generated by the compiler. It's
>> intended to be available to users of libi965_compiler so m
It's not just whether GL_MULTISAMPLE is 1 that determines if multisample
framebuffer operations happen, it's also whether SAMPLE_BUFFERS > 1.
Noticed with my broken sample_mask support when ETQW traces that were only
using a single sampled buffer crashed.
---
src/mesa/state_tracker/st_atom_blend.c
On Fri, Dec 11, 2015 at 3:37 PM, Eric Anholt wrote:
> It's not just whether GL_MULTISAMPLE is 1 that determines if multisample
> framebuffer operations happen, it's also whether SAMPLE_BUFFERS > 1.
> Noticed with my broken sample_mask support when ETQW traces that were only
> using a single sample
Kenneth Graunke writes:
> I want to use this directly from brw_vec4_generator.cpp.
>
> Signed-off-by: Kenneth Graunke
Reviewed-by: Kristian Høgsberg
> ---
> src/mesa/drivers/dri/i965/brw_eu.h | 8
> src/mesa/drivers/dri/i965/brw_eu_emit.c | 2 +-
> 2 files changed, 9 insertions
Kenneth Graunke writes:
> Tessellation evaluation shaders work almost identically to vertex
> shaders - we have a set of URB writes at the end of the program, and the
> last one should terminate it.
>
> Geometry shaders really are the special case, where multiple
> EmitVertex() calls trigger URB
Kenneth Graunke writes:
> Tessellation evaluation shaders will use g4 instead. For now, make an
> fs_reg called urb_handle and use that in place of hardcoding g1.
>
> Signed-off-by: Kenneth Graunke
Reviewed-by: Kristian Høgsberg
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 9 +
My tessellation branch has two additional remap functions. I don't want
to replicate this logic there.
v2: Handle inputs/outputs separately (suggested by Jason Ekstrand).
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_nir.c | 93 +++--
1 file c
The compact VUE map only works when varying packing is in use.
Unfortunately, varying packing is disabled for TCS inputs.
This is needed to fix Piglit's tcs-input-read-array-interface test.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_nir.c | 2 +-
src/mesa/drivers/dri/i965/
The hardware provides us no decent way of getting at the number of input
vertices in the patch topology from the tessellation control shader.
It's actually very surprising - normally this sort of information would
be available in the thread payload.
For the precompile, we guess that the number of
TES outputs work exactly like VS outputs, so we can simply add a case
statement for those.
TCS inputs are very similar to geometry shaders - they're arrays of
per-vertex data. We use the same method I used for the scalar GS
backend.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/
The TCS is the first tessellation shader stage, and the most
complicated. It has access to each of the control points in the input
patch, and computes a new output patch. There is one logical invocation
per output control point; all invocations run in parallel, and can
communicate by reading and
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_nir.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_nir.c
b/src/mesa/drivers/dri/i965/brw_nir.c
index d405991..3cb6123 100644
--- a/src/mesa/drivers/dri/i965/brw_nir.c
+++ b/src/mesa
Without varying packing, if a VS writes a compound variable, and the GS
only reads part of it, the base location of the variable may not
actually be in the VUE map.
To cope with this, we do lowering in terms of varying slots, add any
constant offsets to the base, and then do the VUE map remapping.
The TES is essentially a post-tessellator VS, which has access to the
entire TCS output patch, and a special gl_TessCoord input. Otherwise,
they're very straightforward.
This patch implements SIMD8 tessellation evaluation shaders for Gen8+.
The tessellator can generate a lot of geometry, so opera
Instead of performing the read-modify-write cycle in glsl->nir, we can
simply emit a partial writemask. For locals, nir_lower_vars_to_ssa will
do the equivalent read-modify-write cycle for us, so we continue to get
the same SSA values we had before.
Because glsl_to_nir calls nir_lower_outputs_to_
Tessellation control shaders need to be careful when writing outputs.
Because multiple threads can concurrently write the same output
variables, we need to only write the exact components we were told.
Traditionally, for sub-vector writes, we've read the whole vector,
updated the temporary, and wr
From: Chris Forbes
v2: Rewrite the push constant allocation code to be clearer.
Only apply the minimum VS entries workaround on Gen 8.
Signed-off-by: Chris Forbes
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 21 +++-
src/mesa/drivers/dri/i965/gen7_blorp.c
Based on a patch by Chris Forbes, but largely rewritten by Ken.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_compiler.h | 20 ++-
src/mesa/drivers/dri/i965/brw_vue_map.c | 98 ++--
2 files changed, 111 insertions(+), 7 deletions(-)
diff --git
TCS outputs and TES inputs both refer to a common "patch URB entry"
shared across all invocations. First, there are some number of
per-patch entries. Then, there are per-vertex entries accessed via
an offset for the variable and a stride times the vertex index.
Because these calculations need to
From: Roland Scheidegger
ARB_fragment_layer_viewport requires that if a fs reads layer or viewport
index but it wasn't output by gs (or vs with other extensions), then it reads
0. This never worked for llvmpipe, and is surprisingly non-trivial to fix.
The problem is the mechanism to handle non-ex
On 11/12/15 21:31, srol...@vmware.com wrote:
From: Roland Scheidegger
ARB_fragment_layer_viewport requires that if a fs reads layer or viewport
index but it wasn't output by gs (or vs with other extensions), then it reads
0. This never worked for llvmpipe, and is surprisingly non-trivial to fix
Jason Ekstrand writes:
> The offset for loads is in src[0]. This was a copy+paste error in the
> nir_intrinsic_load/store refactoring. This commit fixes a segfault in
> ES31-CTS.compute_shader.work-group-size. I have no idea how piglit failed
> to catch this...
>
> Bugzilla: https://bugs.freed
Reviewed-by: Jordan Justen
On 2015-12-11 12:16:01, Jason Ekstrand wrote:
> The offset for loads is in src[0]. This was a copy+paste error in the
> nir_intrinsic_load/store refactoring. This commit fixes a segfault in
> ES31-CTS.compute_shader.work-group-size. I have no idea how piglit failed
>
From OpenGL 4.0 spec, section 4.3.2 "Copying Pixels":
"The pixels corresponding to these buffers are copied from the source
rectangle bounded by the locations (srcX0, srcY 0) and (srcX1, srcY 1)
to the destination rectangle bounded by the locations (dstX0, dstY 0)
and (dstX1, dstY 1). The lower
From OpenGL 4.0 spec, section 4.3.2 "Copying Pixels":
"The pixels corresponding to these buffers are copied from the source
rectangle bounded by the locations (srcX0, srcY 0) and (srcX1, srcY 1)
to the destination rectangle bounded by the locations (dstX0, dstY 0)
and (dstX1, dstY 1). The lower bou
Ilia Mirkin writes:
> On Fri, Dec 11, 2015 at 3:37 PM, Eric Anholt wrote:
>> It's not just whether GL_MULTISAMPLE is 1 that determines if multisample
>> framebuffer operations happen, it's also whether SAMPLE_BUFFERS > 1.
>> Noticed with my broken sample_mask support when ETQW traces that were o
On Fri, Dec 11, 2015 at 6:56 PM, Eric Anholt wrote:
> Ilia Mirkin writes:
>
>> On Fri, Dec 11, 2015 at 3:37 PM, Eric Anholt wrote:
>>> It's not just whether GL_MULTISAMPLE is 1 that determines if multisample
>>> framebuffer operations happen, it's also whether SAMPLE_BUFFERS > 1.
>>> Noticed wit
Hmm actually there were some piglit regressions.
I don't mind the ones from the arb_fragment_layer_viewport group from
skip to pass (up to today they failed in llvmpipe too and we don't have
a cap bit for this functionality separately).
However, this broke some more basic stuff like vs point size o
From: Roland Scheidegger
clip -> clip_vertex and pre_clip_pos -> clip_pos.
Looks more obvious to me what these values actually represent (so use
something resembling the vs output names).
---
src/gallium/auxiliary/draw/draw_cliptest_tmp.h | 4 +--
src/gallium/auxiliary/draw/draw_llvm.c
From: Roland Scheidegger
I'm pretty sure this should use position (i.e. pre_clip_pos) and not
the output from clipVertex. Albeit piglit doesn't care. It is what we
use in the clip test, and it is what every other driver does (as they
don't even have clipVertex output and lower the additional plan
From: Roland Scheidegger
Seems obvious now this should use the data from position and not clip_vertex
(albeit might not really make a difference).
---
src/gallium/auxiliary/draw/draw_pipe_clip.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/draw/
From: Roland Scheidegger
vertex header had both clip_pos and clip_vertex.
We only really need one (clip_pos) because the draw llvm shader would
overwrite the position output from the vs with the viewport transformed.
However, we don't really need the second one, which was only really used
for gl_
From: Roland Scheidegger
This is just for code cleanup, conceptually the have_clipdist really
isn't per-vertex state, so don't put it there (just dependent on the
shader). Even though there wasn't really any overhead associated with
this, we shouldn't store random shader information in the vertex
Emil Velikov writes:
> The third release candidate for Mesa 11.1.0 is now available.
With the kernel stuff now looking ready to merge upstream, I'd like to
merge support for vc4 based on the headed-upstream kernel ABI to the
11.1 branch. I've prepared a series at:
https://github.com/anholt/mes
This allows the fallback paths to handle it correctly.
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/intel_blit.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
b/src/mesa/drivers/dri/i965/intel_blit.c
index d4e25d8..
Overlapping blits are anyway undefined in OpenGL. So no need
of overlap check here.
Cc: Chad Versace
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/intel_blit.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
b/src/mesa/drivers/dri/i965/
Experimentation with different values for src/dst horizontal/vertical
alignment showed that these fileds are not used on gen9 hardware.
So, this patch removes the code to setup those fields. A bug has been
created to get the spec language corrected.
Note: Setting up these fields isn't hurting on S
Changing the suggested alignmnet caused piglit regressions. halign and
valign fields in fast copy blit are not used anyways. See more details
in a later patch.
Cc: Chad Versace
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 4 ++--
1 file changed, 2 insertions(+), 2
Fast copy blit is currently enabled for use only with Yf/Ys tiling.
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/intel_blit.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
b/src/mesa/drivers/dri/i965/intel_blit.c
ind
I think it actually works like this: llvmpipe has a single vertex
layout, which it tells draw about, which will then emit the vertices in
this format.
However, softpipe will always tell draw to emit the vertices as-is (via
its first layout). Its second layout has draw written all over it but
draw d
80 matches
Mail list logo
