We had various helper functions trying to come up with the
internalformat/format/type/render formats for pixmaps, and it's much
nicer to just detect what those should be once at startup. This gives
us a chance to do the right thing for GLES.
It also, notably, fixes our format/type for depth 15 and 16 setup for
desktop GL, so that we actually allocate 16bpp (GL_RGB/565) on most
drivers instead of 32bpp (GL_RGB/UBYTE).
GLES still has regressions over desktop (2 regressions in llvmpipe
XTS, many in rendercheck), but I think this is a good baseline.
Signed-off-by: Eric Anholt <eric@anholt.net>
Check the value returned by glamor_set_destination_drawable() and use
the fallback code path where possible.
Bugzilla: https://bugzilla.redhat.com/1417575
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
In commit 9e9fcf5 (glamor: Add a helper function for the common
GL_QUADS fallback pattern.), the glDrawArrays count change was
accidentally changed to nbox.
Fixes xlogo with MESA_GL_VERSION_OVERRIDE=2.1 and
MESA_GLSL_VERSION_OVERRIDE=120
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
A1 and A8 pixmaps are usually stored in the Red channel to conform
with more recent GL versions. When using these pixmaps as mask values,
that works great. When using these pixmaps as source values, then the
value we want depends on what the destination looks like.
For RGBA or RGB destinations, then we want to use the Red channel
for A values and leave RGB all set to zero.
For A destinations, then we want to leave the R values in the Red
channel so that they end up in the Red channel of the output.
This patch adds a helper function, glamor_bind_texture, which performs
the glBindTexture call along with setting the swizzle parameter
correctly for the Red channel. The swizzle parameter for the Alpha
channel doesn't depend on the destination as it's safe to leave it
always swizzled from the Red channel.
This fixes incorrect rendering in firefox for this page:
https://gfycat.com/HoarseCheapAmericankestrel
while not breaking rendering for this page:
https://feedly.com
v2: Add change accidentally left in patch for missing
glDisable(GL_COLOR_LOGIC_OP).
Found by Emil Velikov <emil.l.velikov@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63397
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
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>
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>
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>
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>
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>
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>
If this path needed the filters set, so would all the other
glDrawArrays() callers. But they don't.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Now that we have the DIX global state for the current context, we
don't need to track nesting to try to reduce MakeCurrent overhead.
v2: Fix a mistaken replacement of a put_context with make_current in
glamor_fill_spans_gl() (caught by keithp).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com> (v1)
This accelerates spans operations using GPU-based geometry computation
-wellipse500 goes from about 4k/sec before the patch, to ~8k/sec in
the GLES2 fallback loop, to ~100k/sec in desktop mode.
v2: Rebase on skipping the prepare rewrite for now, and fix the GLSL
1.20 and GLES2 cases (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>
Dave Airlie
Eric Anholt
Olivier Fourdan
Mark Yao
Keith Packard
Maarten Lankhorst