[Mesa-dev] [PATCH 4/5] vc4: Use vc4_setup_slices for resource import

Rather than open-coding populating the first slice inside resource import, use vc4_setup_slices to do it for us. v2: Rebase on VC4_DEBUG=surf change --- src/gallium/drivers/vc4/vc4_resource.c | 52 +- 1 file changed, 19 insertions(+), 33 deletions(-) diff --git

[Mesa-dev] [PATCH 1/5] intel: Move the DRM uapi headers to a non-Intel location.

I want to remove vc4's dependency on headers from libdrm as well, but storing multiple copies of drm_fourcc.h in our tree would be silly. --- {src/intel/drm => include/drm-uapi}/README | 0 {src/intel/drm => include/drm-uapi}/drm.h| 0 {src/intel/drm =>

[Mesa-dev] [PATCH 2/5] vc4: Switch back to using a local copy of vc4_drm.h.

Needing to get our uapi header from libdrm has only complicated things. Follow intel's lead and drop our requirement for it. Generated from the same commit mentioned in the README. --- configure.ac | 2 - include/drm-uapi/vc4_drm.h | 318

[Mesa-dev] [PATCH 5/5] vc4: Set shareable BOs as T tiled if possible

X11 and GL compositor performance on VC4 has been terrible because of our SHARED-usage buffers all being forced to linear. This swaps SHARED && !LINEAR buffers over to being tiled. This is an expected win for all GL compositors during rendering (a full copy of each shared texture per draw call),

[Mesa-dev] [PATCH 3/5] vc4: Make the miptree debug code available under VC4_DEBUG=surf

I kept flipping the bool on for debug, so let's just make it available. --- src/gallium/drivers/vc4/vc4_resource.c | 8 +++- src/gallium/drivers/vc4/vc4_screen.c | 2 ++ src/gallium/drivers/vc4/vc4_screen.h | 1 + 3 files changed, 6 insertions(+), 5 deletions(-) diff --git

[Mesa-dev] [PATCH] vc4: Introduce XML-based packet header generation like Intel's.

I really liked this idea, as it should help with management of packet parsing tools like the CL dump. The python script is forked off of theirs because our packets are byte-based instead of dwords, and the changes to do so while avoiding performance regressions due to unaligned accesses were

Re: [Mesa-dev] [PATCH] Android: use symlinks for driver loading

BRARY) > > ifneq ($(HAVE_GALLIUM_FREEDRENO),) > +GALLIUM_TARGET_DRIVERS += msm > $(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_freedreno) > $(eval GALLIUM_SHARED_LIBS += $(LOCAL_SHARED_LIBRARIES)) > endif Looks like the automake build also gives this one a symlink

Re: [Mesa-dev] [PATCH] Android: add renderonly files to libmesa_gallium

.c:37: error: undefined > reference to 'renderonly_create_gpu_import_for_resource' > src/gallium/winsys/pl111/drm/pl111_drm_winsys.c:37: error: undefined > reference to 'renderonly_create_gpu_import_for_resource' > > Fixes: 7029ec05e2c7 ("gallium: Add renderonly-based support for pl111+vc4.") >

Re: [Mesa-dev] glmark2 segfault on imx6

Fabio Estevam writes: > Hi Lucas, > > On Tue, Jun 13, 2017 at 7:10 PM, Lucas Stach wrote: >> Hi Fabio, >> >> the attached patch should fix the issue. I should really try to get >> this upstream, as some people complained about this already... > > It seems

Re: [Mesa-dev] [PATCH 0/5] GL_OES_required_internalformat

Tapani Pälli <tapani.pa...@intel.com> writes: > On 06/14/2017 01:12 AM, Eric Anholt wrote: >> Tapani Pälli <tapani.pa...@intel.com> writes: >> >>> On 06/12/2017 09:52 AM, Tapani Pälli wrote: >>>> >>>> On 05/18/2017 09:39 PM, E

[Mesa-dev] [PATCH] nir: Move vc4's alpha test lowering to core NIR.

I've been doing this inside of vc4, but it seems like a pass that may be useful for other drivers (Intel has a related path for pre-gen6 with MRT, and freedreno had a TGSI path for it at one point). This required defining a common enum for the standard comparison functions, but other lowering

Re: [Mesa-dev] [RFC PATCH] dri3: Sync after buffer swaps with glXSwapBuffers

Thomas Hellstrom writes: > Applications calling glXSwapBuffers should be able to expect that any X > rendering submitted after the call to glXSwapBuffers returns should be ordered > with respect to the glXSwapBuffers call. (For example piglit reading out from > a window).

[Mesa-dev] [PATCH 1/2] vc4: Switch back to using a local copy of vc4_drm.h.

