| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Reduces duplication, and will do so even more when we change the sampler
plumbing.
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Reduces duplication, and will do so even more when we change the sampler
plumbing.
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We have a CPU-side implementation of conditional rendering; it really
should be done on the GPU. It's not necessarily that hard, but nobody
has gotten to fixing it yet.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we explicitly set the execution size to BRW_EXECUTE_8 and
disabled compression for loop instructions. I can't imagine how this
could be correct in SIMD16 mode.
Looking at the history, it appears that this code has used BRW_EXECUTE_8
since 2007, when we had a SIMD8 backend that supported control flow and
a separate SIMD16 backend that didn't. Presumably, when we added SIMD16
support for shaders with control flow, we simply neglected to update it.
Note that Gen4-5 don't support SIMD16 on shaders with control flow.
This might be a candidate for stable, but would need to be rewritten
completely due to the brw_inst API changes in master.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
The only difference is setting PopCount on Gen4-5.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
We shouldn't need to set them, then set them differently.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
Also delete the comment before that function. Everything in that
comment was either stale, wrong, or captured elsewhere.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
This simplifies all the callers, and it enables the removal of one of
the function parameters.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Apparently unused since it was added in commit af3c9803.
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think OpenVMS was the only platform that Mesa ran on that used a
non-IEEE representation for floats. We removed OpenVMS support a while
back, and this should alleviate the need to continue updating the
this-platform-uses-IEEE list.
The one bit of this patch that needs review is the IS_INF_OR_NAN,
because I'm not sure if MSVC supports isfinite.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82268
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Future patches will rearrange the values in gl_system_value, and I want
to catch errors. Designated initializers would make all of this
unnecessary.
v2: Don't use STATIC_ASSERT. Not only does it not work, but GCC doesn't
tell you that it's not going to work. Thanks for nothing!
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Future patches will necessitate changes to the table, and I only want to
update one.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
| |
Red-only formats should be x001 and RG formats should be xy01.
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
To get uint8_t type, to fix MSVC build.
Trivial.
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
v2: Move the MESA_FORMAT_SWIZZLE enum to the top of the file
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
|
|
|
| |
Compute the bitmask of supported array types once instead of every
time we call a GL vertex array function.
Reviewed-by: Matthew McClure <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This was a regression introduced by commit
f4b0ab7afd83c811329211eae8167c9bf238870c ('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 <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 05b52efbc97731 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 <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: <[email protected]>
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: <[email protected]>
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
| |
Saves one line of code :)
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
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: <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|