from the screen, just use the pFormat
that came from our source picture. The only time we need to look up a
PictFormat when we're doing non-shader gradients, which we put in
a8r8g8b8.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_render.c | 16 +---
1 file chan
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_font.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/glamor/glamor_font.c b/glamor/glamor_font.c
index 6b3a16a..6753d50 100644
--- a/glamor/glamor_font.c
+++ b/glamor/glamor_font.c
@@ -127,8 +127,13 @@ glamor_fo
If the glTexImage (or glTexSubImage) out-of-memories, error out
cleanly so that we can fall back to software.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_picture.c | 37 ++---
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/
The spec allows general undefined behavior when GL_OOM is thrown. But
if the driver happens to throw the error at this point, it probably
means the pixmap was just too big, so we should delete that texture
and have this pixmap fall back to software.
Signed-off-by: Eric Anholt <e...@anholt.
We already have a fallback path, so we just need to jump to it when we
hit the failure.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_composite_glyphs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/glamor/glamor_composite_glyphs.c b/
It is a modest performance improvemnt (2.7% on Intel), with the
significant downside that it keeps extra pixmap contents laying around
for 1000 BlockHandlers without the ability for the system to purge
them when under memory pressure, and tiled renderers don't know that
we could avoid reading
This GBM import path was introduced in 10.2, which we already require.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_egl.c | 37 +++--
1 file changed, 7 insertions(+), 30 deletions(-)
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
I think void * was just used to avoid needing to #include gbm.h, but
we can just forward-declare the structs and be fine.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor.h | 11 +++
glamor/glamor_egl.c | 7 ---
2 files changed, 11 insertions(+), 7 del
source, this
improves x11perf -copypixwin100 from about 4300/sec to 5780/sec under
xcompmgr -a, because we no longer need to upload our x11perf window to
a tiled temporary in order to render it to the screen.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor.c
The DestroyPixmap chain and CloseScreen chain all do pixmap teardown
already, and calling it manually would be redundant.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor.h | 1 -
glamor/glamor_egl.c | 6 --
2 files changed, 7 deletions(-)
diff --git a/glamor/glam
We were rolling ioctl calls ourselves, when there's a nice interface
for it.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_egl.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 7
if the EGLImage object is
destroyed by a call to DestroyImageKHR.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_egl.c | 37 ++---
glamor/glamor_priv.h | 5 -
2 files changed, 6 insertions(+), 36 deletions(-)
diff --git a/glamor/glamor_e
* want to throw away the rendering to it.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_egl.c | 4
1 file changed, 4 deletions(-)
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 2e6c7bd..cc16b0a 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor
This is a branch I've been working on for a while for glamor,
targeting 1.19. The observation is that X allocates many pixmaps,
only a few of which will be shared between clients, and sharing a new
pixmap between clients is infrequent. Given this, we can allocate
higher-performance non-shared
DestroyPixmap handles that just fine. This also lets us drop our use
of the manual image destruction function (Note that the ATI driver
still uses it in a similar fashion, though).
Signed-off-by: Eric Anholt <e...@anholt.net>
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 6 ---
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_egl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index fde7688..e68af18 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -369,9
This is just a bit of the DestroyPixmap chain.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor.c | 9 ++---
glamor/glamor.h | 1 -
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index d4a0236..dbaee46 100644
--- a/
One less layering violation (EGL should call glamor, if anything, not
the other way around).
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor.c | 3 ---
glamor/glamor.h | 2 --
glamor/glamor_egl.c
Rob Clark writes:
> For example, in the PolyFillRect() path w/ nrect==0, we end up in
> glamor_get_vbo_space(size=0):
I wonder instead if we shouldn't just have glamor_get_vbo_space() return
NULL on size == 0?
signature.asc
Description: PGP signature
Keith Packard kei...@keithp.com writes:
Eric Anholt e...@anholt.net writes:
Now that it's always non-null when the pixmap is non-null, we don't
need so much of this. glamor_get_pixmap_private() itself still
accepts a NULL pixmap and returns NULL, because of glamor_render.c
Might want
Michel Dänzer mic...@daenzer.net writes:
On 08.07.2015 09:26, Eric Anholt wrote:
diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
index 0a7de82..a923b7a 100644
--- a/glamor/glamor_utils.h
+++ b/glamor/glamor_utils.h
@@ -756,8 +756,8 @@ glamor_translate_boxes(BoxPtr boxes, int
the fd
dup()-ed by eglInitialize() to stay open, call eglTerminate() from the new
glamor_egl_cleanup() to fix this.
Signed-off-by: Hans de Goede hdego...@redhat.com
Reviewed-by: Eric Anholt e...@anholt.net
I'll stick it in my next pull request, unless keithp grabs it first.
signature.asc
These functions aren't used by anything else, and are specific to the
temporary-upload-as-a-weird-format path of glamor_render.c, called
through glamor_upload_picture_to_texture().
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_picture.c | 870
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_priv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 5989dc4..f3950f1 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -350,7 +350,6 @@ typedef struct
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 11 ---
glamor/glamor_picture.c | 48
glamor/glamor_priv.h| 15 ---
glamor/glamor_render.c | 3 ---
glamor/glamor_utils.h | 10 +-
glamor
pictures with a
transform attached, but that seems unlikely to be used anyway.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_prepare.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor_prepare.c b/glamor/glamor_prepare.c
index 9bfc557
src -f a8r8g8b8,x2r10g10b10
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_render.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 488d1a7..3048cd8 100644
--- a/glamor/glamor_render.c
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_fbo.c | 15 +++
glamor/glamor_utils.h | 15 ---
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
index 1eee304..262033f 100644
--- a/glamor/glamor_fbo.c
the source and mask using
different formats, where we smash the source's format to a new value
so that the mask can use the same uploaded bits. Dropping most of
that should be safe, since it will be uploaded as the source first, so
the smashed format will still be used.
Signed-off-by: Eric Anholt e
This hasn't been used since the format swap/revert stuff for pictures
was added back in 2012.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_utils.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
index 59e6b64..e22bbc1 100644
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_priv.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 1614b6f..508433a 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -741,15 +741,6 @@ Bool
We don't need any of its weird handling of picture formats, since our
XV pixmaps don't have any pictures attached.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_pixmap.c | 2 +-
glamor/glamor_priv.h | 4
glamor/glamor_xv.c | 38
This series came out of the process of trying to figure out if I could
safely store a8 pixmaps in an a8r8g8b8 FBO, to improve glamor
performance on VC4 (which doesn't support 8-bit FBOs). It turns out
the answer is not quite, but the Render code had a lot of bugs
obscuring that fact.
be wrong).
Fixes all failures in rendercheck -t fill and, as a result, the
remaining failures in rendercheck -t blend -o src -f
a8r8g8b8,x2r10g10b10
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_utils.h | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git
These are dead since the glamor_copy.c replacement.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_utils.h | 39 ---
1 file changed, 39 deletions(-)
diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
index 8a96c61..e648af2 100644
Michel Dänzer mic...@daenzer.net writes:
From: Michel Dänzer michel.daen...@amd.com
Fixes slow text display in xdvi.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91260
Signed-off-by: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Eric Anholt e...@anholt.net
I'll grab
Now that it's always non-null when the pixmap is non-null, we don't
need so much of this. glamor_get_pixmap_private() itself still
accepts a NULL pixmap and returns NULL, because of glamor_render.c
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 17
It died as of keithp's new glyphs code.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_utils.h | 12
1 file changed, 12 deletions(-)
diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
index cef62c5..0a7de82 100644
--- a/glamor/glamor_utils.h
+++ b/glamor
start out zero-filled, which matches the callocs we
were doing when making our own privates, and in the case of an fb
pixmap that has a priv where it didn't before, the type ends up being
GLAMOR_MEMORY as we would want.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 43
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_composite_glyphs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/glamor/glamor_composite_glyphs.c b/glamor/glamor_composite_glyphs.c
index cd88524..389c8f4 100644
--- a/glamor/glamor_composite_glyphs.c
+++ b
The commit message in #3 has the meat of the series, but for further
explanation, note that this reduces the glamor library by 8588 bytes
(4.8%) on my x86-64 build, and I've only got 94 client-allocated
pixmaps on my desktop at the moment according to xrestop.
box translation/bounds code. (2015-07-10 09:42:58 -0700)
Eric Anholt (16):
glamor: Reuse the glamor_is_memory helper.
glamor: Drop dead glamor_is_large_picture().
glamor: Ask the server to always allocate our private
Keith Packard <kei...@keithp.com> writes:
> Eric Anholt <e...@anholt.net> writes:
>
>> I think it's a safe enough assumption that we're not generating non-OOM
>> errors. And, now that we're logging errors, we should get reports of
>> them sooner than we used
Mark Kettenis writes:
> This function is used by the modesetting driver to implement DRI2 and
> shouldn't fail on systems that don't support DRI3. Remove the check
> for DRI3 and rename glamor_egl_dri3_fd_name_from_tex to
> glamor_egl_fd_name_from_tex.
At the time you
Emil Velikov writes:
> Otherwise we'll fail miserably later on as we try to use
> glEGLImageTargetTexture2DOES.
I thought this had been implied by other extensions we check for, but I
don't see it.
I think this would go next to the EGL_EXT_image_dma_buf_import check
Alan Coopersmith writes:
> Signed-off-by: Alan Coopersmith
> ---
> glamor/glamor_picture.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/glamor/glamor_picture.c b/glamor/glamor_picture.c
> index
Pekka Paalanen <ppaala...@gmail.com> writes:
> On Wed, 18 Nov 2015 09:57:02 -0800
> Eric Anholt <e...@anholt.net> wrote:
>
>> Keith Packard <kei...@keithp.com> writes:
>>
>> > Eric Anholt <e...@anholt.net> writes:
>> >
>> >&
Keith Packard writes:
> Michel Dänzer writes:
>
>> Is this about x11perf by any chance? I was seeing long lag with that as
>> well, which turned out to be because we weren't correctly synchronizing
>> with the hardware for XGetImage.
>
> x11perf only does
GL_FLOAT, GL_FALSE,
> + 2 * sizeof(float), vbo_offset + 8 *
> sizeof(GLfloat));
>
> glScissor(dstx, dsty, dstw, dsth);
> glDrawArrays(GL_TRIANGLE_FAN, 0, 3);
> +vbo_offset += 16 * sizeof(GLfloat);
You could move the p
|| exit $?
> if test -z "$NOCONFIGURE"; then
> exec "$srcdir"/configure "$@"
> fi
> +
> +git config --local --get format.subjectPrefix ||
> +git config --local format.subjectPrefix "PATCH xserver"
> --
This doesn't work unless y
Hans de Goede writes:
> Hi Eric,
>
> While working on getting tvtime to work on cards using
> the modesetting driver + glamor, I have hit what I believe
> is a bug in glamor's XVideo implementation. I've tried
> with the current xserver master and it seems the bug is
> still
Michel Dänzer writes:
> From: Leo Liu
>
> same monitor modes added causing memory leak
> when looping `xrandr --prop'.
>
> Signed-off-by: Leo Liu
> Signed-off-by: Michel Dänzer
> ---
>
> More than two years later...
Adam Jackson <a...@redhat.com> writes:
> This only worked if the backend server supported DRI1, which is
> stunningly unlikely these days.
Patches 1-3 are:
Reviewed-by: Eric Anholt <e...@anholt.net>
I have an old branch around for doing DRI3 under Xephyr, but I'm happy
to res
No sense doing it on every draw.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_xv.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
index 6e1a588..5d31fee 100644
--- a/glamor/glamor_xv.c
wh ratios are != 1.0 only when large, so with that we can simplify
down how we end up with RepeatFix being used.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_render.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_render.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 5712cf8..51718d1 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -
place.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_xv.c | 68 --
1 file changed, 30 insertions(+), 38 deletions(-)
diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
index 5d31fee..2593d47 100644
--- a/glamor/glamo
i965 does most of its compiling at link time, so our debug output for
its shaders didn't have the name on.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_core.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/glamor/glamor_co
-magpixwin100 (n=40).
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_render.c | 50 +++---
1 file changed, 19 insertions(+), 31 deletions(-)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index ed425f5..da45920
For a small pixmap, it's got a box from 0,0 to width/height, so we can
always use that.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_utils.h | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/glamor/glamor_utils.h b/glamor/glamor_u
This should fix aborts()s from epoxy on old software stacks.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
hw/kdrive/ephyr/ephyr_glamor_glx.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_render.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index da45920..73ac831 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -110,8
This is a step toward using glamor_program.c for Render acceleration.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_priv.h | 12 ++--
glamor/glamor_render.c | 28 ++--
2 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/
One less custom path! By following the common glamor_program.c use
pattern, we get the ability to handle large pixmaps as the
destination. It's also one less place where glamor_utils.h coordinate
transformation happens.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_
We can just hand in a constant mask and the driver will optimize away
the multiplication for us.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_priv.h | 1 -
glamor/glamor_render.c | 17 ++---
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/
after it. (I'm away from the hardware at the moment, but should test
later today).
Eric Anholt (19):
ephyr: Make sure we have GLX_ARB_create_context before calling it.
glamor: Label programs before linking them.
glamor: Clarify when Render fallbacks happen due to an unsupported op.
glamor
They've been dead since the yInverted removal
(e310387f443b6333edf02c8980daa303505382b4).
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_utils.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
index d4366c1..875c935
All sorts of weird indentation, and some cuddled conditional
statements deep in the if tree.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_render.c | 57 ++
1 file changed, 30 insertions(+), 27 deletions(-)
diff --git a/
We had a double loop across h and w, and passed the current x and y
out to callers who then used w to multiply/add to an index. Instead,
just single loop across w * h.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_composite_glyphs.c | 10 ++
glamor/glamor_
This hasn't been used since 2f80c7791bb0b11f261cb1e3e0d89163dcdd0342
(GLAMOR_SEPARATE_TEXTURE removal).
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_utils.h | 20
1 file changed, 20 deletions(-)
diff --git a/glamor/glamor_utils.h b/glamor/glamor_u
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_render.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index a2a7f4a..ed425f5 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_re
Wait long enough, and you don't need to think about it at all.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_transform.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/glamor/glamor_transform.c b/glamor/glamor_transform.c
index ad06943..564a52d 100644
--- a/
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_utils.h | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
index 875c935..3adc687 100644
--- a/glamor/glamor_utils.h
+++ b/
glamor_composite_choose_shader() may upload our scratch pixmaps to get
a Render operation completed. We don't want to hang onto GL memory
for our scratch pixmaps, since we'll just have to reallocate them at a
new w/h next time around, and the contents will be updated as well.
Signed-off-by: Eric
It clarifies what the difference is between the two paths, and would
potentially encourage us to handle GLES extensions that expose
additional types.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_picture.c | 322 ++--
1 file c
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_core.c| 18 ++
glamor/glamor_picture.c | 142 ++--
glamor/glamor_utils.h | 6 --
3 files changed, 46 insertions(+), 120 deletions(-)
diff --git a/glamor/glamor_core.c b/
These just smash your 2_10_10_10 data into , despite what the
comments said. That's not valid rendering, so just ditch this path
and fall back to software. One might also note in the code being
removed here that the REVERT_UPLOADING_10_10_10_2 path wasn't even
connected.
Signed-off-by: Eric
The previous commit asserts that we don't have one.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_picture.c | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/glamor/glamor_picture.c b/glamor/glamor_picture.c
index 9bb2c74..a
the GLES2
cases for a rendercheck/shmblend to make sure I had their swizzles
right (I didn't).
Eric Anholt (12):
glamor: Simplify temporary picture uploading call stack.
glamor: Make sure that GLAMOR_MEMORY pixmaps don't retain an FBO.
glamor: Drop dead fbo handling from GLAMORY_MEMORY pict
The glamor_pixmap_ensure_fbo() in glamor_pixmap_upload_prepare() will
always fail on a large pixmap, so we can just be explicit about
bailing out here and then dump the rest of this garbage.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_picture.c
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_picture.c | 30 +++---
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/glamor/glamor_picture.c b/glamor/glamor_picture.c
index e0f5828..e0458a6 100644
--- a/glamor/glamor_picture.c
+++ b/
doing the conversion path that swaps around the
channels). This is just not worth the complexity.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_picture.c | 123 ++--
glamor/glamor_utils.h | 1 -
2 files changed, 5 insertions(+
glamor_transfer.c is still totally broken, though.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
hw/kdrive/ephyr/ephyr_glamor_glx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c
b/hw/kdrive/ephyr/ephyr_glamor_glx.c
index 6
glamor_upload_sub_pixmap_to_texture() only had the one caller, so we
can merge it in, fix its silly return value, and propagate a bunch of
constants.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_picture.c | 68 ++---
would use for a single Render operation and then throw
away).
We can simplify everything by using GL_ARB_texture_swizzle (or its
GLES3 counterpart). It's just not worth the complexity to try to
improve the performance of this already low-performance path (SHM
pixmaps + Render) on GLES2.
Signed-of
Alex Deucher <alexdeuc...@gmail.com> writes:
> On Mon, Feb 1, 2016 at 4:48 PM, Eric Anholt <e...@anholt.net> wrote:
>> I have a hard time typing anything else at this point.
>>
>> Signed-off-by: Eric Anholt <e...@anholt.net>
>> ---
>> mai
I'd like to move driving of tests out of tests.c and into t_*.c, and
part of that will be allowing tests to use the formats list. While I'm
at it, save the name of the format in the array so it doesn't need to be
recomputed.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
rendercheck.
There's a giant pile of code in glamor for uploading SHM pixmaps to
temporary GL memory for accelerating a Composite operation, and most of
its code is about how you convert formats. Add a test that runs through
all the formats, to give us some coverage.
Signed-off-by: Eric Anholt &l
I have a hard time typing anything else at this point.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
main.c | 21 ++
ops.c| 2 +-
rendercheck.h| 58 +++-
t_blend.c
of the remaining ones use
"win" for presenting results (which we may want to just put in a
global?), and the rest use the pre-created pictures, which would need
some much bigger refactoring if we want to move their test logic into
their test files.
Signed-off-by: Eric Anholt <e...@anholt.net
Signed-off-by: Eric Anholt <e...@anholt.net>
---
autogen.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/autogen.sh b/autogen.sh
index 1b15e18..c262d6b 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -11,3 +11,6 @@ autoreconf -v --install || exit 1
cd $ORIGDIR || exit $?
$
Eric Anholt <e...@anholt.net> writes:
> For a small pixmap, it's got a box from 0,0 to width/height, so we can
> always use that.
This seemed so sensible, but it turns out that for MEMORY pixmaps we'll
attach an FBO to it in the glamor_picture.c code, without setting its
box (wh
Dave Airlie <airl...@gmail.com> writes:
> On 28 January 2016 at 18:21, Dave Airlie <airl...@gmail.com> wrote:
>> On 28 January 2016 at 11:56, Eric Anholt <e...@anholt.net> wrote:
>>> I've been working on vc4 X performance again, particularly looking at
&
Michel Dänzer writes:
> From: Michel Dänzer
>
> According to Nicolai Hähnle, the relevant specification says "All
> messages are initially enabled unless their assigned severity is
> DEBUG_SEVERITY_LOW", so we need to explicitly disable the messages
Dave Airlie writes:
> From: Dave Airlie
>
> This happens if you run twm + mplayer + xclock and drag
> the clock over the mplayer. If we don't catch it, we cause
> an illegal draw elements command to be passed to GL.
What exactly is the error? I was
.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_render.c | 8
1 file changed, 8 insertions(+)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index d8574ec..92b6b0c 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -512,6 +512,14 @@
I originally inherited this from the EXA code, without determining
whether it was really needed. Regular composite should end up doing
the same thing, since it's all just shaders anyway. To the extent
that it doesn't, we should fix composite.
Signed-off-by: Eric Anholt <e...@anholt.
We only need it once at the top of the shader, so just put it
there.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_render.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index e
Signed-off-by: Eric Anholt <e...@anholt.net>
---
glamor/glamor_priv.h | 10 +-
glamor/glamor_render.c | 50 +++---
2 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 5
Here are my fixes for the regressions in the glamor-core-profile
series. The first commit would go just before the GL_RED change, then
I'd squash the other two into GL_RED. The series is now in
glamor-core-profile of my fdo tree.
Eric Anholt (3):
glamor: Drop duplicated
601 - 700 of 1093 matches
Mail list logo