- 30 Jan, 2016 14 commits
-
-
Eric Anholt authored
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>
-
Eric Anholt authored
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>
-
Eric Anholt authored
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>
-
Eric Anholt authored
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>
-
Eric Anholt authored
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>
-
Eric Anholt authored
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>
-
Eric Anholt authored
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>
-
Eric Anholt authored
This hasn't been used since 2f80c779 (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>
-
Eric Anholt authored
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>
-
Eric Anholt authored
Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org>
-
Eric Anholt authored
They've been dead since the yInverted removal (e310387f). Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org>
-
Eric Anholt authored
Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org>
-
Eric Anholt authored
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>
-
Eric Anholt authored
This should fix aborts()s from epoxy on old software stacks. Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org>
-
- 28 Jan, 2016 4 commits
-
-
Adam Jackson authored
This only worked if the backend server supported DRI1, which is stunningly unlikely these days. Signed-off-by:
Adam Jackson <ajax@redhat.com> Reviewed-by:
Eric Anholt <eric@anholt.net>
-
Adam Jackson authored
This applies regardless of which DRI you're asking for. Worse, leaving it out means breaking the config file syntax in a pointless way, since non-DRI servers can safely just parse it and ignore it. Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Adam Jackson <ajax@redhat.com>
-
Adam Jackson authored
Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Adam Jackson <ajax@redhat.com>
-
Dave Airlie authored
This stops Xephyr failing on GLXBadFBConfig. Signed-off-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Dave Airlie <airlied@redhat.com>
-
- 27 Jan, 2016 2 commits
-
-
Timo Aaltonen authored
Adds Skylake, Kabylake and Broxton allowing them to use modesetting + glamor with dri2. Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Reviewed-by:
Andreas Boll <andreas.boll.dev@gmail.com>
-
Adam Jackson authored
Bugzilla: https://bugs.freedesktop.org/93883Signed-off-by:
Adam Jackson <ajax@redhat.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Julien Cristau <jcristau@debian.org>
-
- 26 Jan, 2016 9 commits
-
-
Dave Airlie authored
This adds support to Xwayland to try and use OpenGL core profile for glamor first. v1.1: use version defines. v2: let glamor work out core profile itself. Signed-off-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Eric Anholt <eric@anholt.net>
-
Dave Airlie authored
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>
-
Keith Packard authored
On desktop GL, ask for a 3.1 core profile context if that's available, otherwise create a generic context. v2: tell glamor the profile is a core one. v2.1: add/use GL version defines v3: let glamor work out core itself Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Eric Anholt <eric@anholt.net>
-
Dave Airlie authored
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>
-
Keith Packard authored
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>
-
Eric Anholt authored
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>
-
Dave Airlie authored
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>
-
Dave Airlie authored
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>
-
Eric Anholt authored
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>
-
- 22 Jan, 2016 1 commit
-
-
Eric Anholt authored
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>
-
- 21 Jan, 2016 1 commit
-
-
Adam Jackson authored
As of v4 of this extension, any GLES version number may be requested (to enable GLES3 and later). To comply with this, simply remove the API version checks and leave it to the DRI driver to validate. This happens to also enable using GLES1 in direct contexts, so if that's the dire situation you find yourself in, your client driver at least stands a chance of working. v4 also specifies that both extension strings should be advertised for compatibility with clients written against v1 of the extension spec, so add the es_profile bit to the extension list and enable it whenever we would enable es2_profile. Reviewed-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Adam Jackson <ajax@redhat.com>
-
- 20 Jan, 2016 4 commits
-
-
Keith Packard authored
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>
-
Dave Airlie authored
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>
-
Dave Airlie authored
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>
-
Michel Dänzer authored
When a window moves from one CRTC to another, present_window_to_crtc_msc updates window_priv->msc_offset according to the delta between the current MSC values of the old and new CRTC: window_priv->msc_offset += new_msc - old_msc; window_priv->msc_offset is initially 0, so if new_msc < old_msc, window_priv->msc_offset wraps around and becomes a large number. If the window_msc parameter passed in is small (in particular if it's 0, such as is the case when the client just wants to know the current window MSC value), the returned CRTC MSC value may still be a large number. In that case, the existing MSC comparisons in pixmap_present weren't working as intended, resulting in scheduling a wait far into the future when the target MSC had actually already passed. This would result in the client (e.g. the Chromium browser) hanging when moving its window between CRTCs. In order to fix this, introduce msc_is_(equal_or_)after helper functions which take the wraparound into account for comparing two MSC values. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Keith Packard <keithp@keithp.com> Reviewed-by:
Martin Peres <martin.peres@linux.intel.com> Signed-off-by:
Keith Packard <keithp@keithp.com>
-
- 19 Jan, 2016 1 commit
-
-
Michel Dänzer authored
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=93659Tested-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>
-
- 13 Jan, 2016 2 commits
-
-
Dave Airlie authored
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>
-
Dave Airlie authored
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>
-
- 06 Jan, 2016 2 commits
-
-
Adam Jackson authored
Signed-off-by:
Adam Jackson <ajax@redhat.com> Reviewed-by:
Alan Coopersmith <alan.coopersmith@oracle.com>
-
Thomas Klausner authored
Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Thomas Klausner <wiz@NetBSD.org>
-