Needing to get our uapi header from libdrm has only complicated things. Follow intel's lead and drop our requirement for it. Generated from 056f4f02abb7e9e4a0cf0cda0211586df5e43842 of drm-misc-next --- Sending this patch to the list due to touching configure.ac. configure.ac

[Mesa-dev] [PATCH 2/2] vc4: Set shareable BOs as T tiled if possible.

X11 and GL compositor performance on VC4 has been terrible because of our SHARED-usage buffers all being forced to linear. This swaps SHARED && !LINEAR buffers over to being tiled. This is an expected win for all GL compositors during rendering (a full copy of each shared texture per draw call),

Re: [Mesa-dev] [PATCH 0/5] GL_OES_required_internalformat

Tapani Pälli <tapani.pa...@intel.com> writes: > On 06/12/2017 09:52 AM, Tapani Pälli wrote: >> >> >> On 05/18/2017 09:39 PM, Eric Anholt wrote: >>> Eric Anholt <e...@anholt.net> writes: >>> >>>> This series came out of fixing dEQP

Re: [Mesa-dev] [PATCH 1/2] st/mesa: remove the "Gallium 0.4 on" prefix from GL_RENDERER

nderer string: > Gallium 0.4 on AMD Radeon R9 Fury Series (DRM 3.17.0 / > 4.11.0-staging-01277-gab25a9e, LLVM 5.0.0) > > I'm sincerely sorry for all apps that detect Mesa by expecting "Gallium" > in the string. Reviewed-by: Eric Anholt <e...@anholt.net> Thanks for

Re: [Mesa-dev] [PATCH 2/2] gallium: Add renderonly-based support for pl111+vc4.

Christian Gmeiner <christian.gmei...@gmail.com> writes: > 2017-05-11 1:06 GMT+02:00 Eric Anholt <e...@anholt.net>: >> This follows the model of imx (display) and etnaviv (render): pl111 is a >> display-only device, so when asked to do GL for it, we see if we have a &g

Re: [Mesa-dev] [PATCH] u_format_test: Ignore S3TC errors.

Jose Fonseca <jfons...@vmware.com> writes: > This prevents spurious failures when libtxc-dxtn-s2tc is installed. > > Note: lp_test_format does need any change since we were already ignoring > S3TC failures there. Tested-by: Eric Anholt <e...@anholt.net> signature.asc De

Re: [Mesa-dev] [PATCH] vc4: Remove dead code in vc4_dump_surface_msaa()

Rhys Kidd writes: > Coverity caught the use of dead code copy-paste for > found_colors[] and num_found_colors. Reviewed and pushed. Thanks! signature.asc Description: PGP signature ___ mesa-dev mailing list

Re: [Mesa-dev] [PATCH] travis: Disable scons tests, since the gallium unit tests fail.

Jose Fonseca writes: > I suppose the failures happen with S2TC lib-dxtn implementation. > Because I haven't seen them failing with the old implementation, or when > no implementation is present (as the tests will just skip.) > > We could craft the test cases so they aren't

Re: [Mesa-dev] [PATCH] travis: Disable scons tests, since the gallium unit tests fail.

Rhys Kidd writes: > On 21 May 2017 at 19:33, Roland Scheidegger wrote: > >> I suppose the s3tc problems should go away rather sooner than later, but >> isn't it possible to just disable the formats tests? >> > > Yes, see USE_TXC_DXTN that was introduced

Re: [Mesa-dev] [PATCH 2/2] gallium: Add renderonly-based support for pl111+vc4.

Emil Velikov <emil.l.veli...@gmail.com> writes: > On 17 May 2017 at 20:13, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> On 17 May 2017 at 18:53, Eric Anholt <e...@anholt.net> wrote: >>> Emil Velikov <emil.l.veli...@gmail.com> writes: >>> &g

[Mesa-dev] [PATCH 4/4] vc4: Use the RA callback to improve post-RA register selection's choices.

We simply pick r4 if available (anything else would force a MOV), then round-robin through accumulators (avoids physical regfile RAW delay slots), then round-robin through the physical regfile. The effect on instruction count is pretty impressive: total instructions in shared programs: 76563 ->

[Mesa-dev] [PATCH 2/4] ra: Don't put a node in its own adjacency set.

All the paths looping over adjacency had guards against considering themselves (the non-obvious one was ra_any_neighbors_conflict(), which has in_stack set). --- src/util/register_allocate.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git

[Mesa-dev] [PATCH 3/4] ra: Add a callback for selecting a register from what's available.

VC4 has had a tension, similar to pre-Sandybridge Intel, where we want to use low-numbered registers (more parallelism on Intel, fewer delay slots on vc4), but in order to give instruction scheduling the most freedom to avoid delays we want to round-robin between registers of the same cost. Our

