All sorts of weird indentation, and some cuddled conditional
statements deep in the if tree.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
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 <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
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 <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a step toward using glamor_program.c for Render acceleration.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We can just hand in a constant mask and the driver will optimize away
the multiplication for us.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
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 <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were clipping the drawn rectangle to each clip box, then expanding
the box to a big triangle to avoid tearing, then drawing each triangle
to the destination through a scissor. If we're using a scissor for
clipping, though, then we don't need to clip the drawn primitive on
the CPU in the first place.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
No sense doing it on every draw.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This hasn't been used since 2f80c7791b
(GLAMOR_SEPARATE_TEXTURE removal).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Wait long enough, and you don't need to think about it at all.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
They've been dead since the yInverted removal
(e310387f44).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
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 <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v1.1: use version defines.
v2: let glamor work it out itself
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Glamor works out from the profile if it is
core.
This flag is used to disable quads for rendering.
v1.1: split long line + make whitespace conform (Michel)
v1.2: add GL 3.1 version defines
v2: move to having glamor work out the profile.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
GL_RED is supported by core profiles while GL_ALPHA is not; use GL_RED
for one channel objects (depth 1 to 8), and then swizzle them into the
alpha channel when used as a mask.
[airlied: updated to master, add swizzle to composited glyphs and xv paths]
v2: consolidate setting swizzle into the texture creation code, it
should work fine there. Handle swizzle when setting color as well.
v3: Fix drawing to a8 with Render (changes by anholt, reviewed by airlied).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
We only need it once at the top of the shader, so just put it
there.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
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.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
It's been on the list to add dual source blending support to avoid the
two pass componentAlpha code. Radeon has done this for a while in
EXA, so let's add support to bring glamor up to using it.
This adds dual blend to both render and composite glyphs paths.
Initial results show close to doubling of speed of x11perf -rgb10text.
v2: Fix breakage of all of CA acceleration for systems without
GL_ARB_blend_func_extended. Add CA support for all the ops we
support in non-CA mode when blend_func_extended is present. Clean
up some comments and formatting. (changes by anholt)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reading and writing to 16-depth pixmaps using PICT_x1r5g5b5 ends up
failing, unless you're doing a straight copy at the same bpp where the
misinterpretation matches on both sides.
Fixes rendercheck/blend/over and renderhceck/blend/src in piglit.
Please cherry-pick this to active stable branches.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Core contexts require the use of vertex array objects, so switch both glamor
and ephyr/glamor over.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This converts the Xv code to using VBOs instead of
client ptrs. This is necessary to move towards using
the core profile later.
v2: put all boxes into single vbo, use draw arrays
to offset things. (Eric)
v2.1: brown paper bag with releasing vbo.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This converts two client arrays users to using vbos,
this is necessary to move to using core profile later.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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 we
don't want to get. Failing that, we were accidentally logging e.g.
shader stats intended for shader-db.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93659
Tested-by: Laurent Carlier <lordheavym@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
There is a problem with some fonts that the height necessary
to store the font is greater than the max texture size, which
causes a fallback to occur. We can avoid this by storing two
macro columns side-by-side in the texture and adjusting
the calculations to suit.
This fixes
xfd -fn -*-*-*-*-*-*-*-*-*-*-*-*-*-*
falling back here, when it picks
-arabic-newspaper-medium-r-normal--32-246-100-100-p-137-iso10646-1
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
running xfontsel on haswell here, with a max texture size
of 8kx8k, one font wants 9711 height. This fallsback to
sw in this case.
A proper solution probably involves using an array texture.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If a pixmap isn't getting exported as a dmabuf, then we don't need to
make an EGLImage/GBM bo for it. This should reduce normal pixmap
allocation overhead, and also lets the driver choose non-scanout
formats which may be much higher performance.
On Raspberry Pi, where scanout isn't usable as a texture 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.
v2: Just use pixmap->usage_hint instead of a new field. Drop the
changes that started storing gbm_bos in the pixmap priv due to
lifetime issues.
v3: Fix a missing gbm_bo_destroy() on the pixmap-from-fd success path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This GBM import path was introduced in 10.2, which we already require.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
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 <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
We were rolling ioctl calls ourselves, when there's a nice interface
for it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
One less layering violation (EGL should call glamor, if anything, not
the other way around).
v2: Move glamor.c's DestroyPixmap wrapping up above the
glamor_egl_screen_init() call, since glamor.c's DestroyPixmap
needs to be the bottom of the stack (it calls fb directly and
doesn't wrap). Caught by Michel.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The DestroyPixmap chain and CloseScreen chain all do pixmap teardown
already, and calling it manually would be redundant.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
I assume this was a workaround for an old, broken, closed driver. The
driver doesn't get to throw away rendering just because the rendering
context's shared-across-processes render target is getting freed from
the local address space. If the rendering isn't to a shared render
target, then we *do* want to throw away the rendering to it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
If the source/mask pixmap is a pixmap that doesn't have an FBO
attached, and it doesn't match the Render operation's size, then we'll
composite it to a CPU temporary (not sure why). We would take the
PictFormatShort from the source Picture, make a pixmap of that depth,
and try to look up the PictFormat description from the depth and the
PictFormatShort. However, the screen's PictFormats are only attached
to the screen's visuals' depths. So, with an x2r10g10b10 short format
(depth 30), we wouldn't find the screen's PictFormat for it
(associated with depth 32).
Instead of trying to look up 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 <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
If the glTexImage (or glTexSubImage) out-of-memories, error out
cleanly so that we can fall back to software.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
We already have a fallback path, so we just need to jump to it when we
hit the failure.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
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 <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
GL 4.5 / GLES 3.0 require throwing GL errors at map time, and Mesa
before that might throw errors accidentally if a malloc(0) call was
made to return the mapping.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Otherwise we'll fail and/or crash as no context is bound.
Fixes: 64e6124f27 (glamor: move GL_OES_EGL_image check next to EGL_EXT_image_dma_buf_import)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92105
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Nick Sarnie <commendsarnex@gmail.com>
Reported-by: Nick Sarnie <commendsarnex@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Nick Sarnie <commendsarnex@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
We're using the former only as the latter is present. Thus in some cases
we might incorrectly error out if it's missing.
Namely - glamor_glx, glamor_egl without gbm, EGL_KHR_gl_texture_2D_image
or EGL_EXT_image_dma_buf_import.
Fixes 58d54ee82df(glamor: explicitly check for GL_OES_EGL_image)
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Suggested-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Otherwise we'll fail miserably later on as we try to use
glEGLImageTargetTexture2DOES.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Fixes a regression since a2a2f6e34b. I
missed this in testing on x86, because we never fail to allocate an
FBO. We do hit this path on VC4, though.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Without this, the context of another screen may be current, or no context
at all if glamor_egl_init failed for another screen.
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>
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>
The cache was trying to allow glyph_max_dim in, but since we were
putting over 64x64 into HW memory, it would end up in the
single-glyph-per-render bail_one path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
XRender defines this, GL really doesn't like it.
kwin 4.x and qt 4.x seem to make this happen for the
gradient in the titlebar, and on radeonsi/r600 hw
this draws all kinds of wrong.
v2: bump this up a level, and check it earlier.
(I assume the XXXX was for this case.)
v3: add same code to largepixmap paths (Keith)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
New composite glyphs code uses the updated glamor program
infrastructure to create efficient shaders for drawing render text.
Glyphs are cached in two atlases (one 8-bit, one 32-bit) in a simple
linear fashion. When the atlas fills, it is discarded and a new one
constructed.
v2: Eric Anholt changed the non-GLSL 130 path to use quads instead of
two triangles for a significant performance improvement on hardware
with quads. Someone can fix the GLES quads emulation if they want to
make it faster there.
v3: Eric found more dead code to delete
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This extends the existing API to support options needed for render
accleration, including an additional fragment, 'combine', (which
provides a place to perform the source IN mask operation before the
final OP dest state) and an additional 'defines' parameter which
provides a way to add target-dependent values without using a uniform.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Use code from Piglit project to compute GLSL version for either GL or
GLES. The Piglit code was originally written by Chad Versace.
v2: bail if the parse fails (requested by Eric Anholt)
v3: Use version 1.20 for GLES until we fix our programs (Eric Anholt)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Instead of passing the destination drawable, just pass the depth, as
the underlying functions need only that to check whether the planemask
is going to work.
This API change will allow higher level functions to not need the
destination pixmap.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes a build error with gcc 4.2.1 on OpenBSD due to
-Werror=return-type from xorg-macros.
error: type qualifiers ignored on function return type
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
v2: fixup whitespace
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Pass the inverse of the texture size to glamor vertex shaders so that
we multiply by that instead of dividing by the size as multiplication
is generally faster than division.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The texture2D() happens in each branch, so we may as well do it as early
as possible and hide some of its latency in the branching instructions.
Moving it outside the (uniform) control flow reduces the number of
instructions in the fs_source shader from 64 to 46 and in the
set_alpha_source shader from 69 to 47 on Haswell.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
We should do better than this with an index buffer, but for now at
least make it so that we don't have to copy the same code to new
places.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This possibly is a minor hit for immediate mode renderers (no
difference on copypixin100 on my hsw, n=12), but it gives important
information about drawing bounds to a deferred renderer (3.1x
improvement in copypixwin100 on vc4).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
By dropping the unconditional logic op disable at the end of
rendering, this fixes GL errors being thrown in GLES2 contexts (which
don't have logic ops). On desktop, this also means a little less
overhead per draw call from taking one less trip through the
glEnable/glDisable switch statement of doom in Mesa.
The exchange here is that we end up taking a trip through it in the
XV, Render, and gradient-generation paths. If the glEnable() is
actually costly, we should probably cache our logic op state in our
screen, since there's no way the GL could make that switch statement
as cheap as the caller caching it would be.
v2: Don't forget to set the logic op in Xephyr's drawing.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
When using glamor (either in Xephyr or Xwayland) on hardware with too
low instructions limit, glamor fallbacks to sw due to large shaders.
This makes glamor unbearably slow on such hardware.
Check reported value for GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB
and fail in glamor_init() if the limit is lower than 128.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88316
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Initialize full pixmap private for all pixmaps, including block
dimensions and counts so that no checks are needed when walking the
fbos.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This will let us eliminate the pixmap types shortly
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Just embed the large elements in the regular pixmap private and
collapse the union to a single struct.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
There's no reason to waste memory storing redundant copies of the same
pointer all over the system; just pass in pointers as necessary to
each function.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
The core rendering code already requires that FBOs be allocated at
exactly the pixmap size so that tiling and stippling work
correctly. Remove the allocation support for that, along with the
render code.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is not used anywhere
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This was only used to signal when we couldn't ask the DDX to draw to a
pixmap; now that we have no DDX-based fallbacks, we don't need to have
this type.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
With no DDX-based fallback support, we can remove these functions as
they are no longer called.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
These were used by the non-standard glamor implementation in the intel
driver.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Remove these defines as we start to remove support for non-standard
glamor layering as used by the intel driver.
v2: Rebase on the blockhandler change and the Xephyr init failure
change (by anholt), fix stray NO_DRI3 addition to xwayland.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
GLAMOR_MEMORY_MAP was only used with GLAMOR_CREATE_PIXMAP_MAP, and
GLAMOR_CREATE_PIXMAP_MAP doesn't appear to be used anywhere, so just
remove both of them.
v2: Fix a stray whitespace bug that was introduced (change 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>
Remove the calls to GL_TEXTURE_MAX_LEVEL. Setting the filtering is
a sufficient hint to the driver about texture mipmap allocation.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The latter might not be available on GLES2.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
According to Eric Anholt the check for glGetError is not needed here.
Because a opengl error might be set before this function is called
keeping the check could result in glamor_build_program returning
failure when building the shader succeeded.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Check for GL_EXT_unpack_subimage and GL_NV_pack_subimage to
check if GL_(UN)PACK_ROW_LENGTH is available. Set the offsets
manually to prevent calls to GL_(UN)PACK_SKIP_*.
v2: Check support for GL_NV_pack_subimage as suggested by Matt Turner.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This adds glamor into the block handler call chain
in the correct place.
This should fix interactions between glamor and drivers
requiring damage from glamor.
v2: okay don't consolidate, just leave things wierd for now
remove blcokhandler in screen close.
v3: block handler wrapping the right way.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The number of lines of video to update in the texture needs to be
computed from the height of the updated source, not the full height of
the source.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
_glamor_upload_bits_to_pixmap_texture currently ignores the stride
parameter, but __glamor_upload_pixmap_to_texture uses 4-byte alignment
via glPixelStorei(GL_UNPACK_ALIGNMENT, 4).
Also fix up the stride argument passed in though, in case it starts
being used properly in the future.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87455
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Only called from glamor_fbo.c now.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Calling glamor_purge_fbo directly was incorrect for large pixmaps.
Fixes use-after free with large pixmaps:
==2029== Invalid write of size 8 ~
==2029== at 0x85F93AD: __xorg_list_del (list.h:184)
==2029== by 0x85F93AD: xorg_list_del (list.h:204)
==2029== by 0x85F93AD: glamor_fbo_expire (glamor_fbo.c:280)
==2029== by 0x85F95CA: glamor_pixmap_fbo_cache_put (glamor_fbo.c:159)
==2029== by 0x85D7AB5: glamor_destroy_textured_pixmap (glamor.c:228)
==2029== by 0xC1BDDC4: radeon_glamor_destroy_pixmap (radeon_glamor.c:272)
==2029== by 0x519D00: damageDestroyPixmap (damage.c:1473)
==2029== by 0x4DD307: XvDestroyPixmap (xvmain.c:370)
==2029== by 0x4DB975: ShmDestroyPixmap (shm.c:258)
==2029== by 0x5098F6: FreePicture (picture.c:1425)
==2029== by 0x85E678E: glamor_composite_clipped_region (glamor_render.c:1558)
==2029== by 0x85F763A: glamor_composite_largepixmap_region (glamor_largepixmap.c:1347)
==2029== by 0x85E7964: _glamor_composite (glamor_render.c:1679)
==2029== by 0x85E7A38: glamor_composite (glamor_render.c:1758)
==2029== Address 0x1141d3c0 is 0 bytes inside a block of size 64 free'd
==2029== at 0x4C29E90: free (vg_replace_malloc.c:473)
==2029== by 0x85D7167: glamor_set_pixmap_private (glamor.c:570)
==2029== by 0xC1BDDC4: radeon_glamor_destroy_pixmap (radeon_glamor.c:272)
==2029== by 0x519D00: damageDestroyPixmap (damage.c:1473)
==2029== by 0x4DD307: XvDestroyPixmap (xvmain.c:370)
==2029== by 0x4DB975: ShmDestroyPixmap (shm.c:258)
==2029== by 0x45B246: doFreeResource (resource.c:875)
==2029== by 0x45BD5E: FreeResource (resource.c:905)
==2029== by 0x43444B: ProcFreePixmap (dispatch.c:1422)
==2029== by 0x43856E: Dispatch (dispatch.c:432)
==2029== by 0x43C96F: dix_main (main.c:298)
==2029== by 0x6CFAB44: (below main) (libc-start.c:287)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The other way around fails to destroy the screen pixmap EGL image:
==1782== 80 (32 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 981 of 2,171
==1782== at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==1782== by 0xF9D4BD2: dri2_create_image_from_dri (egl_dri2.c:1264)
==1782== by 0xF9D4BD2: dri2_create_image_dma_buf (egl_dri2.c:1764)
==1782== by 0xF9D4BD2: dri2_create_image_khr (egl_dri2.c:1798)
==1782== by 0xF9C7937: eglCreateImageKHR (eglapi.c:1494)
==1782== by 0x85D5655: _glamor_egl_create_image (glamor_egl.c:134)
==1782== by 0x85D5655: glamor_egl_create_textured_pixmap (glamor_egl.c:302)
==1782== by 0x85D579B: glamor_egl_create_textured_screen (glamor_egl.c:225)
==1782== by 0xC1BE05D: radeon_glamor_create_screen_resources (radeon_glamor.c:67)
==1782== by 0xC1B6153: RADEONCreateScreenResources_KMS (radeon_kms.c:258)
==1782== by 0x4B2105: xf86CrtcCreateScreenResources (xf86Crtc.c:709)
==1782== by 0x43C823: dix_main (main.c:223)
==1782== by 0x6CFAB44: (below main) (libc-start.c:287)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
For robustness against drivers which may call both
glamor_(egl_)destroy_textured_pixmap and glamor_destroy_pixmap.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
==25551== Invalid read of size 8
==25551== at 0x85D5F2C: glamor_egl_destroy_pixmap_image (glamor_egl.c:527)
==25551== by 0x85D7750: glamor_destroy_pixmap (glamor.c:235)
==25551== by 0xC1BDD9B: radeon_glamor_destroy_pixmap (radeon_glamor.c:278)
==25551== by 0x5098F6: FreePicture (picture.c:1425)
==25551== by 0x85DD7A9: glamor_unrealize_glyph_caches (glamor_glyphs.c:257)
==25551== by 0x85D7B50: glamor_close_screen (glamor.c:586)
==25551== by 0x4B1A82: xf86CrtcCloseScreen (xf86Crtc.c:734)
==25551== by 0x4CFFC7: CursorCloseScreen (cursor.c:187)
==25551== by 0x513A44: AnimCurCloseScreen (animcur.c:106)
==25551== by 0x51529B: present_close_screen (present_screen.c:64)
==25551== by 0x43CA83: dix_main (main.c:351)
==25551== by 0x6CFAB44: (below main) (libc-start.c:287)
==25551== Address 0x83dafa0 is 96 bytes inside a block of size 152 free'd
==25551== at 0x4C29E90: free (vg_replace_malloc.c:473)
==25551== by 0x85D76B4: glamor_destroy_textured_pixmap (glamor.c:225)
==25551== by 0x85D7750: glamor_destroy_pixmap (glamor.c:235)
==25551== by 0xC1BDD9B: radeon_glamor_destroy_pixmap (radeon_glamor.c:278)
==25551== by 0x5098F6: FreePicture (picture.c:1425)
==25551== by 0x85DD7A9: glamor_unrealize_glyph_caches (glamor_glyphs.c:257)
==25551== by 0x85D7B50: glamor_close_screen (glamor.c:586)
==25551== by 0x4B1A82: xf86CrtcCloseScreen (xf86Crtc.c:734)
==25551== by 0x4CFFC7: CursorCloseScreen (cursor.c:187)
==25551== by 0x513A44: AnimCurCloseScreen (animcur.c:106)
==25551== by 0x51529B: present_close_screen (present_screen.c:64)
==25551== by 0x43CA83: dix_main (main.c:351)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(Originally written by Dave Airlie; split into a separate patch by
Kenneth Graunke.)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
They are part of the ABI.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When reallocating the framebuffer on screen resize, the old EGL image
was getting leaked. Check for an existing EGL image and free it in
this case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Revewied-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There's no reason to store this in the egl screen private as the
screen pixmap will always hold a reference to it anyways.
Signed-off-by: Keith Packard <keithp@keithp.com>
Revewied-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There were three paths that called eglDestroyImageKHR:
* The front buffer
* The intel driver's flip buffer
* pixmaps under DRI3
This patch unifies the second two by having glamor_destroy_pixmap
always destroy any associaged EGL image. This allows us to stop
storing the back_pixmap pointer in glamor as that was only used to
make sure that buffer was freed at server reset time.
v2: check for valid pixmap_priv before using it in
glamor_egl_destroy_pixmap_image
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>