The old implementation of vrend_add_formats used to check color readback
format even if a depth buffer is bound. As no texture is attached to the
color buffer for such a FBO, it makes glGetIntegerv with
GL_IMPLEMENTATION_COLOR_READ_TYPE fail, and the error can trigger the
GL_NO_ERROR assertion in the function.
Check only if the depth buffer can be read in such a case.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Since we use GLES or the GL core profile on the host, the
alpha formats will not be available anyway, so just emulate
them right away, this helps to fix more piglits from
bin/arb_texture_buffer_object-formats fs arb
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: maksym.wezdecki@collabora.com
The swizzling didn't take into account that the destination might
actually only read a few components or just one, so that the
applied swizzling could even become invalid because code like
dest.z = vec4(dest.z.x, dest.z.y.dest.z.z. dest.z.w)
could be created. The check for when to apply the swizzling was also
not correct because the two values compared came from different
name-spaces.
To fix this, just check whether the TEXTURE_NEEDS_SWIZZLE is set,
and when loweing in the shader, take only the components into account
that are actually written.
This also needs a fix for the alpha-format override to add the
TEXTURE_NEEDS_SWIZZLE flag.
Finally take the shader type into account when checking the number
of sampler views.
v2: Correct the shader code to apply the swizzling (Maksym)
v3: Fix formatting (Maksym)
Fixes: 29c6b9177541f189ebed5158a432b21d0d82211
vrend: apply format swizzling during GLSL generation
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: maksym.wezdecki@collabora.com
On OpenGL all textures can be read back using glGetTexture. On GLES
we have to be able to bind the texture to an FBO to use glReadPixels,
and only a few formats are supported as destination formats.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>
BGRA resources that use external storage (EGL image, GBM)
must keep the data store in the BGRA byte-order, while
producing the correct results when used within the host's
GL or GLES API. To maintain compatability of BGRA resources
with features such as gamma correction, texture views, and
multisampled rendering, virglrenderer swizzles BGRA texture
data to RGBA and passes GL_RGBA to the host API, then swizzles
the RGBA data back to BGRA on readout.
With external storage, virglrenderer no longer has complete
control over buffer accesses, with the possibility that buffers
will be written to and read out by other processes, such as the
display compositor. Under these circumstances, we need to emulate
the external buffer format when using it with the host rendering
API such that data is accessed from the backing buffer as RGBA
and written back as BGRA.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
BGRA emulation was added to address rendering artifacts when GL guest
apps are run on a GLES host with virglrenderer's use_gles == true.
Due to tenuous compatibility of EXT_texture_format_BGRA8888 with
gamma correction (sRGB formats/views) and multisampled rendering on
GLES hosts, it is best to represent BGR* resourcs with RGB* internal
format and add necessary byte re-ordering on to/from transfers instead.
Note, however, that removing the existing BGR* emulation will cause
problems for externally stored resources such as EGL images, and GBM
allocated buffers, which may actually be stored with BGR* byte-order.
This is addressed in the commits immediately following this one.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
For GL hosts CopyImageSubData and TextureView are not defined
when ASTC textures are involved, and the copy fallback currently
doesn't handle these formats correctly. Since Gallium can handles
ASTC texures transparetly in the guest, host support is not really
required to be able to use it.
Fixes all tests out of
dEQP-GLES32.functional.copy_image*astc*
that were failing on the llvmpipe GL host before
Related #224
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
This fixes regression in various astc format related dEQP tests.
Fixes: 51d4d37 ("formats:add astc 2d compressed format support")
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
When virglrenderer creates VIRGL_FORMAT_B8G8R8X8_UNORM texture, it
uses internal format GL_BGRA_EXT.
When Mesa imports dma_buf VIRGL_FORMAT_B8G8R8X8_UNORM/DRM|GBM_FORMAT_XRGB8888
it uses internal format GL_RGB8.
These formats are not copy compatible.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
These formats are supported and required by GLES3. Without these
formats, guest MESA uses uncompressed formats to emulate them
while formats like GL_R16 are not available on GPU like MALI.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Get rid of now useless type casts too.
Fixes#121
v2: rebase to remove type casts that were newly introduced in master
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
On GLES B8G8R8A8_SRGB is not available and B8G8R8A8_UNORM can not be
created as immutable. In order to have versions of these formats that
can be created immutable on GLES provide the formats R8G8B8A8_SRGB and
_UNORM with swizzling to BGRA that can then be used instead of the BGRA
formats. Since this may break things these swizzled versions will later
be only enabled when the guest requests them.
v2: Check the base swizzled BGRA format only on GL
v3: Correct type in method name (Gurchetan)
v4: Add PREFER_EMULATED_BRGA to according format binding flags (Gurchetan)
v5: Add comment about formats nou to be used in the guest (Gurchetan)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
On GLES the formats B10G10R10A2_UNORM and B10G10R10X2_UNORM are defined
like R10G10B10.2_UNORM on desktop GL, which is likely incorrect and
interferes with the readback. Using the blit workaround seems to work in
these cases, so disable diect readback in these cases.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Enable DS redaback depending on the availablility of the
corrosponding extensions.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
With 6a3cd2bd vrend: send list of readback-formats to guest
stricter format checks were introduced on GLES. This may lead to format
conversions in guest and host that can be avoided for additional
implementation specific readback formats. So when we build the format list
also check whether a bound texture format can also be read back from the
fbo and report the standard and additional formats also to the guest.
v2: Make things simpler and more correct (Erik) i.e.:
- default to false in the check for readback formats
- rename test function to indicate that we test color formats only
- don't pass the gl_version, instead use the epoxy functions
to get the platform info
v3: - check for DS readback support (Thanks to Erik for pointing out that this
is not available in unextended GLES)
- drop some superfluous braces (Erik)
v4: - move DS checks to separate commit (Erik)
v5: - split patch to move preparations that don't change
functionality to preceeding patches
- reduce the amount of error checking (Erik)
- only check readback for formats that can actually be used as
render targets
- remove some temporary variables (Erik)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Also limit the scope of some variables.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
The name for the internal texture properies flags VIRGL_BIND_NEED-SWIZZLE
and VIRGL_BIND_CAN_TEXTURE_STORAGE is misleading, and the latter flag was
even mis-using the binding member of the texture format structure.
Rename these flags to make it clear that these are not binding flags and
correctly use the 'flags' member for CAN_TEXTURE_STORAGE. In addition, drop
adding the NEED_SWIZZLE flag to the binding in the alpha texture emulation.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
The formats L8A8_UNORM and L16A16_UNORM are usually not supported, but
L8A8_SRGB might, and this results in problems because the host might
ask for a texture view of a L8A8_SRGB by using L8A8_UNORM, and this will
then fail. Removing these formats lets mesa pick suitable replacements on
the guest side. This helps with "The Talos Principle".
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We should also check for S3_s3tc to detect S3TC texture compression
support.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
To avoid that the guest sends mixed color attachments when this is not
supported test this and add an according caps flag.
Related: #88 (a full fix needs a mesa side patch to make use of the
flag sent)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
As of 2018/11/30 EXT_texture_sRGB_R8 is also a valid extension for
desktop GL. Hence, move the format into the joined list so that
it can be picked up if the D-GL host supports it.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is a GLES only extension and the format is also only supported
on a GLES host.
Enables and passes on a host that supports it:
dEQP-GLES31.functional.texture.filtering.cube_array.formats.sr8*
dEQP-GLES31.functional.srgb_texture_decode.skip_decode.sr8.*
Closes: #49
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
We already use GL_FRAMEBUFFER, which is modern OpenGL and have the
same value.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Not all compressed formats can be uploaded using glTexImage2D, that
only works if the extension provides an online texture-compressor. For
instance, EXT_texture_compression_s3tc only requires an online
compressor in the desktop version.
This test isn't really a test for the presence of an online-compressor,
this code is meant to test if we can render from it. But calling
glCompressedTexImage2D requires us to provide a valid compressed
payload, which is really awkward to maintain.
So let's instead just check for extensions to decide if these formats
are renderable or not.
Also, none of these compressed formats can be rendered to, so there's
no point in even testing for that.
Combined with a commit in mesa that enables EXT_texture_compression_s3tc
on GLES 2.0, this makes these dEQP-tests go from NotSupported to Pass
on i965:
- dEQP-GLES2.functional.negative_api.texture.compressedtexsubimage2d_invalid_target
- dEQP-GLES2.functional.negative_api.texture.compressedtexsubimage2d_neg_level_cube
- dEQP-GLES2.functional.negative_api.texture.compressedtexsubimage2d_level_max_tex2d
- dEQP-GLES2.functional.negative_api.texture.compressedtexsubimage2d_level_max_cube
- dEQP-GLES2.functional.negative_api.texture.compressedtexsubimage2d_neg_offset
- dEQP-GLES2.functional.negative_api.texture.compressedtexsubimage2d_offset_allowed
- dEQP-GLES2.functional.negative_api.texture.compressedtexsubimage2d_neg_wdt_hgt
- dEQP-GLES2.functional.negative_api.texture.compressedtexsubimage2d_invalid_size
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In order to ensure that all the errors in the initialization are handled
before entering this routine assert on pre-existsing errors.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Jakob Bornecrantz <jakob@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We didn't correctly reject textures that would fail glTexImage2D with an
GL_INVALID_OPERATION error. Trying to use the so accepted texture formats would later
lead to errors.
Correct this error and also the definition of VIRGL_FORMAT_X24S8_UINT that is needed
for GLES 3.1.
Closes: #15
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Jakob Bornecrantz <jakob@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Gallium copy_image redirects calls to resource_copy_region for equal src
and dst formats or if at least one of the two is compressed. Handle the
condition for selecting blit vs. glCopyImageSubRegion accordingly.
Fixes piglit: bptc-float-modes
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add the combinations that include compressed format to the check to use
glCopyImageSubData. This fixes a number tests of "arb_copy_image-formats"
were compressed textures are the source and uncompressed textures the
destination (no regressions).
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
glTexStorage*D is more restrictive in supporting texture formats, especially
on GLES. Specifically, it doesn't support BGRA textures that are needed to get
any useful display, but it is needed to get immutable textures that are required
for glTextureView.
Check which formats are supported and use glTexStorage*D for these, otherwise
fall back to use glTexImage*D.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On GLES low MSAA textures with low sample counts like 1 and 2 are not
supported as render targets, therefore, copy the sample positions from the
lowest number of samples.
Remove the debug output too.
Fixes on GLES host:
dEQP-GLES31.functional.texture.multisample.samples_1.sample_position
dEQP-GLES31.functional.texture.multisample.samples_2.sample_position
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These VREND_BIND_*-flags here are basically a subset of the
VIRGL_BIND_*-flags, with one custom flag added. So let's just use
those, and use an unused big from the others for the swizzle-flag.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Three component formats are not very helpful, at least the Intel driver doesn't
expose them as color renderable, and other drivers most likely also just emulate
them using RGBX textur formats. RGB32* we have to keep though because it is needed
for ARB_rbo_rgb32 which in turn is needed for OpenGL 4.0.
To handle the latter, mesa/virgl will take care that RGB32* textures are only
allocated as buffers objects.
Reviewed-by: Gurchetan Singh <gurchetansingh at chromium.org>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
When the host is gles >= 3.2, gl >= 4.3, or when the extension
GL_(ARB|EXT|OES)_copy_image is available, memcopy like blitting and region
copying can be done for many color format combinations by using
glCopyImageSubData.
This fixes a number of tests from the subset
dEQP-GLES31.functional.copy_image.non_compressed.viewclass_*
v2: - Clean list of canonical formats (Gurchetan Singh)
- Use size of canonical formats to decide whether they can be copied via
gCopyImageSubData
- Also honour the render state when deciding whether glCopyImageSubData
will do, or whether we need to do a blit.
v3: - replace format size check by compatibility check (Gurchetan Singh) but
keep the check seperate because we need to add logic for compressed
texture later
Reviewed-by: Gurchetan Singh <gurchetansingh at chromium.org>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
Query the number of supported samples and the sample position and
store these to the caps.v2 structure. We support only up to 16 samples.
This implementation requires a GL host backend.
v2: - glTexImage2Dmultisample is not available on a gles 3.1 host
and trying to call it crashed qemu (Jakob Bornecrantz)
Use glTexStorage2DMultisample instead and delete texture each
round because the texture becomes immutable.
- move call to get sample positions only when caps v2 needs to be
filled.
v3: - rebase against master
- take care of nits (Dave)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The warning doesn't really add value, because the way the code is
written the fields will be initialized to zero, hence disable the warning
in this file.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
Commit 84fc54f6bf introduced the use of RG
formats with a swizzle as backing store for guest requested LA formats.
This works for many cases (e.g. blitting), but unfortunately it can't be
used when rendering with blending to an LA target. Since GL doesn't
support texture write swizzles the swizzle needs to happen in the
fragment shader and that's too early for proper blending.
We can safely revert the offending commit since the tests fixed by it
have since been fixed by other commits (e.g., "vrend: Nop sends to
backing iovs for readonly textures v2") in a different way. The one
side effect of reverting is that, depending on the GL version, a less
efficient path may be taken in the guest Mesa when mipmapping LA formats
since they may not be considered color-renderable anymore.
Fixes:
various piglit LA regressions
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove VIRGL_FORMAT_B8G8R8A8_SRGB and VIRGL_FORMAT_B8G8R8X8_SRGB when
running on GLES because we cannot upload textures in GL_BGRA.
Mesa has been extended to use instead their RGBA counterparts.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
glTexImage2D on GLES doesn't support GL_BGRA, so remove this one more
format so one with a GL_RGBA layout is chosen instead on GLES.
Fixes dEQP-GLES3.functional.texture.format.sized.2d.rgb5_a1_pot
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Tested-by: Jakob Bornecrantz <jakob@collabora.com>
and make sure that on GLES it it chosen for GL_RGBA4 over
VIRGL_FORMAT_B4G4R4A4_UNORM, by removing support for the latter.
This is needed because on GLES3 GL_BGRA isn't a supported format to pass
to glTexImage3D.
Fixes the test dEQP-GLES3.functional.texture.format.sized.3d.rgba4_pot
on GLES hosts.
v2: * Make more explicit the GL/GLES split (Gert Wollny)
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Suggested-by: Jakob Bornecrantz <jakob@collabora.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Tested-by: Jakob Bornecrantz <jakob@collabora.com>
As Mesa doesn't support glReadPixel with GL_BGRA_INTEGER on GLES, add this
format so Virgl calls glReadPixel with GL_RGBA_INTEGER.
Fixes dEQP-GLES3.functional.fbo.color.clear.rgb10_a2ui
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Tested-by: Jakob Bornecrantz <jakob@collabora.com>
It seems under some GPU/profile, GL_INVALID_ENUM is generated
instead of GL_INVALID_VALUE for unsupported internal format.
This is even conflicted in reference documents. Just handle
them at same time.
From:
https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glTexImage2D.xhtml
GL_INVALID_ENUM is generated if internalFormat is not one of the accepted
resolution and format symbolic constants.
From:
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexImage2D.xhtml
GL_INVALID_VALUE is generated if internalFormat is not one of the accepted
resolution and format symbolic constants.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This along with another patch allows us to expose
GL_[EXT|ARB]_framebuffer_sRGB on a GLES host.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
Use GL_RG based formats with a swizzle to implement virgl
luminance/alpha formats. Since GL_RG is color renderable this patch
allows more operations to be implemented for virgl luminance/alpha
formats.
Fixes:
dEQP-GLES2.functional.texture.mipmap.2d.generate.la88_fastest
dEQP-GLES2.functional.texture.mipmap.2d.generate.la88_nicest
dEQP-GLES2.functional.texture.mipmap.cube.generate.la88_fastest
dEQP-GLES2.functional.texture.mipmap.cube.generate.la88_nicest
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Akihiko Odaki
Gert Wollny
Ryan Neph
Lepton Wu
Dominik Behr
cheyang
Erik Faye-Lund
Gurchetan Singh
Alexandros Frantzis
Tomeu Vizoso
Jakob Bornecrantz