[Mesa-dev] [PATCH 1/4] ra: Pull the body of a loop out to a helper function.

I was going to indent this code another level, and decided it would be easier to read as a helper. --- src/util/register_allocate.c | 31 +++ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c

Re: [Mesa-dev] [PATCH] util: Change the pointer hashing function

e. The fnv1 on the pointer was basically a stand-in until someone did the kind of analysis you've done here. Thanks! Reviewed-by: Eric Anholt <e...@anholt.net> signature.asc Description: PGP signature ___ mesa-dev mailing list mes

[Mesa-dev] [PATCH] travis: Disable scons tests, since the gallium unit tests fail.

Every push a developer does to a travis-enabled github comes back as fail, because the unit tests are already failing: Testing util_format_dxt5_rgba_pack_rgba_float ... FAILED: 40 bd 48 90 20 01 12 20 53 76 ab 32 00 10 15 50 obtained f8 11 c5 0c 9a 73 b4 9c f6 8f ab 32 2a 9a

Re: [Mesa-dev] [PATCH 0/5] GL_OES_required_internalformat

Eric Anholt <e...@anholt.net> writes: > This series came out of fixing dEQP failures on vc4's GLES2 context. > Mesa was allowing RGB565 textures, which is only valid with > GL_OES_required_internalformat. Rather than disable RGB565, I decided > the extension was easy enough to

Re: [Mesa-dev] [PATCH 2/2] gallium: Add renderonly-based support for pl111+vc4.

Emil Velikov <emil.l.veli...@gmail.com> writes: > Hi Eric, > > On 11 May 2017 at 00:06, Eric Anholt <e...@anholt.net> wrote: >> This follows the model of imx (display) and etnaviv (render): pl111 is a >> display-only device, so when asked to do GL for it, we see i

Re: [Mesa-dev] [PATCH 0/3] few tgsi_to_nir fixes

Rob Clark <robdcl...@gmail.com> writes: > Looks like somewhere along the way nir_validate got more thorough about > checking src/dst sizes. > > Rob Clark (3): > ttn: fix txs dest size > ttn: fix txd src sizes > ttn: fix dest size for some texture instructions

[Mesa-dev] [PATCH 1/2] etnaviv: Only use renderonly_get_handle for GEM handles.

the GEM handle. Signed-off-by: Eric Anholt <e...@anholt.net> --- Etnaviv devs, do you want to fix this properly a different way? This was my biggest stumbling block using renderonly on vc4 -- I implemented the same get_handle() behavior and kept seeing X try to import bad fds (actually handles).

[Mesa-dev] [PATCH 0/2] PL111+VC4 renderonly support.

This patch series lets X start running with no patches and no xorg.conf on the BCM Cygnus (pl111/vc4) platform, along with kmscube, glmark2, etc. Eric Anholt (2): etnaviv: Only use renderonly_get_handle for GEM handles. gallium: Add renderonly-based support for pl111+vc4. .travis.yml

[Mesa-dev] [PATCH 2/2] gallium: Add renderonly-based support for pl111+vc4.

This follows the model of imx (display) and etnaviv (render): pl111 is a display-only device, so when asked to do GL for it, we see if we have a vc4 renderer, make the vc4 screen, and have vc4 call back to pl111 to do scanout allocations. The difference from etnaviv is that we share the same BO

Re: [Mesa-dev] [PATCH 10/13] mesa: add KHR_no_error support for FramebufferTextureLayer

Timothy Arceri <tarc...@itsqueeze.com> writes: > On 10/05/17 22:00, Nicolai Hähnle wrote: >> On 10.05.2017 02:28, Eric Anholt wrote: >>> Timothy Arceri <tarc...@itsqueeze.com> writes: >>> >>>> --- >>>> src/mapi/glapi/gen/AR

Re: [Mesa-dev] [PATCH 10/13] mesa: add KHR_no_error support for FramebufferTextureLayer

es because this felt like too much code duplication. I understand that you're replicating what the current error-validating code does, but it seems like for no_error we can do a lot better, quite easily. What I'd like for these last 4 patches is to have two patches, each of which implements a Named

Re: [Mesa-dev] [PATCH 07/13] mesa: add error version of get_texture_for_framebuffer()

Timothy Arceri writes: > This is a step towards KHR_no_error support. > --- > src/mesa/main/fbobject.c | 26 ++ > 1 file changed, 18 insertions(+), 8 deletions(-) > > diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c > index

[Mesa-dev] [PATCH] renderonly: Initialize fields of struct winsys_handle.

vc4 was rejecting renderonly's import, because the offset field was nonzero. --- src/gallium/auxiliary/renderonly/renderonly.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/auxiliary/renderonly/renderonly.c b/src/gallium/auxiliary/renderonly/renderonly.c index

