[Mesa-dev] [PATCH 4/5] gallium: Expose a PIPE_CAP_TILE_RASTER_ORDER on vc4.

Because vc4 can control the order that tiles are rasterized in, we can use it to implement overlapping blits using normal drawing and GL_ARB_texture_barrier, as long as we can tell the kernel what order to render the tiles in. v2: Fix on the simulator. v3: Add the cap (disabled) to other drivers,

[Mesa-dev] [PATCH 3/5] broadcom/vc4: Implement GL_ARB_texture_barrier.

Improves x11perf -copywinwin100 from ~2000/sec to ~4700/sec. More importantly, this is a prerequisite for the new GL_MESA_tile_raster_order extension. --- src/gallium/drivers/vc4/vc4_context.c | 11 +++ src/gallium/drivers/vc4/vc4_screen.c | 2 +- 2 files changed, 12 insertions(+), 1

[Mesa-dev] [PATCH 5/5] mesa: Implement a new GL_MESA_tile_raster_order extension.

The intent is to use this extension on vc4 to allow X11 to do overlapping CopyArea() within a pixmap without first blitting the pixmap to a temporary. With associated glamor patches, improves x11perf -copywinwin100 performance on a Raspberry Pi 3 from ~4700/sec to ~5130/sec, and is an even larger

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

in uncomposited X11 performance on Raspberry Pi. If I can get review, I would merge it once the registry PR lands. Eric Anholt (5): docs: Fix a typo in the old MESA_program_debug spec. docs: Update the list of used MESA GL enums. broadcom/vc4: Implement GL_ARB_texture_barrier. gallium: Expose

[Mesa-dev] [PATCH 1/5] docs: Fix a typo in the old MESA_program_debug spec.

Noticed that we had two 0x8bb4 in the spec while grepping to find an open slot in the MESA enums set. gl.xml had the right value. --- docs/specs/OLD/MESA_program_debug.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/specs/OLD/MESA_program_debug.spec

[Mesa-dev] [PATCH 2/5] docs: Update the list of used MESA GL enums.

--- docs/specs/enums.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt index 222adbc72e71..00d808483a43 100644 --- a/docs/specs/enums.txt +++ b/docs/specs/enums.txt @@ -63,6 +63,16 @@ GL_MESAX_texture_stack:

Re: [Mesa-dev] [PATCH] egl: Simplify the "driver" interface

API that doesn't reference a display, like > EGL_EXT_device_query, would have the same issue. > > Fortunately this is a problem that can be solved with the delete key. > > Signed-off-by: Adam Jackson <a...@redhat.com> Reviewed-by: Eric Anholt <e...@anholt.net

Re: [Mesa-dev] [PATCH] mesa: Use a 565 format for GL_RGB and GL_UNSIGNED_SHORT_5_6_5 textures.

Kenneth Graunke <kenn...@whitecape.org> writes: > Found while trying to optimize an application. > > Not observed to help performance on i965, but should at least reduce > the memory usage of such textures a bit. Reviewed-by: Eric Anholt <e...@anholt.net> signat

Re: [Mesa-dev] [PATCH 6/6] meson: build classic swrast

Dylan Baker writes: > This adds support for building the classic swrast implementation. This > driver has been tested with glxinfo and glxgears. > > Signed-off-by: Dylan Baker > --- > meson.build | 2 ++ >

Re: [Mesa-dev] [PATCH 4/6] meson: build gbm

Dylan Baker writes: > This doesn't include egl support, just dri support. > > Signed-off-by: Dylan Baker > --- > meson.build | 49 +--- > meson_options.txt | 14 + > src/{loader

Re: [Mesa-dev] [PATCH 3/6] meson: Add support for configuring dri drivers directory.

Dylan Baker writes: > Signed-off-by: Dylan Baker > --- > meson.build | 6 ++ > meson_options.txt| 14 -- > src/glx/meson.build | 2 +- > src/mesa/drivers/dri/meson.build | 2 +- >

Re: [Mesa-dev] [PATCH 2/6] meson: build glx

Dylan Baker writes: > This gets GLX and the loader building. The resulting GLX and i965 have > been tested on piglit and seem to work fine. This patch leaves a lot of > todo's in it's wake, GLX is quite complicated, and the build options > involved are many, and the goal at

