Lots of the accel paths only make current once they start
doing someting, so a lot of them call the bail paths without
make current, which means on PRIME systems for example
we end up in the wrong context.
Add a prepare pixmap in the prepare fallback path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90667
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes slow text display in xdvi.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91260
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
These are dead since the glamor_copy.c replacement.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This hasn't been used since the format swap/revert stuff for pictures
was added back in 2012.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This function takes the start x/y and the destination's width/height,
so it only works if there's no transform. We could potentially
transform this box and take its bounds with some rounding, but this at
least gets us to read out enough data.
Note that this does the same overshoot on destination pictures with a
transform attached, but that seems unlikely to be used anyway.
v2: Add XXX comment for the commit message note (Suggested by Michel).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Dave Airlie <airlied@redhat.com> (v1)
The pixmap->picture is just the *last* picture attached to the pixmap,
so you'd potentially be looking at the wrong one when trying to
temporarily upload to avoid a composite fallback.
There's some trickiness in glamor_render.c when we're dealing with the
upload of a GLAMOR_MEMORY pixmap as both 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 <eric@anholt.net>
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
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 <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
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 <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Attaching a picture to a pixmap doesn't change its GL format, so it
doesn't change how core rendering should be assigning colors to it.
(Imagine XCreatePixmap(), optional XCreatePicture(pixmap) with various
formats, XFillRectangle, XGetImage(). If the XGetImage results
changed, this would 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 <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
I'm amazed we've made it as far as we have without these checks: if
you made an unusual format picture that wasn't the normal a8r8g8b8 or
x8r8g8b8 or a8, we'd go ahead and try to render with it, ignoring that
the sampler would fetch totally wrong bits.
Fixes 260 tests in rendercheck -t blend -o src -f a8r8g8b8,x2r10g10b10
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
glamor_egl_init() was not undoing any of the init steps on init error,
add an glamor_egl_cleanup() function and use this both on error and on exit
to cleanup the various resources.
Even on a clean exit eglTerminate() was not being called, causing 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 <hdegoede@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
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 <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This avoids a lot of screwing around to attach our privates later. It
means that non-glamor pixmaps now gain 120 bytes of glamor privates on
64-bit (which has quite a bit of fixable bloat), and glamor pixmaps
take one less pointer of storage (not counting malloc overhead).
Note that privates 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.
v2: Clarify that the GLAMOR_MEMORY enum must be 0 (as it was
previosuly), so that the new pixmap private behavior is as
expected. Suggested by keithp.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Keith Packard <keithp@keithp.com>
It died as of keithp's new glyphs code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This significantly reduces the amount of time it takes for xterm to start
up on a fresh X server with the radeonsi driver.
v2: Use GLYPHWIDTHBYTESPADDED instead of hardcoding 4 bytes glyph
alignment (Keith Packard)
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This should help people debugging when glamor does something stupid on
their driver.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Fixes regressions since Eric's "don't make an FBO for the glyph atlas"
change. The a1 upload was a fallback, as expected. However, fallback
reads use glReadPixels() because there's no glGetTexSubImage2D() to
match glTexSubImage2D(). We were just binding the 0 FBO value, so the
glReadPixels() would throw a GL error instead of getting any data.
After the fallback was done we'd write back the undefined data to the
atlas, blowing away the entire rest of the atlas because we didn't
specify any bounds on our prepare.
To fix the fallbacks to actually work, we'd need a prepare path that
allocates some memory memory do a full glGetTexImage() into, then
memcpy out of that. Instead, just dodge the general fallback by
implementing the specific upload we need to do here, which should also
be *much* faster at uploading a1 glyphs since it's not
readpixels/texsubimaging back and forth.
v3: Use CopyPlane to a temp pixmap for the upload
v4: Rewrite anholt's commit message to be from keithp's perspective
(changes by anholt)
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This gives the compiler a chance to optimize when the data is never
changed -- for example, with pict_format_combine_tab, the compiler
ends up inlining the 24 bytes of data into just 10 more bytes of code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
It's been unused since I killed glamor_download_pixmap_to_cpu().
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
It was apparently accidentally dropped in keithp's removal of _nf
functions in 90d326fcc6.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Above, we've already checked for ->fbo && ->fbo->fb and returned.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
v2: Don't forget to set priv->block_w/block_h like the wrapper used
to.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
This should hopefully keep the comments more up to date with the
structure comments. While I'm here, I've reworded a few of them to be
more accurate, and dropped a bunch of stale comments.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The code to set it was deleted in keithp's big rewrite.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Improves text rendering from about 284k glyphs per second to 320k
glyphs per second. There's no GL extension for probing this, because
of the philosophy of "Don't expose whether things are really in
hardware or not."
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Improves x11perf -aa10text performance by 1377.59% +/- 23.8198% (n=93)
on Intel with GLES2.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
We were only looking for the desktop GL version of the extension, so
GLES2 missed out.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
We use this for all of our other performance-sensitive rendering, too.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The GL_QUADS helper takes a number of quads, not a number of vertices.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Rather than create the pixmap, this uses the file descriptor
to change an existing pixmaps backing store.
This is required for reverse prime slaves, where we create
the slave pixmap, then set the backing store.
v1.1: use local pScreen (Eric)
Reviewed-by: Eric Anholt <eric@annholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need this for doing USB offload scenarios using glamor
and modesetting driver.
unfortunately only gbm in mesa 10.6 has support for the
linear API.
v1.1: fix bad define
v2: update the configure.ac test as per amdgpu. (Michel)
set linear bos to external to avoid cache. (Eric)
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
VC4 (and many GLES2 renderers) can't render to GL_ALPHA, so our pixmap
would end up as GLAMOR_MEMORY and our dereference of the FBO would
setfault. Instead, tell the pixmap creation that we don't need an FBO
at all. Our glyph upload path was already glTexImage for non-a1, and
a more general software fallback for a1 (since the glyph is also in
system memory).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