Re: [Mesa-dev] [PATCH v3 0/4] Disable glthread if libX11 isn't thread-safe

k-ported to stable > branch. Besides it would allow to know which applications aren't X > thread safe. And potentially app owners can fix the issue too. > > By the way, I don't have commit access so feel free to push the series :) > > On 5/8/17, Eric Anholt <e...@anholt.net>

Re: [Mesa-dev] [PATCH 5/5] mesa: Set new renderbuffers to RGBA4 on all GLES contexts.

Eric Anholt <e...@anholt.net> writes: > Before we were doing RGBA4 on GLES3 only, but as of GLES2 2.0.22 it should > be RGBA4 as well. Fixes DEQP > functional.state_query.rbo.renderbuffer_internal_format. Note to potential reviewers: This patch hasn't been reviewed yet

Re: [Mesa-dev] [PATCH v3 0/4] Disable glthread if libX11 isn't thread-safe

gregory hainaut writes: > On Fri, 5 May 2017 17:45:01 +0200 > Axel Davy wrote: > >> Hi, >> >> There should be very few X11 calls while rendering (basically only at >> the beginning or end of a frame). >> >> Why not just always run these

Re: [Mesa-dev] [PATCH] mesa: return early with no error when shader source count is 0

Bartosz Tomczyk writes: > You are right, it doesn't free old shader source. Should we also clear > old source if new source is NULL? Then I could unify both conditions. shader_source() would free the old and put in the new. If calloc fails, you could throw

Re: [Mesa-dev] [PATCH 2/7] mesa: add KHR_no_error support for glUseProgramStages()

