Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Due to the destination register width of 1 or 2, these instructions get
ExecSize 1 or 2. But dir and offset (used as src0) are both registers
of width 4, violating the execsize >= width assertion.
I honestly don't think this could have ever worked.
Fixes Piglit's polygon-offset and polygon-mode-offset tests on Gen4-5.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70441
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Current version can create ir_expression where operands have
different base type, patch adds support for unsigned type.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
https://bugs.freedesktop.org/show_bug.cgi?id=80880
Red-only formats should be x001 and RG formats should be xy01.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
If the vertex shader has no position but the gs has, the clipvertex output
was -1 (because it's the same as vs position in this case if there's no
explicit clipvertex output). This caused crashes (or assertion failures) in
clipping since in the end position (which came from gs) was different from
cv (-1) and we then tried to use the bogus cv input.
Rather than just test for -1 cv value in clipping, make it explicitly return
the position output of the gs instead which seems cleaner (since we really
don't want to use the clipvertex value from the vs (it could be a valid value
in the (unsupported) case of vs writing clipvertex but still using a gs).
This fixes piglit shader_runner clip-distance-out-values.shader_test.
Reviewed-by: Zack Rusin <zackr@vmware.com>
The clip stage may crash if there's no position output, for this reason
code was added to avoid running the pipeline stages in this case
(c7c7186045). However, this failed to actually
work when there was a geometry shader, since unlike the vertex shader it did
not initialize the position output to -1, hence the code trying to detect
this didn't trigger. So simply initialize the position output to -1 just like
the vs does.
This fixes piglit glsl-1.50-transform-feedback-type-and-size (segfault->pass).
clip-distance-out-values.shader_test goes from segfault to assertion failure,
suggesting more fixes are needed, no other piglit changes.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
This patch fixes this build error on Mac OS X.
./xmlconfig.h:61:5: error: unknown type name 'uint'; did you mean 'int'?
uint nRanges; /**< \brief Number of ranges */
^~~~
int
./xmlconfig.h:79:5: error: unknown type name 'uint'; did you mean 'int'?
uint tableSize;
^~~~
int
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Again, we delete a lot of functions that aren't really doing anything
interesting anymore.
v2: Comment the texstore_rgba_integer function
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This commit also removes a bunch of functions which aren't doing anything
more interesting than the general path does.
v2: Better comment the texstore_via_float function
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This should be both faster and more accurate than our general slow-path of
converting everything to float.
v2: Add a comment to top of the texstore_swizzle function
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This commit splits the texture storage into three functions:
texstore_depth_stencil, texstore_compressed, and texstore_rgba. Right now
this split seems artificial since we just have one function pointer per
format and there is no difference between these three categories. However,
this split makes it much easier to write a more general function upload
path for one of these categories than the current function pointers.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This commits adds the _mesa_format_to_array function that determines if the
given format can be represented as an array format and computes the array
format parameters. This is a direct helper function for using
_mesa_swizzle_and_convert
v2: Better documentation and commit message
v3: Fixed a potential segfault from an invalid endianness swizzle
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Most format conversion operations required by GL can be performed by
converting one channel at a time, shuffling the channels around, and
optionally filling missing channels with zeros and ones. This adds a
function to do just that in a general, yet efficient, way.
v2:
* Add better comments including full docs for functions
* Don't use __typeof__
* Use inline helpers instead of writing out conversions by hand,
* Force full loop unrolling for better performance
v3: Add another set of parens around the MAX_INT macro
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: Move the MESA_FORMAT_SWIZZLE enum to the top of the file
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Mesa hasn't supported color-indexed textures for some time. This is 0 for
all texture formats, so we don't need to store it.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Instead of a having all of the format metadata in a gigantic hard-to-edit
array of type struct format_info, we now have a human-readable CSV file.
The CSV file also contains more format information than the format_info
struct contained so we can potentially make format_info more detailed later.
The python to generate the format information was added the previous
commit. This commit turns it on in both automake and scons builds.
v2: Split into two commits and stuff to generate format_info.c from scons
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This adds a python script called format_info.py that is used to generate a
single format_info.c file that contains the filled-out format_info array.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The basic concept for the format parser was taken from the format CSV
parser in gallium/auxilliary/util. However, this one has been altered in a
number of ways:
* Removed big endian vs. little endian stuff (mesa doesn't need it)
* Better documentation: Almost every method has a full docstring
* An actual Swizzle class with methods for composition and inverses
* Over-all cleaner (in my opinion) implementation and class interactions
* A few bug fixes
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Specify the quad's Z position in clip coordinate space, not
normalized Z space. Use viewport scale, translation = 0.5, 0.5.
Before, we were specifying the quad's Z position in [0,1] and using
viewport scale=1.0, translate=0.0. That works fine, unless your
driver needs to work in clip coordinate space and needs to
reconstruct viewport near/far values from the scale/translation
factors. The VMware svga driver falls into that category.
When we did that reconstruction we wound up with near=-1 and far=1
which are outside the limits of [0,1]. In some cases, this caused
the quad to be drawn at the wrong depth. In other cases it was
clipped away.
Fixes some scissored depth clears with VMware driver. This should
have no effect on other drivers. We're already using these values
for the glBitmap and glDraw/CopyPixels code.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Compute the bitmask of supported array types once instead of every
time we call a GL vertex array function.
Reviewed-by: Matthew McClure <mcclurem@vmware.com>
This was a regression introduced by commit
f4b0ab7afd ('st/mesa: fix incorrect size
of UBO declarations') which caused an assertion failure while compiling
shaders of e.g. UE4 demos.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81834
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
According to the GL spec the only fragment operations that should affect
glBlitFramebuffer are “the pixel ownership test, the scissor test, and sRGB
conversion”. That implies that dithering should not be performed so we need to
disable it when implementing the blit with a render.
Before commit 05b52efbc9 the dithering state would be left as whatever the
application picks (the default being GL_TRUE) and after that commit it was
explicitly enabled. Neither of these were correct.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81828
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Or the build will fail due to unresolved symbols.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Or the build will fail due to unresolved symbols.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Or the build will fail due to unresolved symbols.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Or the build will fail due to unresolved symbols.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Add documentation for TEX2/TXL2/TXB2 tgsi opcodes. Also, the texture opcode
documentation wasn't very accurate so fix this up a bit.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
In particular need to handle TEX2/TXB2/TXL2 opcodes.
cube map shadow with bias already used TXB2 which didn't work before
at all, despite that there's by default no piglit change (but using
no_quad_lod and no_rho_opt indeed passes some more tex-miplevel-selection
tests).
The actual sampling code still won't handle cube map arrays.
Reviewed-by: Brian Paul <brianp@vmware.com>
This just covers the resource side of things, not the actual sampling.
Here things are trivial as cube map arrays are identical to 2d arrays in
all respects.
Reviewed-by: Brian Paul <brianp@vmware.com>
We would generate EGL_BAD_CONFIG because _eglGetContextAPIBit
returns zero for the combination of EGL_OPENGL_ES_API and a major
version > 3. By just returning zero, the caller can't tell the
difference between a bad version (which should generate
EGL_BAD_MATCH) and a bad API (which should generate
EGL_BAD_CONFIG). This patch causes us to filter out major
versions > 3 at a point where we can generate the correct error.
Fixes gles3 Khronos CTS test:
egl_create_context.egl_create_context
V2: Fix commit message as suggested by Ian.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Changes in the patch will cause datatype to be computed
correctly for 8 and 16 bit integer formats. For example:
GL_RG8I, GL_RG16I etc.
Fixes many failures in gles3 Khronos CTS test:
copy_tex_image_conversions_required
copy_tex_image_conversions_forbidden
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We currently get red bits from ctx->DrawBuffer->Visual.redBits
by making a false assumption that the texture we're writing to
(in glCopyTexImage2D()) is used as a DrawBuffer.
Fixes many failures in gles3 Khronos CTS test:
copy_tex_image_conversions_required
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
GL_TEXTURE_CUBE_MAP is an allowed texture target in glTexStorage2D()
and is allowed to be used (like GL_TEXTURE_2D) with compressed internal
formats.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
