https://bugs.freedesktop.org/show_bug.cgi?id=109140
--- Comment #2 from Hai ---
Is there any additional information needed for this bug? Thanks.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108878
Hai changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=108878
--- Comment #4 from Hai ---
Since ARB_geometry_shader4 is from OpenGL 3.2, this issue is a test case bug
rather than mesa bug. Will close it.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for
On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
> the naming is a bit confusing no matter how you look at it. Within SPIR-V
> "global" memory is memory accessible from all threads. glsl "global" memory
> normally refers to shader thread private memory declared at global scope. As
On Tue, Jan 8, 2019, 7:55 PM Ilia Mirkin On Tue, Jan 8, 2019 at 7:26 PM Marek Olšák wrote:
> >
> > On Tue, Jan 8, 2019 at 7:18 PM Ilia Mirkin wrote:
> >>
> >> On Tue, Jan 8, 2019 at 6:21 PM Marek Olšák wrote:
> >> >
> >> > On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin
> wrote:
> >> >>
> >> >>
https://bugs.freedesktop.org/show_bug.cgi?id=109242
--- Comment #9 from Roman Elshin ---
It looks like i have a same issue with rx560.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=109242
--- Comment #8 from Roman Elshin ---
Created attachment 143025
--> https://bugs.freedesktop.org/attachment.cgi?id=143025=edit
game save
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=109242
--- Comment #7 from Roman Elshin ---
Created attachment 143024
--> https://bugs.freedesktop.org/attachment.cgi?id=143024=edit
dmesg via ssh
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for
Am 07.01.19 um 09:54 schrieb Tomasz Figa:
> On Sun, Dec 23, 2018 at 12:55 AM Roland Scheidegger
> wrote:
>>
>> Alright, I guess it should work...
>>
>> Reviewed-by: Roland Scheidegger
>>
>
> Thanks!
>
> Would we have anyone who could help to commit it?
Pushed (albeit I forgot the R-b on it,
On Tue, Jan 8, 2019 at 7:26 PM Marek Olšák wrote:
>
> On Tue, Jan 8, 2019 at 7:18 PM Ilia Mirkin wrote:
>>
>> On Tue, Jan 8, 2019 at 6:21 PM Marek Olšák wrote:
>> >
>> > On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin wrote:
>> >>
>> >> Why does this need to be in p_state? And who is responsible
On Tue, Jan 8, 2019 at 7:18 PM Ilia Mirkin wrote:
> On Tue, Jan 8, 2019 at 6:21 PM Marek Olšák wrote:
> >
> > On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin wrote:
> >>
> >> Why does this need to be in p_state? And who is responsible for
> >> setting it (and how will it be set)?
> >
> >
> > Oh
On Tue, Jan 8, 2019 at 6:21 PM Marek Olšák wrote:
>
> On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin wrote:
>>
>> Why does this need to be in p_state? And who is responsible for
>> setting it (and how will it be set)?
>
>
> Oh right, there is a way to get it out of p_state.h if needed.
>
> It should
On 08/01/2019 23:54, Rhys Kidd wrote:
On Tue, 11 Dec 2018 at 10:22, Jon Turney
wrote:
Restore optional xf86vidmode, and fix the meson build to actually use it.
Jon Turney (2):
Revert "glx: make xf86vidmode mandatory for direct rendering"
Fix typo preventing xxf86vm being used in meson
On Tue, 11 Dec 2018 at 10:22, Jon Turney
wrote:
> Restore optional xf86vidmode, and fix the meson build to actually use it.
>
> Jon Turney (2):
> Revert "glx: make xf86vidmode mandatory for direct rendering"
> Fix typo preventing xxf86vm being used in meson build
>
Jon I don't believe these
On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin wrote:
> Why does this need to be in p_state? And who is responsible for
> setting it (and how will it be set)?
>
Oh right, there is a way to get it out of p_state.h if needed.
It should be set to 0 by default.
If your thread block is 8x8x1, but you
Quoting Pierre Moreau (2019-01-08 13:11:01)
> Reviewed-by: Dylan Baker
>
> Changes since:
> * v7:
> - Properly align LLVMSPIRVLib comment (Dylan Baker)
> - Only define CLOVER_ALLOW_SPIRV when **both** dependencies are found:
> autotools was only requiring one or the other.
> * v6:
Why does this need to be in p_state? And who is responsible for
setting it (and how will it be set)?
On Tue, Jan 8, 2019 at 2:47 PM Jiang, Sonny wrote:
>
> and add radeonsi support. This will be used by radeonsi internally.
>
> Signed-off-by: Sonny Jiang
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=109201
--- Comment #6 from Alexander ---
Note 2: Does not happen if i set the texture quality to low.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
On Tue, Jan 8, 2019 at 5:17 PM Marek Olšák wrote:
>
> From: Marek Olšák
>
> We have found some pipe_surface leaks internally.
>
> This is the same code as surface_destroy in radeonsi.
> Ideally, surface_destroy would be in pipe_screen.
> No, pipe_surfaces are not context objects.
>
> Cc: 18.3
Reviewed-by: Karol Herbst
Change since:
* v2: Remove the const from the length argument of clCreateProgramWithIL
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +-
src/gallium/state_trackers/clover/api/program.cpp | 8
2 files changed, 9
Reviewed-by: Karol Herbst
Changes since:
* v3: do not advertise SPIR-V support if CLOVER_ALLOW_SPIRV is not
defined
* v2: advertise cl_khr_il_program if if the device support NATIVE as IR
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/platform.cpp | 2 ++
Changes since:
* v4:
- Use is_binary_spirv and is_valid_spirv from the SPIR-V backend;
- Drop the SPIRV-Tools and llvm-spirv dependencies on clover.
* v3: guard parts of the code behind SPIR-V support
* v2:
- Remove the const on the length argument to CreateProgramWithILKHR
(Francisco
Reviewed-by: Karol Herbst
Changes since:
* v3: Use the core define instead of the extension one (Karol Herbst)
* v2: Switch from using a pointer attribute to a vector (Francisco
Jerez)
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/program.cpp | 7 +++
1 file
Reviewed-by: Karol Herbst
Changes since:
* v3: Use the core define instead of the extension one (Karol Herbst)
* v2: Throw an exception if the cl_khr_il_program extension is not
supported (Francisco Jerez)
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/device.cpp
Changes since:
* v9: Add `clover_cpp_std` to the overrides of the `libclspirv` target
in Meson.
* v7: Add DEFINES to libclspirv and libclover, in autotools, as they
would otherwise never know whether CLOVER_ALLOW_SPIRV has been
defined (Dave Airlie)
* v6: Update the dependency
Changes since:
* v6: Update the LLVM API call due to the replacement of llvm-spirv to
the new official SPIRV-LLVM-Translator.
* v5: Update Makefile.am to add to libclllvm its new llvm-spirv
dependency. (Karol Herbst)
* v3:
- guard the SPIR-V code;
- use an istringstream instead of
Reviewed-by: Dylan Baker
Changes since:
* v7:
- Properly align LLVMSPIRVLib comment (Dylan Baker)
- Only define CLOVER_ALLOW_SPIRV when **both** dependencies are found:
autotools was only requiring one or the other.
* v6: Replace the llvm-spirv repository by the new official
Reviewed-by: Karol Herbst
Signed-off-by: Pierre Moreau
---
include/CL/cl_ext.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/include/CL/cl_ext.h b/include/CL/cl_ext.h
index 5078e8f45f0..5ea49680423 100644
--- a/include/CL/cl_ext.h
+++
Reviewed-by: Francisco Jerez
Reviewed-by: Aaron Watry
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/platform.cpp | 4 ++--
src/gallium/state_trackers/clover/core/platform.cpp | 5 +
src/gallium/state_trackers/clover/core/platform.hpp | 2 ++
3 files changed, 9
Reviewed-by: Francisco Jerez
Changes since:
* v5:
- Drop the `valid_devs` argument to `validate_build_common()`
(Francisco Jerez)
- Change `clLinkProgram()` to initialise `prog`’s devices prior to
calling `validate_build_common()`.
* v2:
- validate_build_common no longer returns a
One flag that needs to be tracked is whether a library is allowed to
received mathematics optimisations or not, as the authorisation is given
when creating the library while the optimisations are specified when
creating the executable.
Reviewed-by: Aaron Watry
Changes since:
* v3: drop the
Reviewed-by: Francisco Jerez
Reviewed-by: Aaron Watry
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/api/device.cpp | 11 +--
src/gallium/state_trackers/clover/core/device.cpp | 14 ++
src/gallium/state_trackers/clover/core/device.hpp | 1 +
3 files
Reviewed-by: Aaron Watry
Reviewed-by: Karol Herbst
Changes since:
* v2:
- Dropped supported_irs() (Francisco Jerez)
- Changed supports_ir() argument type to `enum pipe_shader_ir`
(Francisco Jerez)
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/core/device.cpp | 6
From the OpenCL 1.2 Specification, Section 5.6.2 (about clBuildProgram):
> If program is created with clCreateProgramWithBinary, then the
> program binary must be an executable binary (not a compiled binary or
> library).
Reviewed-by: Aaron Watry
Signed-off-by: Pierre Moreau
---
Reviewed-by: Karol Herbst
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/Makefile.am | 11 +-
.../state_trackers/clover/Makefile.sources| 4 -
.../state_trackers/clover/core/program.cpp| 13 +-
src/gallium/state_trackers/clover/meson.build | 10 +-
Reviewed-by: Aaron Watry
Reviewed-by: Karol Herbst
Signed-off-by: Pierre Moreau
---
src/gallium/state_trackers/clover/core/device.cpp | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
If creating a library, do not allow non-compiled object in it, as
executables are not allowed, and libraries would make it really hard to
enforce the "-enable-link-options" flag.
Reviewed-by: Francisco Jerez
Reviewed-by: Aaron Watry
Changes since:
* v5: changed to accommodate the update of
From: Karol Herbst
v6: Fix return type of clCreateCommandQueueWithProperties
v2: add more prototypes
Reviewed-by: Pierre Moreau
Signed-off-by: Karol Herbst
Signed-off-by: Pierre Moreau
---
.../state_trackers/clover/api/dispatch.cpp| 29 ++-
.../state_trackers/clover/api/dispatch.hpp
Hello everyone,
The series is largely unchanged compared to the previous version, but it was
also rebased on the latest master. It would be nice to have the series merged
in for 19.0 (only three patches out of 20 are missing a review), if the series
is ready enough.
For recap since this series
Quoting Kenneth Graunke (2019-01-08 20:17:01)
> On Tuesday, January 8, 2019 3:11:37 AM PST Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > > Hi Andrii,
> > >
> > > Although I think what these patches do makes sense, I think it's missing
> > > the bigger picture.
> > >
On Tuesday, January 8, 2019 3:11:37 AM PST Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > Hi Andrii,
> >
> > Although I think what these patches do makes sense, I think it's missing
> > the bigger picture.
> > There is a lot more state that gets lost if we have to
On Tue, Jan 8, 2019 at 12:54 PM Roland Scheidegger
wrote:
> Am 08.01.19 um 17:17 schrieb Marek Olšák:
> > From: Marek Olšák
> >
> > We have found some pipe_surface leaks internally.
> >
> > This is the same code as surface_destroy in radeonsi.
> > Ideally, surface_destroy would be in
ACK
On Tue, Jan 8, 2019 at 12:27 PM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> Initialize the variable with NULL. Fixes the following
>
> In file included from ../src/compiler/nir/nir_lower_io.c:34:
> ../src/compiler/nir/nir_lower_io.c: In function
>
and add radeonsi support. This will be used by radeonsi internally.
Signed-off-by: Sonny Jiang
---
src/gallium/drivers/radeonsi/si_compute.c | 33 +++
src/gallium/include/pipe/p_state.h| 7 +
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git
On Tue, Jan 8, 2019 at 1:03 PM Karol Herbst wrote:
> On Mon, Jan 7, 2019 at 6:16 PM Jason Ekstrand
> wrote:
> >
> > On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
> >>
> >> With OpenCL some system values match the address bits, but in GLSL we
> also
> >> have some system values being 64
On Tue, Jan 8, 2019 at 1:11 AM Eero Tamminen wrote:
>
> Hi,
>
> On 8.1.2019 8.56, Stéphane Marchesin wrote:
> > Yes I think the Chrome-side is very simple here: because there isn't
> > time or means for in-depth investigation, if a driver crashes too
> > much, it gets blacklisted. The situation
On Mon, Jan 7, 2019 at 6:29 PM Jason Ekstrand wrote:
>
>
> On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
>>
>> Signed-off-by: Karol Herbst
>> ---
>> src/amd/vulkan/radv_meta_buffer.c | 8 ++--
>> src/amd/vulkan/radv_meta_bufimage.c| 28 +++---
>>
On Mon, Jan 7, 2019 at 6:16 PM Jason Ekstrand wrote:
>
> On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
>>
>> With OpenCL some system values match the address bits, but in GLSL we also
>> have some system values being 64 bit like subgroup masks.
>>
>> With this it is possible to adjust the
On Tuesday, 2019-01-08 14:30:32 +0100, Samuel Pitoiset wrote:
> Signed-off-by: Samuel Pitoiset
Acked-by: Eric Engestrom
You've inspired me, I'll send the same for anv in a bit ;)
> ---
> src/amd/vulkan/radv_android.c| 18 +--
> src/amd/vulkan/radv_cmd_buffer.c | 4 +-
>
Initialize the variable with NULL. Fixes the following
In file included from ../src/compiler/nir/nir_lower_io.c:34:
../src/compiler/nir/nir_lower_io.c: In function ‘nir_lower_explicit_io’:
../src/compiler/nir/nir.h:668:11: warning: ‘addr’ may be used uninitialized
in this function
There are two things I'd like to land prior to the branch point (as an FYI):
- Rafiel's code to stop using userptr for ANV state pools (!11)
- VK_EXT_transform_feedback (!2)
Both are pretty close at this point so I think it's feasible.
--Jason
On Tue, Jan 8, 2019 at 11:52 AM Dylan Baker
https://bugs.freedesktop.org/show_bug.cgi?id=109242
--- Comment #6 from Dmitry ---
Saving the game is not important, I started the game first and realized that
hangs in any battles. Problem new.
4.20.0-arch1-1
LLVM 7.0.1-1
I understand this is a problem with the RX460. On bug tracker has
Am 08.01.19 um 17:17 schrieb Marek Olšák:
> From: Marek Olšák
>
> We have found some pipe_surface leaks internally.
>
> This is the same code as surface_destroy in radeonsi.
> Ideally, surface_destroy would be in pipe_screen.
> No, pipe_surfaces are not context objects.
Well they are supposed
Just a reminder that the branchpoint for the 19.0 release and the first RC will
happen on January 29th. I just wanted to give an extra long heads up since many
of us are still recovering from a long holiday season ☺
Dylan
signature.asc
Description: signature
Quoting Ilia Mirkin (2019-01-08 09:12:46)
> Reviewed-by: Ilia Mirkin
>
> Thanks!
>
> On Tue, Dec 18, 2018 at 5:41 PM Dylan Baker wrote:
> >
> > This has never functioned and probably wont ever function, due to the
> > way gallium media state trackers are architected and the tegra video
> >
We've had split send instructions in the hardware since Sky Lake but
haven't bothered to wire them up yet. In order to get there, this MR adds
a new SHADER_OPCODE_SEND opcode which does a generic send without all the
special-casing in fs_generator. At the end, it switches us to sends for
surface
On 08/01/2019 17:33, Caio Marcelo de Oliveira Filho wrote:
Add unreachable case for invalid deref type. Fixes the warning below
In file included from ../src/compiler/nir/nir_lower_io.c:34:
../src/compiler/nir/nir_lower_io.c: In function ‘nir_lower_explicit_io’:
Add unreachable case for invalid deref type. Fixes the warning below
In file included from ../src/compiler/nir/nir_lower_io.c:34:
../src/compiler/nir/nir_lower_io.c: In function ‘nir_lower_explicit_io’:
../src/compiler/nir/nir.h:668:11: warning: ‘addr’ may be used uninitialized
in
For both, Reviewed-by: Brian Paul
On 01/08/2019 08:57 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_cb_eglimage.c | 11 +
> src/mesa/state_tracker/st_manager.c | 32 -
> src/mesa/state_tracker/st_manager.h | 6 +
LGTM. Reviewed-by: Brian Paul
On 01/08/2019 09:17 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> We have found some pipe_surface leaks internally.
>
> This is the same code as surface_destroy in radeonsi.
> Ideally, surface_destroy would be in pipe_screen.
> No, pipe_surfaces are not context
https://bugs.freedesktop.org/show_bug.cgi?id=109249
Jason Ekstrand changed:
What|Removed |Added
CC||i...@freedesktop.org
--- Comment #2
https://bugs.freedesktop.org/show_bug.cgi?id=109249
Samuel Pitoiset changed:
What|Removed |Added
CC||samuel.pitoi...@gmail.com
---
Reviewed-by: Ilia Mirkin
Thanks!
On Tue, Dec 18, 2018 at 5:41 PM Dylan Baker wrote:
>
> This has never functioned and probably wont ever function, due to the
> way gallium media state trackers are architected and the tegra video
> decoder is architected.
>
> Cc: Thierry Reding
> Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=109249
Bug ID: 109249
Summary: vkd3d test failures related to ordered/unordered
comparisons in test_shader_instructions()
Product: Mesa
Version: git
Hardware: All
From: Indrajit Das
Date: Thu, 3 Jan 2019 14:36:33 +0530
Subject: [PATCH] st/va: Return correct status from vlVaQuerySurfaceStatus
This ensures that during encoding, applications can get
the correct status of the surface before submitting
more operations on the same.
Reviewed-by: Leo Liu
Awesome, thanks for the update :)
On Tue, 2019-01-08 at 11:47 +0200, Danylo Piliaiev wrote:
> Hi, Thanks!
>
> I finally got CI results with ALL relevant tests and my
> implementation works on everything but Haswell.
> So I'll fix whatever is wrong there (hope that's just something
> small) and
Quoting Dylan Baker (2018-12-18 14:39:59)
> This has never functioned and probably wont ever function, due to the
> way gallium media state trackers are architected and the tegra video
> decoder is architected.
>
> Cc: Thierry Reding
> Fixes: 1755f608f5201e0a23f00cc3ea1b01edd07eb6ef
>
https://bugs.freedesktop.org/show_bug.cgi?id=109242
--- Comment #5 from Samuel Pitoiset ---
Where is the savegame? Also what kernel and llvm versions are you using? The
ones provided by Arch Linux?
I have just tried to reproduce GPU hangs on my side by playing around few
minutes, no success.
On Tue, Jan 8, 2019 at 6:16 PM Chris Wilson
wrote:
> Quoting andrey simiklit (2019-01-08 16:00:45)
> > On Tue, Jan 8, 2019 at 1:11 PM Chris Wilson
> wrote:
> >
> > Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > > Hi Andrii,
> > >
> > > Although I think what these patches do
From: Marek Olšák
We have found some pipe_surface leaks internally.
This is the same code as surface_destroy in radeonsi.
Ideally, surface_destroy would be in pipe_screen.
No, pipe_surfaces are not context objects.
Cc: 18.3 19.0
---
src/gallium/auxiliary/util/u_inlines.h | 19
Quoting andrey simiklit (2019-01-08 16:00:45)
> On Tue, Jan 8, 2019 at 1:11 PM Chris Wilson wrote:
>
> Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > Hi Andrii,
> >
> > Although I think what these patches do makes sense, I think it's missing
> > the bigger picture.
>
Thanks! I've played around with this a bit and it looks like it's behaving
how I'd expect.
One comment inline below...
On Tue, 8 Jan 2019 at 15:17, Samuel Pitoiset
wrote:
> A simple Vulkan extension that allows apps to query size and
> usage of all exposed memory heaps.
>
> The different usage
On Tue, Jan 8, 2019 at 1:11 PM Chris Wilson
wrote:
> Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > Hi Andrii,
> >
> > Although I think what these patches do makes sense, I think it's missing
> > the bigger picture.
> > There is a lot more state that gets lost if we have to revert all of
From: Marek Olšák
---
src/mesa/state_tracker/st_cb_texture.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 45918e425ac..ff4694da9e0 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
From: Marek Olšák
---
src/mesa/state_tracker/st_cb_eglimage.c | 11 +
src/mesa/state_tracker/st_manager.c | 32 -
src/mesa/state_tracker/st_manager.h | 6 +
3 files changed, 28 insertions(+), 21 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=109153
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
A simple Vulkan extension that allows apps to query size and
usage of all exposed memory heaps.
The different usage values are not really accurate because
they are per drm-fd, but they should be close enough.
v2: - add software counters for the different heaps in the winsys
- improve
The Vulkan spec 1.1.97 says:
"variablePointers specifies whether the implementation supports
the SPIR-V VariablePointers capability. When this feature is
not enabled, shader modules must not declare the
VariablePointers capability."
As the SPIR-V feature is enabled, we should turn
https://bugs.freedesktop.org/show_bug.cgi?id=109242
--- Comment #4 from Dmitry ---
Any heavy scene, for example fight with the first Griffin on a plot.
https://www.youtube.com/watch?v=0J9qnKeID0s
Yes I can. It hangs in the fight.
dmesg is not done because I do a physical reboot.
--
You are
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_android.c| 18 +--
src/amd/vulkan/radv_cmd_buffer.c | 4 +-
src/amd/vulkan/radv_descriptor_set.c | 22 ++--
src/amd/vulkan/radv_device.c | 176 +--
src/amd/vulkan/radv_formats.c| 82
On 08/01/2019 11:11, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-01-08 11:03:26)
Hi Andrii,
Although I think what these patches do makes sense, I think it's missing
the bigger picture.
There is a lot more state that gets lost if we have to revert all of the
emitted commands.
A quick
Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> Hi Andrii,
>
> Although I think what these patches do makes sense, I think it's missing
> the bigger picture.
> There is a lot more state that gets lost if we have to revert all of the
> emitted commands.
> A quick look at
Hi Andrii,
Although I think what these patches do makes sense, I think it's missing
the bigger picture.
There is a lot more state that gets lost if we have to revert all of the
emitted commands.
A quick look at brw_upload_pipeline_state() shows all of the programs
could be invalid as well, or
Reviewed-by: Iago Toral Quiroga
On Mon, 2019-01-07 at 16:11 +0200, Andres Gomez wrote:
> The check for location aliasing was always asuming output variables
> but this validation is also called for input variables.
>
> Fixes: e2abb75b0e4 ("glsl/linker: validate explicit locations for SSO
>
On Thursday, 2018-12-20 10:02:35 +, Silvestrs Timofejevs wrote:
> Feature to print out EGL returned configs for debug purposes.
>
> 'eglChooseConfig' and 'eglGetConfigs' debug information printout is
> enabled when the log level equals '_EGL_DEBUG'. The configs are
> printed, and if any of
On Monday, 2019-01-07 12:43:54 -0800, Dylan Baker wrote:
> Quoting Andres Gomez (2019-01-07 05:49:00)
> > The property is supported by the most of the editors, but not all:
> > https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties#max_line_length
> >
> > Cc: Eric Engestrom
>
Hi all,
Could somebody take a look at this patch?
Regards,
Andrii.
On Mon, Nov 19, 2018 at 11:19 PM wrote:
> From: Andrii Simiklit
>
> This patch is needed to avoid missing 3DSTATE_URB_* commands in a batch
> after
> rollback operation.
>
> To be able to test easily this issue
> the
Hi all,
Could somebody take a look at this patch?
Regards,
Andrii.
On Mon, Nov 19, 2018 at 11:19 PM wrote:
> From: Andrii Simiklit
>
> This patch is needed to avoid incorrect value of StreamOffset flag
> in 3DSTATE_SO_BUFFER command after rollback operation.
>
> To be able to test easily
Hi, Thanks!
I finally got CI results with ALL relevant tests and my implementation
works on everything but Haswell.
So I'll fix whatever is wrong there (hope that's just something small)
and send the final version.
There are still some tests for VK-GL-CTS which are not merged in master e.g.
On January 7, 2019 5:07:34 PM UTC, Andres Gomez wrote:
> As suggested by Emil Velikov.
>
> Cc: Dylan Baker
> Cc: Juan A. Suarez
> Cc: Emil Velikov
> Signed-off-by: Andres Gomez
Reviewed-by: Eric Engestrom
> ---
> docs/release-calendar.html | 10 ++
> docs/releasing.html
On Mon, 7 Jan 2019 at 17:20, Samuel Pitoiset
wrote:
>
> On 1/7/19 6:06 PM, Alex Smith wrote:
>
> Hi Samuel,
>
> Thanks for implementing this - I've been wanting this extension for a
> while so it's good it's finally available.
>
> This is just reporting the total heap sizes as the budget, which
On Wed, 2018-10-17 at 14:58 +0300, Danylo Piliaiev wrote:
> This series implement VK_KHR_draw_indirect_count and
> VK_EXT_conditional_rendering extensions.
> They are implemented together because they are highly interweaved.
>
> There are already tests in VK_CTS for VK_KHR_draw_indirect_count and
Hi,
On 8.1.2019 8.56, Stéphane Marchesin wrote:
Yes I think the Chrome-side is very simple here: because there isn't
time or means for in-depth investigation, if a driver crashes too
much, it gets blacklisted. The situation is not unique, the GPU
blacklist file is 1700 lines:
https://bugs.freedesktop.org/show_bug.cgi?id=109153
--- Comment #6 from Samuel Pitoiset ---
The following commit fixes the crash for me
commit 2f4f5a5055c74a35916645ed6eb2f8bd8ca7d221
Author: Dave Airlie
Date: Wed Jul 4 16:21:49 2018 +1000
spirv/vtn: handle variable pointers without
Thanks! Pushed.
On Mon, Jan 7, 2019 at 9:46 AM Samuel Pitoiset
wrote:
> Acked-by: Samuel Pitoiset
>
> On 1/7/19 4:39 PM, Jason Ekstrand wrote:
> > ---
> > include/vulkan/vulkan.h | 2 +-
> > include/vulkan/vulkan_android.h | 2 +-
> > include/vulkan/vulkan_core.h
Quoting Andres Gomez (2019-01-07 09:04:34)
> As suggested by Emil Velikov.
>
> Cc: Dylan Baker
> Cc: Juan A. Suarez
> Cc: Emil Velikov
> Signed-off-by: Andres Gomez
> ---
> docs/release-calendar.html | 10 ++
> docs/releasing.html| 14 --
> 2 files changed, 22
https://bugs.freedesktop.org/show_bug.cgi?id=109242
--- Comment #3 from Samuel Pitoiset ---
Can you explain how to reproduce? Can you upload a savegame? Is there anything
in dmesg when it hangs?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact
97 matches
Mail list logo