Eric Anholt <e...@anholt.net> writes: > [ Unknown signature status ] > Timothy Arceri <tarc...@itsqueeze.com> writes: > >> --- >> +void GLAPIENTRY >> +_mesa_UseProgramStages_no_error(GLuint pipeline, GLbitfield stages, >>

Re: [Mesa-dev] [PATCH 2/7] mesa: add KHR_no_error support for glUseProgramStages()

Timothy Arceri writes: > --- > src/mapi/glapi/gen/ARB_separate_shader_objects.xml | 2 +- > src/mesa/main/pipelineobj.c| 21 + > src/mesa/main/pipelineobj.h| 3 +++ > 3 files changed, 25 insertions(+),

Re: [Mesa-dev] [PATCH 01/18] mesa: make map_buffer_range() static

This series is: Reviewed-by: Eric Anholt <e...@anholt.net> Thanks for breaking your work up into digestible chunks! I'm looking forward to trying out your no_error stuff in glamor. signature.asc Description: PGP signature ___ mesa-dev mailin

Re: [Mesa-dev] [PATCH 3/3] egl: Implement EGL_EXT_device_{base, query, enumeration}

Adam Jackson <a...@redhat.com> writes: > On Wed, 2017-05-03 at 12:38 -0700, Eric Anholt wrote: >> > Adam Jackson <a...@redhat.com> writes: >> > +#ifdef HAVE_LIBDRM >> > +/* XXX kind of copypasta of drmCompareBusInfo */ >> > +static int >&

Re: [Mesa-dev] [PATCH] mesa: return early with no error when shader source count is 0

Bartosz Tomczyk writes: > malloc can return valid pointer for zero size allocation, > which causes OOB access later on > --- > src/mesa/main/shaderapi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c

Re: [Mesa-dev] [PATCH 0/2] anv/i965: drop libdrm dependency completely

Emil Velikov <emil.l.veli...@gmail.com> writes: > On 27 April 2017 at 16:20, Eric Anholt <e...@anholt.net> wrote: >> Emil Velikov <emil.l.veli...@gmail.com> writes: >> >>> On 25 April 2017 at 23:56, Lionel Landwerlin >>> <lionel.g.landwer

[Mesa-dev] [PATCH 2/5 v2] gallium: Add support for 5551 with the 1-bit field in the low bit.

This is how VC4 stores 5551 textures, which we need to support for GL_OES_required_internalformat. v2: Extend commit message, fix svga driver build, add BE ordering from Roland. --- src/gallium/auxiliary/util/u_format.csv | 2 ++ src/gallium/drivers/svga/svga_format.c | 2 ++

Re: [Mesa-dev] [PATCH 2/5] gallium: Add support for 5551 with the 1-bit field in the low bit.

Roland Scheidegger <srol...@vmware.com> writes: > Am 02.05.2017 um 21:33 schrieb Eric Anholt: >> --- >> >> Do I have the swizzles right here? It's a bit complicated because I >> have a reswizzle in vc4, so I may have just massaged things to work >> out in

[Mesa-dev] [PATCH 3/5 v2] glsl: Restrict func redeclarations (not just redefinitions) on GLSL 1.00.

Fixes DEQP's scoping.invalid.redeclare_function_fragment/vertex. v2: Fix accidental rejection of prototype+decl. Reviewed-by: Samuel Pitoiset --- Thanks for testing! Here's a new version with that fixed. Piglit series covering this regression and more, to follow.

Re: [Mesa-dev] [PATCH 2/3] egl/platform/drm: Don't take display ownership until gbm is initialized

Adam Jackson <a...@redhat.com> writes: > If the gbm_create_device() call here actually did fail, any subsequent > eglTerminate on the display would segfault. #1 and 2 are: Reviewed-by: Eric Anholt <e...@anholt.net> signature.asc Descript

Re: [Mesa-dev] [PATCH 3/3] egl: Implement EGL_EXT_device_{base, query, enumeration}

Adam Jackson writes: > From: Jonny Lamb > > This is a rebase/squash/rewrite of a series Jonny had sent long ago. The > major change is implementing this in terms of the drmDevice API. Both > relevant piglits go from skip to pass on i965. Just some

Re: [Mesa-dev] [PATCH v2] glsl: Corrected some typos and error messages

Andres Gomez <ago...@igalia.com> writes: > v2: left code style/formatting corrections out. > > Signed-off-by: Andres Gomez <ago...@igalia.com> Reviewed-by: Eric Anholt <e...@anholt.net> signature.asc Description: PGP signature _

Re: [Mesa-dev] [PATCH 2/5] glsl: Ban #undefining __LINE__ and friends on GLES2.

Erik Faye-Lund <kusmab...@gmail.com> writes: > On Tue, May 2, 2017 at 7:36 PM, Eric Anholt <e...@anholt.net> wrote: >> Fixes deqp_gles2 undefine_invalid_object_* failures. >> --- >> src/compiler/glsl/glcpp/glcpp-parse.y | 7 ++- >> 1 file changed, 2 i

Re: [Mesa-dev] [PATCH 0/4] Call for testing: Gallium set_index_buffer removal etc.

Marek Olšák writes: > PART 2: Call for testing > > These drivers have been tested: > - ddebug > - llvmpipe > - r300 (also with SWTCL) > - r600 > - radeonsi > - softpipe > - trace > > These drivers need testing: > - etnaviv > - freedreno > - nv30 > - nv50 > - nvc0 > - svga > -

[Mesa-dev] [PATCH 0/5] GL_OES_required_internalformat

, and dEQP has tests for whether enums get accepted for TexImage. There's a functional question in patch #2, see the comment there, and there's a question of whether the extension should be dummy_true in patch #5. branch: https://github.com/anholt/mesa/commits/required-internalformat Eric Anholt (5

[Mesa-dev] [PATCH 3/5] vc4: Add support for 5551 textures.

This keeps us from promoting them up to , at the cost of not being color-renderable. --- src/gallium/drivers/vc4/vc4_formats.c | 5 ++--- src/gallium/drivers/vc4/vc4_uniforms.c | 1 + 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/vc4/vc4_formats.c

[Mesa-dev] [PATCH 5/5] mesa: Expose GL_OES_required_internalformat on GLES contexts.

This extension is effectively a backport of GLES3's internalformat handling to GLES 1/2. It guarantees that sized internalformats specified for textures and renderbuffers have at least the specified size stored. That's a pretty minimal requirement, so I think it can be dummy_true and exposed as a

[Mesa-dev] [PATCH 2/5] gallium: Add support for 5551 with the 1-bit field in the low bit.

--- Do I have the swizzles right here? It's a bit complicated because I have a reswizzle in vc4, so I may have just massaged things to work out in my case. I tried a lot of combinations trying to specify BE swizzles in a way that wouldn't assertion fail in the python script, with no luck.

[Mesa-dev] [PATCH 4/5] mesa: Only expose GLES's EXT_texture_type_2_10_10_10_REV if supported in HW.

Previously, we were downconverting to automatically if the hardware didn't suport it. However, with the advent of GL_OES_required_internalformat, we have to actually store the internalformats we advertise support for. And, it seems rather disingenuous to advertise the extension if we don't

[Mesa-dev] [PATCH 1/5] mesa: Add X1B5G5R5 along with A1B5G5R5.

For supporting RGB5 in hardware with A in the low bit (vc4), we need this format as well. --- src/mesa/main/formats.c | 2 ++ src/mesa/main/formats.csv| 1 + src/mesa/main/formats.h | 1 + src/mesa/main/texformat.c| 1 + src/mesa/swrast/s_texfetch.c | 1 + 5 files changed, 6

Re: [Mesa-dev] [PATCH] fix minor error in YUV2RGB matrix used in shader

bit aligned with wikipedia's conversion result and FFMPeg's result. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100854 Reviewed-by: Eric Anholt <e...@anholt.net> signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/5] mesa: Set new renderbuffers to RGBA4 on all GLES contexts.

