Hi,
AFAIK we disable logic ops after each usage, so this seems a bit
redundant to me. Did we miss one usages? As logic ops aren't very
common, this sounds good to me.
Am 2016-05-13 13:29, schrieb Keith Packard:
If the logic op gets left enabled, it overrides the blending
operation, causing i
Am 2015-03-26 03:33, schrieb Eric Anholt:
The only reason _nf is useful is if you need to implement faster
software fallbacks -- otherwise, you should wrap above glamor, since
_nf
would have been equivalent to calling down.
For faster fallbacks, we could delay the uploading part at the end of
glEGLImageTargetTexture2DOES only set the first level.
Mesa handles this new texture as incomplete and renders a black screen.
We also want to prevent linear filtering.
https://bugs.freedesktop.org/show_bug.cgi?id=81800
Signed-off-by: Markus Wick
---
hw/xwayland/xwayland-glamor.c | 3 +++
1
://bugs.freedesktop.org/show_bug.cgi?id=81800
Signed-off-by: Markus Wick
---
hw/xwayland/xwayland-glamor.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index 09b454f..dd85518 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw
Yeah, I did wrote it. But meanwhile, I'd remove the MAX_LEVEL parameter
as this isn't allowed in gl es.
@Jasper: Texture storage isn't possible here as this texture is
allocated by egl.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://l
STREAM (used once) READ (accessed
by the CPU), so
Reviewed-by: Markus Wick
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Hi,
kwin still works fine.
If you'll remove the "ErrorF" lines, this patch is:
Reviewed-by: Markus Wick
Am 2014-07-17 01:13, schrieb Keith Packard:
I think I understand the code and now believe that both the original
fixed versions are incorrect. However, I cannot repro
Oh, how did I miss this ...
Reviewed-by: Markus Wick
Am 2014-06-28 21:27, schrieb Tomasz Borowik:
From 0a6d1c900b6d5559c50c703480a479a59689b8be Mon Sep 17 00:00:00 2001
From: timon37
Date: Sat, 28 Jun 2014 21:26:27 +0200
Subject: [PATCH] glamor: Fix stack corruption in glamor_init, glGet on
Hi Keith,
here a small summary of my monolog on #org-devel:
Am 2014-05-13 18:02, schrieb Keith Packard:
So in the end, I fear we have to add an offset based on the direction
of
the line. But this shouldn't be as hard with instancing :)
No, we just need to move the lines so that they line up w
Signed-off-by: Markus Wick
---
glamor/glamor_image.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/glamor/glamor_image.c b/glamor/glamor_image.c
index 4791d08..c087a13 100644
--- a/glamor/glamor_image.c
+++ b/glamor/glamor_image.c
@@ -92,6 +92,7 @@ glamor_put_image_bail(DrawablePtr
The max size of renderbuffers and texture often match by accident, but as we
always use textures, we should check for the right flag.
Also check for viewport size as this may be lower and we want to render to
almost every pixmap.
Signed-off-by: Markus Wick
---
glamor/glamor.c | 5 -
1
vram wasting warnings.
Signed-off-by: Markus Wick
---
glamor/glamor_fbo.c| 1 +
glamor/glamor_font.c | 1 +
glamor/glamor_pixmap.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
index 5521683..090dfd8 100644
--- a/glamor/glamor_fbo.c
+++ b/g
Am 2014-05-13 17:34, schrieb Keith Packard:
Sure, if glsl had a 'round' function I'd use it in a second :-)
It was added in glsl130. As you use uvec which was also added in
glsl130, it's fine.
I'm a bit worried about this loop order. We don't change the programm
at
all, so glamor_use_progra
Am 2014-05-06 00:02, schrieb Keith Packard:
+static const char on_off_fs_exec[] =
+" float pattern = texture2D(dash, vec2(dash_offset,
0.5)).w;\n"
+" if (pattern == 0.0)\n"
+" discard;\n";
Did you care about the sampler configuration? eg with linear filte
Am 2014-05-06 00:02, schrieb Keith Packard:
+static const glamor_facet glamor_facet_poly_lines = {
+.name = "poly_lines",
+.vs_vars = "attribute vec2 primitive;\n",
+.vs_exec = (" vec2 pos = vec2(0.0,0.0);\n"
+GLAMOR_POS(gl_Position, primitive.xy)),
+};
iirc th
src,
...
+glTextureBarrierNV();
I think a comment is required here why we have to call
glTextureBarrierNV at all. eg what happens when we get two copy calls in
a row, both doesn't overlap, but they overlap each other. So the second
call might want to r
Am 2014-03-19 06:09, schrieb Keith Packard:
+glamor_pixmap_loop(src_priv, src_box_x, src_box_y) {
+glamor_pixmap_loop(dst_priv, dst_box_x, dst_box_y) {
+for (b = 0; b < nbox; b++) {
Are you sure that this loop order is safe?
Eg what happens, when we copy the
Am 2014-03-24 20:47, schrieb Keith Packard:
Even still, uxa is significantly faster than glamor on this one; uxa
has
a simple test for a request that contains only vertical and horizontal
lines and fills those as rectangles. We could easily do the same thing
in glamor, which should yield better
Am 2014-03-24 06:28, schrieb Keith Packard:
1: intel-glamor.perf
2: intel-glamor-line.perf
1 2 Operation
- -
471000.023100.0 ( 490.446) 1-pixel line
297000.020900.0
Am 2014-03-20 22:55, schrieb Keith Packard:
tbh, without an PBO, this is wrose than the fb fallback as it's one
stall per span.
Yes, it's completely miserable. However, it will never be called as the
only paths to get here are short-circuited above this in the driver.
The
only way to even tes
Am 2014-03-21 00:43, schrieb Keith Packard:
more important to only get one mipmap level: max_level = 0
I copied this code from elsewhere; do you have a substitute suggestion?
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0);
The other parameters are sampler parameters, max_level is a te
Am 2014-03-21 00:46, schrieb Keith Packard:
Patches 7-9 are really nice, but there should be a glsl130+instancing
fallback with another vertex format + shaders.
I'd like to know which hardware is going to need this particular
fallback?
eg ironlake. But I more think about new GPU where the driv
Am 2014-03-20 23:22, schrieb Keith Packard:
I think this functions are worth to reimplement. eg horizontal lines
are
used a lot and very slow on mi.
Having sped up the underlying functions, they're not terrible at this
point:
200 reps @ 0.0035 msec (288000.0/sec): 500-pixel horizont
Am 2014-03-20 23:35, schrieb Keith Packard:
We are used to also disable the gl program here unnecessaryly.
I want to strip them all, so I'm fine without it, but it isn't fair
for
a performance comparison.
I stripped them out in an earlier patch; we could measure performance
at
that point?
Am 2014-03-20 23:07, schrieb Keith Packard:
+glCopyPixels (dx1 + dx - src_box->x1,
+ dy1 + dy - src_box->y1,
+ dx2 - dx1, dy2 - dy1, GL_COLOR);
This functions are deprecated fortunately. Please don't use them
This patch series is a very nice cleanup. I like the new way how this
functions should be implemented, but the shader generator. Plain GLSL +
predefined header are less confusing and more flexible imo.
We also have to figure out on which gl extension we want to rely on. eg
I don't think we sho
I think this functions are worth to reimplement. eg horizontal lines are
used a lot and very slow on mi.
How are the interpolation requirement for a line? Is it possible to
achive them with an opengl quad?
Am 2014-03-19 06:09, schrieb Keith Packard:
Use mi line code for now
Signed-off-by: Kei
Am 2014-03-19 06:09, schrieb Keith Packard:
Uses glCopyPixels for self-copies, otherwise paints with textures.
Performs CPU to GPU transfers for pixmaps in memory.
Accelerates copy plane when both objects are in memory
Includes copy_window acceleration too.
Signed-off-by: Keith Packard
---
gla
Am 2014-03-19 06:09, schrieb Keith Packard:
This accelerates spans operations using GPU-based geometry computation
Signed-off-by: Keith Packard
---
glamor/Makefile.am| 1 +
glamor/glamor.c | 2 +-
glamor/glamor_core.c | 4 +-
glamor/glamor_priv.h | 18 +++
glamor/glamor_span
Am 2014-03-19 06:09, schrieb Keith Packard:
This accelerates poly point when possible by off-loading all geometry
computation to the GPU.
Signed-off-by: Keith Packard
---
glamor/glamor_polyops.c | 92
++---
glamor/glamor_priv.h| 3 ++
2 files
Am 2014-03-19 06:09, schrieb Keith Packard:
These use glTexSubimage2D for upload and glReadPixels for
download. There are a variety of interfaces to the basic function as
needed by the callers.
Signed-off-by: Keith Packard
---
glamor/Makefile.am | 2 +
glamor/glamor_transfer.c | 260
+
Am 2014-03-19 06:09, schrieb Keith Packard:
This just adds a bunch of support code to construct shaders from
'facets', which bundle attributes needed for each layer of the
rendering system. At this point, that includes only the primtive and
the fill stuff.
Signed-off-by: Keith Packard
---
glam
From: Eric Anholt
v2: Fix crash because of removed strdup. (by Markus Wick)
---
hw/kdrive/src/kxv.c | 27 ++-
hw/kdrive/src/kxv.h | 36 ++--
2 files changed, 4 insertions(+), 59 deletions(-)
diff --git a/hw/kdrive/src/kxv.c b/hw/kdrive
---
glamor/glamor.c | 6 +++---
glamor/glamor_core.c | 23 ---
glamor/glamor_priv.h | 5 -
3 files changed, 3 insertions(+), 31 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index 9d171b7..ef969e2 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -
The mbr path was hard coded enabled for desktop gl and disabled for gles.
But there are both, desktop without mbr and mobiles with mbr.
---
glamor/glamor.c | 2 ++
glamor/glamor_priv.h | 1 +
glamor/glamor_vbo.c | 4 ++--
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/glamor/
---
glamor/glamor.c | 10 +-
glamor/glamor_core.c | 22 --
glamor/glamor_priv.h | 1 -
3 files changed, 5 insertions(+), 28 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index 0f7d68b..9d171b7 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -3
---
glamor/glamor_fill.c | 3 ---
glamor/glamor_gradient.c | 4
glamor/glamor_render.c| 6 +-
glamor/glamor_trapezoid.c | 6 --
4 files changed, 1 insertion(+), 18 deletions(-)
diff --git a/glamor/glamor_fill.c b/glamor/glamor_fill.c
index 7461b62..2fa726e 100644
--- a/glam
They are already cleared in glamor_put_vbo_space.
---
glamor/glamor_gradient.c | 8
1 file changed, 8 deletions(-)
diff --git a/glamor/glamor_gradient.c b/glamor/glamor_gradient.c
index ce24d73..c24f342 100644
--- a/glamor/glamor_gradient.c
+++ b/glamor/glamor_gradient.c
@@ -1120,8 +1120
We don't care that much about startup time to write different code paths...
---
glamor/glamor_render.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 62236b9..cdf8eff 100644
--- a/glamor/glamor_rend
But I still don't know if the last patch is worth as this code will likely be
removed soon by Keith.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
This fixes gtkperf. It seemed to hang forever.
---
glamor/glamor_gradient.c | 48
1 file changed, 4 insertions(+), 44 deletions(-)
diff --git a/glamor/glamor_gradient.c b/glamor/glamor_gradient.c
index f77d6a8..38dac68 100644
--- a/glamor/glamor_gr
We will never ever run on OpenGL 1.2 as we use shaders everywhere.
2.0 may be enough, but we also often use PBOs and our big shaders
won't fit into the first GLSL limits.
---
glamor/glamor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
i
---
glamor/glamor_fill.c | 40
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/glamor/glamor_fill.c b/glamor/glamor_fill.c
index 2fa726e..3286aa1 100644
--- a/glamor/glamor_fill.c
+++ b/glamor/glamor_fill.c
@@ -190,9 +190,6 @@ _glamor_solid_
Patch 1 seems to fix my issue on nvidia, so:
Tested-by: Markus Wick
Patches 2-5 are:
Reviewed-by: Markus Wick
Patches 7-9 are really nice, but there should be a glsl130+instancing
fallback with another vertex format + shaders.
Patch 10 also have to check for gl extensions. We could fall
First, I like to have some common functions to compile our shaders, bind
common uniforms, defining common headers, ...
But tbh I don't see why it's easier to split up the glsl source
completely. Most shaders aren't more than 5 loc, so they are easier to
read entirely.
In dolphin, we've a common
Am 2014-03-14 07:30, schrieb Keith Packard:
diff --git a/glamor/glamor_font.c b/glamor/glamor_font.c
new file mode 100644
index 000..4f303b9
--- /dev/null
+++ b/glamor/glamor_font.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright © 2014 Keith Packard
+ *
+ * Permission to use, copy, modify, distribute, a
Am 2014-03-14 07:30, schrieb Keith Packard:
diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c
index 96723c0..8c10c92 100644
--- a/glamor/glamor_core.c
+++ b/glamor/glamor_core.c
@@ -410,7 +410,7 @@ glamor_stipple(PixmapPtr pixmap, PixmapPtr stipple,
}
GCOps glamor_gc_ops = {
-.FillS
This one looks so similiar with your last one, isn't there a way to
merge them?
There would be an unneeded multiplication in the shader and the padding
with one, everything else could be as it is.
So there are also the same issues as in the last patch.
__
Am 2014-03-14 07:30, schrieb Keith Packard:
diff --git a/glamor/glamor_polyops.c b/glamor/glamor_polyops.c
index 1484d80..eac1688 100644
--- a/glamor/glamor_polyops.c
+++ b/glamor/glamor_polyops.c
@@ -27,17 +27,93 @@
*/
#include "glamor_priv.h"
+#include "glamor_transform.h"
+
+static const g
Am 2014-03-14 07:29, schrieb Keith Packard:
diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c
index 5e98bfe..31e0730 100644
--- a/glamor/glamor_vbo.c
+++ b/glamor/glamor_vbo.c
@@ -153,6 +153,7 @@ glamor_put_vbo_space(ScreenPtr screen)
glBufferData(GL_ARRAY_BUFFER, glamor_priv->vbo_o
Yeah, this fixes a crash in
"kdrive: Remove duplicated definitions of some XV-related structs.".
But as this patch was skipped in the megaseries, there is no need in
only applying this fix.
Maybe squashing both patches together as the origin was a nice cleanup?
Am 2014-03-14 07:29, schrieb Kei
wow, big patch series ...
Patches 3-5, 7-22, 24-27 are:
Reviewed-by: Markus Wick
But as 21-22 are very big one, I'd like to see another review from
someone familiar with the X11 renderings. But the gl code is fine :D
Patches 1, 2, 6, 23 also looks fine for me, but I don't kno
Is there a generic mi fallback for all poly_lines? If not, I'd suggest
to move this logic into mi itself.
Am 2014-03-11 22:30, schrieb Eric Anholt:
If the lines aren't solid-filled vert/horiz solid-filled rectangles,
we fall back. libreoffice has some diagonal lines, and the
performance of the
Are we able to add cached textures to CharInfoPtr? If not, then this
would be the ideal use case for texture_arrays ;)
Again, using GL_POINTS and check for every bit on CPU isn't the way to
go.
Am 2014-03-11 22:30, schrieb Eric Anholt:
Using the same idea as the previous PushPixels code, just
I didn't find any issues in this patch, but I don't see the point:
Do we really want to convert a pixmap with 1 bit per pixel into a list
of enabled pixels on cpu?
Isn't it as easy to upload this pixmap as texture and do everything else
in the pixel shader?
In this way, we won't have to care ab
Am 2014-03-11 22:30, schrieb Eric Anholt:
The common pattern is to do nested if statements making calls to
prepare_access() and then pop those mappings back off in each set of
braces. Some cases checked for src == dst to avoid leaking mappings,
but others didn't. Others didn't even do the neste
Am 2014-03-11 22:30, schrieb Eric Anholt:
This unpacks the bitfield into an int size, but my experience has been
that packing bitfields doesn't matter for performance.
Signed-off-by: Eric Anholt
---
glamor/glamor_fbo.c | 2 +-
glamor/glamor_priv.h | 25 -
2 files chan
Am 2014-03-11 22:30, schrieb Eric Anholt:
diff --git a/glamor/glamor.h b/glamor/glamor.h
index e25dc73..9cda46d 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -131,14 +131,6 @@ extern _X_EXPORT void
glamor_set_screen_pixmap(PixmapPtr screen_pixmap,
extern _X_EXPORT uint32_t glamor_get_pi
Am 2014-03-10 21:09, schrieb Eric Anholt:
On release builds, glGetError won't be called and so this won't clear
the gl error log. So we'll fall back to the mbr code because of any gl
error somewhere in glamor.
Yeah, I think that's fine -- you shouldn't have any errors, anyway.
But then, we sh
There are some trival issues in patch 7 and 9. After fixing them,
patches 2-9 will be:
Reviewed-by: Markus Wick
Am 2014-03-09 05:07, schrieb Eric Anholt:
Here's a series for the reusable VBO support code in glamor. The
Render code using it still pretty scary, but it seems to work, and
Am 2014-03-09 05:07, schrieb Eric Anholt:
diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c
new file mode 100644
index 000..be2c2af
--- /dev/null
+++ b/glamor/glamor_vbo.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, t
Am 2014-03-09 05:07, schrieb Eric Anholt:
v2:
- Make the default buffer size a #define. (by Markus Wick)
- Fix the return offset for mapping with buffer_storage. (oops!)
v3:
- Avoid GL error at first rendering from unmapping no buffer.
- Rebase on the glBindBuffer(GL_ARRAY_BUFFER, 0
Am 2014-03-09 05:07, schrieb Eric Anholt:
The argument to setup_composte_vbo is the number of verts.
Signed-off-by: Eric Anholt
---
glamor/glamor_render.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 7829977..63b
Am 2014-03-09 05:07, schrieb Eric Anholt:
+vb += i * glamor_priv->vb_stride / 4;
This should be "/ sizeof(float)" instead.
+vb += 3 * glamor_priv->vb_stride / 4;
Here also.
___
xorg-devel@lists.x.org: X.Org development
A
Patches 1-5 are:
Reviewed-by: Markus Wick
Am 2014-03-06 18:00, schrieb Eric Anholt:
Here are some trivial patches from the glamor-server branch for
review. I'm planning to send out the VBO changes next, which get us
closer to making glamor not actually suck for performance.
These are o
Am 2014-03-06 18:00, schrieb Eric Anholt:
PRIVATE_ALL was apparently dropped before
There wasn't any PRIVATE_ALL key neither in xserver nor in glamor. I
guess it's just a wrong reference to privates.h, so it's the same as the
enum DevPrivateKey itself.
_
Am 2014-03-06 18:00, schrieb Eric Anholt:
+/* We'd like to require GL_ARB_map_buffer_range or
OpenGL ES 3 or
+ * GL_OES_map_buffer_range, since it offers more information to
+ * the driver than plain old glMapBuffer() or glBufferSubData().
+ * It's been supported on Mesa on the
67 matches
Mail list logo