Commit fe98aef3 authored by Rocky Automation's avatar Rocky Automation 📺
Browse files

import mesa-21.3.4-2.el9

parents
SOURCES/mesa-21.3.4.tar.xz
80187e8dd7701a931676058ce456de008fdcaf8c SOURCES/mesa-21.3.4.tar.xz
From 07dc3d4238e57901ccf98e0b506d9aad2c86b9d9 Mon Sep 17 00:00:00 2001
From: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Mon, 10 Jan 2022 17:18:05 -0800
Subject: [PATCH] iris: implement inter-context busy-tracking
Previously, no buffers were ever marked as EXEC_OBJECT_ASYNC so the
Kernel would ensure dependency tracking for us. After we implemented
explicit busy tracking in commit 89a34cb8450a, only the external
objects kept relying on the Kernel's implicit tracking and Iris did
inter-batch busy tracking, meaning we lost inter-screen and
inter-context synchronization. This seemed fine to me since, as far as
I understood, it is the duty of the application to synchronize itself
against multiple screens and contexts.
The problem here is that applications were actually relying on the old
behavior where the Kernel guarantees synchronization, so 89a34cb8450a
can be seen as a regression. This commit addresses the inter-context
synchronization case.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5731
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5812
Fixes: 89a34cb8450a ("iris: switch to explicit busy tracking")
Tested-by: Konstantin Kharlamov <hi-angel@yandex.ru>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
src/gallium/drivers/iris/iris_batch.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/iris/iris_batch.c b/src/gallium/drivers/iris/iris_batch.c
index b7bde60aae7..1b0c5896d4f 100644
--- a/src/gallium/drivers/iris/iris_batch.c
+++ b/src/gallium/drivers/iris/iris_batch.c
@@ -835,6 +835,12 @@ update_bo_syncobjs(struct iris_batch *batch, struct iris_bo *bo, bool write)
move_syncobj_to_batch(batch, &deps->write_syncobjs[other_batch_idx],
I915_EXEC_FENCE_WAIT);
+ /* If it's being written by our screen, wait on it too. This is relevant
+ * when there are multiple contexts on the same screen. */
+ if (deps->write_syncobjs[batch_idx])
+ move_syncobj_to_batch(batch, &deps->write_syncobjs[batch_idx],
+ I915_EXEC_FENCE_WAIT);
+
struct iris_syncobj *batch_syncobj = iris_batch_get_signal_syncobj(batch);
if (write) {
@@ -847,6 +853,8 @@ update_bo_syncobjs(struct iris_batch *batch, struct iris_bo *bo, bool write)
move_syncobj_to_batch(batch, &deps->read_syncobjs[other_batch_idx],
I915_EXEC_FENCE_WAIT);
+ move_syncobj_to_batch(batch, &deps->read_syncobjs[batch_idx],
+ I915_EXEC_FENCE_WAIT);
} else {
/* If we're reading, replace the other read from our batch index. */
--
GitLab
Subject: RE: Question about Mesa MLAA license
From: Jorge Jimenez <iryoku@gmail.com>
Date: 01/08/2013 12:50 PM
To: Tom Callaway <tcallawa@redhat.com>
CC: "jorge@iryoku.com" <jorge@iryoku.com>
Yes to both questions.
Thanks,
Jorge
From: Tom Callaway <tcallawa@redhat.com>
Sent: January 8, 2013 6:49 PM
To: Jorge Jimenez <iryoku@gmail.com>
CC: jorge@iryoku.com
Subject: Re: Question about Mesa MLAA license
On 01/08/2013 12:39 PM, Jorge Jimenez wrote:
> Hi Tom,
>
> What we meant with that is that we made an exception for clause 2.
> Instead of clause 2, in the case of the Mesa project, you have to name
> the technique Jimenez's MLAA in the config options of Mesa. We did that
> just to allow them to solve license issues. This exception should be for
> the Mesa project, and any project using Mesa, like Fedora.
>
> We want to widespread usage of our MLAA, so we want to avoid any kind of
> license complications. Hope current one is good for Fedora, if not
> please tell, and we'll see what we can do!
Okay, a few more questions:
* If Fedora decides to simply reproduce the quoted statement:
"Uses Jimenez's MLAA. Copyright (C) 2010 by Jorge Jimenez, Belen Masia,
Jose I. Echevarria, Fernando Navarro and Diego Gutierrez."
Specifically, if this is done as part of documentation included with
Mesa, is that sufficient to meet clause 2 even if the Mesa config option
is not set as described in your exception?
* Currently, the Mesa config option for MLAA says: "Morphological
anti-aliasing based on Jimenez\' MLAA. 0 to disable, 8 for default
quality". Is this in compliance with your exception?
Thanks again,
~tom
==
Fedora Project
Subject: RE: Question about Mesa MLAA license
From: Jorge Jimenez <iryoku@gmail.com>
Date: 01/08/2013 12:39 PM
To: "jorge@iryoku.com" <jorge@iryoku.com>, Tom Callaway <tcallawa@redhat.com>
Hi Tom,
What we meant with that is that we made an exception for clause 2.
Instead of clause 2, in the case of the Mesa project, you have to name
the technique Jimenez's MLAA in the config options of Mesa. We did that
just to allow them to solve license issues. This exception should be for
the Mesa project, and any project using Mesa, like Fedora.
We want to widespread usage of our MLAA, so we want to avoid any kind of
license complications. Hope current one is good for Fedora, if not
please tell, and we'll see what we can do!
Cheers,
Jorge
From: Tom Callaway <tcallawa@redhat.com>
Sent: January 8, 2013 6:30 PM
To: jorge@iryoku.com
Subject: Question about Mesa MLAA license
Jorge,
Thanks for all of your fantastic graphics work! I have been auditing
Fedora (a popular distribution of Linux) for license compliance and I
came across your MLAA code in Mesa.
The license says:
* 2. Redistributions in binary form must reproduce the following
statement:
*
* "Uses Jimenez's MLAA. Copyright (C) 2010 by Jorge Jimenez, Belen Masia,
* Jose I. Echevarria, Fernando Navarro and Diego Gutierrez."
*
* Only for use in the Mesa project, this point 2 is filled by naming the
* technique Jimenez's MLAA in the Mesa config options.
That wording is unclear. When you say "Only for use in the Mesa
project...", it seems like you could either be saying:
- This code may only be used as part of Mesa.
OR
- In Mesa, you can comply with clause 2 by simply selecting "Jimenez's
MLAA" in the Mesa config options.
*****
If the first item is true, then we may have to remove the MLAA code from
Fedora's copy of Mesa. However, looking at the license on your SMAA
code, I do not believe it to be the case. Please let me know either way!
Thanks in advance,
Tom Callaway
Fedora Legal
==
Fedora Project
This diff is collapsed.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment