We currently handle this by lowering it to a uniform for gen8+ but
the SPIR-V path generates this as a system value, so handle that
case as well.
---
src/mesa/drivers/dri/i965/brw_tcs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c
This intrinsic is produced to load SYSTEM_VALUE_VERTICES_IN, which is
generated to load gl_PatchVerticesIn in the SPIR-V path for both
Vulkan and OpenGL.
---
src/compiler/nir/nir_gather_info.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compiler/nir/nir_gather_info.c
b/src/compiler/ni
https://bugs.freedesktop.org/show_bug.cgi?id=103699
--- Comment #11 from Tapani Pälli ---
Created attachment 135512
--> https://bugs.freedesktop.org/attachment.cgi?id=135512&action=edit
test case
Could you please compile and run this test application and attach what is
prints? Does it create a
https://bugs.freedesktop.org/show_bug.cgi?id=103757
--- Comment #10 from Pekka Paalanen ---
(In reply to Michael Olbrich from comment #9)
> (In reply to Pekka Paalanen from comment #1)
> > Any reason you cannot use EGL_KHR_platform_wayland?
>
> It's not my code. It's somewhere in gstreamer-vaapi
https://bugs.freedesktop.org/show_bug.cgi?id=103586
--- Comment #14 from Jan Vesely ---
(In reply to Dave Gilbert from comment #12)
>
> It doesn't seem to help, if I add:
> --- a/ocl.cpp
> +++ b/ocl.cpp
> @@ -74,6 +74,7 @@ static int got_dev(cl::Platform &plat,
> std::vector &devices, cl::Dev
>
On Wed, Nov 15, 2017 at 5:10 PM, Dylan Baker wrote:
> This patch checks for an and then enables sse4.1 optimizations if the
> host machine will be x86/x86_64.
There's some stack realignment stuff that probably needs to stay, but
depending on what gcc version we require we can just always enable S
https://bugs.freedesktop.org/show_bug.cgi?id=103128
Nicolai Hähnle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=103674
Nicolai Hähnle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
These are all either done already, or are autotools specific. The
misspelled gallium G3DVL is the autotools specific bit, meson is
handling that via build_by_default.
Signed-off-by: Dylan Baker
---
meson.build | 15 ---
1 file changed, 15 deletions(-)
diff --git a/meson.build b/meso
This function is required for both the Intel "Anvil" vulkan driver and
the i965 GL driver. Error out if either of those is enabled but this
function isn't found.
Signed-off-by: Dylan Baker
---
meson.build | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meson.build b/mes
This patch allows building asm for x86 on x86_64 platforms, when the
operating system is the same. Previously cross compile always turned off
assembly. This allows using a cross file to cross compile x86 binaries
on x86_64 with asm.
This could probably be relaxed further thanks to meson's "exe_wra
This patch checks for an and then enables sse4.1 optimizations if the
host machine will be x86/x86_64.
Signed-off-by: Dylan Baker
---
meson.build | 27 ++-
src/mesa/meson.build | 14 +++---
2 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/m
Quoting Timothy Arceri (2017-11-15 16:16:10)
> This was left out of c980a3aa3133
> ---
> src/mesa/state_tracker/st_program.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_program.c
> b/src/mesa/state_tracker/st_program.c
> index 97b
This was left out of c980a3aa3133
---
src/mesa/state_tracker/st_program.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index 97b2e1234b..dc81a17289 100644
--- a/src/mesa/state_tracker/st_pr
For checking that bitfields are large enough to hold the largest
expected value.
v2: move into existing util/macros.h header where STATIC_ASSERT() lives.
---
src/util/macros.h | 16
1 file changed, 16 insertions(+)
diff --git a/src/util/macros.h b/src/util/macros.h
index a9a52a1
Folks,
If you have feedback or questions, you can mail them to i...@lunarg.com
Karen Ghavam
CEO and Engineering Director
LunarG, Inc. - 3D Graphics Software Innovations
ka...@lunarg.com
970-988-9043
On Wed, Nov 15, 2017 at 1:32 PM, Pierre-Loup A. Griffais <
pgriff...@valvesoftware.com> wrote:
>
On 16/11/17 00:22, Eduardo Lima Mitev wrote:
From: Nicolai Hähnle
---
src/mesa/main/mtypes.h| 1 +
src/mesa/main/shaderapi.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 1c953b83155..cfc763f043e 100644
--- a/src/mesa/main/
https://bugs.freedesktop.org/show_bug.cgi?id=103412
Brian Paul changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
while timespec_get() is supposed to hide OS differences, compatibility doesn't
cover old OSes (like CentOS 6) where timespec_get() does not exist.
Fall back to using os_get_time_nano(), but separate out the functionality
that populates struct timespec, so it can also be called from
_util_queue_fen
On 16/11/17 00:22, Eduardo Lima Mitev wrote:
This will be used by the linker code to dfferentiate between
programs made out of SPIR-V or GLSL shaders.
So far everywhere this is used it seems you could just do something like:
if (shProg->_LinkedShaders[stage]->spirv_data)
... spriv stuff ..
On 2017-11-15 08:35, Nicolai Hähnle wrote:
From: Nicolai Hähnle
v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
Cc: Jon Turney
Cc: Rob Herring
Cc: Alexander von Gluck IV
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 c
From: Dave Airlie
This just uses the vulkan api to get the fd from the memory.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_wsi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index e4f7fa7..3cf0cb
On Wed, Nov 15, 2017 at 5:49 PM, Nanley Chery wrote:
> On Wed, Nov 15, 2017 at 12:08:58PM -0500, Ilia Mirkin wrote:
>> On Wed, Nov 15, 2017 at 11:54 AM, Juan A. Suarez Romero
>> wrote:
>> > From section 8.7, page 179 of OpenGL ES 3.2 spec:
>> >
>> > An INVALID_OPERATION error is generated by Co
From: Dave Airlie
We ignore layout currently, not sure what would be correct to pass.
(this is based on Jason's last wsi rfc)
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_meta.h | 4
src/amd/vulkan/radv_meta_copy.c | 20
src/amd/vulkan/radv_wsi.c |
On Wed, Nov 15, 2017 at 12:08:58PM -0500, Ilia Mirkin wrote:
> On Wed, Nov 15, 2017 at 11:54 AM, Juan A. Suarez Romero
> wrote:
> > From section 8.7, page 179 of OpenGL ES 3.2 spec:
> >
> > An INVALID_OPERATION error is generated by CompressedTexImage3D
> > if internalformat is one of the the
From: Dave Airlie
This just seems cleaner, and we may expand this in future.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_wsi.c | 3 ++-
src/intel/vulkan/anv_wsi.c | 3 ++-
src/vulkan/wsi/wsi_common.h | 4 +---
src/vulkan/wsi/wsi_common_wayland.c | 2 +-
4 file
On 15 November 2017 at 04:40, Jason Ekstrand wrote:
> This commit significantly reworks the way prime support works and lets
> us pull it even further into radv. The old mechanism required the
> specific WSI layer to be aware of the linear shadow copy that has to be
> done in order for prime to w
2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> This is to make sure that the TS is properly flushed to memory before
> rendering to a new surface starts.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_emit.c | 5 +
2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> Sampler TS introduces yet another format enumeration for
> renderable+textureable formats. Introduce it into the etnaviv_format
> table as another column.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
>
2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> Resources only need a resolve-to-itself if their TS is valid for any
> level, not just if it happens to be allocated.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_r
https://bugs.freedesktop.org/show_bug.cgi?id=100151
--- Comment #12 from Pradeep Yadav ---
As I mentioned while filing this defect that Mesa's classic software rasterizer
has no such black window issue. So we have potential temporary solution for our
customers who are using older Linux versions.
On Wednesday, 2017-11-15 20:59:18 +, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Tested with Travis and Appveyor.
>
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
> v3: use check_functions in Scons (Eric)
>
> Cc: Rob Herring
> Cc: Alexander von Gluck IV
> Bugzilla: https://
This looks at prog->*. You don't get to do that unless you listen to
BRW_NEW_*_PROGRAM, which is a superset of the cases where
BRW_NEW_*_PROG_DATA is flagged.
---
src/mesa/drivers/dri/i965/gen7_l3_state.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_l3_s
This should make scons work correctly on every platform, so:
Reviewed-by: Dylan Baker
Quoting Nicolai Hähnle (2017-11-15 12:58:12)
> From: Nicolai Hähnle
>
> Tested with Travis and Appveyor.
>
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
> v3: use check_functions in Scons (Eric)
>
On Wednesday, 2017-11-15 16:51:29 +, Kai Wasserbäch wrote:
> I'm still good with this, thanks for reapplying!
To be clear, is that an ack, or an r-b? :P
>
> Eric Engestrom wrote on 14.11.2017 18:26:
> > This is a revert of Marek's 2cb9ab53dd3ae6850a26 revert.
> > It was needed to revert the
From: Nicolai Hähnle
Tested with Travis and Appveyor.
v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
v3: use check_functions in Scons (Eric)
Cc: Rob Herring
Cc: Alexander von Gluck IV
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update f
Hi Mesa-Devel,
Today we're happy to announce that we're making the LunarG driver
testing system available to the Mesa development community. We've been
using this system internally for quite some time, but we've recently
done some more work so the results could also be publicly available for
the
Quoting Ilia Mirkin (2017-11-15 09:52:06)
> On Wed, Nov 15, 2017 at 12:47 PM, Dylan Baker wrote:
> > Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
> > cannot be built without it (Because of LLVM). As far as I can tell the GLSL
> > compiler and the Intel Compiler are t
Reviewed-by: Brian Paul
On 11/15/2017 11:35 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Bugzilla:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D103128&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=xmgFa
On 15 November 2017 at 19:30, Jordan Justen wrote:
> On 2017-11-14 07:37:27, Emil Velikov wrote:
>> On 10 November 2017 at 23:39, Jordan Justen
>> wrote:
>> > On 2017-11-10 08:19:38, Emil Velikov wrote:
>> >> On 7 November 2017 at 11:54, Emil Velikov
>> >> wrote:
>> >> > From: Emil Velikov
>>
On 2017-11-14 07:37:27, Emil Velikov wrote:
> On 10 November 2017 at 23:39, Jordan Justen wrote:
> > On 2017-11-10 08:19:38, Emil Velikov wrote:
> >> On 7 November 2017 at 11:54, Emil Velikov wrote:
> >> > From: Emil Velikov
> >> >
> >> > Checking the override was useful in the early stages of d
On Tue, 2017-11-14 at 11:28 -0800, Matt Turner wrote:
> On Tue, Nov 14, 2017 at 6:37 AM, Emil Velikov
> wrote:
> > The fourth release candidate for Mesa 17.3.0 is now available.
> >
> > As per the issue tracker [1] we still have a number of outstanding bugs
> > blocking the release.
> >
> > [1]
> Sorry for noticing before, but this breaks glmark2 texture. I didn't
> yet dig into the issue but it's definitely caused by this commit.
>
> To reproduce, simply run
> glmark2-es2-drm -b texture:texture-filter=mipmap
That's weird, as that neither uses point sprites nor flat shading.
I'll have
"Mun, Gwan-gyeong" writes:
> Hi all,
>
> I am sorry that I didn't have enough discussion about why new window
> system code is needed for Tizen on mesa.
>
> This is a brief architecture of Tizen Window System.
>
>
> +-
Hi Wladimir,
Am Mittwoch, den 15.11.2017, 18:03 +0100 schrieb Wladimir J. van der Laan:
> A recent commit (see below) fixed flat shading but at the same time
> broke the use of point sprites with multiple varyings. This resulted in
> particle systems rendering wrongly.
>
> The reason for this is
https://bugs.freedesktop.org/show_bug.cgi?id=103128
--- Comment #2 from Nicolai Hähnle ---
https://patchwork.freedesktop.org/patch/188544/ fixes this for me.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
From: Nicolai Hähnle
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103128
Fixes: cad959d90145 ("gallium: add LDEXP TGSI instruction and corresponding
cap")
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxilia
On 15/11/2017 14:35, Nicolai Hähnle wrote:
From: Nicolai Hähnle
v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
Cc: Jon Turney
Cc: Rob Herring
Cc: Alexander von Gluck IV
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 c
Quoting Nicolai Hähnle (2017-11-15 06:35:49)
> From: Nicolai Hähnle
>
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
>
> Cc: Jon Turney
> Cc: Rob Herring
> Cc: Alexander von Gluck IV
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
> Fixes: f1a364878431 ("threads: upd
On Wed, Nov 15, 2017 at 12:47 PM, Dylan Baker wrote:
> Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
> cannot be built without it (Because of LLVM). As far as I can tell the GLSL
> compiler and the Intel Compiler are the only C++ code in mesa not using C++11.
Actuall
On 15.11.2017 17:45, Kai Wasserbäch wrote:
Doesn't the meson.build file need the same change?
I don't really know Meson, but the master build file looks to me like
Meson always builds with C++11.
Cheers,
Nicolai
Nicolai Hähnle wrote on 15.11.2017 12:55:
From: Nicolai Hähnle
It is requi
Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
cannot be built without it (Because of LLVM). As far as I can tell the GLSL
compiler and the Intel Compiler are the only C++ code in mesa not using C++11.
Quoting Kai Wasserbäch (2017-11-15 08:45:30)
> Doesn't the meson.bu
Quoting Jon Turney (2017-11-15 02:52:29)
> I'm not sure of the reason for this. I don't see anything like this in
> configure.ac
I hadn't had a chance to test other platforms, and I wasn't sure about Windows
and Haiku. Some of the BSD's also stiil use pthread-stubs, and I don't think
those get HAV
Reviewed-by: Dylan Baker
Quoting Rafael Antognolli (2017-11-15 09:32:47)
> Xorg (and possibly other things) depend on this variable to find the
> path to DRI drivers.
>
> Signed-off-by: Rafael Antognolli
> Cc: Dylan Baker
> ---
> src/mesa/drivers/dri/meson.build | 1 +
> 1 file changed, 1 ins
Xorg (and possibly other things) depend on this variable to find the
path to DRI drivers.
Signed-off-by: Rafael Antognolli
Cc: Dylan Baker
---
src/mesa/drivers/dri/meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/meson.build b/src/mesa/drivers/dri/meson.build
On Wednesday, 2017-11-15 10:52:29 +, Jon Turney wrote:
> I'm not sure of the reason for this. I don't see anything like this in
> configure.ac
>
> In include/c11/threads.h the cases are:
>
> 1) building for Windows -> threads_win32.h
> 2) HAVE_PTHREAD -> threads_posix.h
> 3) Not supported on
On Wed, Nov 15, 2017 at 11:54 AM, Juan A. Suarez Romero
wrote:
> From section 8.7, page 179 of OpenGL ES 3.2 spec:
>
> An INVALID_OPERATION error is generated by CompressedTexImage3D
> if internalformat is one of the the formats in table 8.17 and target
> is not TEXTURE_2D_ARRAY, TEXTURE_CUB
A recent commit (see below) fixed flat shading but at the same time
broke the use of point sprites with multiple varyings. This resulted in
particle systems rendering wrongly.
The reason for this is that it set VARYING_COMPONENT_USE_POINTCOORD_[XY]
for all non-color varyings, causing them to be re
https://bugs.freedesktop.org/show_bug.cgi?id=103757
--- Comment #9 from Michael Olbrich ---
(In reply to Pekka Paalanen from comment #1)
> Any reason you cannot use EGL_KHR_platform_wayland?
It's not my code. It's somewhere in gstreamer-vaapi. I was just debugging why
my application was crashing
From section 8.7, page 179 of OpenGL ES 3.2 spec:
An INVALID_OPERATION error is generated by CompressedTexImage3D
if internalformat is one of the the formats in table 8.17 and target
is not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
An INVALID_OPERATION error is generated by
https://bugs.freedesktop.org/show_bug.cgi?id=103757
--- Comment #8 from Michael Olbrich ---
(In reply to Daniel Stone from comment #7)
> Good point - I guess it'd have to be if
> (_eglPointerIsDereferencable(child_pointer) &&
> _eglPointerIsDereferencable(((char *) child_pointer) + strlen("wl_dis
Doesn't the meson.build file need the same change?
Nicolai Hähnle wrote on 15.11.2017 12:55:
> From: Nicolai Hähnle
>
> It is required for LLVM anyway.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103658
> Fixes: 7f33e94e43a6 ("amd/addrlib: update to latest version")
> ---
> src/
I'm still good with this, thanks for reapplying!
Eric Engestrom wrote on 14.11.2017 18:26:
> This is a revert of Marek's 2cb9ab53dd3ae6850a26 revert.
> It was needed to revert the previous commit, and didn't have any issue
> itself.
> --
>
> The "DRI2" name was reported as confusing when printing
On Tue, 2017-11-14 at 16:57 -0800, Nanley Chery wrote:
> On Wed, Nov 08, 2017 at 04:52:02PM +0100, Juan A. Suarez Romero wrote:
> > From section 8.7, page 179 of OpenGL ES 3.2 spec:
> >
> > An INVALID_OPERATION error is generated by CompressedTexImage3D
> > if internalformat is one of the the
Hey Matias,
Matias N. Goldberg wrote on 15.11.2017 16:51:
>> Why, doesn't your distro have LLVM development packages?
> They aren't as up to date. Keeping up-to-date with everything mesa needs is
> exhausting.
> I started compiling LLVM from source when I needed to test an LLVM patch to
> fix a G
https://bugs.freedesktop.org/show_bug.cgi?id=103757
--- Comment #7 from Daniel Stone ---
(In reply to Michael Olbrich from comment #6)
> (In reply to Daniel Stone from comment #2)
>
> > Michael, I'll attach a compiled but untested patch; can you please let me
> > know if it helps?
>
> Looks goo
The OVERWRITE bit disables destination fetches, which is exactly what
we want when there is no valid color buffer bound.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_blend.c | 4 ++--
src/gallium/drivers/etnaviv/etnaviv_state.c | 2 +-
2 files changed, 3 insertions(+), 3 de
https://bugs.freedesktop.org/show_bug.cgi?id=103757
--- Comment #6 from Michael Olbrich ---
(In reply to Daniel Stone from comment #2)
> Michael, I'll attach a compiled but untested patch; can you please let me
> know if it helps?
Looks good. It does the right thing for wayland and drm at least
FYI:
Original Message
Subject:[Mesa-users] Thank you! Keep up the good work for older AMD
Cards!
Date: Wed, 15 Nov 2017 13:56:22 +0100
From: Thomas Zoller
To: mesa-us...@lists.freedesktop.org
Hello,
i only want to say THANK YOU to all developers for extending
Am Dienstag, den 14.11.2017, 10:21 +0100 schrieb Wladimir J. van der
Laan:
> Sampler TS introduces yet another format enumeration for
> renderable+textureable formats. Introduce it into the etnaviv_format
> table as another column.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Lucas S
Hi!
> Are you using the amdgpu kernel driver from an amdgpu-pro release or
> from the upstream Linux kernel? (If you're not sure, provide the dmesg
> output and Xorg log file)
> If the latter, can you try a 4.13 or 4.14 kernel and see if that works
> better?
I'm using upstream Linux kernel (wit
Am Dienstag, den 14.11.2017, 10:21 +0100 schrieb Wladimir J. van der
Laan:
> Resources only need a resolve-to-itself if their TS is valid for any
> level, not just if it happens to be allocated.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Lucas Stach
> ---
> src/gallium/drivers/e
Am Dienstag, den 14.11.2017, 10:21 +0100 schrieb Wladimir J. van der Laan:
> This is to make sure that the TS is properly flushed to memory before
> rendering to a new surface starts.
>
> Signed-off-by: Wladimir J. van der Laan
This seems to work as intended, at least I wasn't able to spot missi
https://bugs.freedesktop.org/show_bug.cgi?id=103757
--- Comment #5 from Daniel Stone ---
(In reply to Emil Velikov from comment #4)
>
> I do recall mentioning that exposing the same symbol(s) will lead to bad
> experiences. Followed by some ideas...
>
Yep, as per the discussion on inlining way
This deduplicates free routines of color_buffers array.
v2:
- Add clear_all argument to check clearing all of color_buffers or not.
- Fixes from Eric's review:
a) polish check routine of check_lock and color_buffers[i].locked
b) move 'native_buffer = NULL' to avoid leaking locked buffers
To share common free DRIimage code.
In preparation to adding of new platform which uses this helper.
v2:
- Fixes from Eric's review:
a) Split out series of refactor for helpers to a separate series.
b) Add the new helper function and use them to replace the old code in the
same patch
This is added for preventing adding of new color buffers structure and back*
when new platform backend is added.
This refactoring separates out the common and platform specific bits.
This makes odd casting in the platform_foo.c but it prevents adding of new
ifdef magic.
Because of color_buffers arr
https://bugs.freedesktop.org/show_bug.cgi?id=103757
--- Comment #4 from Emil Velikov ---
I do recall mentioning that exposing the same symbol(s) will lead to bad
experiences. Followed by some ideas...
WRT eglGetDisplay - I'd recommend moving towards the EGL_*_platform_*
extensions ASAP - EGL_E
On Wednesday, 2017-11-15 15:35:49 +0100, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
>
> Cc: Jon Turney
> Cc: Rob Herring
> Cc: Alexander von Gluck IV
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
> Fixes: f1a364878
For the fast path, radv_fill_buffer() ensures that the BO is
already in the list. For the slow path, the depth surface is
part of the framebuffer which means the BO is added to the list
when the framebuffer is emitted.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 2 --
1
Similar to how the driver sets the depth clear regs after a
fast depth clear. Most of the time, this will copy a 32-bit reg
instead of a 64-bit reg.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --g
Already checked in emit_clear().
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_clear.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index 7b6ab4a9b7..b42ecedfc9 100644
--- a/src/amd/vulkan/radv_meta_clear
aspects can't be zero and there is an assertion that ensures
it's not in emit_clear().
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 18503cd513..146dcf439f 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/
From: Nicolai Hähnle
v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
Cc: Jon Turney
Cc: Rob Herring
Cc: Alexander von Gluck IV
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 changes")
---
SConstruct | 7
https://bugs.freedesktop.org/show_bug.cgi?id=103732
--- Comment #5 from Michel Dänzer ---
(In reply to Andrés Gómez García from comment #4)
> FWIW, with similar conditions, I've not been able to reproduce with
> llvmpipe, softpipe nor i965.
Hmm, then maybe it is related to threading done by SWR
https://bugs.freedesktop.org/show_bug.cgi?id=103762
Andrés Gómez García changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=90081
Andrés Gómez García changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=103762
Bug ID: 103762
Summary: [swr] piglit
ext_transform_feedback-immediate-reuse-uniform-buffer
has a ~5% pass rate
Product: Mesa
Version: 17.2
Hardware: Ot
https://bugs.freedesktop.org/show_bug.cgi?id=103699
--- Comment #10 from Tapani Pälli ---
(In reply to sergio.callegari from comment #9)
> Tried right now. Incidentally, I have always been working with SNA, since it
> is fine on haswell and snappier than glamor.
>
> I still see the issue with me
On Wednesday, 2017-11-15 14:22:14 +0100, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro
>
> Ideally this should be generated somehow. One option would be gather
> all the extension dependencies listed on the core grammar, but there
> would be the possibility of not including some of the exte
On Wednesday, 2017-11-15 14:22:13 +0100, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro
>
> ---
> src/mapi/glapi/gen/ARB_spirv_extensions.xml | 13
> src/mapi/glapi/gen/Makefile.am | 1 +
> src/mapi/glapi/gen/gl_API.xml | 2 ++
> src/mesa/Makefile.sourc
https://bugs.freedesktop.org/show_bug.cgi?id=103699
--- Comment #9 from sergio.calleg...@gmail.com ---
Tried right now. Incidentally, I have always been working with SNA, since it is
fine on haswell and snappier than glamor.
I still see the issue with mesa as of
17.4 git snapshot taken on 17/11/
On Wednesday, 2017-11-15 13:17:25 +, Rogovin, Kevin wrote:
> Thanks, I missed that; sorry for the mailing list chatter caused by
> missing the original e-mail on the material.
No worries, there's a lot of traffic, I'm pretty sure nobody read every
single emails of these lists :P
> -Kevin
>
On Wednesday, 2017-11-15 14:22:04 +0100, Eduardo Lima Mitev wrote:
> From: Nicolai Hähnle
>
> ---
> src/mapi/glapi/gen/ARB_gl_spirv.xml | 21 ++
> src/mapi/glapi/gen/Makefile.am | 1 +
> src/mapi/glapi/gen/gl_API.xml | 4 +++
> src/mapi/glapi/gen/gl_genexec.p
https://bugs.freedesktop.org/show_bug.cgi?id=103732
--- Comment #4 from Andrés Gómez García ---
FWIW, with similar conditions, I've not been able to reproduce with llvmpipe,
softpipe nor i965.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for t
https://bugs.freedesktop.org/show_bug.cgi?id=103128
--- Comment #1 from Nicolai Hähnle ---
I can reproduce this, will take a look now.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mes
https://bugs.freedesktop.org/show_bug.cgi?id=102122
--- Comment #1 from Nicolai Hähnle ---
I cannot reproduce this on Mesa master by running:
$ GALLIUM_DRIVER=softpipe LIBGL_ALWAYS_SOFTWARE=true ./bin/fdo10370 -auto
What am I missing?
--
You are receiving this mail because:
You are the QA Con
https://bugs.freedesktop.org/show_bug.cgi?id=103757
--- Comment #3 from Daniel Stone ---
Created attachment 135490
--> https://bugs.freedesktop.org/attachment.cgi?id=135490&action=edit
egldisplay-try-interface-name-for-wl-display.patch
--
You are receiving this mail because:
You are the QA Co
https://bugs.freedesktop.org/show_bug.cgi?id=103757
--- Comment #2 from Daniel Stone ---
(In reply to Pekka Paalanen from comment #1)
> eglGetDisplay() is by definition broken on multi-platform implementations,
> yes.
Ugh. It is broken by definition, but Mesa does go to great lengths to try to
m
1 - 100 of 176 matches
Mail list logo