Re: [Mesa-dev] [PATCH 1/6] meson: Build i965 and dri stack

Dylan Baker writes: > This gets pretty much the entire classic tree building, as well as > i965, including the various glapis. There are some workarounds for bugs > that are fixed in meson 0.43.0, which is due out on October 8th. > > I have tested this with piglit using glx.

Re: [Mesa-dev] [PATCH 1/6] meson: Build i965 and dri stack

Dylan Baker writes: > This gets pretty much the entire classic tree building, as well as > i965, including the various glapis. There are some workarounds for bugs > that are fixed in meson 0.43.0, which is due out on October 8th. > > I have tested this with piglit using glx.

Re: [Mesa-dev] Add a travis job for meson vulkan

Dylan Baker <dy...@pnwbakers.com> writes: > This adds a job to travis to build the vulkan driver and run some driver > checks, > and fix building on travis (which uses a particularly old Ubuntu). This series is: Reviewed-by: Eric Anholt <e...@anholt.net> signature

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

Boris Brezillon <boris.brezil...@free-electrons.com> writes: > On Wed, 27 Sep 2017 12:41:52 -0700 > Eric Anholt <e...@anholt.net> wrote: > >> Boris Brezillon <boris.brezil...@free-electrons.com> writes: >> >> > On Wed, 27 Sep 2017 10:15:2

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

Boris Brezillon <boris.brezil...@free-electrons.com> writes: > On Wed, 27 Sep 2017 10:15:23 -0700 > Eric Anholt <e...@anholt.net> wrote: > >> Boris Brezillon <boris.brezil...@free-electrons.com> writes: >> >> > On Wed, 27 Sep 2017 15:24:16 +0100 &g

Re: [Mesa-dev] initial meson port

Dylan Baker writes: > [ Unknown signature status ] > I've gone ahead and pushed the Vulkan drivers meson builds. > > For those interested in helping finish the conversion, I have a branch > "wip/meson-4" on my github (github.com/dcbaker/mesa) that has i965 and most of > the

Re: [Mesa-dev] [PATCH] vc4: Mark BOs as purgeable when they enter the BO cache

Boris Brezillon writes: > On Wed, 27 Sep 2017 15:24:16 +0100 > Chris Wilson wrote: > >> Quoting Boris Brezillon (2017-09-27 15:06:53) >> > On Wed, 27 Sep 2017 14:50:10 +0100 >> > Chris Wilson wrote: >> >

Re: [Mesa-dev] [PATCH] glx: Be more tolerant in glXImportContext (v2)

f _XReply succeeds, it will have buffered the whole > reply, we can just walk through each property one at a time. > > v2: Now with no arbitrary limits. (Eric Anholt) Even nicer than my idea. Reviewed-by: Eric Anholt <e...@anholt.net> signatu

Re: [Mesa-dev] [PATCH] glx: Be slightly more tolerant in glXImportContext

Adam Jackson writes: > Ugh the GLX code. __GLX_MAX_CONTEXT_PROPS is 3 because glxproto.h is > just a pile of ancient runes, so when the server begins sending more > than 3 context properties this code refuses to work _at all_. > > This extension is pretty obscure, so this

Re: [Mesa-dev] [PATCH v3 3/4] meson: Add build Intel "anv" vulkan driver

verting my vc5-vulkan work over to the meson build. Given the rate I have to rebase that branch, it would be worth my time to convert over it in the next day of actual code development I get to do. So, I'll offer a few bits of feedback on meson usage, after which you can have my Reviewed-by: E

Re: [Mesa-dev] initial meson port

Matt Turner <matts...@gmail.com> writes: > On Thu, Sep 21, 2017 at 5:06 AM, Jakob Bornecrantz <wallbra...@gmail.com> > wrote: >> On Thu, Sep 21, 2017 at 2:20 AM, Eric Anholt <e...@anholt.net> wrote: >>> Dylan Baker <dy...@pnwbakers.com> writes: >&

Re: [Mesa-dev] initial meson port

Dylan Baker writes: > Results > autotools : sh -c 535.34s user 30.33s system 310% cpu 3:02.05 total > meson : sh -c 136.58s user 11.98s system 372% cpu 39.895 total I just want to point at these numbers again. meson is so transformative for your normal build/test

