Current implementation allowed usage of unsized type texture GL_FLOAT
and GL_HALF_FLOAT as a render target as this was 'expected behavior' by
WEBGL_oes_texture_float and is also allowed by the oes-texture-float
WebGL test. However this broke some ES3 conformance tests that do not
accept such behavior. Patch sets such an fbo incomplete as expected by
the ES3 conformance tests. Textures with sized types like RGBA32F will
still continue to work as render targets.
v2: code style cleanups (Ian Romanick, Matt Turner)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88905
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Right now the places that used to emit a mov.sf just put the SF on the
previous instruction when it generated the source of the SF value. Even
without optimization to push the sf up further (and kill thus potentially
kill more MOVs), this gets us:
total uniforms in shared programs: 13455 -> 13457 (0.01%)
uniforms in affected programs: 3 -> 5 (66.67%)
total instructions in shared programs: 40296 -> 40198 (-0.24%)
instructions in affected programs: 12595 -> 12497 (-0.78%)
Quiets compiler warning since e7f2f2dea5.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The compiler can't tell that we're always going to hit the first if block
on the first time through the loop.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
If execution was supposed to be supported in this case, we'd run into
trouble from completely uninitialized sat_imm values.
v2: Drop the '!' before the string.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We always pass this argument, even if it won't be used by the particular
texture op.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Commit f82f2fb3dc added use of the Mesa
IR optimizer for both ARB_fragment_program and ARB_vertex_program, but
only justified the vertex-program portions with measured performance
improvements.
Meanwhile, the optimizer was seen to generate hundreds of unused
immediates without discarding them, causing failures.
Discard the use of the optimizer for now to fix the regression. (In
the future, we anticpate things moving from Mesa IR to NIR for better
optimization anyway.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82477
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
CC: "10.3 10.4 10.5" <mesa-stable@lists.freedesktop.org>
We need to build certain parts of Mesa (namely gallium, llvmpipe, and
therefore util) with Windows SDK 7.0.7600, which includes MSVC 2008.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
To fix build when libdrm is not found,
commit a594cec7e3 did put several
parts of egl code under #ifdef HAVE_DRM_PLATFORM.
HAVE_DRM_PLATFORM means the egl drm platform is being built.
What should have been used instead is HAVE_LIBDRM.
At a few locations, the HAVE_DRM_PLATFORM introduced
have already been replaced by HAVE_LIBDRM, this patch
replaces the remaining occurences.
This patch makes for example EGL_EXT_image_dma_buf_import
be advertised by egl under x11 when the drm egl platform
is not built, whereas previously it required the drm egl
platform to be built.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
With commit c642e87d9f4(auxiliary/vl: rework the build of the VL code)
we split out the VL code into a separate static library that was meant
to be used by the VL targets alone - va, vdpau, xvmc.
The commit failed to consider the way we handle vdpau-gl interop and
broke it. Bring back the functionality by keeping the vl <> vl_stub
separation as requrested by Christian.
v2: Update the omx target as well. Update mesa-stable email address.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86837
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Andy Furniss <adf.lists@gmail.com>
Currently having the wayland-scanner is optional, which causes problems
when autotools parses through the makefiles, and tries to generate all
the BUILT_SOURCES.
As the config option --with-egl-platform=wayland is not the default, we
won't end up setting the WAYLAND_SCANNER variable, which in turn will
cause some files to not get generated.
There has been a wayland-scanner package as of wayland 1.2 which
provides a variable for the scanner binary, so let's use that one and
fall back to manually searching via AC_PATH_PROG when needed.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Use nir/nir_opcodes.h as is (w/o the absolute path), as it is the target
name used to generate the actual file. Otherwise the target is missing,
the file won't get generated and the build will fail.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We're using a SIMD4x2 sampler message, which has execsize 4, and so the
register width must be <= 4. Use <4,4,1> regioning instead of <8,8,1>
regioning to access the same data but avoid tripping the assert.
Fixes the following piglit tests:
spec/glsl-1.20/compiler/structure-and-array-operations/array-selection.vert
spec/glsl-es-3.00/compiler/uniform_block/interface-name-basic.vert
spec/glsl-es-3.00/compiler/uniform_block/interface-name-field-clashes-with-struct.vert
spec/glsl-es-3.00/compiler/uniform_block/interface-name-field-clashes-with-function.vert
spec/glsl-es-3.00/compiler/uniform_block/interface-name-array.vert
glslparsertest/glsl2/condition-07.vert
spec/glsl-es-3.00/compiler/uniform_block/interface-name-field-clashes-with-variable.vert
v2: Better commit message courtesy of Ken.
I had a discussion with Ken, and we both question how we end up with a mov and
execsize 4. For now though, this fixes the piglit tests, so we can worry about
it later.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
