[Mesa-dev] [PATCH] configure.ac: fix the --disable-llvm-shared-libs build

When building with --disable-llvm-shared-libs use llvm-config --libfiles instead of of --libs so the full path to the .a files is used instead of -lname. Otherwise at install time gallium_dri.a is installed of gallium_dri.so and the hardlinking of gallium_dri.so to other names fails. Cc: "11.2 11

Re: [Mesa-dev] [PATCH 08/11] nvc0: add indirect compute support on Kepler

On Sat, Feb 27, 2016 at 9:02 AM, Samuel Pitoiset wrote: > The grid size is stored as three 32-bits integers in the indirect > buffer but the launch descriptor uses a 32-bits integer for both > griddim_y and griddim_z like this (z << 16) | y. To make it work, > the 16 high bits of griddim_y are ove

Re: [Mesa-dev] [PATCH 05/11] nvc0: allow to use more than 7 UBOs for compute on Kepler

On Sat, Feb 27, 2016 at 9:02 AM, Samuel Pitoiset wrote: > The launch descriptor only allows to set up 8 CBs, but OpenGL > requires at least 14 UBOs. To bypass this limitation, we store > the addrs into the driver constbuf and we directly load from > the global memory. > > Signed-off-by: Samuel Pit

Re: [Mesa-dev] [PATCH 04/11] nvc0: bind constant buffers for compute on Kepler