[Mesa-dev] [PATCH 1/5] intel/genxml: Convert a not-present-or-"1" dict to a set.

I was implementing the same enum support in broadcom's gen_pack_header.py, and did this same simplification there. --- src/intel/genxml/gen_pack_header.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/intel/genxml/gen_pack_header.py

[Mesa-dev] [PATCH 5/5] configure: Add the new "vc5" driver to the list, requiring a simulator.

My intent is to develop the vc5 driver in-tree for some time to build the CL generation and shader compiler code, and keep out-of-tree patches for talking to an actual kernel driver until the kernel driver can be stabilized on the hardware. v2: Define a HAVE_BROADCOM_DRIVERS, like HAVE_INTEL or

[Mesa-dev] [PATCH 3/5] anv: Fix some comment typos.

--- src/intel/vulkan/anv_private.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h index df8de8d9407c..2808a5e991e7 100644 --- a/src/intel/vulkan/anv_private.h +++ b/src/intel/vulkan/anv_private.h @@ -1895,7

[Mesa-dev] [PATCH 0/5] vc5 prep touching common code

Here are a few little patches in my vc5 series -- a couple of required ones, and a couple of cleanups from the vc5 and bcmv work. The remainder of vc5 I think I have the necessary acks to merge (airlied and danvet). Eric Anholt (5): intel/genxml: Convert a not-present-or-"1" dic

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

I've been doing this inside of vc4, but vc5 wants it as well and it 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

[Mesa-dev] [PATCH 2/5] gallium: Weaken assertion about u_mm's align2 field.

vc5 MMU mappings are access-controlled at a 128kb boundary, so the 4kb here was too small for that purpose. Allowing any valid align2 value that u_mm's 32-bit addressing can represent will still catch most cases of people passing in a byte alignment. --- src/gallium/auxiliary/util/u_mm.c | 5

Re: [Mesa-dev] [PATCH 4/8] nir: add some helpers for doing linking

ons is actually defined by this patch. I was hoping to use nir_remove_unread_outputs() from vc4 for my coordinate shaders. Other than that, Reviewed-by: Eric Anholt <e...@anholt.net> Have you looked at extending linking to garbage collect unused individual components? That's where I think I

Re: [Mesa-dev] [PATCH] st/dri: Add an option to always request a front buffer from the loader

Thomas Hellstrom writes: > When an application decides to read from the front buffer of a window, > typically a fake front is created and initialized with the real front window > contents. However, if there was a window manager reparenting operation between > the last

Re: [Mesa-dev] [PATCH 4/4] i965: Use prepare_external instead of make_shareable in setTexBuffer2

Jason Ekstrand <ja...@jlekstrand.net> writes: > On Mon, Sep 18, 2017 at 9:20 AM, Chad Versace <chadvers...@chromium.org> > wrote: > >> On Thu 14 Sep 2017, Eric Anholt wrote: >> > Jason Ekstrand <ja...@jlekstrand.net> writes: >> > >>

Re: [Mesa-dev] [PATCH 3/4] i965/tex_image: Reference the renderbuffer miptree in setTexBuffer2

> really want this function to work without doing a resolve so long as you > have modifiers so we need to fix that. I think this patch in particular might be why I was CCed. This looks like a very good, and very obvious (to me) cleanup. Reviewed-by: Eri

Re: [Mesa-dev] [PATCH 4/4] i965: Use prepare_external instead of make_shareable in setTexBuffer2

Jason Ekstrand writes: > The setTexBuffer2 hook from GLX is used to implement glxBindTexImageEXT > which has tighter restrictions than just "it's shared". In particular, > it says that any rendering to the image while it is bound causes the > contents to become undefined.

Re: [Mesa-dev] [PATCH 1/2] mesa: provide more info in some texture image error messages

Both patches are: 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] ttn: Fix out-of-bounds accesses since the always-2D-constants change.

Only one of the three checks for dim was updated, so we would try to set a UBO buffer index source value on a nir_load_uniform, and wouldn't actually declare non-UBO uniforms. Fixes: 37dd8e8dee1d ("gallium: all drivers should accept two-dimensional constant buffer indexing") ---