Before we were doing RGBA4 on GLES3 only, but as of GLES2 2.0.22 it should be RGBA4 as well. Fixes DEQP functional.state_query.rbo.renderbuffer_internal_format. --- src/mesa/main/renderbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/renderbuffer.c

[Mesa-dev] [PATCH 3/5] glsl: Restrict func redeclarations (not just redefinitions) on GLSL 1.00.

Fixes DEQP's scoping.invalid.redeclare_function_fragment/vertex. --- src/compiler/glsl/ast_to_hir.cpp | 10 ++ 1 file changed, 10 insertions(+) diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp index 9e02529dffb9..58088cec0d3a 100644 ---

[Mesa-dev] [PATCH 0/5] misc dEQP fixes for vc4

Here's a little set of changes for dEQP fixes for GLES2 contexts. I haven't done a full run to confirm no regressions, as full runs on hardware take a day or so. I'm hoping the Intel CI system might be able to test these for me. Eric Anholt (5): glsl: Restrict functions to not return arrays

[Mesa-dev] [PATCH 2/5] glsl: Ban #undefining __LINE__ and friends on GLES2.

Fixes deqp_gles2 undefine_invalid_object_* failures. --- src/compiler/glsl/glcpp/glcpp-parse.y | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y b/src/compiler/glsl/glcpp/glcpp-parse.y index e113253061f6..5cb2a380605b 100644 ---

[Mesa-dev] [PATCH 4/5] glsl: Don't allow redefining builtin functions on GLSL 1.00.

The spec text cited above says you can't, but only the GLSL 3.00 (redefine or overload) case was implemented. Fixes dEQP scoping.invalid.redefine_builtin_fragment/vertex. --- src/compiler/glsl/ast_to_hir.cpp | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git

[Mesa-dev] [PATCH 1/5] glsl: Restrict functions to not return arrays or SOAs in GLSL 1.00.

From the spec, Arrays are allowed as arguments, but not as the return type. [...] The return type can also be a structure if the structure does not contain an array. Fixes DEQP shaders.functions.invalid.return_array_in_struct_fragment. --- src/compiler/glsl/ast_to_hir.cpp | 12

Re: [Mesa-dev] [PATCH 2/4] gallium: Enable ARM NEON CPU detection.

Eric Anholt <e...@anholt.net> writes: > I wrote this code with reference to pixman, though I've only decided to > cover Linux (what I'm testing) and Android (seems obvious enough). Linux > has getauxval() as a cleaner interface to the /proc entry, but it's more > glibc-specific

Re: [Mesa-dev] [PATCH] fix minor error in YUV2RGB matrix used in shader

ir_fadd(b, y, nir_imm_float(b, -0.0627451f))), > + nir_channel(b, nir_fadd(b, u, nir_imm_float(b, > -0.50196078431f)), 0), > + nir_channel(b, nir_fadd(b, v, nir_imm_float(b, > -0.50196078431f)), 0), > nir_imm_float(b, 0.0)); Could we use 16.0/2

Re: [Mesa-dev] [PATCH 0/2] anv/i965: drop libdrm dependency completely

Emil Velikov writes: > On 25 April 2017 at 23:56, Lionel Landwerlin > wrote: >> Hi, >> >> While working with changes that span from kernel to user space, I've >> been wondering whether we need to depend on libdrm at all for the anv >> &

[Mesa-dev] [PATCH 1/4] vc4: Only build the NEON code on arm32.

NEON is sufficiently different on arm64 that we can't just reuse this code. Disable it on arm64 for now. v2: Use PIPE_ARCH_ARM instead, as __ARM_ARCH may be 8 for a 32-bit build for a v8 CPU. Signed-off-by: Eric Anholt <e...@anholt.net> Cc: <mesa-sta...@lists.freedesktop.org&

[Mesa-dev] [PATCH 4/4] vc4: Use runtime CPU detection for whether NEON is available.

This will allow Raspbian's ARMv6 builds to take advantage of the new NEON code, and could prevent problems if vc4 ends up getting used on a v7 CPU without NEON. v2: Drop dead NEON_SUFFIX (noted by Erik Faye-Lund) --- src/gallium/drivers/vc4/vc4_screen.c | 3 +++

[Mesa-dev] [PATCH 3/4] vc4: Use a wrapper file to set VC4_BUILD_NEON instead of CFLAGS.

Android.mk was setting the flag across the entire driver, so we didn't have non-NEON versions getting built. This was going to be a problem with the next commit, when I start auto-detecting NEON support and use the non-NEON version when appropriate. --- Rob: I'm happy to just drop this patch if

