The compiler decides how many LDTMUs we're going to emit, and that must
match the P1 flags. This brings the return channel counting to a single
place (so all that's passed into the compiler is "how many return channels
you may request from this texture's format), and was a necessary step for
shadow samplers once we stop using OVRTMUOUT=0.
This means that we get a single copy of it emitted, instead of once at the
start of each tile (though it's still executed once per tile). Fixes
assertion failures with the updated simulator.
In newer versions they've removed the C interface, so make one here. This
also isolates the Mesa codebase from the simulator codebase, so we don't
have conflicts over things like "unreachable"
As Marek noted, the GL_RGBA + GL_UNSIGNED_INT_2_10_10_10_REV type
combo is also good for readback of BGRX1010102 framebuffers, not
only for BGRA1010102 framebuffers for use with glReadPixels()
under GLES, so add it for the GL_IMPLEMENTATION_COLOR_READ_TYPE_OES
query.
Successfully tested on gallium r600 driver with a (quickly hacked
for RGBA 10 10 10 0) dEQP testcase
dEQP-EGL.functional.wide_color.window_1010102_colorspace_default.
Suggested-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Some clients may not like rgb10 fbconfigs and visuals.
Support driconf option 'allow_rgb10_configs' on gallium
to allow per application enable/disable.
The option defaults to enabled.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Successfully tested under Weston 3.0.
Photometer confirms 10 rgb bits from rendering to display.
v2: Rebased onto master for dri2_teardown_wayland().
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Enables eglCreateImageKHR() with target set to
EGL_NATIVE_PIXMAP_KHR to handle color depth 30
X11 drawables.
Note that in theory the drawable depth 32 case in the
current implementation is ambiguous: A depth 32 drawable
could be of format ARGB8888 or ARGB2101010, therefore an
assignment of __DRI_IMAGE_FORMAT_ARGB8888 for a pixmap of
ARGB2101010 format would be wrong. In practice however, the
X-Server (as of v1.19) does not provide any depth 32 visuals
for ARGB2101010 EGL/GLX configs. Those are associated with
depth 30 visuals without an alpha channel instead. Therefore
the switch-case depth 32 branch is only executed for ARGB8888
pixmaps and we get away with this.
Tested with KDE Plasma 5 under X11, DRI2 and DRI3/Present,
selecting EGL + OpenGL compositing and different fbconfigs
with/without 2 bit alpha channel. glxinfo confirms use of
depth 30 visuals for ARGB2101010 only.
Suggested-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Similar to the matching of 24 bit RGB visuals to 32-bit
RGBA EGLConfigs, so X11 compositors won't alpha-blend any
config with a destination alpha buffer during compositing.
Additionally this fixes failure to select ARGB2101010
configs via eglChooseConfig() with EGL_ALPHA_BITS 2 on
a depth 30 X-Screen. The X-Server doesn't provide any
visuals of depth 32 for ARGB2101010 configs, it only
provides depth 30 visuals. Therefore if we'd only match
ARGB2101010 configs to depth 32 RGBA visuals, we would
not ever get a visual for such a config.
This was apparent in piglit tests for egl configs, which
are fixed by this commit.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
This format + type combo is good for BGRA1010102 framebuffers
for use with glReadPixels() under GLES, so add it for the
GL_IMPLEMENTATION_COLOR_READ_TYPE_OES query.
Allows successful testing of 10 bpc / depth 30 rendering with dEQP test
case dEQP-EGL.functional.wide_color.window_1010102_colorspace_default.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Allows to prevent exposing RGB10 configs and visuals to
clients.
v2: Rename expose_rgb10_configs to allow_rgb10_configs,
as suggested by Emil.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Some clients may not like RGB10X2 and RGB10A2 fbconfigs and
visuals. Add a new driconf option 'allow_rgb10_configs' to
allow per application enable/disable.
The option defaults to enabled.
v2: Rename expose_rgb10_configs to allow_rgb10_configs,
as suggested by Emil. Add comment to option parsing,
to make sure it stays before the ->InitScreen().
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Expose formats which are supported at least back to Gen 5 Ironlake,
possibly further. Allow creation of 10 bpc winsys buffers for drawables.
glxinfo now lists new RGBA 10 10 10 2/0 formats.
v2: Move the BGRA/BGRX1010102 formats before the RGBA/RGBX8888
32 bit formats, as the code comments require. Thanks Emil!
Update num_formats from 3 to 5, to keep the special Android
handling intact.
v3: Use num_formats = ARRAY_SIZE(formats) - 2 as suggested by Tapani,
to only exclude the last 2 Android formats, add Tapani's r-b.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Allow DRI3/Present buffer sharing for 10 bpc buffers.
Otherwise composited desktops under DRI3 will only display
black client areas for redirected windows.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Used to support ARGB2101010 and XRGB2101010
winsys framebuffers / drawables, but added
other 10 bpc fourcc's as well for consistency
with definitions in wayland_drm.h, gbm.h, and
drm_fourcc.h.
v2: Align new defines with tabs instead of spaces, for
consistency with remainder of that block of definitions,
as suggested by Tapani.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Extend intel_miptree_blit() to handle at least
ARGB2101010 -> XRGB2101010, ARGB2101010 -> ARGB2101010,
and XRGB2101010 -> XRGB2101010 via the BLT engine,
but not XRGB2101010 -> ARGB2101010 yet.
This works as tested under Compiz, KDE-5, Gnome-Shell.
v2: Restrict BLT fast path to exclude XRGB2101010 -> ARGB2101010,
as intel_miptree_set_alpha_to_one() isn't ready to set 2 bit
alpha channels to 1.0 yet. However, couldn't find a test case
where this specific blit would be needed, so maybe not much
of a point to improve here.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
The parameters to gen_xmlpool.py are wrong and cause the following
warnings:
Warning: language 'out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_util_intermediates/xmlpool/es/LC_MESSAGES/options.mo' not found.
Warning: language 'out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_util_intermediates/xmlpool/nl/LC_MESSAGES/options.mo' not found.
Warning: language 'out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_util_intermediates/xmlpool/fr/LC_MESSAGES/options.mo' not found.
Warning: language 'out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_util_intermediates/xmlpool/sv/LC_MESSAGES/options.mo' not found.
Warning: language 'external/mesa3d/src/util/xmlpool/t_options.h' not found.
Warning: language 'out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_util_intermediates/xmlpool' not found.
Warning: language 'de' not found.
Warning: language 'es' not found.
Warning: language 'nl' not found.
Warning: language 'fr' not found.
Warning: language 'sv' not found.
The result is English is the only language in options.h. Use "$<"
instead of "$^" because we only need the first dependency (the script),
not all dependencies.
Signed-off-by: Rob Herring <robh@kernel.org>
Older OpenGL defines two equations for converting from signed-normalized
to floating point data. These are:
f = (2c + 1)/(2^b - 1) (equation 2.2)
f = max{c/2^(b-1) - 1), -1.0} (equation 2.3)
Both OpenGL 4.2+ and OpenGL ES 3.0+ mandate that equation 2.3 is to be
used in all scenarios, and remove equation 2.2. DirectX uses equation
2.3 as well. Intel hardware only supports equation 2.3, so Gen7.5+
systems that use the vertex fetcher hardware to do the conversions
always get formula 2.3.
This can make a big difference for 10-10-10-2 formats - the 2-bit value
can represent 0 with equation 2.3, and cannot with equation 2.2.
Ivybridge and older were using equation 2.2 for OpenGL, and 2.3 for ES.
Now that Ivybridge supports OpenGL 4.2, this is wrong - we need to use
the new rules, at least in core profile. That would leave Gen4-6 doing
something different than all other hardware, which seems...lame.
With context version promotion, applications that requested a pre-4.2
context may get promoted to 4.2, and thus get the new rules. Zero cases
have been reported of this being a problem. However, we've received a
report that following the old rules breaks expectations. SuperTuxKart
apparently renders the cars red when following equation 2.2, and works
correctly when following equation 2.3:
https://github.com/supertuxkart/stk-code/issues/2885#issuecomment-353858405
So, this patch deletes the legacy equation 2.2 support entirely, making
all hardware and APIs consistently use the new equation 2.3 rules.
If we ever find an application that truly requires the old formula, then
we'd likely want that application to work on modern hardware, too. We'd
likely restore this support as a driconf option. Until then, drop it.
This commit will regress Piglit's draw-vertices-2101010 test on
pre-Haswell without the corresponding Piglit patch to accept either
formula (commit 35daaa1695ea01eb85bc02f9be9b6ebd1a7113a1):
draw-vertices-2101010: Accept either SNORM conversion formula.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions. The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.
Here's the problem scenario:
- Application calls a meta function that generates a name. The first
Gen will probably return 1.
- Application decides to use the same name for an object of the same
type without calling Gen. Many demo programs use names 1, 2, 3,
etc. without calling Gen.
- Application calls the meta function again, and the meta function
replaces the data. The application's data is lost, and the app
fails. Have fun debugging that.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
All of the callers of _mesa_meta_bind_rb_as_tex_image call
_mesa_meta_setup_sampler shortly after. _mesa_meta_setup_sampler also
binds the texture. This is necessary because not all paths that lead to
_mesa_meta_setup_sampler some through _mesa_meta_bind_rb_as_tex_image.
Rename the function _mesa_meta_texture_object_from_renderbuffer to
reflect its true purpose.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Also, the comment on _mesa_record_error was wrong.
dd_function_table::Error was not called because that function does not
exist.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
The in-place resolve probably has some additional restrictions when not
operating on a super tiled surface. Disable it on non-supertiled surfaces
for now to work around a GPU hang.
Fixes: 78ade65956 ("etnaviv: Do GC3000 resolve-in-place when possible")
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Overall it does not really help or hurt. The deferred demo gets 1%
improvement and some games a 3% decrease, so I don't think this
should be enabled by default.
But with the code upstream it is easier to experiment with it.
v2: Remove initializing the registers from si_emit_config.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Eric Anholt