Re: [Mesa-dev] [PATCH 1/3] mesa: don't use %s for PACKAGE_VERSION macro

e it directly, so let's update > the final two instances. > > Signed-off-by: Emil Velikov <emil.veli...@collabora.com> sha1 is so much more informative than date/time, and improves reproducibility. Patch 1-2 are: Reviewed-by: Eric Anholt <e...@anholt

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

Kenneth Graunke writes: > [ Unknown signature status ] > On Saturday, August 26, 2017 6:40:14 AM PDT Qiang Yu wrote: >> Hi guys, >> >> When working on lima gp compiler, I come across two problems about >> inserting extra uniform >> and instructions in nir for the driver

Re: [Mesa-dev] Question for nir lower load uniform to scalar

Qiang Yu writes: > Hi Eric, > > I'm working on lima gp compiler which should benefit from nir lowering > uniform load to scalar. > I notice you write the nir_lower_io_to_scalar.c which support lowering > shader_in/shader_out > but left the uniform lowering in vc4 driver, any

Re: [Mesa-dev] [PATCH 4/7 v2] configure.ac: Introduce HAVE_ARM_ASM/HAVE_AARCH64_ASM and the -D flags.

Emil Velikov <emil.l.veli...@gmail.com> writes: > Hi Eric, > > On 10 August 2017 at 23:43, Eric Anholt <e...@anholt.net> wrote: > >> +aarch64) >> +DEFINES="$DEFINES -DUSE_AARCH64_ASM" > I cannot see any places where the define is used.

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

Emil Velikov <emil.l.veli...@gmail.com> writes: > On 17 August 2017 at 17:10, Eric Anholt <e...@anholt.net> wrote: >> This is how VC4 stores 5551 textures, which we need to support for >> GL_OES_required_internalformat. >> >> v2: Extend commit message, fix

[Mesa-dev] [PATCH 5/6] broadcom: Add VC5 NIR compiler.

This is a pretty straightforward fork of VC4's NIR compiler to VC5. The condition codes, registers, and I/O have all changed, making the backend hard to share, though their heritage is still recognizable. --- Contents trimmed due to patch size. Full series at:

[Mesa-dev] [PATCH 6/6] broadcom: Add V3D 3.3 gallium driver called "vc5", for BCM7268.

V3D 3.3 is a continuation of the 3D implementation in VC4 (v2.1 and v2.6). V3D 3.3 introduces an MMU (no more CMA allocations) and support for GLES3.1. This driver is not currently conformant, though that will be a target as soon as possible. V3D 3.x parts use a new texture tiling layout common

[Mesa-dev] [PATCH 2/6] configure: Add the new "vc5" driver to the list, requiring a simulator.

My intent is to develop the vc5 driver in-tree for some time to build the CL generation and shader compiler code, and keep out-of-tree patches for talking to an actual kernel driver until the kernel driver can be stabilized on the hardware. --- configure.ac | 12 +++- 1 file changed, 11

[Mesa-dev] [PATCH 0/6] vc5 driver to merge

concerns go? Anyone else want to ack/nack merging at this early stage? Eric Anholt (6): nir: Move vc4's alpha test lowering to core NIR. configure: Add the new "vc5" driver to the list, requiring a simulator. broadcom: Add V3D 3.3 QPU instruction pack, unpack, and disasm. broadco

[Mesa-dev] [PATCH 3/6] broadcom: Add V3D 3.3 QPU instruction pack, unpack, and disasm.

Unlike VC4, I've defined an unpacked instruction format with pack/unpack functions to convert to 64-bit encoded instructions. This will let us incrementally put together our instructions and validate them in a more natural way than the QPU_GET_FIELD/QPU_SET_FIELD used to. The pack/unpack

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

I've been doing this inside of vc4, but vc5 wants it as well and it 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

[Mesa-dev] [PATCH 4/6] broadcom: Add vc5 CLIF dumping