[Mesa-dev] [PATCH 2/4] gallium: Enable ARM NEON CPU detection.

I wrote this code with reference to pixman, though I've only decided to cover Linux (what I'm testing) and Android (seems obvious enough). Linux has getauxval() as a cleaner interface to the /proc entry, but it's more glibc-specific and I didn't want to add detection for that. This will be used

Re: [Mesa-dev] [PATCH] RFC: mesa: remove MESA_VERBOSE env variable

Emil Velikov writes: > From: Emil Velikov > > The env variable was useful in the early days of mesa development, when > tools such at Apitrace were not available. > > Nowadays, out of the 12 options only a third are used. With nearly all >

Re: [Mesa-dev] [RFC 2/2] glx: drop GLX_MESA_multithread_makecurrent support

Timothy Arceri <tarc...@itsqueeze.com> writes: > On 20/04/17 10:53, Eric Anholt wrote: >> Timothy Arceri <tarc...@itsqueeze.com> writes: >> >>> This extension is not supported by GLVND, also as far >>> as I can tell this extension re

Re: [Mesa-dev] [PATCH] mesa/glthread: correctly comparae thread handles

Emil Velikov <emil.l.veli...@gmail.com> writes: > From: Emil Velikov <emil.veli...@collabora.com> > > As mentioned in the manual - comparing pthread_t handles via the C > comparison operator is incorrect and pthread_equal() should be used > instead. Seems fine

Re: [Mesa-dev] [RFC 2/2] glx: drop GLX_MESA_multithread_makecurrent support

Timothy Arceri writes: > This extension is not supported by GLVND, also as far > as I can tell this extension requires us to do extra > locking for objects that are not normaly shared across > contexts, like vertex array and pipeline objects. Can you explain how it would

Re: [Mesa-dev] [PATCH 2/9] mesa/st: compute+SSBO support for glsl_to_nir

Rob Clark <robdcl...@gmail.com> writes: > Signed-off-by: Rob Clark <robdcl...@gmail.com> I don't know too much about compute/ssbo, but the logic seems to basically match the VS/FS cases. Reviewed-by: Eric Anholt <e...@anholt.net> signature.asc Descr

Re: [Mesa-dev] [PATCH V3 2/2] glsl: don't run the GLSL pre-processor when we are skipping compilation

cache lookup to before the preprocessor. In our experience, shaders are unlikely to hash the same after preprocessing if they didn't hash the same before, so we can skip preprocessing for cache hits." With something like that, Reviewed-by: Eric Anholt <e...@anholt.net> signat

Re: [Mesa-dev] [PATCH v2] gbm: add support for loading third-party backend (v2)

Emil Velikov writes: > On 14 April 2017 at 10:38, Yu, Qiang wrote: >> >> Hi Emil, >> >>> What happened with the idea of reusing your existing amdgpu_dri.so ? >>> As mentioned before the DRI loader (libgbm) <> DRI driver (foo_dri.so) >>> interface is

Re: [Mesa-dev] [PATCH v3 4/4] vc4: Only build the NEON code on arm32.

Emil Velikov <emil.l.veli...@gmail.com> writes: > On 14 April 2017 at 18:47, Eric Anholt <e...@anholt.net> wrote: >> NEON is sufficiently different on arm64 that we can't just reuse this >> code. Disable it on arm64 for now. >> >> Signed-off-by: Eric

[Mesa-dev] [PATCH v3 1/4] gallium: Enable ARM NEON CPU detection.

I wrote this code with reference to pixman, though I've only decided to cover Linux (what I'm testing) and Android (seems obvious enough). Linux has getauxval() as a cleaner interface to the /proc entry, but it's more glibc-specific and I didn't want to add detection for that. This will be used

[Mesa-dev] [PATCH v3 4/4] vc4: Only build the NEON code on arm32.

NEON is sufficiently different on arm64 that we can't just reuse this code. Disable it on arm64 for now. Signed-off-by: Eric Anholt <e...@anholt.net> --- src/gallium/drivers/vc4/vc4_tiling_lt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/drive

[Mesa-dev] [PATCH v3 3/4] vc4: Use runtime CPU detection for whether NEON is available.

This will allow Raspbian's ARMv6 builds to take advantage of the new NEON code, and could prevent problems if vc4 ends up getting used on a v7 CPU without NEON. --- src/gallium/drivers/vc4/vc4_screen.c | 3 +++ src/gallium/drivers/vc4/vc4_tiling.h | 25 + 2 files changed,

[Mesa-dev] [PATCH v3 2/4] vc4: Use a wrapper file to set VC4_BUILD_NEON instead of CFLAGS.

Android.mk was setting the flag across the entire driver, so we didn't have non-NEON versions getting built. This was going to be a problem with the next commit, when I start auto-detecting NEON support and use the non-NEON version when appropriate. --- src/gallium/drivers/vc4/Android.mk

