From: Dave Airlie
This was falling into the quantizetof16 path.
Signed-off-by: Dave Airlie
---
src/compiler/spirv/vtn_alu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index 55f7f2e..0738fe0 100644
--- a/src/co
From: Dave Airlie
zero extend ->u64 and sign extend ->i64.
Signed-off-by: Dave Airlie
---
src/amd/common/ac_nir_to_llvm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 883656d..e9e3d14 100644
--- a/src/amd/com
From: Dave Airlie
These are enough for the spir-v generator to handle UConvert
and SConvert operations, and fix the 4 tests in CTS.
Signed-off-by: Dave Airlie
---
src/compiler/nir/nir.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/src/compiler
From: Dave Airlie
Signed-off-by: Dave Airlie
---
src/compiler/nir/nir.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 8bbc41d..d92e6eb 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -688,6 +688,12 @@ nir_get_
These should be applied before radv int64 is enabled.
These 3 fix the 64-bit variants of
dEQP-VK.spirv_assembly.instruction.compute.uconvert.*
dEQP-VK.spirv_assembly.instruction.compute.sconvert.*
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesk
On Tuesday, February 14, 2017 11:29:47 PM PST Jason Ekstrand wrote:
> We can only do the optimization if the source *is* SSA.
>
> Cc: "13.0 17.0"
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/b
On Wed, Feb 15, 2017 at 2:03 AM, Jason Ekstrand wrote:
> ---
> src/util/Makefile.sources | 3 ++-
> src/util/vk_util.h| 43 +++
> 2 files changed, 45 insertions(+), 1 deletion(-)
> create mode 100644 src/util/vk_util.h
>
> diff --git a/src/util/Ma
Reviewed-by: Lionel Landwerlin
On 15/02/17 08:26, Dave Airlie wrote:
From: Dave Airlie
This was falling into the quantizetof16 path.
Signed-off-by: Dave Airlie
---
src/compiler/spirv/vtn_alu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/spirv/vtn_alu.
On 14.02.2017 19:10, Marek Olšák wrote:
On Mon, Feb 13, 2017 at 4:57 PM, Marek Olšák wrote:
On Mon, Feb 13, 2017 at 4:37 PM, Nicolai Hähnle wrote:
On 11.02.2017 20:58, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_query.c | 25
++-
On 14.02.2017 18:20, Marek Olšák wrote:
On Tue, Feb 14, 2017 at 9:23 AM, Nicolai Hähnle wrote:
On 13.02.2017 23:08, Samuel Pitoiset wrote:
Only the Radeon kernel driver exposed the GPU temperature and
the shader/memory clocks, this implements the same functionality
for the AMDGPU kernel drive
On 02/15/2017 11:59 AM, Nicolai Hähnle wrote:
On 14.02.2017 18:20, Marek Olšák wrote:
On Tue, Feb 14, 2017 at 9:23 AM, Nicolai Hähnle
wrote:
On 13.02.2017 23:08, Samuel Pitoiset wrote:
Only the Radeon kernel driver exposed the GPU temperature and
the shader/memory clocks, this implements t
glGetTextureSubImage() and glGetCompressedTextureSubImage() are currently
returning INVALID_OPERATION error when the passed texture argument does not
correspond to an existing texture object. However, the error should be
INVALID_VALUE instead. From OpenGL 4.5 spec PDF, section '8.11. Texture
Querie
Hi,
On 14.02.2017 21:06, Ian Romanick wrote:
On 02/10/2017 02:56 AM, Eero Tamminen wrote:
On 09.02.2017 19:30, Ian Romanick wrote:
On 02/09/2017 05:19 PM, Eero Tamminen wrote:
When checking GL errors for "Unturned" (Steam top-20 Unity3D based
game), I noticed that it uses functions from exten
Hi Matt,
Afaics dl_iterate_phdr is available on musl, (some?) BSDs and Solaris
- thank you for opting for it.
Out of curiosity:
Have you checked if on those platforms the "GNU\0" strcmp is
applicable and not another string ? Worth adding a note/comment ?
On 14 February 2017 at 23:58, Matt Turne
On 14 February 2017 at 21:02, Chad Versace wrote:
> On Tue 14 Feb 2017, Kenneth Graunke wrote:
>> On Tuesday, February 14, 2017 12:38:45 PM PST Chad Versace wrote:
>> > On Tue 14 Feb 2017, Matt Turner wrote:
>> >
>> >
>> > > static bool
>> > > -anv_get_function_timestamp(void *ptr, uint32_t* time
On 13 February 2017 at 17:54, Daniel Stone wrote:
> Hi,
>
> On 13 February 2017 at 17:49, Emil Velikov wrote:
>> On 13 February 2017 at 17:34, Daniel Stone wrote:
>>> On 13 February 2017 at 17:27, Emil Velikov wrote:
Wouldn't it be better to have this in dri2_wl_create_window_surface() ?
>
On 13.02.2017 20:23, Emil Velikov wrote:
From: Emil Velikov
The version tag used to nominate has bitten even experienced mesa
developers. Not to mention that it deviates from the one used in the
kernel leading to further confusion.
Simplify things and omit it all together.
Signed-off-by: Emil
Good changes, I think. Except for a comment on patch #3, the series is
Reviewed-by: Nicolai Hähnle
On 13.02.2017 20:23, Emil Velikov wrote:
From: Emil Velikov
Provide information and an example.
Signed-off-by: Emil Velikov
---
docs/submittingpatches.html | 5 +
1 file changed, 5 inser
On 14.02.2017 16:18, Samuel Pitoiset wrote:
Mesa currently doesn't allow to create 3.1+ compatibility profiles
mainly because various features are unimplemented and bugs can
happen.
However, some buggy apps request a compat profile without using
any old features unimplemented in mesa, and they f
On 14.02.2017 23:51, Marek Olšák wrote:
On Tue, Feb 14, 2017 at 11:47 PM, Timothy Arceri wrote:
On 15/02/17 08:35, Marek Olšák wrote:
On Tue, Feb 14, 2017 at 9:53 PM, Timothy Arceri
wrote:
On 15/02/17 02:14, Marek Olšák wrote:
On Tue, Feb 14, 2017 at 1:52 AM, Timothy Arceri
wrote:
-
On 15.02.2017 12:14, Eduardo Lima Mitev wrote:
glGetTextureSubImage() and glGetCompressedTextureSubImage() are currently
returning INVALID_OPERATION error when the passed texture argument does not
correspond to an existing texture object. However, the error should be
INVALID_VALUE instead. From O
Hi,
I am getting same result with 17.0.x which I got for version 13 ( of Mesa). Not
sure if Qt has something to do with this. I am using Qt version 5.6.
Thanks,
Sujith H
-Original Message-
From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of
Haridasan, Sujith
Sent
Hi Ben,
On 10 February 2017 at 23:10, Ben Crocker wrote:
> Reenable the PPC64LE Vector-Scalar Extension for LLVM versions >= 3.8.1,
> now that LLVM bug 26775 and its corollary, 25503, are fixed.
>
> Amendment: remove extraneous spaces in macro def & invocations.
>
> We would prefer a runtime chec
From: Emil Velikov
Signed-off-by: Emil Velikov
---
configure.ac | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4b7f2298f7..3ef1dd5e20 100644
--- a/configure.ac
+++ b/configure.ac
@@ -305,7 +305,7 @@ if test "x$GCC"
On 15 February 2017 at 12:57, Haridasan, Sujith
wrote:
> Hi,
>
> I am getting same result with 17.0.x which I got for version 13 ( of Mesa).
> Not sure if Qt has something to do with this. I am using Qt version 5.6.
>
In that case I would strongly encourage that you flesh out a simple
test app, w
Reviewed-by: Samuel Iglesias Gonsálvez
On Wed, 2017-02-15 at 18:43 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
> ---
> src/compiler/nir/nir.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> inde
On Wed, 2017-02-15 at 18:43 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> These are enough for the spir-v generator to handle UConvert
> and SConvert operations, and fix the 4 tests in CTS.
>
> Signed-off-by: Dave Airlie
> ---
> src/compiler/nir/nir.c | 26 +++---
> 1 f
Hi all,
On 11 February 2017 at 02:44, Pierre-Loup A. Griffais
wrote:
> Ideally LLVM could expose a version string/number that's granular enough,
> and distros/users could be trusted to properly amend that version string if
> they make functional changes to something that can affect shader
> comp
Hi Matt,
On 14 February 2017 at 23:58, Matt Turner wrote:
> The --build-id=... ld flag has been present since binutils-2.18,
> released 28 Aug 2007.
> ---
> src/intel/vulkan/Makefile.am | 1 +
> src/intel/vulkan/anv_device.c | 28 +++-
> 2 files changed, 8 insertions(+)
If an unsized declared array is not the last in an SSBO
and an implicit size can not be defined on linking time,
the linker should raise an error instead of reaching
an assertion on GL.
This reverts part of commit 3da08e166415a745139c1127040a24e8a45dc553
getting back to the behavior of commit 5b26
I've forgot the --annotate to submit this comment about this patch, so
here it is:
This patch fixes an incorrect behavior exposed by the piglit tests about
SSBOs
and unsized arrays submitted by Dave Airlie not yet in master
https://lists.freedesktop.org/archives/piglit/2016-May/019852.html
Chema
On 15 February 2017 at 12:33, Nicolai Hähnle wrote:
> On 13.02.2017 20:23, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> The version tag used to nominate has bitten even experienced mesa
>> developers. Not to mention that it deviates from the one used in the
>> kernel leading to further conf
Oops... R-b
On Feb 15, 2017 12:27 AM, "Dave Airlie" wrote:
> From: Dave Airlie
>
> This was falling into the quantizetof16 path.
>
> Signed-off-by: Dave Airlie
> ---
> src/compiler/spirv/vtn_alu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/spirv/vtn_
On Tue, 2017-02-14 at 11:11 -0800, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez writes:
>
> > Previously we were emitting two MOV_INDIRECT instructions by
> > calculating
> > source's indirect offsets for each 32-bit half of a DF source.
> > However,
> > this is not needed as we can just em
From: Emil Velikov
Print only the information needed. Namely:
*info: the DRI module picked and the vendor/renderer strings
*gears: everything but the "...configuration file..." line(s)
v2: (Eric) Use "2>&1 |" over "|&", properly escape &.
Signed-off-by: Emil Velikov
---
docs/releasing.html |
Happy to rework the implementation.
Would creating a util_clear_texture function which pulls out the
necessary components from util_clear_render_target be in alignment
with what you're imagining?
The idea would be to have util_clear_texture take a pipe_resource
instead of a pipe_surface.
Something
From: Emil Velikov
Drop the extra handling and assert() if things change in the future.
Signed-off-by: Emil Velikov
---
src/egl/main/eglarray.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/src/egl/main/eglarray.c b/src/egl/main/eglarray.c
ind
From: Emil Velikov
We'll be using the drmGetDevice[s]2 API in src/loader with next patch.
v2: Rebase.
Signed-off-by: Emil Velikov
Reviewed-by: Michel Dänzer (v1)
Reviewed-by: Eric Engestrom (v1)
---
configure.ac | 2 +-
scons/gallium.py | 2 +-
2 files changed, 2 insertions(+), 2 deleti
From: Emil Velikov
drmGetDevices2() provides us with enough flexibility to build heuristics
upon. Opening a random node on the other hand will wake up the device,
regardless if it's the one we're interested or not.
v2:
- Explicitly require/check for libdrm.
- Zero physicalDeviceCount when drmG
From: Emil Velikov
Analogous to previous commit
Cc: Dave Airlie
Signed-off-by: Emil Velikov
Reviewed-by: Michel Dänzer
Reviewed-by: Bas Nieuwenhuizen
Reviewed-by: Eric Engestrom
---
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Emil Velikov
drmGetDevices2() provides us with enough flexibility to build heuristics
upon. Opening a random node on the other hand will wake up the device,
regardless if it's the one we're interested or not.
v2: Rebase.
Cc: Michel Dänzer
Cc: Dave Airlie
Signed-off-by: Emil Velikov
Rev
From: Emil Velikov
By this allows us to fetch the device list/info w/o the revision field.
At the moment retrieving the latter wakes up the device.
Note: kernel patch to resolve that should be in 4.10.
Signed-off-by: Emil Velikov
Reviewed-by: Michel Dänzer
Reviewed-by: Eric Engestrom
---
Due
From: Emil Velikov
Analogous to previous commit
Signed-off-by: Emil Velikov
Reviewed-by: Michel Dänzer
Reviewed-by: Marek Olšák
Reviewed-by: Eric Engestrom
---
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/w
Hi all,
This is mostly a resent from v1, with a couple of fixes on the ANV
patch and commit message polish as per Eric/Michel's input.
In case you've forgotten:
Using the non "2" API fetches the PCI revision field, which wakes up
the device [even if we don't end up using it], which can lead to
From: Emil Velikov
The VK_SUCCESS/VK_INCOMPLETE pattern is quite common.
Signed-off-by: Emil Velikov
---
Based on top of the drmGetDevice2 series sent earlier.
src/intel/vulkan/anv_device.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/s
On 9 February 2017 at 13:35, Emil Velikov wrote:
> From: Emil Velikov
>
> No other env var used in mesa allows for space in the variable contents.
>
> Signed-off-by: Emil Velikov
> ---
> Worth documenting and/or even renaming them ?
Tim, with the documentation going in, we can land this ?
We mi
On Wed, Feb 15, 2017 at 10:51 AM, Emil Velikov wrote:
> From: Emil Velikov
>
> drmGetDevices2() provides us with enough flexibility to build heuristics
> upon. Opening a random node on the other hand will wake up the device,
> regardless if it's the one we're interested or not.
>
> v2:
> - Expli
On 02/15/2017 05:36 PM, Mark Janes wrote:
With this series, I encounter the following crash using wflinfo:
wflinfo: src/mesa/drivers/dri/common/xmlconfig.c:1028: driQueryOptionb: Assertion
`cache->info[i].name != ((void *)0)' failed.
Mmh.
Can you provide a full backtrace?
Samuel Pitoiset
---
src/compiler/nir/nir_builder.h | 41 +
1 file changed, 41 insertions(+)
diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index 194d327..cdfc15b 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
Only build-tested.
On Wed, Feb 15, 2017 at 8:43 AM, Jason Ekstrand
wrote:
> ---
> src/compiler/nir/nir_builder.h | 41 ++
> +++
> 1 file changed, 41 insertions(+)
>
> diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_
> builder.h
> index 194d
On 15 February 2017 at 16:38, Ilia Mirkin wrote:
>> +anv_enumerate_devices(struct anv_instance *instance)
>> +{
>> + /* TODO: Check for more devices ? */
>> + drmDevicePtr devices[8];
>> + VkResult result = VK_SUCCESS;
Should read
VkResult result = VK_ERROR_INCOMPATIBLE_DRIVER;
>> +
With this series, I encounter the following crash using wflinfo:
wflinfo: src/mesa/drivers/dri/common/xmlconfig.c:1028: driQueryOptionb:
Assertion `cache->info[i].name != ((void *)0)' failed.
Samuel Pitoiset writes:
> Mesa currently doesn't allow to create 3.1+ compatibility profiles
> mainly
On Wed, Feb 15, 2017 at 1:49 PM, Nicolai Hähnle wrote:
> On 14.02.2017 23:51, Marek Olšák wrote:
>>
>> On Tue, Feb 14, 2017 at 11:47 PM, Timothy Arceri
>> wrote:
>>>
>>>
>>>
>>> On 15/02/17 08:35, Marek Olšák wrote:
On Tue, Feb 14, 2017 at 9:53 PM, Timothy Arceri
wrote:
>
Hey Samuel,
I think you forgot to define the default value for our driver.
I'm not too familiar with this code. Is there a way to have default
values for all dri drivers?
Thanks,
-
Lionel
On 15/02/17 16:42, Samuel Pitoiset wrote:
On 02/15/2017 05:36 PM, Mark Janes wrote:
With this series
Signed-off-by: Lionel Landwerlin
Fixes: 9d16f3903e2 ("driconf: add allow_higher_compat_version option")
---
src/mesa/drivers/dri/i965/intel_screen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 83b1f
Thanks.
Reviewed-by: Samuel Pitoiset
On 02/15/2017 05:59 PM, Lionel Landwerlin wrote:
Signed-off-by: Lionel Landwerlin
Fixes: 9d16f3903e2 ("driconf: add allow_higher_compat_version option")
---
src/mesa/drivers/dri/i965/intel_screen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/m
Reviewed-by: Matt Turner
Please commit ASAP.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Feb 15, 2017 at 2:14 AM, Grazvydas Ignotas
wrote:
> On Wed, Feb 15, 2017 at 2:03 AM, Jason Ekstrand
> wrote:
> > ---
> > src/util/Makefile.sources | 3 ++-
> > src/util/vk_util.h| 43 ++
> +
> > 2 files changed, 45 insertions(+), 1 deleti
---
src/util/Makefile.sources | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index eec0311..aecb7c2 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -45,7 +45,7 @@ MESA_UTIL_FILES :=\
u_
On Wednesday, 2017-02-15 15:36:00 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Drop the extra handling and assert() if things change in the future.
>
> Signed-off-by: Emil Velikov
Reviewed-by: Eric Engestrom
> ---
> src/egl/main/eglarray.c | 27 +--
> 1 file c
Reviewed-by: Eric Engestrom
On Wednesday, 2017-02-15 09:30:01 -0800, Jason Ekstrand wrote:
> ---
> src/util/Makefile.sources | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
> index eec0311..aecb7c2 100644
> --- a/src
According to Ivybridge PRM, Volume 4 Part 1 p73, signed integer formats
cannot be multisampled.
Also in the same PRM p63, any format with greater than 64 bits per
element cannot be multisampled.
This fixes the following Vulkan CTS tests in Haswell:
dEQP-VK.memory.requirements.image.regular_tilin
On Wed, Feb 15, 2017 at 10:09 AM, Juan A. Suarez Romero wrote:
> According to Ivybridge PRM, Volume 4 Part 1 p73, signed integer formats
> cannot be multisampled.
>
> Also in the same PRM p63, any format with greater than 64 bits per
> element cannot be multisampled.
>
> This fixes the following
On 02/15/2017 01:56 PM, Nicolai Hähnle wrote:
> On 15.02.2017 12:14, Eduardo Lima Mitev wrote:
>> glGetTextureSubImage() and glGetCompressedTextureSubImage() are currently
>> returning INVALID_OPERATION error when the passed texture argument
>> does not
>> correspond to an existing texture object.
On Wed, Feb 15, 2017 at 4:03 AM, Emil Velikov wrote:
> Hi Matt,
>
> Afaics dl_iterate_phdr is available on musl, (some?) BSDs and Solaris
> - thank you for opting for it.
>
> Out of curiosity:
> Have you checked if on those platforms the "GNU\0" strcmp is
> applicable and not another string ? Wort
On Wed, Feb 15, 2017 at 6:05 AM, Emil Velikov wrote:
> Hi Matt,
>
> On 14 February 2017 at 23:58, Matt Turner wrote:
>> The --build-id=... ld flag has been present since binutils-2.18,
>> released 28 Aug 2007.
>> ---
>> src/intel/vulkan/Makefile.am | 1 +
>> src/intel/vulkan/anv_device.c | 28
https://bugs.freedesktop.org/show_bug.cgi?id=99467
--- Comment #17 from Joeri Capens ---
The new patches work great for me. No more brightly colored fog which occurred
randomly and often made the game impossible to play.
I'm on Gentoo with a 4.9.9 kernel, RX 460 card.
Thank you for the amazing
On Wed, Feb 15, 2017 at 10:57 AM, Matt Turner wrote:
> On Wed, Feb 15, 2017 at 4:03 AM, Emil Velikov
> wrote:
> > Hi Matt,
> >
> > Afaics dl_iterate_phdr is available on musl, (some?) BSDs and Solaris
> > - thank you for opting for it.
> >
> > Out of curiosity:
> > Have you checked if on those p
Reviewed-by: Jason Ekstrand
Thanks for getting this figured out!
On Tue, Feb 14, 2017 at 3:58 PM, Matt Turner wrote:
> The --build-id=... ld flag has been present since binutils-2.18,
> released 28 Aug 2007.
> ---
> src/intel/vulkan/Makefile.am | 1 +
> src/intel/vulkan/anv_device.c | 28 ++
Yes, I guess a new util_clear_texture helper would work -
util_clear_render_target and util_clear_depth_stencil are modeled after
the respective pipe functions too, so why not have a util_clear_texture
modeled after the respective pipe function... Maybe rip out most of the
actual implementation of
The --build-id=... ld flag has been present since binutils-2.18,
released 28 Aug 2007.
---
src/intel/vulkan/Makefile.am | 1 +
src/intel/vulkan/anv_device.c | 28 +++-
2 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/src/intel/vulkan/Makefile.am b/src/intel
Provides the ability to read the .note.gnu.build-id section of ELF
binaries, which is inserted by the --build-id=... flag to ld.
Reviewed-by: Emil Velikov
---
configure.ac | 6 +++
src/util/Makefile.sources | 2 +
src/util/build_id.c | 109 +
https://bugs.freedesktop.org/show_bug.cgi?id=99467
--- Comment #18 from Bogomil Vasilev ---
I can confirm the same. The blurry colors are gone. The game works perfect so
far.
David, are you polishing the patches before pushing them? I'm asking is because
I don't see any reason not to submit it to
Emil Velikov writes:
> From: Emil Velikov
>
> The version tag used to nominate has bitten even experienced mesa
> developers. Not to mention that it deviates from the one used in the
> kernel leading to further confusion.
>
> Simplify things and omit it all together.
>
> Signed-off-by: Emil Velc
Samuel Iglesias Gonsálvez writes:
> From: "Juan A. Suarez Romero"
>
> In IVB and BYT, both regioning parameters and execution sizes are measured as
> 32-bits element size.
>
> So when we have something like:
>
> mov(8) g2<1>DF g3<4,4,1>DF
>
> We are not actually moving 8 doubles (our intention),
On Wed, Feb 15, 2017, at 09:43, Dave Airlie wrote:
> From: Dave Airlie
>
> zero extend ->u64 and sign extend ->i64.
>
> Signed-off-by: Dave Airlie
> ---
> src/amd/common/ac_nir_to_llvm.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/
Samuel Iglesias Gonsálvez writes:
> From: Matt Turner
>
> On HSW+, scalar DF sources can be accessed using the normal <0,1,0>
> region, but on IVB and BYT DF regions must be programmed in terms of
> floats. A <0,2,1> region accomplishes this.
>
> v2:
> - Apply region <0,2,1> in brw_reg_from_fs_r
https://bugs.freedesktop.org/show_bug.cgi?id=99789
Matt Turner changed:
What|Removed |Added
CC|damian.di...@gmail.com |
--- Comment #1 from Matt Turner ---
(you
Samuel Iglesias Gonsálvez writes:
> From: "Juan A. Suarez Romero"
>
> When converting a DF to 32-bit conversions, we set dst stride to 2,
> to fulfill alignment restrictions because the upper Dword of every
> Qword will be written with undefined value.
>
> But in IVB/BYT, this is not necessary,
Samuel Iglesias Gonsálvez writes:
> From: "Juan A. Suarez Romero"
>
> According to the IVB and HSW PRMs:
>
> "2.When the destination requires two registers and the sources are
> indirect, the sources must use 1x1 regioning mode."
>
> So for DF instructions the execution size is not limited by t
On 15 February 2017 at 19:00, Matt Turner wrote:
> On Wed, Feb 15, 2017 at 6:05 AM, Emil Velikov
> wrote:
>> Hi Matt,
>>
>> On 14 February 2017 at 23:58, Matt Turner wrote:
>>> The --build-id=... ld flag has been present since binutils-2.18,
>>> released 28 Aug 2007.
>>> ---
>>> src/intel/vulk
Series is
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
To hopefully make progress towards landing support for OA unit metrics exposed
via INTEL_performance_query the idea here is to first just tackle upstreaming
the backend rework with an initial implementation supporting pipeline
statistics.
In case anyone wants to look ahead, my branch with these pa
This adds a bare-bones backend for the INTEL_performance_query extension
that exposes pipeline statistics.
Although this could be considered redundant given that the same
statistics are already available via query objects, they are a simple
starting point for this extension and it's expected to be
Instead of using the same backend interface as AMD_performance_monitor
this defines a dedicated INTEL_performance_query interface that is
modelled more on the ARB_query_buffer_object interface (considering the
similarity of the extensions) with the addition of vfuncs for
initializing and enumeratin
To allow the backend interfaces for AMD_performance_monitor and
INTEL_performance_query to evolve independently based on the more
specific requirements of each extension this starts by separating
the frontends of these extensions.
Even though there wasn't much tying these frontends together, this
I won't have time for the next 2 weeks, but after that I'll propose a file
formatted in a way that is both easy to parse and easy to edit by a human.
2017-02-12 21:58 GMT-05:00 Jason Ekstrand :
> I'm certainly not opposed. I've considered adding such a tracking file
> for a while. I'm not sure
On Wed 15 Feb 2017, Emil Velikov wrote:
> On 14 February 2017 at 21:02, Chad Versace wrote:
> > On Tue 14 Feb 2017, Kenneth Graunke wrote:
> >> On Tuesday, February 14, 2017 12:38:45 PM PST Chad Versace wrote:
> >> > On Tue 14 Feb 2017, Matt Turner wrote:
> >> >
> >> >
> >> > > static bool
> >> >
On Wed, Feb 15, 2017 at 1:54 PM, Chad Versace
wrote:
> On Wed 15 Feb 2017, Emil Velikov wrote:
> > On 14 February 2017 at 21:02, Chad Versace
> wrote:
> > > On Tue 14 Feb 2017, Kenneth Graunke wrote:
> > >> On Tuesday, February 14, 2017 12:38:45 PM PST Chad Versace wrote:
> > >> > On Tue 14 Feb
move util/u_upload_mgr.h inside extern "C"
---
src/gallium/drivers/swr/swr_context.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/swr_context.cpp
b/src/gallium/drivers/swr/swr_context.cpp
index 2e37bac..04ff146 100644
--- a/src/gallium/drivers/swr/
I'd rather see the remainder of the headers fixed to be includable
from C++ contexts. extern "C" { #include } is an anti-pattern...
-ilia
On Wed, Feb 15, 2017 at 5:23 PM, George Kyriazis
wrote:
> move util/u_upload_mgr.h inside extern "C"
> ---
> src/gallium/drivers/swr/swr_context.cpp | 2 +-
On 16/02/17 03:37, Emil Velikov wrote:
On 9 February 2017 at 13:35, Emil Velikov wrote:
From: Emil Velikov
No other env var used in mesa allows for space in the variable contents.
Signed-off-by: Emil Velikov
---
Worth documenting and/or even renaming them ?
Tim, with the documentation goin
You mean use extern "C" (inside a c++ guard) on u_upload_mgr.h and friends?
Thanks,
George
> -Original Message-
> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
> Mirkin
> Sent: Wednesday, February 15, 2017 4:25 PM
> To: Kyriazis, George
> Cc: mesa-dev@lists.free
Yeah, just like all the other headers:
#ifdef __cplusplus
extern "C" {
#endif
define api's
#ifdef __cplusplus
}
#endif
You can see examples in, e.g., u_bitcast.h (picked one at random).
On Wed, Feb 15, 2017 at 5:45 PM, Kyriazis, George
wrote:
> You mean use extern "C" (inside a c++ guard) on
---
src/compiler/glsl/glsl_to_nir.cpp | 38 +++---
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index 96d8164..e46fe2c 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/
Each of the pop functions (and push_else) take a control flow parameter as
their second argument. If NULL, it assumes that the builder is in a block
that's a direct child of the control-flow node you want to pop off the
virtual stack. This is what 90% of consumers will want. The SPIR-V pass,
how
---
src/compiler/nir/nir_lower_indirect_derefs.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/src/compiler/nir/nir_lower_indirect_derefs.c
b/src/compiler/nir/nir_lower_indirect_derefs.c
index 09cc9a3..52adde8 100644
--- a/src/compiler/nir/nir_lower_indi
I was looking at Ian's int64 lowering code last night and was thinking
about what the lowering would look like in NIR. The fact that it uses
loops and other control flow for handling division got me thinking about
doing control flow in nir_builder again. So I spent a little time this
morning and
---
src/compiler/nir/nir_lower_gs_intrinsics.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/compiler/nir/nir_lower_gs_intrinsics.c
b/src/compiler/nir/nir_lower_gs_intrinsics.c
index 3acb742..68e20dd 100644
--- a/src/compiler/nir/nir_lower_gs_intrinsics.c
+++ b/
---
src/compiler/spirv/vtn_cfg.c | 45 ++--
1 file changed, 14 insertions(+), 31 deletions(-)
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 3a31657..54248b1 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/
1 - 100 of 130 matches
Mail list logo