This will be usable with "VC5_DEBUG=cl" on the vc5 driver to stream a CLIF file (the Broadcom equivalent of i965's AUB) to stderr. I haven't tested that this is actually usable with the internal CLIF-consuming tools, but is close enough as a baseline and is useful for visually inspecting the

Re: [Mesa-dev] [PATCH 2/2] egl: Add dma_buf_import_modifiers for glvnd

Daniel Stone <dan...@fooishbar.org> writes: > On 31 July 2017 at 15:15, Daniel Stone <dani...@collabora.com> wrote: >> Make sure we advertise the new entrypoints to libglvnd's EGL dispatch. > > Anyone? Reviewed-by: Eric Anholt <e...@anholt.net> signatu

[Mesa-dev] [PATCH] gallium: Weaken assertion about u_mm's align2 field.

vc5 MMU mappings are access-controlled at a 128kb boundary, so the 4kb here was too small for that purpose. Allowing any valid align2 value that u_mm's 32-bit addressing can represent will still catch most cases of people passing in a byte alignment. --- src/gallium/auxiliary/util/u_mm.c | 5

[Mesa-dev] [PATCH 3/6] 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 2/6] 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 ++

[Mesa-dev] [PATCH 6/6] 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. Tested-by: Matt Turner --- src/mesa/main/renderbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Mesa-dev] [PATCH 4/6] 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/6] 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

[Mesa-dev] [PATCH 5/6] 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

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

Mark Janes <mark.a.ja...@intel.com> writes: > Eric Anholt <e...@anholt.net> writes: > >> Tapani Pälli <tapani.pa...@intel.com> writes: >> >>> On 06/22/2017 02:08 AM, Eric Anholt wrote: >>>> Tapani Pälli <tapani.pa...@intel.com>

[Mesa-dev] [PATCH 6/7 v3] broadcom/vc4: Port NEON-code to ARM64

From: Jonas Pfeil Changed all register and instruction names, works the same. v2: Rebase on build system changes (by anholt) v3: Fix build on clang (by anholt, reported by Rob) Signed-off-by: Jonas Pfeil --- src/gallium/drivers/vc4/vc4_tiling_lt.c | 84

[Mesa-dev] [PATCH 5/7 v2] broadcom/vc4: Build the vc4_tiling_lt_neon.c with -mfpu=neon on ARM.

If you don't pass this, the compiler refuses to compile the assembly for pre-v7 CPUs. This also keeps us from building identical, non-NEON code on aarch64 and x86. Fixes: a373f77662c5 ("vc4: Use a wrapper file to set VC4_BUILD_NEON instead of CFLAGS.") v2: Fix Android build by just appending

[Mesa-dev] [PATCH 4/7 v2] configure.ac: Introduce HAVE_ARM_ASM/HAVE_AARCH64_ASM and the -D flags.

I've been trying to get away without these conditionals in vc4's NEON code, but it meant compiling extra unused code on x86, and build failing on ARMv6. v2: Use the _arm/_arm64 flags to simplify detection (suggested by Rob), but hide the _arm version under ARCH_ARM_HAVE_NEON to keep from

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

Tapani Pälli <tapani.pa...@intel.com> writes: > On 06/22/2017 02:08 AM, Eric Anholt wrote: >> 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:

[Mesa-dev] [PATCH 3/7] util: Fix build on old glibc.

We need to link librt for u_thread.h's clock_gettime() call. Fixes: b822d9dd67b5 ("gallium/util: move u_queue.{c,h} to src/util") --- src/util/Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/util/Makefile.am b/src/util/Makefile.am index

[Mesa-dev] [PATCH 4/7] configure.ac: Introduce HAVE_ARM_ASM/HAVE_AARCH64_ASM and the -D flags.

I've been trying to get away without these conditionals in vc4, but it meant compiling extra unused code on x86, and build failing on ARMv6. --- Android.common.mk | 8 configure.ac | 24 2 files changed, 32 insertions(+) diff --git a/Android.common.mk

[Mesa-dev] [PATCH 0/7] old-glibc backport, vc4 NEON improvements

I was trying to build Mesa with NEON support for Raspbian wheezy (gross), and found a couple of easy fixes. I'm hoping for an ack here on configure.ac/DEFINES changes and an Android test. Branch available at: https://github.com/anholt/mesa/commits/vc4-neon Eric Anholt (5): broadcom: Add

[Mesa-dev] [PATCH 2/7] broadcom: Add v3d_xml.h to gitignore.