[Mesa-dev] [PATCH v2 1/2] gallium: Enable ARM NEON/VFP CPU detection.

I wrote this code with reference to pixman, though I've only decided to cover Linux (what I'm testing) and Android (seems obvious enough). Linux has getauxval() as a cleaner interface to the /proc entry, but it's more glibc-specific and I didn't want to add detection for that. This will be used

Re: [Mesa-dev] [PATCH] configure.ac: honour --disable-libunwind if the .pc file is present

Emil Velikov <emil.l.veli...@gmail.com> writes: > From: Emil Velikov <emil.veli...@collabora.com> > > We should check the presence in order to determine if we should > [implicitly] set the CFLAGS/LIBS > > Cc: Eric Anholt <e...@anholt.net> > Reported-by: Eri

[Mesa-dev] [PATCH 1/2] gallium: Enable ARM NEON/VFP CPU detection.

I wrote this code with reference to pixman, though I've only decided to cover Linux (what I'm testing) and Android (seems obvious enough). Linux has getauxval() as a cleaner interface to the /proc entry, but it's more glibc-specific and I didn't want to add detection for that. This will be used

[Mesa-dev] [PATCH 2/2] vc4: Use runtime CPU detection for whether NEON is available.

This will allow Raspbian's ARMv6 builds to take advantage of the new NEON code, and could prevent problems if vc4 ends up getting used on a v7 CPU without NEON. --- src/gallium/drivers/vc4/vc4_screen.c | 3 +++ src/gallium/drivers/vc4/vc4_tiling.h | 25 + 2 files changed,

Re: [Mesa-dev] [PATCH] mesa: use pre_hashed version of search for the mesa hash table

also be happy with not having the temp and just doing: entry = _mesa_hash_table_search_pre_hashed(table->ht, uint_hash(key), uint_key(key)); which I think looks pretty nice. Either way, Reviewed-by: Eric Anholt <e...@anhol

Re: [Mesa-dev] [PATCH] vc4: Optimizing vc4_load_utile/vc4_store_utile with sse for x86 build

mas...@eltechs.com writes: > From: Maxim Maslov The commit message needs some explanation of why we would want that (given that 2835 is an ARM) and some performance data justifying the change. > > --- src/gallium/drivers/vc4/vc4_tiling_lt.c | 93

Re: [Mesa-dev] [PATCH 2/2] travis: add the txc-dxtn library so scons check can pass

Andres Gomez writes: > The packaged libtxc-dxtn-s2tc0 will make scons check fail. Manually > remove this package and install libtxc-dxtn instead. I don't think we should be automatically installing and using this software on other people's machines. The patent is why dxtn

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

d *map_data) >return; > > dri->image->unmapImage(dri->context, bo->image, map_data); > + > + /* > +* Not all DRI drivers use direct maps. They may queue up DMA operations > +* on the mapping context. Since there is no explicit gbm flush > +* mechanism. We n

Re: [Mesa-dev] [PATCH 2/2] mesa: load a user defined drirc file specified via an environment variable

Edmondo Tommasina <edmondo.tommas...@gmail.com> writes: > On Mon, Mar 27, 2017 at 11:32 PM, Eric Anholt <e...@anholt.net> wrote: >> Edmondo Tommasina <edmondo.tommas...@gmail.com> writes: >> >>> On Mon, Mar 27, 2017 at 6:05 PM, Eric Anholt <e

Re: [Mesa-dev] [PATCH 2/2] mesa: load a user defined drirc file specified via an environment variable

Edmondo Tommasina <edmondo.tommas...@gmail.com> writes: > On Mon, Mar 27, 2017 at 6:05 PM, Eric Anholt <e...@anholt.net> wrote: >> Edmondo Tommasina <edmondo.tommas...@gmail.com> writes: >> >>> Define a new MESA_USER_DRIRC environment variable to load

Re: [Mesa-dev] [PATCH 3/3] mesa/main: Reduce the size of nr_enabled_units in ff cache key.

of structs. However, these changes all look good to me. Series is: Reviewed-by: Eric Anholt <e...@anholt.net> I think that moving the cache key to the context is a really good idea. Back when I did this work, we still had non-shader-based hardware as a significant concern, but I don't

Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

Jose Fonseca writes: > On 27/03/17 17:42, Dylan Baker wrote: >> Quoting Jose Fonseca (2017-03-27 09:31:04) >>> On 27/03/17 17:24, Dylan Baker wrote: Quoting Jose Fonseca (2017-03-26 14:53:50) > I've pushed the branch to mesa/demos, so we can all collaborate without

<    3   4   5   6   7   8   9   10   11   12   >