Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX
Hi,
It's possible 19.1 has another issue, I only tested the master branch
with my fix. I would suggest trying 19.0 or the master branch.
FYI, I haven't pushed it anywhere but I recently rebased my Nexus 5
patches from last year (and been looking at getting call audio working).
Jonathan
On 6/8/19 9:08 PM, Brian Masney wrote:
Hi,
I'm trying to get the GPU working using the Freedreno driver (A330) on
the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches
related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run
glxgears, I see the gears show up for a fraction of a second and then
it terminates due to the following error:
-
shader: MESA_SHADER_FRAGMENT
inputs: 1
outputs: 1
uniforms: 0
shared: 0
decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0)
decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, 0, 0)
decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, 0, 0)
decl_function main (0 params)
impl main {
block block_0:
/* preds: */
vec1 32 ssa_0 = load_const (0x /* 0.00 */)
vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /*
interp_mode=1 */
vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, ssa_0) (0,
0) /* base=0 */ /* component=0 */ /* in_0 */
vec1 32 ssa_3 = deref_var (uniform sampler2D)
vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y
vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 (sampler_deref),
ssa_4 (coord)
Unhandled NIR tex src type: 11
intrinsic store_output (ssa_5, ssa_0) (0, 15, 0) /* base=0 */ /*
wrmask=xyzw */ /* component=0 */ /* out_0 */
/* succs: block_1 */
block block_1:
}
Assertion failed: !"" (../src/freedreno/ir3/ir3_context.c: ir3_context_error:
407)
-
I verified that the mesa 19.1.0-rc5 release contains this recent a3xx
fix from Jonathan:
https://gitlab.freedesktop.org/mesa/mesa/commit/1db86d8b62860380c34af77ae62b019ed2376443
Any suggestions?
[1] https://github.com/masneyb/linux/commits/v5.2-rc3-nexus5-gpu-wip
The GPU specific patches start at Rob's patch 'qcom-scm: add support
to restore secure config' on that list. I submitted the patches
below that a few weeks ago to the upstream kernel and I expect
they'll be merged. Once I have a working GPU, I plan to start
working on the interconnect support in the kernel for msm8974 so
that the clock hacks can be dropped.
Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX
Hi,
I'm trying to get the GPU working using the Freedreno driver (A330) on
the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches
related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run
glxgears, I see the gears show up for a fraction of a second and then
it terminates due to the following error:
-
shader: MESA_SHADER_FRAGMENT
inputs: 1
outputs: 1
uniforms: 0
shared: 0
decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0)
decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, 0, 0)
decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, 0, 0)
decl_function main (0 params)
impl main {
block block_0:
/* preds: */
vec1 32 ssa_0 = load_const (0x /* 0.00 */)
vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /*
interp_mode=1 */
vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, ssa_0) (0, 0)
/* base=0 */ /* component=0 */ /* in_0 */
vec1 32 ssa_3 = deref_var (uniform sampler2D)
vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y
vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 (sampler_deref), ssa_4
(coord)
Unhandled NIR tex src type: 11
intrinsic store_output (ssa_5, ssa_0) (0, 15, 0) /* base=0 */ /*
wrmask=xyzw */ /* component=0 */ /* out_0 */
/* succs: block_1 */
block block_1:
}
Assertion failed: !"" (../src/freedreno/ir3/ir3_context.c: ir3_context_error:
407)
-
I verified that the mesa 19.1.0-rc5 release contains this recent a3xx
fix from Jonathan:
https://gitlab.freedesktop.org/mesa/mesa/commit/1db86d8b62860380c34af77ae62b019ed2376443
Any suggestions?
[1] https://github.com/masneyb/linux/commits/v5.2-rc3-nexus5-gpu-wip
The GPU specific patches start at Rob's patch 'qcom-scm: add support
to restore secure config' on that list. I submitted the patches
below that a few weeks ago to the upstream kernel and I expect
they'll be merged. Once I have a working GPU, I plan to start
working on the interconnect support in the kernel for msm8974 so
that the clock hacks can be dropped.
Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110861] The Witcher 3: blocky shadow artifacts on distant objects
https://bugs.freedesktop.org/show_bug.cgi?id=110861 --- Comment #1 from tele4...@hotmail.com --- Hi, this looks like #110811 (https://bugs.freedesktop.org/show_bug.cgi?id=110811), please retest with mesa built against LLVM r362749 or newer. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110810] Vulkan spec break: VkCommandBufferInheritanceInfo.framebuffer is NOT optional
https://bugs.freedesktop.org/show_bug.cgi?id=110810 Sebastian Sydow changed: What|Removed |Added Version|unspecified |19.1 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110810] Vulkan spec break: VkCommandBufferInheritanceInfo.framebuffer is NOT optional
https://bugs.freedesktop.org/show_bug.cgi?id=110810 Sebastian Sydow changed: What|Removed |Added Component|Other |Drivers/Vulkan/radeon -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110810] Vulkan spec break: VkCommandBufferInheritanceInfo.framebuffer is NOT optional
https://bugs.freedesktop.org/show_bug.cgi?id=110810 --- Comment #3 from Sebastian Sydow --- Thanks for the clarification on the Intel front. Let's just hope the RADV team sees this -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110861] The Witcher 3: blocky shadow artifacts on distant objects
https://bugs.freedesktop.org/show_bug.cgi?id=110861 Bug ID: 110861 Summary: The Witcher 3: blocky shadow artifacts on distant objects Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: tempel.jul...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org There are blocky shadow artifacts on distant objects: https://abload.de/img/tw3lyk3t.png I think this is a regression in either radv or llvm, as I can't recall seeing these artifacts the last time I tested with radv. Funny: amdvlk had a similar (or even the very same?) issue and it got fixed with its latest update. mesa-git 19.2.0_devel.111569.22025595f3f llvm-libs-git 9.0.0_r318186.669775f9db7 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] android: radv: fix necessary dependecies
Hi,
please provide Reviewed-by when possible
There is another patch sent to ML which his already reviewed by Tapani and
waiting for this one
Mauro
On Wed, Apr 24, 2019 at 3:44 PM Mauro Rossi wrote:
> Fixes building errors due to missing libmesa_util generated files include
> and libexpat dependencies:
>
> In file included from external/mesa/src/amd/vulkan/radv_device.c:52:
> external/mesa/src/util/xmlpool.h:115:10: fatal error: 'xmlpool/options.h'
> file not found
> ^~~
> 1 error generated.
>
> FAILED:
> out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/vulkan.radv_intermediates/LINKED/
> vulkan.radv.so
> ...
> external/mesa/src/util/xmlconfig.c:670: error: undefined reference to
> 'XML_ParserCreate'
> ...
> clang.real: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> Fixes: 3c2e826 ("radv: Add support for driconf.")
> Signed-off-by: Mauro Rossi
> ---
> src/amd/vulkan/Android.mk | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
> index 9574bf54e5..ab39ba3b72 100644
> --- a/src/amd/vulkan/Android.mk
> +++ b/src/amd/vulkan/Android.mk
> @@ -71,7 +71,8 @@ LOCAL_C_INCLUDES := \
> $(call
> generated-sources-dir-for,STATIC_LIBRARIES,libmesa_amd_common,,) \
> $(call
> generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
> $(call
> generated-sources-dir-for,STATIC_LIBRARIES,libmesa_radv_common,,) \
> - $(call
> generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util
> + $(call
> generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util \
> + $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_util,,)
>
> LOCAL_WHOLE_STATIC_LIBRARIES := \
> libmesa_vulkan_util \
> @@ -165,5 +166,14 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
>
> LOCAL_SHARED_LIBRARIES += $(RADV_SHARED_LIBRARIES) libz libsync liblog
>
> +# If Android version >=8 MESA should static link libexpat else should
> dynamic link
> +ifeq ($(shell test $(PLATFORM_SDK_VERSION) -ge 27; echo $$?), 0)
> +LOCAL_STATIC_LIBRARIES := \
> + libexpat
> +else
> +LOCAL_SHARED_LIBRARIES += \
> + libexpat
> +endif
> +
> include $(MESA_COMMON_MK)
> include $(BUILD_SHARED_LIBRARY)
> --
> 2.20.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: Change memory type order for GPUs without dedicated VRAM
On Mon, 3 Jun 2019 at 13:27, Koenig, Christian
wrote:
> Am 03.06.19 um 14:21 schrieb Alex Smith:
>
> On Mon, 3 Jun 2019 at 11:57, Koenig, Christian
> wrote:
>
>> Am 02.06.19 um 12:32 schrieb Alex Smith:
>> > Put the uncached GTT type at a higher index than the visible VRAM type,
>> > rather than having GTT first.
>> >
>> > When we don't have dedicated VRAM, we don't have a non-visible VRAM
>> > type, and the property flags for GTT and visible VRAM are identical.
>> > According to the spec, for types with identical flags, we should give
>> > the one with better performance a lower index.
>> >
>> > Previously, apps which follow the spec guidance for choosing a memory
>> > type would have picked the GTT type in preference to visible VRAM (all
>> > Feral games will do this), and end up with lower performance.
>> >
>> > On a Ryzen 5 2500U laptop (Raven Ridge), this improves average FPS in
>> > the Rise of the Tomb Raider benchmark by up to ~30%. Tested a couple of
>> > other (Feral) games and saw similar improvement on those as well.
>>
>> Well that patch doesn't looks like a good idea to me.
>>
>> Using VRAM over uncached GTT should have something between no and only
>> minimal performance difference on APU.
>>
>> To make things even worse VRAM is still needed for scanout and newer
>> laptops have only a very very low default setting (32 or 16MB). So you
>> can end up in VRAM clashing on those systems.
>>
>> Can you check some kernel statistics to figure out what exactly is going
>> on here?
>>
>
> What statistics should I look at?
>
>
> First of all take a look at amdgpu_gem_info file in the debugfs directory
> while using GTT and match that to using VRAM. You should see a lot more of
> GTT ... CPU_GTT_USWC entries with the GTT variant. If the CPU_GTT_USWC flag
> is missing we have found the problem.
>
> If that looks ok, then take a look at the ttm_page_pool or
> ttm_dma_page_pool file and see how many wc/uc and wc/uc huge pages you got.
> Huge pages should be used for anything larger than 2MB, if not we have
> found the problem.
>
> If that still isn't the issue I need to take a look at the VM code again
> and see if we still map VRAM/GTT differently on APUs.
>
OK, got around to looking at this. amdgpu_gem_info does have more USWC
entries when using GTT. I've attached the output from VRAM vs GTT in case
you can spot anything else in there.
ttm_page_pool has 9806 wc, 238 wc huge, no uc or uc huge.
FWIW this was from kernel 5.0.10, I just upgraded to 5.1.6 and still the
same perf difference there.
Thanks,
Alex
>
> Thanks,
> Christian.
>
>
> Thanks,
> Alex
>
>
>>
>> Regards,
>> Christian.
>>
>> >
>> > Signed-off-by: Alex Smith
>> > ---
>> > I noticed that the memory types advertised on my Raven laptop looked a
>> > bit odd so played around with it and found this. I'm not sure if it is
>> > actually expected that the performance difference between visible VRAM
>> > and GTT is so large, seeing as it's not dedicated VRAM, but the results
>> > are clear (and consistent, tested multiple times).
>> > ---
>> > src/amd/vulkan/radv_device.c | 18 +++---
>> > 1 file changed, 15 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
>> > index 3cf050ed220..d36ee226ebd 100644
>> > --- a/src/amd/vulkan/radv_device.c
>> > +++ b/src/amd/vulkan/radv_device.c
>> > @@ -171,12 +171,11 @@ radv_physical_device_init_mem_types(struct
>> radv_physical_device *device)
>> > .heapIndex = vram_index,
>> > };
>> > }
>> > - if (gart_index >= 0) {
>> > + if (gart_index >= 0 && device->rad_info.has_dedicated_vram) {
>> > device->mem_type_indices[type_count] =
>> RADV_MEM_TYPE_GTT_WRITE_COMBINE;
>> > device->memory_properties.memoryTypes[type_count++] =
>> (VkMemoryType) {
>> > .propertyFlags =
>> VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT |
>> > - VK_MEMORY_PROPERTY_HOST_COHERENT_BIT |
>> > - (device->rad_info.has_dedicated_vram ? 0 :
>> VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT),
>> > + VK_MEMORY_PROPERTY_HOST_COHERENT_BIT,
>> > .heapIndex = gart_index,
>> > };
>> > }
>> > @@ -189,6 +188,19 @@ radv_physical_device_init_mem_types(struct
>> radv_physical_device *device)
>> > .heapIndex = visible_vram_index,
>> > };
>> > }
>> > + if (gart_index >= 0 && !device->rad_info.has_dedicated_vram) {
>> > + /* Put GTT after visible VRAM for GPUs without dedicated
>> VRAM
>> > + * as they have identical property flags, and according
>> to the
>> > + * spec, for types with identical flags, the one with
>> greater
>> > + * performance must be given a lower index. */
>> > + device->mem_type_indices[type_count] =
>> RADV_MEM_TYPE_GTT_WRITE_COMBINE;
>> > +
[Mesa-dev] [Bug 110468] using swrAVX renders incorrectly at particular resolutions
https://bugs.freedesktop.org/show_bug.cgi?id=110468 --- Comment #8 from pal1000 --- I tested 19.0.6 release and couldn't reproduce the glitched rendering. Here is the build environment information: https://raw.githubusercontent.com/pal1000/mesa-dist-win/19.0.6-2/buildinfo/msvc.txt -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r300g: implement GLSL disk shader caching
On Sat, 8 Jun 2019, 01:55 Dieter Nützel, wrote: > Hello Rui, > > do you have some numbers with/without shader caching enabled, handy? > I didn't have r300 hardware anylonger... > > Thanks! > > Dieter > Hi, Dieter, Not really. Not yet, at least. Do you have any suggestions on how to do objective testing, even if synthetic? I haven't played any demanding games in over ten years… ;) Thanks, Rui > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Enable helper invocations when texturing
On June 7, 2019 18:04:40 Alyssa Rosenzweig wrote: it turns out we have explicit control over helper invocations; if a particular bit in the fragment shader descriptor is set, helper invocations are launched; if it clear, they are not. Helper invocations are required whenever computing derivatives, whether explicitly (dFdx/dFdy) *or* implicitly (any texturing). Accordingly, we set this bit when texturing to fix edge case behaviour (literally, haha). Hehe Thank you to Jason Ekstrand and Ilia Mirkin for pointing out the representative dEQP test failed along triangle edges and for suggesting helper invocations / derivatives as a list of suspect pieces (which led to discovering the helper invocations enable bit in the first place). Signed-off-by: Alyssa Rosenzweig --- .../drivers/panfrost/ci/expected-failures.txt | 72 --- .../drivers/panfrost/include/panfrost-job.h | 14 +++- src/gallium/drivers/panfrost/pan_context.c| 12 +++- .../drivers/panfrost/pandecode/decode.c | 3 +- 4 files changed, 25 insertions(+), 76 deletions(-) diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt b/src/gallium/drivers/panfrost/ci/expected-failures.txt index 9cbea0c6bfd..bb679e31934 100644 --- a/src/gallium/drivers/panfrost/ci/expected-failures.txt +++ b/src/gallium/drivers/panfrost/ci/expected-failures.txt @@ -425,44 +425,6 @@ dEQP-GLES2.functional.texture.filtering.2d.linear_mipmap_nearest_nearest_repeat_ dEQP-GLES2.functional.texture.filtering.2d.linear_mipmap_nearest_nearest_repeat_rgb888 dEQP-GLES2.functional.texture.filtering.2d.linear_mipmap_nearest_nearest_repeat_rgba dEQP-GLES2.functional.texture.filtering.2d.linear_mipmap_nearest_nearest_repeat_rgba -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_clamp_etc1 -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_clamp_l8_npot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_clamp_l8_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_clamp_rgb888_npot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_clamp_rgb888_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_clamp_rgba_npot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_clamp_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_clamp_rgba_npot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_clamp_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_mirror_etc1 -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_mirror_l8_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_mirror_rgb888_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_mirror_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_mirror_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_repeat_etc1 -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_repeat_l8_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_repeat_rgb888_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_repeat_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.linear_nearest_repeat_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_clamp_etc1 -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_clamp_l8_npot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_clamp_l8_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_clamp_rgb888_npot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_clamp_rgb888_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_clamp_rgba_npot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_clamp_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_clamp_rgba_npot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_clamp_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_mirror_etc1 -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_mirror_l8_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_mirror_rgb888_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_mirror_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_mirror_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_repeat_etc1 -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_repeat_l8_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_repeat_rgb888_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_repeat_rgba_pot -dEQP-GLES2.functional.texture.filtering.2d.nearest_linear_repeat_rgba_pot dEQP-GLES2.functional.texture.filtering.2d.nearest_mipmap_linear_linear_clamp_etc1 dEQP-GLES2.functional.texture.filtering.2d.nearest_mipmap_linear_linear_clamp_rgba dEQP-GLES2.functional.texture.filtering.2d.nearest_mipmap_linear_linear_mirror_etc1 @@ -493,40 +455,6 @@ dEQP-GLES2.functional.texture.filtering.2d.nearest_mipmap_nearest_nearest_repeat
