Re: [Mesa-dev] [PATCHv3 09/20] i965/fs: Get 64-bit indirect moves working on IVB.

On Fri, 2017-02-10 at 10:44 -0800, Francisco Jerez wrote: > Samuel Iglesias Gonsálvez writes: > > > On Thu, 2017-02-09 at 18:28 -0800, Francisco Jerez wrote: > > > Francisco Jerez writes: > > > > > > > --- > > > > This replaces "[PATCH v2 09/20]

Re: [Mesa-dev] [PATCH v2 09/20] i965/fs: indirect addressing with doubles is not supported in IVB/BYT

On Fri, 2017-02-10 at 10:10 -0800, Francisco Jerez wrote: > Samuel Iglesias Gonsálvez writes: > > > On Thu, 2017-02-09 at 12:18 -0800, Francisco Jerez wrote: > > > Samuel Iglesias Gonsálvez writes: > > > > > > > It is tested empirically that IVB/BYT

[Mesa-dev] [PATCH] i965/fs: fix 32-bit data type to int64 conversion on BSW/BXT

The 32-bit to 64-bit conversions need to have the 32-bit data source elements aligned to 64-bit but only with doubles as destination type. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99660 Signed-off-by: Samuel Iglesias Gonsálvez Tested-by: Mark Janes

[Mesa-dev] [PATCH 2/3] radv: start splitting init config up

From: Dave Airlie This is just prep work for the following patch to use a common gfx init indirect buffer. Signed-off-by: Dave Airlie --- src/amd/vulkan/si_cmd_buffer.c | 28 1 file changed, 20 insertions(+), 8 deletions(-)

[Mesa-dev] [PATCH 1/3] radv: don't pass physical device to si_init_ fns.

From: Dave Airlie This is just a trivial cleanup. Signed-off-by: Dave Airlie --- src/amd/vulkan/radv_cmd_buffer.c | 4 ++-- src/amd/vulkan/radv_private.h| 6 ++ src/amd/vulkan/si_cmd_buffer.c | 10 +- 3 files changed, 9

[Mesa-dev] [PATCH 3/3] radv: use indirect buffer for initial gfx state.

From: Dave Airlie This puts the common gfx state for the device into an indirect buffer, and just calls out to it, on CIK and above. This is taken from what radeonsi does. Signed-off-by: Dave Airlie --- src/amd/vulkan/radv_cmd_buffer.c | 16

Re: [Mesa-dev] [PATCH 4/6] gallium/radeon: fix performance of buffer readbacks

On 10/02/17 08:27 PM, Marek Olšák wrote: > On Fri, Feb 10, 2017 at 12:22 PM, Emil Velikov > wrote: >> On 9 February 2017 at 11:56, Marek Olšák wrote: >>> From: Marek Olšák >>> >>> We want cached GTT for all non-persistent read

Re: [Mesa-dev] How about vk_features.txt?

I'm certainly not opposed. I've considered adding such a tracking file for a while. I'm not sure whether or not it's needed but it wouldn't hurt. On Sun, Feb 12, 2017 at 6:48 PM, Romain Failliot < romain.faill...@foolstep.com> wrote: > Hi! > > I regularly receive questions about having

[Mesa-dev] How about vk_features.txt?

Hi! I regularly receive questions about having Mesamatrix tracking the state of Vulkan API for ANV and RADV. I don't think there is a file in mesa repo that state the progression of Vulkan on each driver. So if you're interested, I could generate a base file (xml?) extracting the tag from the

Re: [Mesa-dev] software implementation of vulkan for gsoc/evoc

forgot to add mesa-dev when I sent. -- Forwarded message -- From: "Jacob Lifshay" Date: Feb 12, 2017 6:16 PM Subject: Re: [Mesa-dev] software implementation of vulkan for gsoc/evoc To: "Dave Airlie" Cc: On Feb 12, 2017 5:34 PM,

Re: [Mesa-dev] software implementation of vulkan for gsoc/evoc

> I'm assuming that control barriers in Vulkan are identical to barriers > across a work-group in opencl. I was going to have a work-group be a single > OS thread, with the different work-items mapped to SIMD lanes. If we need to > have additional scheduling, I have written a javascript compiler

Re: [Mesa-dev] [PATCH v2] nir: delete magic number

On 9 February 2017 at 02:48, Timothy Arceri wrote: > On Wed, 8 Feb 2017 15:54:46 -0800 > Jason Ekstrand wrote: > > > On Wed, Feb 8, 2017 at 2:20 PM, Elie Tournier > > wrote: > > > > > Signed-off-by: Elie Tournier

Re: [Mesa-dev] [PATCH] virgl/vtest: disconnect on destroy

- Original Message - > On 10 February 2017 at 00:35, wrote: > > From: Marc-André Lureau > > > > Since vtest is currently only handling a context at a time, calling > > disconnect in virgl_vtest_winsys_destroy() allows to pass

Re: [Mesa-dev] software implementation of vulkan for gsoc/evoc

I'm assuming that control barriers in Vulkan are identical to barriers across a work-group in opencl. I was going to have a work-group be a single OS thread, with the different work-items mapped to SIMD lanes. If we need to have additional scheduling, I have written a javascript compiler that

Re: [Mesa-dev] software implementation of vulkan for gsoc/evoc

On 11 February 2017 at 09:03, Jacob Lifshay wrote: > I would like to write a software implementation of Vulkan for inclusion in > mesa3d. I wanted to use a tiled renderer coupled with llvm and either write > or use a whole-function-vectorization pass. Would anyone be

