| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seems like we forget to update the index buffer (ib) status and
IndexedDrawCutIndexEnable or CutIndexEnable flag is left unchanged it
leads to ignoring of glEnable/glDisable functions for GL_PRIMITIVE_RESTART
in some cases. The index buffer (ib) status should be re-emmited after the
reset option change to avoid some unexpected behavior.
Reviewed-by: Lionel Landwerlin <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109451
Cc: <[email protected]>
Signed-off-by: Andrii Simiklit <[email protected]>
Signed-off-by: Andrii Simiklit <[email protected]>
|
|
|
|
|
|
|
|
|
| |
From the table in isl_format.c, it appears that all generations
support blending on 32-bit float surfaces.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
Found by inspection.
Signed-off-by: Lionel Landwerlin <[email protected]>
Fixes: 3da858a6b990c5 ("intel/compiler: add scale_factors to sampler_prog_key_data")
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
|
|
|
| |
Object handles are local to the device fd, so double check we are not
mixing together objects from multiple screens on execbuf submission.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
After the previous changes to emulate the ETC/EAC formats using the
secondary shadow miptree, the etc_format field of the intel_mipmap_tree
struct became redundant and the remaining check that used it has been
replaced. (Nanley Chery)
Reviewed-by: Nanley Chery <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
OES_copy_image extension was disabled on Gen7 due to the lack of support
for ETC2 images. Enabled it back. (Kenneth Graunke)
v2:
- Removed the blank lines in the comments above OES_copy_image and
OES_texture_view extensions in intel_extensions.c (Nanley Chery)
Reviewed-by: Nanley Chery <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For CopyImageSubData to copy the data during the 1st draw call, we need
to update the shadow tree right before the rendering.
v2:
- Added assertion that the miptree doesn't need update at the time we
update the texture surface. (Nanley Chery)
v3:
- As we now update the tree before the rendering we don't need to copy
the data during the unmap anymore. Removed the unnecessary update from
the intel_miptree_unmap in intel_mipmap_tree.c (Nanley Chery)
v4:
- Fixed unrelated empty line removal (Nanley Chery)
- As now the intel_upate_etc_shadow of intel_mipmap_tree.c is only
called inside its following function, we don't need to declare it at
the top of the file anymore. (Nanley Chery)
Reviewed-by: Nanley Chery <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GPUs Gen < 8 cannot sample ETC2 formats. So far, they converted the
compressed EAC/ETC2 images to non-compressed RGBA images. When
GetCompressed* functions were called, the pixels were returned in this
RGBA format and not the compressed format that was expected.
Trying to fix this problem, we use a secondary shadow miptree to store the
decompressed data for the rendering and the main miptree to store the
compressed for the Get functions to work. Each time that the main miptree
is written with compressed data, we decompress them to RGB and update the
shadow. Then we use the shadow for rendering.
v2:
- Fixes in the commit message (Nanley Chery)
- Reversed the changes in brw_get_texture_swizzle and swapped the b, g
values at the time that we decompress the data in the function:
intel_miptree_update_etc_shadow of intel_mipmap_tree.c (Nanley Chery)
- Simplified the format checks in the miptree_create function of the
intel_mipmap_tree.c and reserved the call of the
intel_lower_compressed_format for the case that we are faking the ETC
support (Nanley Chery)
- Removed the check for the auxiliary usage for the shadow miptree at
creation (miptree_create of intel_mipmap_tree.c) as we won't use
auxiliary buffers with these types of trees (Nanley Chery)
- Set the etc_format of the non-ETC miptrees to MESA_FORMAT_NONE and
removed the unecessary checks (Nanley Chery)
- Fixed an unrelated indentation change (Nanley Chery)
- Modified the function intel_miptree_finish_write to set the
mt->shadow_needs_update to true to catch all the cases when we need to
update the miptree (Nanley Chery)
- In order to update the shadow miptree during the unmap of the
main and always map the main (Nanley Chery) the following change was
necessary: Splitted the previous update function that was updating all
the mipmap levels and use two functions instead: one that updates one
level and one that updates all of them. Used the first during unmap
and the second before the rendering.
- Removed the BRW_MAP_ETC_BIT flag and the mechanism to decide which
miptree should be mapped each time and reversed all the changes in the
higher level texture functions that upload data to textures as they
aren't needed anymore.
- Replaced the boolean needs_fake_etc with an inline function that
checks when we need to fake the ETC compression (Nanley Chery)
- Removed the initialization of the strides in the update function as
the values will be overwritten by the intel_miptree_map call (Nanley
Chery)
- Used minify instead of division in the new update function
intel_miptree_update_etc_shadow_levels in intel_mipmap_tree.c (Nanley
Chery)
- Removed the depth from the calculation of the number of slices in
the new update function (intel_miptree_update_etc_shadow_levels of
intel_mipmap_tree.c) as we don't need to support 3D ETC images.
(Nanley Chery)
v3:
- Renamed the rgba_fmt in function miptree_create
(intel_mipmap_tree.c) to decomp_format as the format is not always in
rgba order. (Nanley Chery)
- Documented the new usage for the shadow miptree in the comment above
the field in the intel_miptree struct in intel_mipmap_tree.h (Nanley
Chery)
- Removed the redundant flags from the mapping of the miptrees in
intel_miptree_update_etc_shadow of intel_mipmap_tree.c (Nanley Chery)
- Fixed the switch from surface's logical level to physical level in
the intel_miptree_update_etc_shadow_levels of intel_mipmap_tree.c
(Nanley Chery)
- Excluded the Baytrail GPUs from the check for the ETC emulation as
they support the ETC formats natively. (Nanley Chery)
- Simplified the check if the format is BGRA in
intel_miptree_update_etc_shadow of intel_mipmap_tree.c (Nanley Chery)
v4:
- Removed the functions intel_miptree_(map|unmap)_etc and the check if
we need to call them as with the new changes, they became unreachable.
(Nanley Chery)
- We'd rather calculate the level width and height using the shadow
miptree instead of the main in intel_miptree_update_etc_shadow_levels of
intel_mipmap_tree.c (Nanley Chery)
- Fixed the format in the mt_surface_usage, set at the miptree creation,
in miptree_create of intel_mipmap_tree.c (Nanley Chery)
v5:
- Fixed the levels calculations in intel_mipmap_tree.c (Nanley Chery)
- Update the flag shadow_needs_update outside the function
intel_miptree_update_etc_shadow (Nanley Chery)
- Fixed indentation error (Nanley Chery)
v6:
- Fixed typo in commit message (Nanley Chery)
- Simplified the assignment of the mt_fmt in the miptree_create of the
intel_mipmap_tree.c (Nanley Chery)
- Combined declarations and assignments where it was possible in the
intel_miptree_update_etc_shadow and
intel_miptree_update_etc_shadow_levels of the intel_mipmap_tree.c
(Nanley Chery)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81843
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104272
Reviewed-by: Nanley Chery <[email protected]>
|
|
|
|
|
|
|
| |
Use more generic field names. We'll reuse these fields for a workaround
with ASTC miptrees.
Reviewed-by: Eleni Maria Stea <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
We have cases where we would not like to expose these.
v2: call the option allow_rgb565_configs for consistency
with existing allow_rgb10_configs (Eric, Jason)
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
There was an issue recently caused by the system header being included
by mistake, so let's just get rid of this include path and always
explicitly #include "drm-uapi/FOO.h"
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Kristian H. Kristensen <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Tapani Pälli <[email protected]>
Signed-off-by: Lin Johnson <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
|
|
| |
Patch propagates given scale_factors to lowering options.
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
prog->SamplersUsed is set by the linker when validating resource limits,
while info->textures_used is gathered after NIR optimizations, which may
have eliminated some unused surfaces.
This may let us skip some work.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
textures_used_by_txf is a subset of textures_used which is a subset
of prog->SamplerUnits. This should do nothing.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eric and I would like a bitmask of which samplers are used, similar to
prog->SamplersUsed, but available in NIR. The linker uses SamplersUsed
for resource limit checking, but later optimizations may eliminate more
samplers. So instead of propagating it through, we gather a new one.
While there, we also gather the existing textures_used_by_txf bitmask.
Gathering these bitfields in nir_shader_gather_info is awkward at best.
The main reason is that it introduces an ordering dependency between the
two passes. If gathering runs before lower_samplers_as_deref, it can't
look at var->data.binding. If the driver doesn't use the full lowering
to texture_index/texture_array_size (like radeonsi), then the gathering
can't use those fields. Gathering might be run early /and/ late, first
to get varying info, and later to update it after variant lowering. At
this point, should gathering work on pre-lowered or post-lowered code?
Pre-lowered is also harder due to the presence of structure types.
Just doing the gathering when we do the lowering alleviates these
ordering problems. This fixes ordering issues in i965 and makes the
txf info gathering work for radeonsi (though they don't use it).
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
An upcoming patch will start building derefs in prog_to_nir, at which
point we'll need to lower them to indexes.
This gets both GLSL and non-GLSL shaders using the same paths.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
I guess that when we calculating the width0, height0, depth0
to use for function 'intel_miptree_create' we need to consider
the 'base level' like it is done in the 'intel_miptree_create_for_teximage'
function.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
Signed-off-by: Andrii Simiklit <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
It is always false on Gen8+.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Android.mk and autotools disagree about where generated files should
go, which wasn't a problem until we wanted to build a dist
tarball. This corrects the problem by changing the output and include
paths to be the same on android and autotools (meson already has the
correct include path).
Fixes: 7d7b30835cfb9eb89beca9fb8593d0954f79b84d
("automake: Fix path to generated source")
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
|
|
|
|
|
| |
If you pass a bool in as the value to set, the C standard says that it
gets converted to an int prior to shifting. If you try to set a bool to
bit 31, this lands you in undefined behavior. It's better just to add
the explicit cast and let the compiler delete it for us.
Reviewed-by: Iago Toral Quiroga <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Gert Wollny <[email protected]>
Reviewed-by: <Gurchetan Singh [email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Compilation of user-specified shaders with software fp64 works by
compiling on demand an "fp64-funcs" shader implementing various fp64
operations and then linking it into the "user shader".
In
commit 64b8c86d37ebb1e1d286c69d642d52b7bcf051d3
Author: Timothy Arceri <[email protected]>
Date: Thu Jan 17 17:16:29 2019 +1100
glsl: be much more aggressive when skipping shader compilation
we changed the behavior of the shader cache to skip compilation earlier
when we get a cache hit.
After the aforementioned commit, compiling a user program using fp64
would store into the cache an entry for the fp64-funcs shader.
Subsequent compilations of uncached user shaders using fp64 would fail
in compile_fp64_funcs() after finding a cache entry for the fp64-funcs,
but being unprepared to read from the cache.
It's unclear to me how to retrieve the cached NIR of the fp64-funcs (if
it even is cached), so just call _mesa_glsl_compile_shader() with
force_recompile=true in order to ensure we generate the fp64-funcs
successfully.
Tested-by: Mark Janes <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original idea was that the backend compiler could eliminate
surfaces, so we would have it mark which ones are actually used,
then shrink the binding table accordingly. Unfortunately, it's a
pretty blunt mechanism - it can only prune things from the end,
not the middle - since we decide the layout before we even start
the backend compiler, and only limit the size. It also basically
gives up if it sees indirect array access.
Besides, we do the vast majority of our surface elimination in NIR
anyway, not the backend - and I don't see that trend changing any
time soon. Vulkan abandoned this plan a long time ago, and I don't
use it in Iris, but it's still been kicking around in i965.
I hacked shader-db to print the binding table size in bytes, and
observed no changes with this patch. So, this code appears to do
nothing useful.
Acked-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This will allow drivers to pin shader buffers if necessary.
i965 and anv do not need to do this today, but iris will.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, BLORP expects drivers to provide two functions for dealing
with buffers: blorp_emit_reloc and blorp_surface_reloc. Both record a
relocation and combine the BO address and offset into a full 64-bit
address. Traditionally, blorp_surface_reloc has written that combined
address to an implicitly-known buffer where surface states are stored.
(In contrast, blorp_emit_reloc returns the value.)
The upcoming Iris driver stores surface states in multiple buffers,
which makes it impossible for blorp_surface_reloc to write the combined
address - it only takes an offset, not the actual buffer to write to.
This commit adds a third function, blorp_get_surface_address, which
combines and returns an address, which is then passed to ISL's surface
state fill functions. Softpin-only drivers can return a real address
here and skip writing it in blorp_surface_reloc. Relocation-based
drivers are have options. They can simply return 0 from the new
function, and continue writing the address from blorp_surface_reloc.
Or, they can return a presumed address from blorp_get_surface_address,
and have other relocation processing write the real value later.
For now, i965 and anv simply return 0.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Brown bag fix...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch moves intel_tiled_memcpy[_sse41] libraries to isl, renames some
functions and types and makes the required build system changes for
meson, automake and Android. No functional changes are introduced.
v2: code cleanups, move isl_get_memcpy_type to i965 (Jason)
v3: move isl_mem_copy_fn to priv header, cleanups (Jason, Dylan)
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Now that we have software implementations of ARB_gpu_shader_int64 and
ARB_gpu_shader_fp64 we can unconditionally enable these extensions.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
The following patches will add implementations of various
double-precision operations to this file.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
From glibc printf(3):
Z A nonstandard synonym for z that predates the appearance of z.
Do not use in new code.
Z may not exist on non-glibc systems. Prefer the standard symbol.
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
| |
Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even with the previous commit, hangs are still happening. The problem
there is that the VF cache invalidate do happen immediately without
waiting for previous rendering to complete. What happens is that we
invalidate the cache the moment the PIPE_CONTROL is parsed but we
still have old rendering in the pipe which continues to pull data into
the cache with the old high address bits. The later rendering with the
new high address bits then doesn't have the clean cache that it
expects/needs.
v2: Update commit message/explanation with Jason's
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Fixes: a363bb2cd0e2a1 ("i965: Allocate VMA in userspace for full-PPGTT systems.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109072
|
|
|
|
|
|
|
|
|
|
|
| |
These buffers are using VB slots and should be included in the
workaround decision.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Fixes: a363bb2cd0e2a1 ("i965: Allocate VMA in userspace for full-PPGTT systems.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109072
|
|
|
|
|
|
|
|
|
| |
Documentation of the 3DSTATE_VERTEX_BUFFERS packet says this is only
needed before ICL.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Gen9-10 have fewer than 4 subslices per slice, so they need this to be
rounded up. Gen11 isn't documented as needing this hack, and it can
also have more than 4 subslices, so the hack actually can break things.
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gen9 hardware requires some workarounds to disable preemption depending
on the type of primitive being emitted.
We implement this by adding a function that checks the primitive type
and number of instances right before the 3DPRIMITIVE.
For now, we just ignore blorp. The only primitive it emits is
3DPRIM_RECTLIST, and since it's not listed in the workarounds, we can
safely leave preemption enabled when it happens. Or it will be disabled
by a previous 3DPRIMITIVE, which should be fine too.
v3:
- Apply missing workarounds for instanced rendering and line loop (Ken)
- Move workaround code to brw_draw_single_prim()
Signed-off-by: Rafael Antognolli <[email protected]>
Cc: Kenneth Graunke <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set bit when initializing context.
v3:
- Always toggle preemption bool to false before enabling it for the
first time, so the state gets emitted (Chris Wilson).
- Emit end of pipe sync with PIPE_CONTROL_RENDER_TARGET_FLUSH (Ken)
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we first started using genxml, we decided to represent MOCS as an
actual structure, and pack values. However, in many places, it was more
convenient to use a numeric value rather than treating it as a struct,
so we added secondary setters in a bunch of places as well.
We were not entirely consistent, either. Some places only had one.
Gen6 had both kinds of setters for STATE_BASE_ADDRESS, but newer gens
only had the struct-based setters. The names were sometimes "Constant
Buffer Object Control State" instead of "Memory", making it harder to
find. Many had prefixes like "Vertex Buffer MOCS"...in a vertex buffer
packet...which is a bit redundant.
On modern hardware, MOCS is simply an index into a table, but we were
still carrying around the structure with an "Index to MOCS Table" field,
in addition to the direct numeric setters. This is clunky - we really
just want a number on new hardware.
This patch eliminates the struct-based setters, and makes the numeric
setters be consistently called "MOCS". We leave the struct definition
around on Gen7-8 for reference purposes, but it is unused.
v2: Drop bonus "Depth Buffer MOCS" fields on Gen7.5 and Gen9
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kristian H. Kristensen <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
load_register_imm and load_register_mem take the destination as the
first argument, so I'd like load_register_reg to do the same the sake
of consistency. Otherwise, reading sequences of mixed LRI/LRM/LRR is
needlessly confusing.
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
| |
Dead since commit 09e041d61d367ff3a9e8492521606090050255d4 (May 2016).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the softpin world, surface state base address may be a fixed 64-bit
address (with no associated BO). It makes sense to store this in the
offset field. But it needs to be the full size.
We also update the clear color address to be consistently uint64_t
everywhere so we can continue passing intel_miptree_get_clear_color
a pointer to the blorp_address's offset field without type mismatches.
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This also turns on EXT_multisampled_render_to_texture which is a
subset of EXT_multisampled_render_to_texture2, allowing only
COLOR_ATTACHMENT0.
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Kristian H. Kristensen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extension is not properly tested (testing for
GL_ARB_fragment_shader_interlock is not sufficient), and since this was
noted in review on August 28th no tests have been sent.
Revert "i965: Add INTEL_fragment_shader_ordering support."
Revert "mesa: Add GL/GLSL plumbing for INTEL_fragment_shader_ordering"
This reverts commit 03ecec9ed2099f6e2b62994b33dc948dc731e7b8.
This reverts commit 119435c8778dd26cb7c8bcde9f04b3982239fe60.
Cc: [email protected]
Acked-by: Jason Ekstrand <[email protected]>
Acked-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
The warning is emitted when building without INLINE_SSE41.
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally the driver reported GL_FRAMEBUFFER_UNSUPPORTED in all cases,
adding more specific error messages was not correct and broke many tests.
Mostly revert this and only report GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT
for MESA_FORMAT_R_SRGB8.
Fixes: ebcde3454552adc6d3fea8af2207aafaba857796
i965: be more specific about FBO completeness errors
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108805
Signed-off-by: Gert Wollny <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
|