Mesa have these in it's virgl_hw.h copy, and the values needs to
stay in sync between mesa and virglrenderer here. So let's add this
definition here, where it can be defined only once.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This controls access to the Blend*i* interfaces.
remove comment for colormask interfaces where this doesn't apply.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Similar to e387116, we also need to report this for GLES hosts.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We end up evaluating vrend_format_is_emulated_alpha once in either
case, so let's just lift the logic up so we only have one call-site
in this function.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We already set up a short-hand accessor for vstate->base, so let's
use that for somewhat cleaner code.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since the framebuffer used for blits is reused, attachements must be removed
after executing the blits, otherwise, a still bound depth buffer results
in failing color blits and vice versa.
Stabelizes piglits from "fbo-generatemipmap-formats"
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Instead of having the features in separate named bool, convert it
to an array of bools indexed by an enum.
This is a straight mechanical patch, no code flows should change
and it doesn't change any functionality, it just refactors the
code to use the enum list and a bool array.
Future work should be a lot easier on this, so I'd like to
land it first.
v2: use lowercase enum, move debug_cb in as well.
rename tf2, sort list.
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
This way, mesa can know that the TGSI-parser groks the _PRECISE
modifier, and it doesn't need to cull them any more.
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>
TGSI has a different model for precise than GLSL, so we have to mark
all outputs that has gotten an precise operation output to it as
precise.
This only implements part of the 'precise' keyword (still lacking
support on individual operations), but it's enough to pass some dEQP
tests, in particular:
- dEQP-GLES31.functional.tessellation.common_edge.triangles_equal_spacing_precise
- dEQP-GLES31.functional.tessellation.common_edge.triangles_fractional_odd_spacing_precise
- dEQP-GLES31.functional.tessellation.common_edge.triangles_fractional_even_spacing_precise
- dEQP-GLES31.functional.tessellation.common_edge.quads_equal_spacing_precise
- dEQP-GLES31.functional.tessellation.common_edge.quads_fractional_odd_spacing_precise
- dEQP-GLES31.functional.tessellation.common_edge.quads_fractional_even_spacing_precise
v2: flipped ordering of "invariant" and "precise", to avoid compiler
errors if both are emitted.
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>
v2: use str_match_no_case to fix _SAT_PRECISE detection
v4: usd is_digit_alpha_underscore to match end of mods
Signed-off-by: Karol Herbst <karolherbst@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
[cherry-picked from 4611343bcc05c75bcc9697243dabbb083f7078de in mesa]
Signed-off-by: Dave Airlie <airlied@redhat.com>
Only implemented for glsl->tgsi. Other converters just set precise to 0.
v2: remove precise paramter from ureg_tex_insn and ureg_memory_insn
Signed-off-by: Karol Herbst <karolherbst@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
[cherry-picked from d0dfdf704d6ef974a3bbac826cfd7e511e918f4b in mesa]
Signed-off-by: Dave Airlie <airlied@redhat.com>
OpenGL ES 3.1 does not have glPrimitiveRestart; only OpenGL 3.1
does. So let's avoid making the renderer thing calling this is OK.
Otherwise, it'd be possible to generate evil commands from a rouge
guest-driver that can crash the VM.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise, it'd be possible to generate evil commands from a rouge
guest-driver that can crash the VM.
This is a bit trickier than the previous one, because we were already
mixing calls to the OpenGL 3.0 version and the GL_NV_conditional_render
version, which indicates that this was previously only safe if *both*
were supported, that is OpenGL 3.0 *with* GL_NV_conditional_render.
Now, this code should match the caps we generate, which shouldn't give
any percieved feature-regressions or gl-versions supported.
v2: do not set have_gl_conditional_render if on GLES 3.0 or above.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Tested-by: Po-Hsien Wang <pwang@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise, it'd be possible to generate evil commands from a rouge
guest-driver that can crash the VM.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise, it'd be possible to generate evil commands from a rouge
guest-driver that can crash the VM.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This pulls the code out from the gles31 development,
and modifies the caps to support two different limits
(so far I've only found fs/cs vs everyone else limits differ)
v2: fix buffer creation paths, limit maximums, handle indirect
(don't pass -1 into gl funcs when we don't need to).
v3: free ssbo locs
v4: use two caps fields
Co-authors: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
This passes the structs into translate_tex and cleans up after.
(Inspired while look at merging some stuff from gles tree)
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
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>
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>
I had some missunderstanding about what glEnable(sRGB) did when I added this
warning. As in GLES there is no need to do glEnable(sRGB) at all since it is
implied from the framebuffer.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
Erik Faye-Lund
Dave Airlie
Po-Hsien Wang
Tomeu Vizoso
Gert Wollny
Karol Herbst
Jakob Bornecrantz