Re: [Mesa-dev] [Mesa-stable] [PATCH] st/mesa: don't pass compare mode for stencil-sampled textures

Reviewed-by: Marek Olšák Marek On Sun, Feb 12, 2017 at 8:20 PM, Ilia Mirkin wrote: > Fixes dEQP-GLES31.functional.stencil_texturing.misc.compare_mode_effect > > Signed-off-by: Ilia Mirkin > Cc: mesa-sta...@lists.freedesktop.org

Re: [Mesa-dev] [PATCH 2/2] etnaviv: Set shader instruction area correctly for GC3000

Hi 2017-02-09 13:18 GMT+01:00 Wladimir J. van der Laan : > - Use the same instruction area on GC3000 as the Vivante driver. > This allows the same number of instructions on GC3000 as GC2000 > instead of half. > > - Makes sure that the "PE to FE" stall before updating the

Re: [Mesa-dev] [PATCH 1/2] etnaviv: Update hw header files

Hi Wladimir, 2017-02-09 13:16 GMT+01:00 Wladimir J. van der Laan : > Update from etnaviv repository rnndb. > --- > src/gallium/drivers/etnaviv/hw/cmdstream.xml.h | 6 +- > src/gallium/drivers/etnaviv/hw/common.xml.h| 14 +-- > src/gallium/drivers/etnaviv/hw/isa.xml.h

[Mesa-dev] [PATCH] st/mesa: don't pass compare mode for stencil-sampled textures

Fixes dEQP-GLES31.functional.stencil_texturing.misc.compare_mode_effect Signed-off-by: Ilia Mirkin Cc: mesa-sta...@lists.freedesktop.org --- src/mesa/state_tracker/st_atom_sampler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Mesa-dev] [PATCH] radv: Fix radv_GetPhysicalDeviceQueueFamilyProperties2KHR.

On 11 February 2017 at 06:39, Bas Nieuwenhuizen wrote: > The struct have different size, so the arrays have different stride. > > Signed-off-by: Bas Nieuwenhuizen Reviewed-by: Dave Airlie > --- > src/amd/vulkan/radv_device.c |

[Mesa-dev] [PATCH] radv: detect command buffers that do no work and drop them (v2)

From: Dave Airlie If a buffer is just full of flushes we flush things on command buffer submission, so don't bother submitting these. This will reduce some CPU overhead on dota2, which submits a fair few command streams that don't end up drawing anything. v2: reorganise

Re: [Mesa-dev] [PATCH] radv: reduce CPU overhead merging bo lists.

On 11 February 2017 at 04:30, Bas Nieuwenhuizen wrote: > Was thinking of a sort or other asymptotically more efficient merge > method, but in the meantime this is I did get that, I just didn't have the brain power to work out what would be better, so just optimised the

Re: [Mesa-dev] [PATCH 2/2] vdpau: skip vlVdpOutputSurfacePutBitsNative with a zero-area rectangle

Hey Marek, Marek Olšák wrote on 12.02.2017 15:53: > From: Marek Olšák > > This prevents errors: > "EE r600_texture.c:1571 r600_texture_transfer_map - failed to create > temporary texture to hold untiled copy" > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99542

[Mesa-dev] [Bug 99781] Some Unity games fail assertion on startup in glXCreateContextAttribsARB

https://bugs.freedesktop.org/show_bug.cgi?id=99781 Bug ID: 99781 Summary: Some Unity games fail assertion on startup in glXCreateContextAttribsARB Product: Mesa Version: 13.0 Hardware: Other OS: All

Re: [Mesa-dev] [PATCH 10/21] winsys/amdgpu: extract amdgpu_do_add_real_buffer

On 10.02.2017 23:07, Marek Olšák wrote: Assuming you address other people's comments, the first 10 are: Reviewed-by: Marek Olšák Thanks. There are some bugs in the later patches, I will send out a new series, probably in some days. Nicolai Marek On Wed, Feb 8,

[Mesa-dev] [PATCH 1/2] gallium/radeon: add an assertion to texture_transfer_map for app bugs

From: Marek Olšák --- src/gallium/drivers/radeon/r600_texture.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/radeon/r600_texture.c b/src/gallium/drivers/radeon/r600_texture.c index 5d84eb4..47aa8b1 100644 ---

[Mesa-dev] [PATCH 2/2] vdpau: skip vlVdpOutputSurfacePutBitsNative with a zero-area rectangle

From: Marek Olšák This prevents errors: "EE r600_texture.c:1571 r600_texture_transfer_map - failed to create temporary texture to hold untiled copy" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99542 --- src/gallium/state_trackers/vdpau/output.c | 7 +++ 1

[Mesa-dev] [Bug 99776] Graphical Corruption and Kernel Lockup on Polaris10

https://bugs.freedesktop.org/show_bug.cgi?id=99776 Vedran Miletić changed: What|Removed |Added CC||ved...@miletic.net

Re: [Mesa-dev] [PATCH 14/26] mesa: Connect the generated GL command marshalling code to the build.

> >> > void > >> > _mesa_glthread_init(struct gl_context *ctx) > >> > { > >> > struct glthread_state *glthread = calloc(1, sizeof(*glthread)); > >> > > >> > if (!glthread) > >> >return; > >> > > >> > + /* The marshalling dispatch table isn't integrated with the > >> >