On Thu, 4 Apr 2019 at 06:54, Chia-I Wu wrote:
>
> You could end up having two virgl_hw_res with two different GEM handles
> pointing to the same kernel GEM object. That might break some assumptions
> about dependency tracking.
>
> For example, when the cmdbuf being built uses a buffer and you
Depth fast clears were unrestricted, meaning they were enabled on every
hardware generation. However, gen11+ requires some extra code to make it
work properly.
---
src/gallium/drivers/iris/iris_clear.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/iris/iris_clear.c
Reviewed-by: Bas Nieuwenhuizen
On Wed, Apr 3, 2019 at 11:17 PM Marek Olšák wrote:
>
> From: Marek Olšák
>
> ---
> src/amd/addrlib/src/gfx9/gfx9addrlib.cpp | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
>
Seems ok for now.
Reviewed-by: Timothy Arceri
On 3/4/19 10:37 pm, Samuel Pitoiset wrote:
The current algorithm only supports packing 32-bit types.
If a shader uses both 16-bit and 32-bit varyings, we shouldn't
compact them together.
Cc: Timothy Arceri
Signed-off-by: Samuel Pitoiset
---
From: Marek Olšák
---
src/amd/addrlib/src/gfx9/gfx9addrlib.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
b/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
index b3cbccf..9be775f 100644
--- a/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp
+++
You could end up having two virgl_hw_res with two different GEM handles
pointing to the same kernel GEM object. That might break some assumptions
about dependency tracking.
For example, when the cmdbuf being built uses a buffer and you want to
transfer some more data into the buffer, you
To all X.Org Foundation Members:
We're currently halfway through our annual election at 71.4% turnout. If you
haven't done so please login to https://members.x.org/, click on the Active
ballot "X.Org 2019 Elections v2 and xorg+fdo merger" and leave your vote.
In order to pass the proposed
Alyssa Rosenzweig writes:
> While a partial set of viewport system values exist, these are scalar
> values, which is a poor fit for viewport transformations on vector ISAs
> like Midgard (where the vec3 values for scale and offset each need to be
> coherent in a vec4 uniform slot to take
I also have no problems with this from the Bifrost facing side.
On Tue, Apr 2, 2019 at 7:25 PM Tomeu Vizoso
wrote:
> On 4/1/19 2:16 AM, Alyssa Rosenzweig wrote:
> > Previously, there was minimal support for interoperating with legacy
> > kernels (reusing kernel modules originally designed for
On Tue, 2 Apr 2019 at 20:00, Ian Romanick wrote:
>
> On 4/2/19 4:43 AM, Emil Velikov wrote:
> > On Tue, 2 Apr 2019 at 04:55, Dave Airlie wrote:
> >>
> >> On Tue, 2 Apr 2019 at 11:24, Dave Airlie wrote:
> >>>
> >>> Marek's commit to add ARB_parallel_shader_compile broke some es1 tests
> >>> in
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 3, 2019 at 12:13 PM Guido Günther wrote:
> Dump u.tex.first_level instead of dumping u.tex.last_level twice.
>
> Signed-off-by: Guido Günther
> ---
> src/gallium/auxiliary/util/u_dump_state.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Dump u.tex.first_level instead of dumping u.tex.last_level twice.
Signed-off-by: Guido Günther
---
src/gallium/auxiliary/util/u_dump_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_dump_state.c
b/src/gallium/auxiliary/util/u_dump_state.c
For the series:
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 3, 2019 at 11:01 AM Zhu, James wrote:
> Add memory barrier sync for multiple launch cases, and unbind completed
> resources after launch.
>
> Signed-off-by: James Zhu
> ---
> src/gallium/auxiliary/vl/vl_compositor_cs.c | 11
Add memory barrier sync for multiple launch cases, and unbind completed
resources after launch.
Signed-off-by: James Zhu
---
src/gallium/auxiliary/vl/vl_compositor_cs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c
On Wed, Apr 3, 2019 at 10:13 AM Mathias Fröhlich
wrote:
> > What is missing for merging this?
>
> I saw the pbuffer swrast crash and proposed to disable them via the
> 3rd patch that I pushed into my branch for you.
> Emil never responded to that proposal directly. In one mail he mentioned
>
From: Iago Toral Quiroga
v2:
- Adapted unit tests to make them consistent with the changes done
to the validation of half-float conversions.
v3 (Curro):
- Check all the accummulators
- Constify declarations
- Do not check src1 type in single-source instructions.
- Check for all instructions
From: Iago Toral Quiroga
v2:
- Consider implicit conversions in 2-src instructions too (Curro)
- For restrictions that involve destination stride requirements
only validate them for Align1, since Align16 always requires
packed data.
- Skip general rule for the dst/execution type size
From: Iago Toral Quiroga
v2: f32to16/f16to32 can use a :W destination (Curro)
---
src/intel/compiler/brw_fs.cpp | 71 +++
1 file changed, 71 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index d4803c63b93..48b5cc6c403
> What is missing for merging this?
I saw the pbuffer swrast crash and proposed to disable them via the
3rd patch that I pushed into my branch for you.
Emil never responded to that proposal directly. In one mail he mentioned
that he wanted to care for swrast to cope with the pbuffers. So I hoped
On Tue, Apr 2, 2019 at 2:22 PM Zhu, James wrote:
>
> Add memory barrier sync and unbind resource after launch will enhance
> the robustness.
I can't tell from the comment -- is this working around driver bugs,
or is the state tracker using the API incorrectly and this fixes the
usage. If the
On Wed, Apr 3, 2019 at 9:57 AM Ilia Mirkin wrote:
> On Wed, Apr 3, 2019 at 9:36 AM Marek Olšák wrote:
> >
> > On Wed, Apr 3, 2019 at 9:06 AM Ilia Mirkin wrote:
> >>
> >> On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák wrote:
> >> >
> >> > On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote:
> >> >>
On Wed, Apr 3, 2019 at 9:36 AM Marek Olšák wrote:
>
> On Wed, Apr 3, 2019 at 9:06 AM Ilia Mirkin wrote:
>>
>> On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák wrote:
>> >
>> > On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote:
>> >>
>> >> Ilia Mirkin writes:
>> >>
>> >> > Shouldn't this sort of
On Tue, Apr 2, 2019 at 2:22 PM Zhu, James wrote:
> Add memory barrier sync and unbind resource after launch will enhance
> the robustness.
>
> Signed-off-by: James Zhu
> ---
> src/gallium/auxiliary/vl/vl_compositor_cs.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 3, 2019 at 7:08 AM Guido Günther wrote:
> Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
>
> #0 0x in ()
> #1 0xa72a3c54 in dri2_get_fence_fd (_screen=0xed4f2090,
> _fence=0xed9ef880) at
>
What is missing for merging this?
Thanks,
Marek
On Wed, Apr 3, 2019 at 12:30 AM Mathias Fröhlich
wrote:
> Marek,
>
> On Tuesday, 2 April 2019 23:07:50 CEST Marek Olšák wrote:
> > Do you have a branch with patch 7/8 and 8/8? I'm interested in
> > EGL_EXT_platform_device on radeonsi.
>
> You can
On Wed, Apr 3, 2019 at 9:06 AM Ilia Mirkin wrote:
> On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák wrote:
> >
> > On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote:
> >>
> >> Ilia Mirkin writes:
> >>
> >> > Shouldn't this sort of decision be left up to the driver? If the
> >> > driver would like
On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák wrote:
>
> On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote:
>>
>> Ilia Mirkin writes:
>>
>> > Shouldn't this sort of decision be left up to the driver? If the
>> > driver would like to use CS for blits, fine, but why not let it blit
>> > in the most
On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote:
> Ilia Mirkin writes:
>
> > Shouldn't this sort of decision be left up to the driver? If the
> > driver would like to use CS for blits, fine, but why not let it blit
> > in the most optimal way possible and force it to use a compute shader?
>
>
Am Mittwoch, den 03.04.2019, 13:08 +0200 schrieb Guido Günther:
> Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
>
> #0 0x in ()
> #1 0xa72a3c54 in dri2_get_fence_fd (_screen=0xed4f2090,
> _fence=0xed9ef880) at
The current algorithm only supports packing 32-bit types.
If a shader uses both 16-bit and 32-bit varyings, we shouldn't
compact them together.
Cc: Timothy Arceri
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_linking_helpers.c | 10 ++
1 file changed, 10 insertions(+)
diff
Hi,
On Wed, Apr 03, 2019 at 12:43:05PM +0200, Lucas Stach wrote:
> Hi Guido,
>
> Am Montag, den 01.04.2019, 14:19 +0200 schrieb Guido Günther:
> > Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
> >
> > #0 0x in ()
> > #1 0xa72a3c54 in
Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
#0 0x in ()
#1 0xa72a3c54 in dri2_get_fence_fd (_screen=0xed4f2090,
_fence=0xed9ef880) at ../src/gallium/state_trackers/dri/dri_helpers.c:140
#2 0xa8744824 in
Hi Guido,
Am Montag, den 01.04.2019, 14:19 +0200 schrieb Guido Günther:
> Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
>
> #0 0x in ()
> #1 0xa72a3c54 in dri2_get_fence_fd (_screen=0xed4f2090,
> _fence=0xed9ef880) at
On Mon, 2019-04-01 at 12:43 -0700, Lepton Wu wrote:
>
>
> On Tue, Mar 19, 2019 at 4:29 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
> > On Mon, 2019-03-18 at 14:44 -0700, Lepton Wu wrote:
> > > virgl render complains about "Illegal resource" when running
> > > dEQP-
> >
https://bugs.freedesktop.org/show_bug.cgi?id=87738
--- Comment #6 from Jan Vesely ---
(In reply to smt from comment #5)
> Is there any progress at all towards this? I feel like it would really
> improve Linux use case for some of us using software like Darktable and
> whatever other software
Skip over non-existent files.
Signed-off-by: Jan Vesely
---
This should help detect instances of messed up/missing symbols in the driver.
windows build seems OK:
https://ci.appveyor.com/project/jvesely/mesa/builds/23550498#L1292
.../auxiliary/pipe-loader/pipe_loader.c | 5 +-
36 matches
Mail list logo
