summaryrefslogtreecommitdiff
path: root/glamor
AgeCommit message (Collapse)AuthorFilesLines
2017-08-14glamor: Scissor CopyArea to the bounds of the drawing.Eric Anholt2-4/+30
Like the previous fix to rectangles, this reduces the area drawn on tiled renderers by letting the CPU-side tile setup know what tiles might be drawn at all. Surprisingly, it improves x11perf -copypixwin1 -repeat 1 -reps 10000 on i965 by 2.93185% +/- 1.5561% (n=90). v2: Drop extra glamor_bounds_union_box() from previous debugging (caught by Mark Marshall). Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com> (v1)
2017-08-14glamor: Scissor rectangle drawing to the bounds of the rects.Eric Anholt2-4/+57
Scissors provide a critical hint to tiled renderers as to what tiles need to be load/stored because they could be modified by the rendering. The bounds calculation here is limited to when we have a small number of rects (large enough to cover rounded window corners, but probably not xeyes) to avoid overhead on desktop GL. No performance difference on i965 with x11perf -rect1 -repeat 1 -reps 10000 (n=50) v2: Clamp rectangle bounds addition. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2017-07-05glamor: update "required EGL extensions" commentEmil Velikov1-2/+1
The extensions listed have not been needed in a while. Replace with the only remaining requirement. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2017-06-29glamor: remove no longer needed KHR_gl_texture_2D_image requirementEmil Velikov1-1/+0
The code that needed it was introduced with commit 7cfd9cc2327 ("Add DRI3 support to glamor") back in 2013. And was nuked a couple of years ago with commit 51984dddfcc ("glamor: Delay making pixmaps shareable until we need to.") Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2017-06-12glamor: Clarify variable names in glamor_copy_cpu_fboKeith Packard1-17/+23
This function creates a temporary pixmap to hold data being moved from the source to the destination. However, it labeled all of the variables associated with this as src_, which makes it confusing to read the code. Rename them tmp_ instead. Also fix the comment describing the function to note that it copies from CPU to GPU, not GPU to GPU. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
2017-06-13glamor: Fix temporary pixmap coordinate offsetsMichel Dänzer1-2/+2
The previous values happened to work in basic cases, but not in general if the destination is a subwindow or has a border. Fixes crash with xli, which moves a large subwindow inside a smaller parent window for scrolling. No regressions with xterm, x11perf -copyplane or the xscreensaver phosphor hack. Bug: https://bugs.debian.org/857983 Reviewed-by: Keith Packard <keithp@keithp.com>
2017-06-05glamor: Store the actual EGL/GLX context pointer in lastGLContextMichel Dänzer1-2/+2
Fixes subtle breakage which could sometimes trigger after a server reset with multiple screens using glamor: Screen A enters glamor_close_screen last and calls various cleanup functions, which at some point call glamor_make_current to make sure screen A's GL context is current. This sets lastGLContext to screen A's &glamor_priv->ctx. Finally, glamor_close_screen calls glamor_release_screen_priv, which calls free(glamor_priv). Later, screen B enters glamor_init, which allocates a new glamor_priv. With bad luck, this can return the same pointer which was previously used for screen A's glamor_priv. So when screen B's glamor_init calls glamor_make_current, lastGLContext == &glamor_priv->ctx, so MakeCurrent isn't called for screen B's GL context, and the following OpenGL API calls triggered by glamor_init mess up screen A's GL context. The observed end result of this was a crash in glamor_get_vbo_space because glamor_priv->vbo didn't match the GL context, though there might be other possible outcomes. Assigning the actual GL context pointer to lastGLContext prevents this by preventing the false negative test in glamor_make_current. Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2017-06-02glamor: Remove the "delayed fallback" code.Eric Anholt2-31/+0
The usage of this died with the old core rendering code. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2017-06-02glamor: Drop glamor_set_screen_pixmap().Eric Anholt3-20/+0
All that was left here was updating the FBO's size. However, the FBO size was always set correctly already through glamor_set_pixmap_texture() from whoever had attached a new BO to the pixmap. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2017-06-02glamor: Stop tracking the screen_fbo.Eric Anholt3-6/+1
This means we no longer get "s" for on-screen drawing in glamor_debug, and there's only "m" (CPU memory) or "f" (Any GPU memory, aka FBOs). That seems fine to me. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2017-06-02glamor_egl: Stop saving the EGL major/minor version.Eric Anholt1-3/+1
We don't use them for anything. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2017-05-18glamor_egl: Drop glamor_egl_create_textured_screen_ext().Eric Anholt2-18/+4
The function hasn't been doing anything useful since keithp's resource freeing fixes in 2014. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-05-18glamor_egl: Automatically choose a GLES2 context if desktop GL fails.Eric Anholt1-33/+39
GLES2 support has been requested multiple times, and we've had this code laying around trying to implement it. The GLES2 implementation is not quite there yet (some pixel transfer failures), but it shouldn't take much fixing at this point. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-05-18glamor_egl: Remove check for KHR_surfaceless_context_*Eric Anholt1-6/+1
Those extensions don't exist. There's only surfaceless_context. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
2017-05-18glamor_egl: Drop warning about indirect GLX and GLES2.Eric Anholt1-6/+0
Indirect GLX uses its own context and doesn't care what glamor is using. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-05-18glamor_egl: Avoid flink names in glamor_egl_create_textured_pixmap().Eric Anholt1-63/+21
Using flink is banned on render nodes, and they needlessly expose our screen pixmap contents to any authenticated client. This also incidentally drops the dependency on EGL_MESA_drm_image. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-05-18glamor_egl: Drop dead "cpp" fieldEric Anholt1-1/+0
It's been unused since the initial import. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-05-18glamor_egl: Drop dead gl_context_depth.Eric Anholt1-1/+0
This was replaced in 4afe15d8bfd575c010ed1868697a7922a37ab378, but not deleted. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-05-18glamor_egl: Drop unnecessary check for KHR_gl_renderbuffer_image.Eric Anholt1-1/+0
I couldn't find it being used anywhere in the history of the code. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-05-18glamor_egl: Always require the gbm-based image import path.Eric Anholt1-28/+27
This has been associated with dri3 for now, but we need to use it elsewhere in order to avoid flink. The extensions have been implemented for long enough that I couldn't find when it was that we turned them on. Oddly, we already required renderbuffer import support, which is basically as hard to implement as texture import. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Daniel Stone <daniels@collabora.com>
2017-05-18glamor_egl: Drop the has_gem flag.Eric Anholt1-28/+7
We're using GBM, so we know we've got GEM. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-05-18glamor_egl: Unifdef GLAMOR_HAS_GBM.Eric Anholt1-34/+0
We only build this code with GBM, and supporting non-GBM well would be invasive. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-05-18glamor_egl: Print a useful identifying string on initialization.Eric Anholt1-14/+3
The EGL version is not used anywhere in the glamor code, so it's not interesting. And when saying that we've started using GL acceleration, it's nice to know what GL we're actually using. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-04-26Add a Meson build system alongside autotools.Eric Anholt1-0/+58
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest, and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but hasn't been built yet. The unit tests are also not done. The intent is to build this as a complete replacement for the autotools system, then eventually replace autotools. meson is faster to generate the build, faster to run the bulid, shorter to write the build files in, and less error-prone than autotools. v2: Fix indentation nits, move version declaration to project(), use existing meson_options for version-config.h's vendor name/web. Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Keith Packard <keithp@keithp.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
2017-04-26Use #ifdef instead of #if for features to make Meson easier.Eric Anholt1-2/+2
We mostly use #ifdef throughout the tree, and this lets the generated config.h files just be #define TOKEN instead of #define TOKEN 1. Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-04-21glamor: an FBO is not needed for Xv pixmapsOlivier Fourdan1-3/+6
It appears that on some hardware/diver combo such as nv30/nouveau, using GL_ALPHA as format for 8-bit depth will cause an incomplete attachment error (GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT) when trying to bind the texture. As a result, the FBO is NULL and glamor segfaults when trying to access the FBO width/height in pixmap_priv_get_scale() in glamor_xv_render(). This happens with glamor-xv which uses 8-bit pixmaps, meaning that on such hardware/driver, trying to play a video using Xv will lead to a crash of the Xserver. This affects Xwayland, Xephyr, modesetting driver with glamor accel. But the use of an FBO is not actually needed for glamox-xv, so by disabling FBO at pixmap creation, we can avoid the issue entirely. Fix suggested by Eric Anholt <eric@anholt.net> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100710 Fixes: https://bugzilla.redhat.com/1412814 Reviewed-by: Eric Anholt <eric@anholt.net>
2017-03-23glamor: Fix some formatting that confused the unifdef command.Eric Anholt1-1/+1
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Eric Anholt <eric@anholt.net>
2017-03-20glamor: Avoid software fallback for planemasked ZPixmap GetImageAdam Jackson1-1/+11
Same trick as in fb: just do a normal GetImage and deal with the planemask on the CPU if you have to. Since the software fallback hit for glamor is pretty brutal, this is a much more impressive win for glamor than it was for fb: 11100.0 87700.0 (7.901) (copy 0xaaaaaaaa) ShmGetImage 10x10 square 9840.0 47800.0 (4.858) (copy 0xaaaaaaaa) ShmGetImage 100x100 square 1550.0 4240.0 (2.735) (copy 0xaaaaaaaa) ShmGetImage 500x500 square 9450.0 78900.0 (8.349) (0xaaaaaaaa) GetImage 10x10 square 6910.0 30900.0 (4.472) (0xaaaaaaaa) GetImage 100x100 square 431.0 2020.0 (4.687) (0xaaaaaaaa) GetImage 500x500 square Measured with Xephyr -glamor on Skylake GT3e. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
2017-03-17glamor: avoid a crash if texture allocation failedOlivier Fourdan1-0/+4
Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY is raised, in which case the texture returned is zero. But the texture value is not checked in glamor_create_fbo() and glamor will abort in glamor_pixmap_ensure_fb() because the fbo->tex is 0: Truncated backtrace: Thread no. 1 (10 frames) #4 glamor_pixmap_ensure_fb at glamor_fbo.c:57 #5 glamor_create_fbo_from_tex at glamor_fbo.c:112 #6 glamor_create_fbo at glamor_fbo.c:159 #7 glamor_create_fbo_array at glamor_fbo.c:210 #8 glamor_create_pixmap at glamor.c:226 #9 compNewPixmap at compalloc.c:536 #10 compAllocPixmap at compalloc.c:605 #11 compCheckRedirect at compwindow.c:167 #12 compRealizeWindow at compwindow.c:267 #13 RealizeTree at window.c:2617 Check the value returned by _glamor_create_tex() in glamor_create_fbo() and return NULL in the texture is zero. All callers of glamor_create_fbo() actually check the returned value and will use a fallback code path if it's NULL. Please cherry-pick this to active stable branches. Bugzilla: https://bugzilla.redhat.com/1433305 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2017-03-17fb: Remove 24bpp support (v3)Adam Jackson1-37/+0
v2: - Require power-of-two bpp in ScreenInit - Eliminate fbCreatePixmapBpp v3 - Squash in the exa and glamor changes so we can remove pRotatedPixmap in the same stroke. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
2017-03-16glamor: Fix dashed line rendering.Eric Anholt1-1/+1
We were binding the screen pixmap as the dash and sampling its alpha, which is usually just 1.0 (no dashing at all). Please cherry-pick this to active stable branches. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
2017-03-15glamor: Check glamor_set_destination_drawable() return valueOlivier Fourdan7-44/+66
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>
2017-03-15glamor: glamor_set_destination_drawable() can failOlivier Fourdan2-3/+10
The fbo_array of a given glamor pixmap can be NULL in some cases, as glamor_create_fbo_array() can fail to allocate the FBO array. If this is the case, glamor_pixmap_fbo_at() will return NULL even though the box index is valid, and glamor_set_destination_drawable() simply assumes glamor_pixmap_fbo_at() will return an FBO prior to pass the value to glamor_set_destination_pixmap_fbo(), which will segfault. We need a way for glamor_set_destination_drawable() to fail safely and let the caller know about the failure. Add a boolean return value to glamor_set_destination_drawable() for that purpose. Bugzilla: https://bugzilla.redhat.com/1417575 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
2017-03-15glamor: Check for NULL pixmap in glamor_get_pixmap_texture()Olivier Fourdan1-0/+3
glamor_create_pixmap() would return a NullPixmap if the given size is larger than the maximum size of a pixmap. But glamor_get_pixmap_texture() won't check if the given pixmap is non-null, leading to a segfault if glamor_create_pixmap() failed. This can be reproduced by passing Xephyr a very large screen width, e.g.: $ Xephyr -glamor -screen 32768x1024 :10 (EE) (EE) Backtrace: (EE) 0: Xephyr (OsSigHandler+0x29) (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) (EE) 2: Xephyr (glamor_get_pixmap_texture+0x30) (EE) 3: Xephyr (ephyr_glamor_create_screen_resources+0xc6) (EE) 4: Xephyr (ephyrCreateResources+0x98) (EE) 5: Xephyr (dix_main+0x275) (EE) 6: /lib64/libc.so.6 (__libc_start_main+0xf1) (EE) 7: Xephyr (_start+0x2a) (EE) 8: ? (?+0x2a) [0x2a] (EE) (EE) Segmentation fault at address 0x0 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) Aborted (core dumped) Bugzilla: https://bugzilla.redhat.com/1431633 Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
2017-03-09glamor: Fix typo: "vec2_pos" -> "vec2 pos"Michel Dänzer1-1/+1
Fixes crash when trying to use dashed lines: Failed to compile VS: 0:8(2): error: `vec2_pos' undeclared Trivial. Fixes: d8161aeb5089 ("glamor: Fix missing declaration in dash vertex shader") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99943
2017-03-07glamor: use drmGetDeviceNameFromFD2 when availableQiang Yu1-0/+4
This is for glamor can support fd from DRM render node which is useful for a render only DDX. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
2017-02-23glamor: Fix missing declaration in dash vertex shaderDr.-Ing. Dieter Jurzitza1-0/+1
Fixes a GLSL compilation error: Failed to compile VS: 0:13(43): error: `pos' undeclared 0:13(14): error: operands to arithmetic operators must be numeric 0:13(13): error: operands to arithmetic operators must be numeric Tested-by: Stefan Dirsch <sndirsch@suse.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2017-01-24glamor: Two pass won't work on memory pixmapsOlivier Fourdan1-0/+4
When selecting "CA_TWO_PASS" in glamor_composite_clipped_region() when the hardware does not support "GL_ARB_blend_func_extended", we call glamor_composite_choose_shader() twice in a row, which in turn calls glamor_pixmap_ensure_fbo(). On memory pixmaps, the first call will set the FBO and the second one will fail an assertion in glamor_upload_picture_to_texture() because the FBO is already set. Bail out earlier when the mask pixmap is in memory and the hardware capabilities would require to use two pass, so that the assertion is not failed and the rendering is correct. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99346 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2017-01-02glamor: Squash unused variable warningAdam Jackson1-2/+0
Accidentally introduced in 05e19644. Signed-off-by: Adam Jackson <ajax@redhat.com>
2017-01-02glamor: Trust eglGetPlatformDisplayEXT if it existsHans De Goede2-3/+5
If the libEGL we are using has eglGetPlatformDisplayEXT, yet it still returns NULL, then this very likely means that it does not support the type (e.g. EGL_PLATFORM_GBM_MESA) passed in, and then returning NULL is the right thing to do. This avoids falling back to an eglGetDisplay() implementation which does not understands the passed in gbm handle, treats it as a pointer to something else completely, followed by a crash sooner or later. Specifically this fixes using the nvidia binary driver, with nvidia's libEGL + the modesetting driver on a secondary GPU crashing inside glamor_egl_init() sometimes. Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2016-11-30glamor: restore vfunc handlers on init failureOlivier Fourdan1-3/+8
In glamor_init(), if the minimum requirements are not met, glamor may fail after setting up its own CloseScreen() and DestroyPixmap() routines, leading to a crash when either of the two routines is called if glamor failed to complete its initialization, e.g: (EE) Backtrace: (EE) 0: Xwayland (OsSigHandler+0x29) (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) (EE) 2: Xwayland (glamor_sync_close+0x2a) (EE) 3: Xwayland (glamor_close_screen+0x52) (EE) 4: Xwayland (CursorCloseScreen+0x88) (EE) 5: Xwayland (AnimCurCloseScreen+0xa4) (EE) 6: Xwayland (present_close_screen+0x42) (EE) 7: Xwayland (dix_main+0x4f9) (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf1) (EE) 9: Xwayland (_start+0x2a) Restore the previous CloseScreen() and DestroyPixmap() vfunc handlers in case of failure when checking for the minimum requirements, so that if any of the requirement is not met we don't leave the CloseScreen() and DestroyPixmap() from glamor handlers in place. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1390018 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2016-10-25glamor: don't look for non-existing EGL_KHR_platform_baseEmil Velikov1-11/+8
The extension does not exist in the registry, thus needs to know they're using EGL 1.5 in order to determine the eglGetPlatformDisplay function pointer is valid. Thus brings us into some lovely circular dependency. Since mesa won't be able (in the foreseeable future) to export the KHR flavour of extension (another way one could assume that EGL 1.5 is available) just drop all the heuristics and use the EGL_EXT_platform_base extension. In practise (checked with the Mali driver) any EGL 1.5 driver will advertise support for EGL_EXT_platform_base. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
2016-10-05glamor: Use eglGetPlatformDisplay{,EXT} if we canAdam Jackson3-5/+89
eglGetDisplay forces the implementation to guess which kind of display it's been handed. glvnd does something different from Mesa, and in general it's impossible for the library to get this right. Add a new inline that gets the logic right, and works around a quirk in epoxy. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2016-10-05glamor: Fix pixmap offset for bitplane in glamor_copy_fbo_cpuOlivier Fourdan1-8/+10
Commit cba28d5 - "glamor: Handle bitplane in glamor_copy_fbo_cpu" introduced a regression as the computed pixmap offset would not match the actual coordinates and write data elsewhere in memory causing a segfault in fbBltOne(). Translate the pixmap coordinates so that the data is read and written at the correct location. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97974 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
2016-09-30glamor: spans: fixup wrong count on glDrawArraysMark Yao1-1/+1
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>
2016-09-29glamor: Fix link failure on GLES2.Eric Anholt1-2/+1
Current Mesa requires that the precision qualifier on uniforms matches between stages, even if (as in this case) the uniform isn't used in one of the stages. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2016-09-29glamor: Remove #if 0-ed picture dumping code.Eric Anholt2-384/+0
I don't think anybody has run this code since it was pulled into the server. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2016-09-29glamor: Remove many unused glamor util functions.Eric Anholt1-171/+0
Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2016-09-29glamor: Require GL_OES_texture_border_clamp for GLES2.Eric Anholt2-19/+22
The extension came out in 2000, and all Mesa-supported hardware that can do glamor supports it. We were already relying on the ARB version being present on desktop. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2016-09-28glamor: Fall back to software for CopyPlane if we need toAdam Jackson3-0/+6
glUniform4ui is available starting in GL{,ES} 3.0. Technically it's also in EXT_gpu_shader4, but that's not worth supporting. There was also a MESA_shading_language_130 spec proposed at one point; if that ever gets finished, we can update epoxy to know about it and fix up the feature check. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-18 02:25:45 +0000