Some drivers are calling glFinish, they really should be doing this.
This also is needed for some reverse prime scenarios.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
When using PictOpSrc, the destination is wrongly shifted back to (0, 0).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94568
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
I'm pretty sure Eric suspected this could cause a problem, and we
couldn't find a test. Well loading feedly in firefox seems to trigger
badness that this solves.
bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94554
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Without this, we may be manipulating the context of another screen.
In a system with two GPUs using glamor, this fixes lots of
(EE) glamor256: GL error: GL_INVALID_OPERATION in glBindTexture(non-gen name)
spew since 0b4c0c75 ('glamor: Replace "finish access" shader with texture
swizzling').
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
For pictures without alpha, and for most other formats for GLES2, we
would make a temporary FBO, make another temporary texture, upload our
GLAMOR_MEMORY pixmap to the texture, then run the "finish access" shader
across it to swizzle its values around into the temporary FBO (which we
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.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Pixman is quite qualified to allocate our temporary memory, and all we
need to do is decide what formats to convert from and to.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
There was only a pretty special case that could have even worked --
you've got a GLES2 renderer, you've got a SHM pixmap, it's 1555 (not
the usual 565 for 16-bit), and you're little endian (BE was broken,
since GL's 5_5_5_1 picks the 1 bit from the lowest bit of the short,
and on BE we weren't doing the conversion path that swaps around the
channels). This is just not worth the complexity.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
These just smash your 2_10_10_10 data into 8888, 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.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
It clarifies what the difference is between the two paths, and would
potentially encourage us to handle GLES extensions that expose
additional types.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
We were using the destination pixmap depth to determine the source
picture format.
Fixes incorrect text rendering with some MATE desktop GTK3 themes.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94246
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
The former takes explicit screen and depth parameters instead of
deriving them from a pixmap.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
We already take src_y into account when uploading the src data by
starting at the top line of the src data when uploading.
Adjust src_y accordingly when rendering.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For hardware that doesn't do actual jumps for conditionals (i915,
current vc4 driver), this reduces the number of texture fetches
performed (assuming the driver isn't really smart about noticing that
the same sampler is used on each side of an if just with different
coordinates).
No performance difference on i965 with x11perf -magpixwin100 (n=40).
Improves -magpixwin100 by 12.9174% +/- 0.405272% (n=5) on vc4.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
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>