On Sat, Feb 27, 2016 at 9:02 AM, Samuel Pitoiset wrote: > --- a/src/gallium/drivers/nouveau/nvc0/nve4_compute.h > +++ b/src/gallium/drivers/nouveau/nvc0/nve4_compute.h > @@ -56,7 +56,7 @@ static inline void > nve4_cp_launch_desc_set_cb(struct nve4_cp_launch_desc *desc, >

Re: [Mesa-dev] [PATCH 02/11] nvc0: bind driver cb for compute on c7[] for Kepler

I think you're trying to resolve conflicts with images here again... please do that separately, and in a way that makes images available everywhere, not just compute. I don't think this needs to be part of this series though. On Sat, Feb 27, 2016 at 9:01 AM, Samuel Pitoiset wrote: > Signed-off-by

Re: [Mesa-dev] [PATCH 4/4] mesa: add OES_texture_buffer and EXT_texture_buffer support

On Sat, Feb 27, 2016 at 4:30 PM, Ilia Mirkin wrote: > Allow ES 3.1 contexts to access the texture buffer functionality. > > Signed-off-by: Ilia Mirkin > --- > docs/GL3.txt| 2 +- > src/mapi/glapi/gen/apiexec.py | 4 ++-- > src/mapi/glapi/gen/es_EXT.xml

[Mesa-dev] [PATCH 4/4] mesa: add OES_texture_buffer and EXT_texture_buffer support

Allow ES 3.1 contexts to access the texture buffer functionality. Signed-off-by: Ilia Mirkin --- docs/GL3.txt| 2 +- src/mapi/glapi/gen/apiexec.py | 4 ++-- src/mapi/glapi/gen/es_EXT.xml | 36 ++ src/mesa/main/bufferob

[Mesa-dev] [PATCH 2/4] mesa: add OES_texture_buffer and EXT_texture_buffer extension to table

Signed-off-by: Ilia Mirkin --- src/mesa/main/extensions_table.h | 2 ++ src/mesa/main/mtypes.h | 1 + 2 files changed, 3 insertions(+) diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h index c139bb4..546948d 100644 --- a/src/mesa/main/extensions_table.h +

[Mesa-dev] [PATCH 3/4] glsl: add OES_texture_buffer and EXT_texture_buffer support

Expose the samplerBuffer/imageBuffer types, and allow the various functions to operate on them. Signed-off-by: Ilia Mirkin --- src/compiler/glsl/builtin_functions.cpp | 20 ++-- src/compiler/glsl/builtin_types.cpp | 22 -- src/compiler/glsl/glcpp/glcpp-p

[Mesa-dev] [PATCH 1/4] mesa: properly return GetTexLevelParameter queries for buffer textures

This fixes all failures with dEQP tests in this area. While ARB_texture_buffer_object explicitly says that GetTexLevelParameter & co should not be supported, GL 3.1 reverses this decision and allows all of these queries there. Conversely, there is no text that forbids the buffer-specific queries f

[Mesa-dev] [PATCH] r600g: Fix ARB_texture_rgb10_a2ui support in big-endian

This patch enables the correct detection of PIPE_FORMAT_R10G10B10A2_UINT and PIPE_FORMAT_B10G10R10A2_UINT formats in r600g in big-endian mode, by adjusting the order of channels in various functions. This enables support for ARB_texture_rgb10_a2ui, which otherwise is not detected as supported. Si

Re: [Mesa-dev] [PATCH] anv: generate different VkSemaphore handles

On Sat, Feb 27, 2016 at 11:39 AM, Jacek Konieczny wrote: > On 2016-02-27 19:58, Jason Ekstrand wrote: > > > > > > On Sat, Feb 27, 2016 at 5:47 AM, Jacek Konieczny > > wrote: > > > > The same handle returned by all vkCreateSemaphore() calls confuses > > validatio

[Mesa-dev] [Bug 94273] OpenCL segfault during testing of clBLAS

https://bugs.freedesktop.org/show_bug.cgi?id=94273 --- Comment #6 from Matt Arsenault --- (In reply to Matt Arsenault from comment #5) > Can you post the output of CLOVER_DEBUG=llvm > > The backtrace seems to indicate that you somehow have ended up with debug > info included which isn't fully im

[Mesa-dev] [Bug 94273] OpenCL segfault during testing of clBLAS

https://bugs.freedesktop.org/show_bug.cgi?id=94273 --- Comment #5 from Matt Arsenault --- Can you post the output of CLOVER_DEBUG=llvm The backtrace seems to indicate that you somehow have ended up with debug info included which isn't fully implemented yet -- You are receiving this mail becaus

Re: [Mesa-dev] [PATCH] anv: generate different VkSemaphore handles

On 2016-02-27 19:58, Jason Ekstrand wrote: > > > On Sat, Feb 27, 2016 at 5:47 AM, Jacek Konieczny > wrote: > > The same handle returned by all vkCreateSemaphore() calls confuses > validation layers: > > > From the Vulkan 1.0 spec, Glossary: > > Non-Dispatcha

Re: [Mesa-dev] [PATCH] anv: generate different VkSemaphore handles

On Sat, Feb 27, 2016 at 5:47 AM, Jacek Konieczny wrote: > The same handle returned by all vkCreateSemaphore() calls confuses > validation layers: > >From the Vulkan 1.0 spec, Glossary: Non-Dispatchable Handle A handle of an integer handle type. Handle values may not be unique, even for two objec

Re: [Mesa-dev] [PATCH] anv: generate different VkSemaphore handles

On 2016-02-27 19:32, Kenneth Graunke wrote: > On Saturday, February 27, 2016 2:47:22 PM PST Jacek Konieczny wrote: >> The same handle returned by all vkCreateSemaphore() calls confuses >> validation layers: >> >> SEMAPHORE(ERROR): object: 0x1 type: 5 location: 1443 msgCode: 0: > vkQueueSubmit: Sem

[Mesa-dev] [Bug 94273] OpenCL segfault during testing of clBLAS

https://bugs.freedesktop.org/show_bug.cgi?id=94273 --- Comment #4 from Serge Martin --- What version of llvm do you use? This sources compile fine here when clover is build with llvm 3.9svn -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the

Re: [Mesa-dev] [PATCH] anv: generate different VkSemaphore handles

On Saturday, February 27, 2016 2:47:22 PM PST Jacek Konieczny wrote: > The same handle returned by all vkCreateSemaphore() calls confuses > validation layers: > > SEMAPHORE(ERROR): object: 0x1 type: 5 location: 1443 msgCode: 0: vkQueueSubmit: Semaphore must not be currently signaled or in a wait

[Mesa-dev] [PATCH v2 4/8] mesa: add OES_sample_variables to extension table, add enable bit

Signed-off-by: Ilia Mirkin --- src/mesa/main/extensions_table.h | 1 + src/mesa/main/mtypes.h | 1 + 2 files changed, 2 insertions(+) diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h index 29ad53c..7362a58 100644 --- a/src/mesa/main/extensions_table.h ++

[Mesa-dev] [PATCH v2 6/8] mesa: add GL_OES_sample_shading support

Signed-off-by: Ilia Mirkin --- src/mapi/glapi/gen/es_EXT.xml | 6 ++ src/mesa/main/enable.c | 4 ++-- src/mesa/main/extensions_table.h| 1 + src/mesa/main/multisample.c | 3 ++- src/mesa/main/tests/dispatch_sanity.cpp | 3 +++ 5 files changed, 14

[Mesa-dev] [PATCH v2 7/8] mesa: add GL_OES_shader_multisample_interpolation support

Signed-off-by: Ilia Mirkin --- src/compiler/glsl/builtin_functions.cpp | 12 +++- src/compiler/glsl/glcpp/glcpp-parse.y| 4 +++- src/compiler/glsl/glsl_lexer.ll | 2 +- src/compiler/glsl/glsl_parser_extras.cpp | 1 + src/compiler/glsl/glsl_parser_extras.h | 2 ++ src/m

[Mesa-dev] [PATCH v2 0/8] Add GL ES per-sample shading support

GL ES adds several extensions that enable the full functionality. I sent many of these out before on a piecemeal basis, but this unifies everything in one series and includes various little fixes I made along the way. As part of this series, I also implement the clarification regarding per-sample

[Mesa-dev] [PATCH v2 1/8] st/mesa: don't force per-sample interp if only sampleid/pos are used

The OES extensions clarify this behaviour to differentiate between per-sample invocation and per-sample interpolation. Using sampleid/pos will force per-sample invocation but not per-sample interpolation. See https://www.khronos.org/bugzilla/show_bug.cgi?id=1462 Signed-off-by: Ilia Mirkin --- s

[Mesa-dev] [PATCH v2 2/8] nv50/ir: using sampleid/pos shouldn't force per-sample interpolation

See https://www.khronos.org/bugzilla/show_bug.cgi?id=1462 Signed-off-by: Ilia Mirkin --- src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 - src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 6 +- 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/src/galliu

[Mesa-dev] [PATCH v2 8/8] st/mesa: add ES sample-shading support

We require the full ARB_gpu_shader5 for now, but in the future some other CAP could get exposed to indicate that only the multisample-related behavior of ARB_gpu_shader5 is available. Signed-off-by: Ilia Mirkin --- docs/GL3.txt | 6 +++--- src/mesa/state_tracker/st_exte

[Mesa-dev] [PATCH v2 5/8] glsl: add GL_OES_sample_variables support

Signed-off-by: Ilia Mirkin --- src/compiler/glsl/builtin_variables.cpp | 12 +--- src/compiler/glsl/glcpp/glcpp-parse.y| 2 ++ src/compiler/glsl/glsl_parser_extras.cpp | 1 + src/compiler/glsl/glsl_parser_extras.h | 2 ++ 4 files changed, 14 insertions(+), 3 deletions(-) diff -

[Mesa-dev] [PATCH v2 3/8] glsl: add gl_MaxSamples, new in GL 4.5 / GL ES 3.2

Signed-off-by: Ilia Mirkin --- src/compiler/glsl/builtin_variables.cpp | 3 +++ src/compiler/glsl/glsl_parser_extras.cpp | 3 +++ src/compiler/glsl/glsl_parser_extras.h | 3 +++ 3 files changed, 9 insertions(+) diff --git a/src/compiler/glsl/builtin_variables.cpp b/src/compiler/glsl/builtin_

Re: [Mesa-dev] [PATCH 01/11] nvc0: use a different offset for buffers and surfaces

On 02/27/2016 04:13 PM, Ilia Mirkin wrote: On Sat, Feb 27, 2016 at 9:50 AM, Samuel Pitoiset wrote: On 02/27/2016 03:42 PM, Ilia Mirkin wrote: Why wouldn't you have surfaces for other shader types? Surface == image. I was thinking they would just use a fixed offset from the suinfobase whic

Re: [Mesa-dev] [PATCH 01/11] nvc0: use a different offset for buffers and surfaces

On Sat, Feb 27, 2016 at 9:50 AM, Samuel Pitoiset wrote: > > > On 02/27/2016 03:42 PM, Ilia Mirkin wrote: >> >> Why wouldn't you have surfaces for other shader types? Surface == image. >> I was thinking they would just use a fixed offset from the suinfobase >> which I repurposed for buffers. >> >>

Re: [Mesa-dev] [PATCH 01/11] nvc0: use a different offset for buffers and surfaces

On 02/27/2016 03:42 PM, Ilia Mirkin wrote: Why wouldn't you have surfaces for other shader types? Surface == image. I was thinking they would just use a fixed offset from the suinfobase which I repurposed for buffers. Either way, why do you need to touch this now? Because for compute on Kepl

Re: [Mesa-dev] [PATCH 01/11] nvc0: use a different offset for buffers and surfaces

Why wouldn't you have surfaces for other shader types? Surface == image. I was thinking they would just use a fixed offset from the suinfobase which I repurposed for buffers. Either way, why do you need to touch this now? On Feb 27, 2016 9:02 AM, "Samuel Pitoiset" wrote: > To not overwrite buffe

Re: [Mesa-dev] [PATCH] nvc0: avoid using magic numbers for the uniform_bo offsets

On 02/25/2016 12:16 AM, Ilia Mirkin wrote: On Wed, Feb 24, 2016 at 3:35 PM, Samuel Pitoiset wrote: +/* TIC/TSC entries (6 user clip planes, base instance id) */ +#define NVC0_CB_AUX_TXC_INFO0x000 +#define NVC0_CB_AUX_TXC_SIZE(8 * 4) This makes no sense. UCP's and base instan

[Mesa-dev] [PATCH 11/11] nvc0: enable compute shaders on Kepler (GK104)

Compute support on GK110+ is still unstable. Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c inde

[Mesa-dev] [PATCH 09/11] nvc0/ir: fix wrong pred emission for ld lock on GK104

This fixes 84b9b8f (nvc0/ir: add missing emission of locked load predicate). Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.

[Mesa-dev] [PATCH 02/11] nvc0: bind driver cb for compute on c7[] for Kepler

Signed-off-by: Samuel Pitoiset --- .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_context.h| 11 ++- src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 10 +++--- src/gallium/drivers/nouveau/nvc0/nve4_compute.c| 38 ++---

[Mesa-dev] [PATCH 04/11] nvc0: bind constant buffers for compute on Kepler

Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/nouveau/nvc0/nve4_compute.c | 70 +++-- src/gallium/drivers/nouveau/nvc0/nve4_compute.h | 2 +- 2 files changed, 66 insertions(+), 6 deletions(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nve4_compute.c b/src/galliu

[Mesa-dev] [PATCH 05/11] nvc0: allow to use more than 7 UBOs for compute on Kepler

The launch descriptor only allows to set up 8 CBs, but OpenGL requires at least 14 UBOs. To bypass this limitation, we store the addrs into the driver constbuf and we directly load from the global memory. Signed-off-by: Samuel Pitoiset --- .../drivers/nouveau/codegen/nv50_ir_driver.h | 1

[Mesa-dev] [PATCH 07/11] nvc0: reduce likelihood of collision for real buffers on Kepler

Reduce likelihood of collision with real buffers by placing the hole at the top of the 4G area. This fixes some indirect draw+compute tests with large buffers. Suggested by Ilia Mirkin. Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/nouveau/nvc0/nve4_compute.c | 4 ++-- 1 file changed,

[Mesa-dev] [PATCH 06/11] nvc0: bump the number of available UBOs for compute on Kepler

Like for 3D, we can now expose the minimum number of uniform buffer objects that OpenGL requires. Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 -- src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 1 - 2 files changed, 3 deletions(-) diff --git a/src/gall

[Mesa-dev] [PATCH 08/11] nvc0: add indirect compute support on Kepler

The grid size is stored as three 32-bits integers in the indirect buffer but the launch descriptor uses a 32-bits integer for both griddim_y and griddim_z like this (z << 16) | y. To make it work, the 16 high bits of griddim_y are overwritten by griddim_z. Signed-off-by: Samuel Pitoiset --- src/

[Mesa-dev] [PATCH 10/11] nv50/ir: add atomics support on shared memory for Kepler

Signed-off-by: Samuel Pitoiset --- .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 112 - .../nouveau/codegen/nv50_ir_lowering_nvc0.h| 1 + 2 files changed, 112 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.

[Mesa-dev] [PATCH 03/11] nvc0: bind shader buffers for compute on Kepler

Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 3 +- src/gallium/drivers/nouveau/nvc0/nve4_compute.c | 38 + 2 files changed, 39 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c b/src/galliu

[Mesa-dev] [PATCH 00/11] nvc0: compute shaders for Kepler (GK104)

Hi there, This series adds support for ARB_compute_shader on Kepler GK104. GK110+ support is still unstable and need more work. Almost all dEQP compute tests pass with a ratio of ~97%. As usual, the list of fails is described below. About piglit, only two tests fail but this is related to images

[Mesa-dev] [PATCH 01/11] nvc0: use a different offset for buffers and surfaces

To not overwrite buffers and surfaces on Kepler, we need a different offset. This will be currently only used for compute because we have to bind both surfaces and buffers. Signed-off-by: Samuel Pitoiset --- .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 + .../nouveau/codegen/nv50_ir_l

[Mesa-dev] [PATCH] anv: generate different VkSemaphore handles

The same handle returned by all vkCreateSemaphore() calls confuses validation layers: SEMAPHORE(ERROR): object: 0x1 type: 5 location: 1443 msgCode: 0: vkQueueSubmit: Semaphore must not be currently signaled or in a wait state Signed-off-by: Jacek Konieczny --- src/intel/vulkan/anv_device.c | 4

[Mesa-dev] [PATCH 3/3 v2] st/nine: Fix second Multithreading issue with MANAGED buffers

Here is another threading issue with MANAGED buffers: Thread 1: buffer creation Thread 1: buffer lock Thread 2: Draw call Thread 1: writes data Thread 1: Unlock Without this patch, the buffer is initially dirty and in the list of things to upload after its creation. The draw call will then upload

[Mesa-dev] [Bug 91556] Struct / union sizes being calculated incorrectly

https://bugs.freedesktop.org/show_bug.cgi?id=91556 --- Comment #9 from Serge Martin --- getTypeAllocSize is making the rounding : 00388 uint64_t getTypeAllocSize(Type *Ty) const { 00389 // Round up to the next alignment boundary. 00390 return alignTo(getTypeStoreSize(Ty), getABITypeAli

[Mesa-dev] [PATCH 2/3] st/nine: Fix Multithreading issue with MANAGED buffers

d3d calls are protected by mutexes, however if app is doing in two threads: Thread 1: buffer Lock Thread 2: Draw call Thread 1: writes data Thread 1: Unlock Then before this patch, the Draw call would begin to upload the buffer. Solves this by moving the moment we add the buffer to the queue of

[Mesa-dev] [PATCH 1/3] st/nine: Handle READONLY for buffer MANAGED pool

READONLY won't trigger an upload. Cc: "11.2" Signed-off-by: Axel Davy --- src/gallium/state_trackers/nine/buffer9.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/src/gallium/state_trackers/nine/buffer9.c b/src/gallium/state_trackers/nine/buffer9.c inde

[Mesa-dev] [PATCH 3/3] st/nine: Fix second Multithreading issue with MANAGED buffers

Here is another threading issue with MANAGED buffers: Thread 1: buffer creation Thread 1: buffer lock Thread 2: Draw call Thread 1: writes data Thread 1: Unlock Without this patch, the buffer is initially dirty and in the list of things to upload after its creation. The draw call will then upload

[Mesa-dev] [PATCH 0/3] gallium nine MANAGED buffers fixed

Unfortunately cc0114f30b587a10766ec212afb3ad356099ef23: "st/nine: Implement Managed vertex/index buffers" introduced some regressions. We have finally managed to find exactly what was the source of the regressions, and it appears to be some threading issues. In addition to these threading issues