Those stages only really work for OGL-style texturing (so number of samplers
and views mostly the same, certainly for the max values).
These get often set up all at once, thus there might be max number of both
even if all of them are just NULL. We must not set the max number of samplers
and views to the same value since that will lead to terrible things if a driver
supports more views than samplers (and the state tracker set up all the views).
(This will not make these stages magically work if a shader uses dx10-style
texturing, they might still replace an actually used sview in that case.)
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This patch modifies the SSE4.1 test in configure.ac to use a global
variable to initialize vector variables. In addition, we now return the
value of the computation instead of 0.
This is done so gcc 4.9 (and lower) won't optimize the SSE4.1 assembly
instructions (when using -O1 and higher), because then the configure test
might incorrectly pass even though the assembler doesn't support the
SSE4.1 instructions (the test will pass because the compiler does support the intrinsics).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91806
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
OpenGLES 3.1 cannot be enabled for gen 7 (Ivy Bridge, Haswell) since
they are still missing ARB_stencil_texturing.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
Previously we were checking the desktop OpenGL ARB_compute_shader
requirements, but for OpenGLES 3.1, the requirements are lower.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
The OpenGL ARB_compute_shader extension specfication requires at least
1024 for GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS, whereas OpenGLES 3.1
only required 128.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The maximum number of resident warps per multiprocessor is 64 on
Kepler instead of 48 on Fermi.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
It's nonsense to drain the pipeline like this.
v2: keep the drain for DMA-buf exports.
v3: flush before the export and after compositing and add TODO comment.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Julien Isorce <j.isorce@samsung.com>
Tested-by: Julien Isorce <j.isorce@samsung.com>
This reverts commit 839793680f.
The patch was breaking DRI3 because driGLFormatToImageFormat does not
handle MESA_FORMAT_B8G8R8X8_SRGB which ended up making it fail to
create the renderbuffer and it would later crash. It's not trivial to
add this format because there is no __DRI_IMAGE_FORMAT nor
__DRI_IMAGE_FOURCC define for the format either. I'm not sure how
difficult adding this would be and whether adding a new format would
require some sort of new version for DRI. Seeing as this might take a
while to fix I think it makes sense to just revert the patch in the
meantime in order to avoid regressing master.
It is also not handled in intel_gles3_srgb_workaround and there may be
other cases where it breaks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93388
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>
Previously the GL spec required that whenever glBlitFramebuffer is
used with either buffer being multisampled, the internal formats must
match. However the GL 4.4 spec was later changed to remove this
restriction. In the section entitled “Changes in the released
Specification of July 22, 2013” it says:
“Relax BlitFramebuffer in section 18.3.1 so that format conversion can
take place during multisample blits, since drivers already allow this
and some apps depend on it.”
If most drivers already allowed this in earlier versions I think it's
safe to assume that this is a spec bug and it should also be allowed
in all versions.
This patch just removes the restriction on desktop GL. For GLES there
are conformance tests that assert the previous behaviour so it is
probably safer to leave it in.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92706
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
"image" is not ready yet since it will be set at
the end of the function by: *image = *img;
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Reviewed-by: Christian K<C3><B6>nig <christian.koenig@amd.com>
We just ignored them altogether. While this feature is rather old-fashioned
supporting it is actually rather trivial.
This fixes the associated piglit tests (2 gl-1.0-edgeflag, 2 gl-2.0-edgeflag
and all (7) of point-vertex-id).
v2: comment fixes, and make the use of the edgeflag in clipmask consistent
with when it's actually there (should be impossible to hit a case where the
difference would actually matter but still...)
Reviewed-by: Brian Paul <brianp@vmware.com>
This just adds confusion, these parameters are used when fetching vertices
by translate, but certainly not when emitting hw vertices for drivers, they
make no sense there (setting them has no consequences otherwise since there
won't be any elements with instance_divisor set). So just set them to 0 (the
draw_pipe_vbuf code for emitting vertices when the draw pipeline is run
already does exactly that).
Also while here do some whitespace cleanup.
Reviewed-by: Brian Paul <brianp@vmware.com>
Previously this wasn't a problem. However, with the new API update,
descriptor sets can now be sparse so the client doesn't have to provide an
entry for every binding. This means that it's possible for a binding to be
uninitialized other than the memset. In that case, we want to have a null
array of immutable samplers.
Now that we have a helper in the builder for system values and a helper in
core NIR to get the intrinsic opcode, there's really no point in having
things split out into a helper function. This commit "modernizes" this
pass to use helpers better and look more like newer passes.
Reviewed-by: Eric Anholt <eric@anholt.net>
The VC4_DEBUG=cl,qpu is nice and all, but I want to be able to get more
detailed dumps, and to replay the same exact commands in simulation. For
that I need a dump with all of the VBOs, shaders, shader recs, etc. This
dump can be parsed by vc4-gpu-tools.
For now this is only doable from simulator mode, because otherwise we
don't have access to the RCL contents generated by the kernel.
Any update here should have been the same as in
vc4_set_framebuffer_state(), except for the point where vc4_blit.c
temporarily sets different state for its different buffers.
This is apparently a weirdness of gallium -- nr_samples==1 is occasionally
used and means the same thing as nr_samples==0. Fixes a bunch of
ARB_framebuffer_srgb blit cases in piglit.
It's really harsh to abort() the X Server because of a momentary failure
(particularly -ENOMEM). I don't see a way to pass an -ENOMEM up the stack
from here, but we can at least log to stderr before proceeding on.
Cc: "11.1" <mesa-stable@lists.freedesktop.org>
