| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On android platform, the width and height of a native window surface may
be updated after initialization. It is therefore necessary to query android
framework for the current width and height.
v2: remove Android specific #ifdef's and just implement the fallback directly
if the platform query_surface() callback is not provided.
TEST=dEQP-EGL.functional.resize.surface_size#* on cyan-cheets
Reviewed-by: Kristian H. Kristensen <[email protected]> (v1)
Reviewed-by: Tomasz Figa <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Change-Id: I673f7d2f1d90c3bf572b30f63da537f2cae1496e
|
|
|
|
|
|
|
| |
Passes all 30 min_sample_shading tests in vulkan cts.
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
V1: Add multisample positions (Nanley)
V2: Fix 8x sample positions to match OpenGL (Anuj)
V3: Vulkan has standard sample locations. They need not be same as
in OpenGL. (Anuj)
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
| |
This will help sharing multisample state setting code.
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
We need this for 'inline'.
Signed-off-by: Mathias Fröhlich <[email protected]>
Tested-by: Brian Paul <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
As requested with the initial creation of util/bitscan.h
now move other bitscan related functions into util.
v2: Split into two patches.
Signed-off-by: Mathias Fröhlich <[email protected]>
Tested-by: Brian Paul <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables GL_shader_draw_parameters and GL_ARB_indirect_parameters as well
as a properly accelerated implementation of GL_ARB_multi_draw_indirect.
Enabling the feature requires a sufficiently uptodate firmware -- those have
already been released a long time ago, although this does mean that the
feature only works with the amdgpu kernel module, since the radeon module
doesn't have a way to query the firmware version.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Note that for indirect draws, the new MULTI firmware packets are required.
There's also no need to reset last_{start_instance,sh_base_reg}, since
resetting last_base_vertex is sufficient.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Byte indices don't need any alignment, so remove this assertion (it got moved
into a path where a piglit test hit it during the refactoring of
commit 64ff23a58c).
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This fixes a bug when indirect draw data is generated by transform
feedback.
Cc: [email protected]
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC doesn't support 64-bit enum values, at least not with C code.
The compiler was warning:
c:\users\brian\projects\mesa\src\mesa\state_tracker\st_atom_list.h(43) : warning
C4309: 'initializing' : truncation of constant value
c:\users\brian\projects\mesa\src\mesa\state_tracker\st_atom_list.h(44) : warning
C4309: 'initializing' : truncation of constant value
...
And at runtime we crashed since the high 32-bits of the 'dirty' bitmask
was always 0xffffffff and the 32+u_bit_scan() index went out of bounds of
the atoms[] array.
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
| |
Literally.
Signed-off-by: Miklós Máté <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
I think this was an oversight when the PIPE_DUMP flags were added.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would not print a swizzle on ssa_52 when only its .x
component is used (as seen in the definition of ssa_53):
vec3 ssa_52 = fadd ssa_51, ssa_51
vec1 ssa_53 = flog2 ssa_52
vec1 ssa_54 = flog2 ssa_52.y
vec1 ssa_55 = flog2 ssa_52.z
But this makes the interpretation of the RHS of the definition difficult
to understand and dependent on the size of the LHS. Just print swizzles
when they are not the identity swizzle, so the previous example is now
printed as:
vec3 ssa_52 = fadd ssa_51.xyz, ssa_51.xyz
vec1 ssa_53 = flog2 ssa_52.x
vec1 ssa_54 = flog2 ssa_52.y
vec1 ssa_55 = flog2 ssa_52.z
Reviewed-by: Timothy Arceri <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the following failures :
dEQP-VK.api.copy_and_blit.resolve_image.whole_4_bit
dEQP-VK.api.copy_and_blit.resolve_image.whole_8_bit
dEQP-VK.api.copy_and_blit.resolve_image.partial_4_bit
dEQP-VK.api.copy_and_blit.resolve_image.partial_8_bit
dEQP-VK.api.copy_and_blit.resolve_image.with_regions_4_bit
dEQP-VK.api.copy_and_blit.resolve_image.with_regions_8_bit
Tested on IVB/HSW
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a37e46323c7e18bec4160f2f66847c10b7041dc1.
It broke the game Overlord such that it hung a GCN GNU. While I don't know
how the hang happened because of its randomness and gfx corruption precedes
it, many of the shaders contain this:
out vec4 FragData[gl_MaxDrawBuffers];
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for YV12 pixel format to the Android platform
backend. Only creating EGL images is supported, it is not added to the
list of available visuals.
v2: Use const array defined just for YV12 instead of trying to be overly
generic.
Signed-off-by: Tomasz Figa <[email protected]>
Signed-off-by: Kalyan Kondapally <[email protected]>
Tested-by: Rob Herring <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Change-Id: I4aeb2d67a95c5cdd10b530c549b23146c8f0b983
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode
and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is
enabled. This is technically incompatible in certain cases, but is
more consistent across GL, ES, and WebGL, and more flexible.
The NVIDIA 367.35 drivers appear to follow this behavior.
For the awful spec analysis, please read Piglit's
tests/spec/arb_framebuffer_srgb/blit.c, which explains the differences
between GL 4.1, 4.2, 4.3 (2012), 4.3 (2013), and 4.4, and why this
is the right rule to implement.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Just avoid whacking GL_FRAMEBUFFER_SRGB altogether, so we respect
the application's setting. This appears to work.
v2: Update one more comment (requested by Ian).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode
and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is
enabled. This is technically incompatible in certain cases, but is
more consistent across GL, ES, and WebGL, and more flexible.
The NVIDIA 367.35 drivers appear to follow this behavior.
For the awful spec analysis, please read Piglit's
tests/spec/arb_framebuffer_srgb/blit.c, which explains the differences
between GL 4.1, 4.2, 4.3 (2012), 4.3 (2013), and 4.4, and why this
is the right rule to implement.
Note that ctx->Color.sRGBEnabled is initialized to _mesa_is_gles(ctx),
and ES doesn't have enable/disable flags for GL_FRAMEBUFFER_SRGB, so
it's effectively on all the time. This means the ES behavior should
be unchanged.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should have no effect, as all drivers which support BLORP also
support ES 3.0 - so ES 2.0 would be promoted and follow the ES 3 rules.
ES 1.0 doesn't have BlitFramebuffer.
This is purely to clarify the next patch a bit.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This reverts commit 4e549ddb500cf677b6fa16d9ebdfa67cc23da097,
dropping the hack from Gallium that I just deleted from i965.
See the previous commit for rationale.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've never quite understood the purpose of this hack - supposedly,
doing resolves in the sRGB colorspace is slightly more accurate.
Currently, BlitFramebuffer() ignores sRGB encoding and decoding
on OpenGL, although it encodes and decodes in GLES 3.x.
The updated OpenGL 4.4 rules also allow for encoding and decoding
if GL_FRAMEBUFFER_SRGB is enabled, allowing the application to
control what colorspace blits are done in. I don't think this hack
makes any sense in such a world - the application can do what it
wants, and we shouldn't second guess them.
A related Piglit patch, "Make multisample accuracy test set
GL_FRAMEBUFFER_SRGB when resolving." makes the Piglit MSAA accuracy
test explicitly request SRGB encoding/decoding during resolves when
running "srgb" subtests. Without that patch, this commit will regress
those tests, but with it, they should continue to work just fine.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modern OpenGL BlitFramebuffer require sRGB encode/decode when
GL_FRAMEBUFFER_SRGB is enabled. The blitter can't handle this,
so we need to bail. On Gen4-5, this means falling back to Meta,
which should handle it.
We allow sRGB <-> sRGB blits, as decode then encode ought to be a noop
(other than potential precision loss, which nobody wants anyway).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are DRI_IMAGE_FOURCC macros, for which there are no corresponding
DRI_IMAGE_FORMAT macros. To support such formats we need to make the
lookup function take the native format directly. As a side effect, it
simplifies all existing calls to this function, because they all called
get_format() first to convert from native to DRI_IMAGE_FORMAT.
Signed-off-by: Tomasz Figa <[email protected]>
Tested-by: Rob Herring <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Change-Id: I4674000fb5ccfd02e38b8fa89bc567ac1d4fc16b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch splits current dri2_create_image_android_native_buffer() into
main entry point and two additional functions, one for creating an image
from flink name and one for handling prime FDs using the generic DMA-buf
path. This makes the code cleaner and also prepares for disabling flink
path more easily in the future.
v2: Split into separate patch.
Add error messages.
Signed-off-by: Tomasz Figa <[email protected]>
Tested-by: Rob Herring <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Change-Id: Ifdfb5927399d56992fe707160423c29278f49172
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drivers can request different set of buffers depending on the buffer
mask they pass to the get_buffers callback. This patch makes
droid_image_get_buffers() respect this mask.
v2: Return error only in case of real error condition and ignore requests
of unavailable buffers.
Signed-off-by: Tomasz Figa <[email protected]>
Tested-by: Rob Herring <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Change-Id: I6c3c4eca90f4c618579f6725dec323c004cb44ba
|
|
|
|
|
|
|
|
|
|
| |
Fix compilation warnings due to unused variables left after some earlier
code changes.
Signed-off-by: Tomasz Figa <[email protected]>
Tested-by: Rob Herring <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Change-Id: Iec09eb2a62887f3a38dff156756ed8385f3f3447
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We've been setting it in gen7 forever but never in gen8; best to make it
consistent. This hasn't caused any problems yet because we don't advertise
support for statistics queries yet.
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The multisample rasterization mode is computed based on this field,
3DSTATE_RASTER::DXMultisampleRasterizationMode (only for forced
multisampling), 3DSTATE_RASTER::APIMode, and the number of samples. There
are two tables in the SKL PRM that describe how the final multisample mode
is calculated: "Windower (WM) Stage >> Multisampling >> Multisample
ModeState >> Table 1" and the formula for "SF_INT::Multisample
Rasterization Mode".
The "DX Multisample Rasterization Enable" bit changes whether multisample
mode is set to OFF_PIXEL or ON_PATTERN in the samples > 1 case. In the
samples == 1 case, the bit has no effect. Since Vulkan has no concept of
disabling multisampling for samples > 1, we can just set the bit.
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
This is now handled in emit_3dstate_clip
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This error condition is not implementable when using tessellation or
geometry shaders. The text was also removed from the ES 3.2 spec.
I believe the intended behavior is to remove the error condition
when either OES_geometry_shader or OES_tessellation_shader are
exposed.
v2: Quote a better part of issue 13 (suggested by Ian).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
| |
Mostly, I want to share the GLES 3 transform feedback handling,
though most of the rest of the code is identical as well.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
| |
This adds the #extension directive support, built-in #defines,
lexer keyword support, and updates has_tessellation_shader().
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
| |
This makes them available in the GLES 3.1 API.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also update _mesa_has_tessellation to know about the new extensions.
For now, these are dummy_false, to avoid turning on the extension
until everything's in place. Eventually, we'll move them over to
the "ARB_tessellation_shader" bit so that any drivers supporting
both the desktop extension and ES 3.1 get the feature.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|