--- src/broadcom/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/src/broadcom/.gitignore b/src/broadcom/.gitignore index fcc603f0cf01..5442872127e1 100644 --- a/src/broadcom/.gitignore +++ b/src/broadcom/.gitignore @@ -1 +1,2 @@ +cle/v3d_xml.h cle/*_pack.h -- 2.13.3

[Mesa-dev] [PATCH 7/7] broadcom/vc4: Optimize vc4_load_utile/vc4_store_utile with sse for x86

From: Maxim Maslov Mesa vc4 drivers can be built for x86 in order to run hw accelerated graphics inside virtual machines (QEMU, Exagear) on Raspberry Pi. Improves playing intro videos on Diablo II inside Exagear to take 11% of CPU instead of 20%. v2: Runtime CPU detection

[Mesa-dev] [PATCH 5/7] broadcom/vc4: Build the vc4_tiling_lt_neon.c with -mfpu=neon on ARM.

If you don't pass this, the compiler refuses to compile the assembly for pre-v7 CPUs. This also keeps us from building identical, non-NEON code on aarch64 and x86. Fixes: a373f77662c5 ("vc4: Use a wrapper file to set VC4_BUILD_NEON instead of CFLAGS.") --- src/gallium/drivers/vc4/Android.mk

[Mesa-dev] [PATCH 6/7] broadcom/vc4: Port NEON-code to ARM64

From: Jonas Pfeil Changed all register and instruction names, works the same. v2: Rebase on build system changes (by anholt) Signed-off-by: Jonas Pfeil --- src/gallium/drivers/vc4/vc4_tiling_lt.c | 84 + 1 file changed, 84

[Mesa-dev] [PATCH 1/7] broadcom: Add missing libexpat cflags for the decoder.

The Raspbian ARMv6 cross compiler wasn't picking up my (amd64) system copy of the header the way that the system gcc and armhf cross-compile did. --- src/broadcom/Makefile.am | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/broadcom/Makefile.am b/src/broadcom/Makefile.am index

Re: [Mesa-dev] [PATCH 02/12] egl/x11: advertise __DRI_USE_INVALIDATE for DRI2

loader was never updated to expose the > extension. > > Do so allowing the driver to do fine grained tuning. 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

Re: [Mesa-dev] [PATCH] st/dri: don't set PIPE_BIND_SHARED for privately-allocated renderbuffers

Marek Olšák <mar...@gmail.com> writes: > From: Marek Olšák <marek.ol...@amd.com> > > which are MSAA and depth/stencil buffers. Reviewed-by: Eric Anholt <e...@anholt.net> signature.asc Description: PGP signature ___ mes

Re: [Mesa-dev] [PATCH mesa v2] util/ra: fix memory leak

Eric Engestrom writes: > From: Eric Engestrom > > CID: 1415909 > Fixes: 7a34a0e8903249c41fae "ra: Add a callback for selecting a register > from what's available." > Signed-off-by: Eric Engestrom

Re: [Mesa-dev] [PATCH 5/6] mesa: Implement a new GL_MESA_tile_raster_order extension.

Jason Ekstrand <ja...@jlekstrand.net> writes: > On Thu, Jul 27, 2017 at 7:30 PM, Eric Anholt <e...@anholt.net> wrote: > >> The intent is to use this extension on vc4 to allow X11 to do overlapping >> CopyArea() within a pixmap without first blitting the pixmap to a

Re: [Mesa-dev] [PATCH 5/6] mesa: Implement a new GL_MESA_tile_raster_order extension.

Nicolai Hähnle <nhaeh...@gmail.com> writes: > On 28.07.2017 04:30, Eric Anholt wrote: >> The intent is to use this extension on vc4 to allow X11 to do overlapping >> CopyArea() within a pixmap without first blitting the pixmap to a >> temporary. With associated glamo

Re: [Mesa-dev] [PATCH 2/2] st/mesa: fix assertion failure in st_get_texture_sampler_view_from_stobj

Marek Olšák <mar...@gmail.com> writes: > From: Marek Olšák <marek.ol...@amd.com> > > Remove the assertion and replace it with a runtime check. > The reason of the failure is unknown. > > Only Eric Anholt can reproduce it with Glamor. Found the r

[Mesa-dev] [PATCH 3/6] broadcom/vc4: Implement GL_ARB_texture_barrier.

Improves x11perf -copywinwin100 from ~2000/sec to ~4700/sec. More importantly, this is a prerequisite for the new GL_MESA_tile_raster_order extension. --- src/gallium/drivers/vc4/vc4_context.c | 11 +++ src/gallium/drivers/vc4/vc4_screen.c | 2 +- 2 files changed, 12 insertions(+), 1

[Mesa-dev] [PATCH 6/6] vc4: Keep pipe_sampler_view->texture matching the original texture.

I was overwriting view->texture with the shadow resource when we need to do shadow copies (retiling or baselevel rebase), but that tripped up some critical new sanity checking in state_tracker (making sure that stObj->pt hasn't changed from view->texture through TexImage-related paths). To avoid

[Mesa-dev] [PATCH 5/6] mesa: Implement a new GL_MESA_tile_raster_order extension.

+ +MESA_tile_raster_order + +Name Strings + +GL_MESA_tile_raster_order + +Contact + +Eric Anholt, Broadcom (e...@anholt.net) + +Status + +Proposal + +Version + +Last modified date: 26 July 2017 + +Number + +TBD + +Dependencies + +GL_ARB_texture_barrier is required + +Overview

[Mesa-dev] [PATCH 4/6] gallium: Expose a PIPE_CAP_TILE_RASTER_ORDER on vc4.

Because vc4 can control the order that tiles are rasterized in, we can use it to implement overlapping blits using normal drawing and GL_ARB_texture_barrier as long as we can tell the kernel what order to render the tiles in. --- include/drm-uapi/vc4_drm.h| 17 ++---

[Mesa-dev] [PATCH 0/6] Proposed GL_MESA_tile_raster_order extension

) you're likely to have many cliprects for fancy rounded window borders. kernel: https://lists.freedesktop.org/archives/dri-devel/2017-July/148381.html glamor: https://github.com/anholt/xserver/commits/glamor-copyarea-overlap Eric Anholt (6): docs: Fix a typo in the old MESA_program_debug spec

[Mesa-dev] [PATCH 1/6] docs: Fix a typo in the old MESA_program_debug spec.

Noticed that we had two 0x8bb4 in the spec while grepping to find an open slot in the MESA enums set. gl.xml had the right value. --- docs/specs/OLD/MESA_program_debug.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/specs/OLD/MESA_program_debug.spec

[Mesa-dev] [PATCH 2/6] docs: Update the list of used MESA GL enums.

--- docs/specs/enums.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt index 222adbc72e71..00d808483a43 100644 --- a/docs/specs/enums.txt +++ b/docs/specs/enums.txt @@ -63,6 +63,16 @@ GL_MESAX_texture_stack:

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

Eric Anholt <e...@anholt.net> writes: > I was going to indent this code another level, and decided it would be > easier to read as a helper. Could some other user of the RA take a look at this series? signature.asc Description: PGP signature

[Mesa-dev] [PATCH 1/2] intel/decoder: Reuse the MAX2 macro instead of defining another one.

--- src/intel/common/gen_decoder.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c index ba3a5139aec6..60591ad666bf 100644 --- a/src/intel/common/gen_decoder.c +++ b/src/intel/common/gen_decoder.c @@ -39,8

[Mesa-dev] [PATCH 2/2] intel/decoder: Reuse the gen_make_gen() helper.

--- src/intel/common/gen_decoder.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c index 60591ad666bf..85880143f00e 100644 --- a/src/intel/common/gen_decoder.c +++ b/src/intel/common/gen_decoder.c @@ -39,8

Re: [Mesa-dev] [PATCH 0/8] compiler: Add a new gl_image_format enum and use it

Jason Ekstrand writes: > I know what you're all thinking: Why are we adding yet another format > enum? I asked myself the same question. Really, I've spent enough of my > life writing format enum conversion tables that I should know better. > > It all started as an

Re: [Mesa-dev] [PATCH] Android: Fix vc4 build since XML changes.

Rob Herring <r...@kernel.org> writes: > On Wed, Jul 5, 2017 at 1:19 PM, Eric Anholt <e...@anholt.net> wrote: >> diff --git a/src/broadcom/Android.genxml.mk b/src/broadcom/Android.genxml.mk >> index df44b2ec0b79..dfd00a93fbcf 100644 >> --- a/src/broadcom/Androi

Re: [Mesa-dev] [PATCH v2 05/73] nir: add nir_lower_uniforms_to_ubo pass

> of the backend. I don't think I'll be able to use it, but this seems like a reasonable tool to have around. Reviewed-by: Eric Anholt <e...@anholt.net> signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedeskto

Re: [Mesa-dev] [PATCH v2 07/73] st/glsl_to_nir: fix the case where NIR clone testing is enabled

Nicolai Hähnle <nhaeh...@gmail.com> writes: > From: Nicolai Hähnle <nicolai.haeh...@amd.com> > > In that case, prog->nir must be assigned at the end. Reviewed-by: Eric Anholt <e...@anholt.net> signature.asc Description: PGP signature __

Re: [Mesa-dev] [PATCH v2 09/73] st/mesa: get rid of st_glsl_types

Nicolai Hähnle <nhaeh...@gmail.com> writes: > From: Nicolai Hähnle <nicolai.haeh...@amd.com> > > It's a duplicate of glsl_type::count_attribute_slots. Reviewed-by: Eric Anholt <e...@anholt.net> It's a bit unfortunate to duplicate the little wrapper func

[Mesa-dev] BCM7268 V3D3.3 ("vc5") driver release

I've just pushed a "vc5" branch to my Mesa tree (https://github.com/anholt/mesa/commits/vc5). This is the culmination of a couple of months of work on building a new driver for Broadcom's V3D 3.3. V3D 3.3 is a GLES3.1 part, though I'm nowhere near conformance yet. This driver is for BCM7268, a

[Mesa-dev] [PATCH] Android: Fix vc4 build since XML changes.

For the automake build, -Isrc/ is implied from the gallium cflags, while Android gallium driver builds don't get that by default. I think it'll be better for vc4 to have broadcom includes appear as "#include " to make it more clear where to look in the tree than "#include " does. --- Rob: The

[Mesa-dev] [PATCH] anv: Move a comment that got left behind in the u_vector refactor.

--- src/intel/vulkan/anv_private.h | 8 src/util/u_vector.c| 9 + 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h index 573778dad556..f1de08b32f35 100644 ---

Re: [Mesa-dev] [PATCH 1/5] dri3: Wait for all pending swapbuffers to be scheduled before touching the front

ide, so we have to manually sync against it to pretend that Presents happen in the GL command stream. Thus: Reviewed-by: Eric Anholt <e...@anholt.net> signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.

Re: [Mesa-dev] [PATCH v2] intel: Move the DRM uapi headers to a non-Intel location.

Alex Deucher <alexdeuc...@gmail.com> writes: > On Fri, Jun 30, 2017 at 12:40 PM, Lionel Landwerlin > <lionel.g.landwer...@intel.com> wrote: >> On 30/06/17 17:14, Alex Deucher wrote: >>> >>> On Fri, Jun 30, 2017 at 12:02 PM, Eric Anholt <e...@anholt

Re: [Mesa-dev] [PATCH v2] intel: Move the DRM uapi headers to a non-Intel location.

Alex Deucher <alexdeuc...@gmail.com> writes: > On Thu, Jun 29, 2017 at 11:42 AM, Eric Anholt <e...@anholt.net> wrote: >> 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. >>

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

Kenneth Graunke <kenn...@whitecape.org> writes: > [ Unknown signature status ] > On Wednesday, June 28, 2017 11:18:40 AM PDT Eric Anholt wrote: >> I really liked this idea, as it should help with management of packet >> parsing tools like the CL dump. The python script

[Mesa-dev] [PATCH v2] 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. v2: Update Android.mk as well, move distcheck drm*.h references to top-level noinst_HEADERS. Reviewed-by: Lionel Landwerlin

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

Emil Velikov <emil.l.veli...@gmail.com> writes: > Hi Eric, > > On 29 June 2017 at 02:15, Eric Anholt <e...@anholt.net> wrote: >> Needing to get our uapi header from libdrm has only complicated things. >> Follow intel's lead and drop our requirement for it. >

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