USHRT_MAX seems too low. Traces for workstation apps create 20-30k BOs,
which is not very far from the limit. RADV doesn't suballocate BOs. Neither
GL nor VK has a ilmit on the number of BOs that can be created. The
hypothetical maximum number of BOs that can be allocated on a GPU with 32GB
of addr
On Mon, Jan 20, 2025 at 1:41 PM Simona Vetter
wrote:
> On Mon, Jan 20, 2025 at 08:58:20AM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> >
> > Am 18.01.25 um 03:37 schrieb Marek Olšák:
> > [...]
> > >
> > > 3) Implementing DRM_FORMAT_MOD_LINEAR as
15, 2025 at 12:20:07PM +, Daniel Stone wrote:
> > On Wed, 15 Jan 2025 at 04:05, Marek Olšák wrote:
> > > On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone
> wrote:
> > >> AMD hardware is the only hardware I know of which doesn't support
> > >> overalig
On Tue, Jan 14, 2025 at 1:34 PM Faith Ekstrand wrote:
> On January 14, 2025 03:39:45 Marek Olšák wrote:
>
>> I would keep the existing modifier interfaces, API extensions, and
>> expectations the same as today for simplicity.
>>
>> The new linear modifier definit
On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone wrote:
> Hi,
>
> On Tue, 14 Jan 2025 at 09:38, Marek Olšák wrote:
> > I would keep the existing modifier interfaces, API extensions, and
> expectations the same as today for simplicity.
>
> Well yes, not just for simplicity
On Tue, Jan 14, 2025 at 12:55 PM James Jones wrote:
> I don't see how that fits in the current modifier usage patterns. I'm
> not clear how applications are supposed to programmatically "look at the
> modifiers of other drivers to find commonalities," nor how that "keeps
> "expectations the same
I would keep the existing modifier interfaces, API extensions, and
expectations the same as today for simplicity.
The new linear modifier definition (proposal) will have these fields:
5 bits for log2 pitch alignment in bytes
5 bits for log2 height alignment in rows
5 bits for log2 offset
On Fri, Dec 20, 2024 at 10:24 AM Simona Vetter
wrote:
> On Thu, Dec 19, 2024 at 05:09:33PM +0100, Michel Dänzer wrote:
> > On 2024-12-19 10:02, Daniel Stone wrote:
> > >
> > > How this would be used in practice is also way too underdocumented. We
> > > need to document that exact-round-up 64b is
>
> * Modifiers must uniquely encode buffer layout. In other words, a buffer
> must
> * match only a single modifier.
>
That sentence is misleading and impossible to meet. Specifications are
sometimes changed to reflect the overwhelming reality. Multiple modifiers
can represent identical layouts
On Thu, Dec 19, 2024 at 5:32 AM Brian Starkey wrote:
> On Wed, Dec 18, 2024 at 09:53:56PM +0000, Marek Olšák wrote:
> > On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey
> wrote:
> >
> > > On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> > > >
On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey wrote:
> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> >
> > For that reason I think linear modifiers with explicit pitch/size
> > alignment constraints is a sound concept and fits into how modifiers work
> > overall.
> > -Sima
>
>
On Mon, Dec 16, 2024 at 9:53 AM Simona Vetter
wrote:
> On Mon, Dec 16, 2024 at 11:46:13AM +0100, Lucas Stach wrote:
> > Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer:
> > > On 2024-12-15 21:53, Marek Olšák wrote:
> > > > The com
On Mon, Dec 16, 2024 at 5:46 AM Lucas Stach wrote:
> Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer:
> > On 2024-12-15 21:53, Marek Olšák wrote:
> > > The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> > >
> > > Signed-off-
On Mon, Dec 16, 2024 at 4:27 AM Michel Dänzer
wrote:
> On 2024-12-15 21:53, Marek Olšák wrote:
> > The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> >
> > Signed-off-by: Marek Olšák marek.ol...@amd.com>>
> >
> > diff --git a/include/uap
Missed 2 lines from the diff:
+#define DRM_FORMAT_MOD_LINEAR_PITCH_ALIGN_128B fourcc_mod_code(NONE, 2)
+#define DRM_FORMAT_MOD_LINEAR_PITCH_ALIGN_256B fourcc_mod_code(NONE, 3)
Marek
On Sun, Dec 15, 2024 at 3:53 PM Marek Olšák wrote:
> The comment explains the problem w
The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
Signed-off-by: Marek Olšák
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 78abd819fd62e..8ec4163429014 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -484,9 +484,27
Reviewed-by: Marek Olšák
BTW, we don't have to define everything here. We can use most of the
32 values freely.
Marek
On Fri, Oct 25, 2024 at 2:03 AM Qiang Yu wrote:
>
> From: Qiang Yu
>
> This is used when radeonsi export small texture's modifier
> to user with eglE
The reason is that our DCC requires 768K alignment in some cases. I haven't
read this patch series, but one way to do that is to align to 256K,
overallocate by 512K, and then not use either 0, 256K, or 512K at the
beginning to get to 768K alignment.
Marek
On Tue, Jul 23, 2024, 11:04 Matthew Auld
AMDGPU_GEM_CREATE_GFX12_DCC is set on 90% of all memory allocations, and
almost all of them are not displayable. Shouldn't we use a different way to
indicate that we need a non-power-of-two alignment, such as looking at the
alignment field directly?
Marek
On Tue, Jul 16, 2024, 11:45 Arunpravin Pa
Hi Thomas,
FYI, this doesn't fix the issue of lightdm not being able to start for me.
Marek
Marek
On Tue, Jun 25, 2024 at 4:18 AM Thomas Zimmermann wrote:
>
> Retrieving the system framebuffer's parent device in sysfb_init()
> increments the parent device's reference count. Hence release the
Attached is the revert commit that works for me. Tested with Radeon
6800 and Radeon 7900XTX.
Marek
Marek
On Wed, Jun 19, 2024 at 9:50 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 13.06.24 um 07:59 schrieb Marek Olšák:
> > Hi Thomas,
> >
> > Commit 9eac534db0013aff9
On Thu, Jun 13, 2024 at 3:23 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 13.06.24 um 08:00 schrieb Marek Olšák:
> > +amd-gfx
> >
> > On Thu, Jun 13, 2024 at 1:59 AM Marek Olšák wrote:
> >> Hi Thomas,
> >>
> >> Commit 9eac534db0013aff9b912
+amd-gfx
On Thu, Jun 13, 2024 at 1:59 AM Marek Olšák wrote:
>
> Hi Thomas,
>
> Commit 9eac534db0013aff9b9124985dab114600df9081 as per the title
> breaks (crashes?) lightdm (login screen) such that all I get is the
> terminal. It's also reproducible with tag v6.9 where
Hi Thomas,
Commit 9eac534db0013aff9b9124985dab114600df9081 as per the title
breaks (crashes?) lightdm (login screen) such that all I get is the
terminal. It's also reproducible with tag v6.9 where the commit is
present.
Reverting the commit fixes lightdm. A workaround is to bypass lightdm
by trig
amdgpu: Make amdgpu_cs_signal_semaphore() thread-safe
Marek Olšák (2):
amdgpu: sync amdgpu_drm.h
Bump version to 2.4.121
Matt Turner (2):
symbols-check: Add _GLOBAL_OFFSET_TABLE_
symbols-check: Add _fbss, _fdata, _ftext
Pierre-Eric Pelloux-Prayer (5):
The most extreme ping-ponging is mitigated by throttling buffer moves
in the kernel, but it only works without VM_ALWAYS_VALID and you can
set BO priorities in the BO list. A better approach that works with
VM_ALWAYS_VALID would be nice.
Marek
On Wed, Apr 24, 2024 at 1:12 PM Friedrich Vock wrote
int p = -1.
unsigned u = p;
int p2 = u;
p2 is -1.
Marek
On Tue, Jan 9, 2024, 03:26 Christian König wrote:
> Am 09.01.24 um 09:09 schrieb 李真能:
>
> Thanks!
>
> What about the second patch?
>
> The second patch: amdgpu: change proirity value to be consistent with
> kernel.
>
> As I want to pass
New libdrm has been released.
Marek Olšák (2):
amdgpu: add amdgpu_va_get_start_addr
meson: bump libdrm version to 2.4.119
git tag: libdrm-2.4.119
https://dri.freedesktop.org/libdrm/libdrm-2.4.119.tar.xz
SHA256: 0a49f12f09b5b6e68eaaaff3f02ca7cff9aa926939b212d343161d3e8ac56291
libdrm
On Wed, Aug 9, 2023 at 3:35 AM Michel Dänzer wrote:
>
> On 8/8/23 19:03, Marek Olšák wrote:
> > It's the same situation as SIGSEGV. A process can catch the signal,
> > but if it doesn't, it gets killed. GL and Vulkan APIs give you a way
> > to catch the
It's the same situation as SIGSEGV. A process can catch the signal,
but if it doesn't, it gets killed. GL and Vulkan APIs give you a way
to catch the GPU error and prevent the process termination. If you
don't use the API, you'll get undefined behavior, which means anything
can happen, including pr
A screen that doesn't update isn't usable. Killing the window system
and returning to the login screen is one option. Killing the window
system manually from a terminal or over ssh and then returning to the
login screen is another option, but 99% of users either hard-reset the
machine or do sysrq+R
On Tue, Jul 25, 2023 at 4:03 AM Michel Dänzer
wrote:
>
> On 7/25/23 04:55, André Almeida wrote:
> > Hi everyone,
> >
> > It's not clear what we should do about non-robust OpenGL apps after GPU
> > resets, so I'll try to summarize the topic, show some options and my
> > proposal to move forward o
On Wed, Jul 5, 2023 at 3:32 AM Michel Dänzer wrote:
>
> On 7/5/23 08:30, Marek Olšák wrote:
> > On Tue, Jul 4, 2023, 03:55 Michel Dänzer wrote:
> > On 7/4/23 04:34, Marek Olšák wrote:
> > > On Mon, Jul 3, 2023, 03:12 Michel Dänzer > > wrote:
> >
On Tue, Jul 4, 2023, 03:55 Michel Dänzer wrote:
> On 7/4/23 04:34, Marek Olšák wrote:
> > On Mon, Jul 3, 2023, 03:12 Michel Dänzer <mailto:michel.daen...@mailbox.org>> wrote:
> > On 6/30/23 22:32, Marek Olšák wrote:
> > > On Fri, Jun 30, 2023 at 11:11
On Mon, Jul 3, 2023, 22:38 Randy Dunlap wrote:
>
>
> On 7/3/23 19:34, Marek Olšák wrote:
> >
> >
> > On Mon, Jul 3, 2023, 03:12 Michel Dänzer <mailto:michel.daen...@mailbox.org>> wrote:
> >
>
> Marek,
> Please stop sending html emails to the ma
On Mon, Jul 3, 2023, 03:12 Michel Dänzer wrote:
> On 6/30/23 22:32, Marek Olšák wrote:
> > On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer <
> michel.daen...@mailbox.org <mailto:michel.daen...@mailbox.org>> wrote:
> >> On 6/30/23 16:59, Alex Deucher wrote:
>
That's a terrible idea. Ignoring API calls would be identical to a freeze.
You might as well disable GPU recovery because the result would be the same.
There are 2 scenarios:
- robust contexts: report the GPU reset status and skip API calls; let the
app recreate the context to recover
- non-robust
On Tue, Jun 27, 2023 at 5:31 PM André Almeida
wrote:
> Hi Marek,
>
> Em 27/06/2023 15:57, Marek Olšák escreveu:
> > On Tue, Jun 27, 2023, 09:23 André Almeida > <mailto:andrealm...@igalia.com>> wrote:
> >
> > +User Mode Driver
> > +---
On Tue, Jun 27, 2023, 09:23 André Almeida wrote:
> Create a section that specifies how to deal with DRM device resets for
> kernel and userspace drivers.
>
> Acked-by: Pekka Paalanen
> Signed-off-by: André Almeida
> ---
>
> v4:
> https://lore.kernel.org/lkml/20230626183347.55118-1-andrealm...@i
On Wed, May 3, 2023, 14:53 André Almeida wrote:
> Em 03/05/2023 14:08, Marek Olšák escreveu:
> > GPU hangs are pretty common post-bringup. They are not common per user,
> > but if we gather all hangs from all users, we can have lots and lots of
> > them.
> >
> &
WRITE_DATA with ENGINE=PFP will execute the packet on the frontend engine,
while ENGINE=ME will execute the packet on the backend engine.
Marek
On Wed, May 3, 2023 at 1:08 PM Marek Olšák wrote:
> GPU hangs are pretty common post-bringup. They are not common per user,
> but if we gath
GPU hangs are pretty common post-bringup. They are not common per user, but
if we gather all hangs from all users, we can have lots and lots of them.
GPU hangs are indeed not very debuggable. There are however some things we
can do:
- Identify the hanging IB by its VA (the kernel should know it)
-
probability. No such app can be allowed to continue executing after a reset.
Marek
On Wed, Apr 26, 2023 at 5:51 AM Michel Dänzer
wrote:
> On 4/25/23 21:11, Marek Olšák wrote:
> > The last 3 comments in this thread contain arguments that are false and
> were specifically pointed out as fals
y the case. If an application has
> enabled robustness it should notice that something went wrong and act
> appropriately.
>
> The only thing we need to handle is for applications without robustness
> in case of a hard reset or otherwise it will trigger an reset over and
> over again.
ed by userspace may result in persistent corruption.
Marek
On Tue, Apr 25, 2023 at 6:27 AM Michel Dänzer
wrote:
> On 4/24/23 18:45, Marek Olšák wrote:
> > Soft resets are fatal just as hard resets, but no reset is "always
> fatal". There are cases when apps keep working
Soft resets are fatal just as hard resets, but no reset is "always fatal".
There are cases when apps keep working depending on which features are
being used. It's still unsafe.
Marek
On Mon, Apr 24, 2023, 03:03 Christian König
wrote:
> Am 24.04.23 um 03:43 schrieb André Almeida:
> > When a DRM
I don't know what iris does, but I would guess that the same problems as
with AMD GPUs apply, making GPUs resets very fragile.
Marek
On Tue., Mar. 29, 2022, 08:14 Christian König,
wrote:
> My main question is what does the iris driver better than radeonsi when
> the client doesn't support the r
I don't think fork() would work with userspace where all buffers are
shared. It certainly doesn't work now. The driver needs to be notified that
a buffer or texture is shared to ensure data coherency between processes,
and the driver must execute decompression and other render passes when a
buffer
against such behavior because it will receive them too.
I don't know if that would work with dma_fence.
Marek
On Thu, Jun 17, 2021 at 3:04 PM Daniel Vetter wrote:
> On Thu, Jun 17, 2021 at 02:28:06PM -0400, Marek Olšák wrote:
> > The kernel will know who should touch the implicit-
gt; As long as we can figure out who touched to a certain sync object last
> that
> > would indeed work, yes.
>
> Don't you need to know who will touch it next, i.e. who is holding up your
> fence? Or maybe I'm just again totally confused.
> -Daniel
>
> >
>
d that.
>
> If the hardware says that seq - 1 was written fine, but seq is missing
> then the kernel blames whoever was supposed to write seq.
>
> Just pieping the write through a privileged instance should be fine to
> make sure that we don't run into issues.
>
> Chri
Hi Daniel,
We just talked about this whole topic internally and we came up to the
conclusion that the hardware needs to understand sync object handles and
have high-level wait and signal operations in the command stream. Sync
objects will be backed by memory, but they won't be readable or writable
On Thu., Jun. 3, 2021, 15:18 Daniel Vetter, wrote:
> On Thu, Jun 3, 2021 at 7:53 PM Marek Olšák wrote:
> >
> > Daniel, I think what you are suggesting is that we need to enable user
> queues with the drm scheduler and dma_fence first, and once that works, we
> can investi
r the
hw does it. It's the same code, just in a different place.
Thanks,
Marek
On Thu, Jun 3, 2021 at 7:22 AM Daniel Vetter wrote:
> On Thu, Jun 3, 2021 at 12:55 PM Marek Olšák wrote:
> >
> > On Thu., Jun. 3, 2021, 06:03 Daniel Vetter, wrote:
> >>
> >> On T
On Thu., Jun. 3, 2021, 06:03 Daniel Vetter, wrote:
> On Thu, Jun 03, 2021 at 04:20:18AM -0400, Marek Olšák wrote:
> > On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter wrote:
> >
> > > On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote:
> > > > On Wed,
On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote:
> > On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter wrote:
> >
> > > On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote:
> > > > On Wed
On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote:
> > On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák wrote:
> >
> > > Yes, we can't break anything because we don't want to complicate things
> &
On Wed, Jun 2, 2021 at 5:44 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 02.06.21 um 10:57 schrieb Daniel Stone:
> > Hi Christian,
> >
> > On Tue, 1 Jun 2021 at 13:51, Christian König
> > wrote:
> >> Am 01.06.21 um 14:30 schrieb Daniel Vetter:
> >>> If you want to enable thi
On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák wrote:
> Yes, we can't break anything because we don't want to complicate things
> for us. It's pretty much all NAK'd already. We are trying to gather more
> knowledge and then make better decisions.
>
> The idea we a
Yes, we can't break anything because we don't want to complicate things for
us. It's pretty much all NAK'd already. We are trying to gather more
knowledge and then make better decisions.
The idea we are considering is that we'll expose memory-based sync objects
to userspace for read only, and the
On 2021-06-01 12:21 p.m., Christian König wrote:
> >>>> Am 01.06.21 um 11:02 schrieb Michel Dänzer:
> >>>>> On 2021-05-27 11:51 p.m., Marek Olšák wrote:
> >>>>>> 3) Compositors (and other privileged processes, and display
> flipping) can
e, but it's not possible to know which
process is guilty (all processes holding the buffer handle would be
suspects).
Marek
On Fri, May 28, 2021 at 6:25 PM Marek Olšák wrote:
> If both implicit and explicit synchronization are handled the same, then
> the kernel won't be able to iden
iggest problem are the sync_files for Android, since they are really
> not easy to support at all. If Android wants to support user queues we
> would probably have to do some changes there.
>
> Regards,
> Christian.
>
> Am 27.05.21 um 23:51 schrieb Marek Olšák:
>
> Hi
Hi,
Since Christian believes that we can't deadlock the kernel with some
changes there, we just need to make everything nice for userspace too.
Instead of explaining how it will work, I will explain the cases where
future hardware (and its kernel driver) will break existing userspace in
order to p
I see some mentions of XNACK and recoverable page faults. Note that all
gaming AMD hw that has userspace queues doesn't have XNACK, so there is no
overhead in compute units. My understanding is that recoverable page faults
are still supported without XNACK, but instead of the compute unit
replaying
but in the kernel without
concurrency/preemption. Is this now safe enough for dma_fence?
Marek
On Mon, May 3, 2021 at 4:36 PM Marek Olšák wrote:
> What about direct submit from the kernel where the process still has write
> access to the GPU ring buffer but doesn't use it? I
hink where that leaves us is that there is no safe place to
> create a dma_fence except for inside the ioctl which submits the work
> and only after any necessary memory has been allocated. That's a
> pretty stiff requirement. We may still be able to interact with
> userspace a bit
On Wed, Apr 28, 2021 at 5:07 AM Michel Dänzer wrote:
> On 2021-04-28 8:59 a.m., Christian König wrote:
> > Hi Dave,
> >
> > Am 27.04.21 um 21:23 schrieb Marek Olšák:
> >> Supporting interop with any device is always possible. It depends on
> which drivers we nee
On Wed., Apr. 28, 2021, 00:01 Jason Ekstrand, wrote:
> On Tue, Apr 27, 2021 at 4:59 PM Marek Olšák wrote:
> >
> > Jason, both memory-based signalling as well as interrupt-based
> signalling to the CPU would be supported by amdgpu. External devices don't
> need to
to keep the kernel out of the picture.
Marek
On Tue, Apr 27, 2021 at 3:41 PM Jason Ekstrand wrote:
> Trying to figure out which e-mail in this mess is the right one to reply
> to
>
> On Tue, Apr 27, 2021 at 12:31 PM Lucas Stach
> wrote:
> >
> > Hi,
> >
>
Supporting interop with any device is always possible. It depends on which
drivers we need to interoperate with and update them. We've already found
the path forward for amdgpu. We just need to find out how many other
drivers need to be updated and evaluate the cost/benefit aspect.
Marek
On Tue,
have the same problem in the kernel.
>
> The good news is I think we can relatively easily convert i915 and older
> amdgpu device to something which is compatible with user fences.
>
> So yes, getting that fixed case by case should work.
>
> Christian
>
> Am 27.04.21 um
e
"external -> amd" dependency too?
Marek
On Tue., Apr. 27, 2021, 08:15 Daniel Vetter, wrote:
> On Tue, Apr 27, 2021 at 2:11 PM Marek Olšák wrote:
> > Ok. I'll interpret this as "yes, it will work, let's do it".
>
> It works if all you care ab
gt;
> That could only be a problem for A+I Laptops.
>
> Memory management will just work with preemption fences which pause the
> user queues of a process before evicting something. That will be a
> dma_fence, but also a well known approach.
>
> Christian.
>
> Am 27.04.21
, 2021, 04:02 Daniel Vetter, wrote:
> On Mon, Apr 26, 2021 at 04:59:28PM -0400, Marek Olšák wrote:
> > Thanks everybody. The initial proposal is dead. Here are some thoughts on
> > how to do it differently.
> >
> > I think we can have direct command submission from users
Thanks everybody. The initial proposal is dead. Here are some thoughts on
how to do it differently.
I think we can have direct command submission from userspace via
memory-mapped queues ("user queues") without changing window systems.
The memory management doesn't have to use GPU page faults like
On Tue, Apr 20, 2021 at 2:39 PM Daniel Vetter wrote:
> On Tue, Apr 20, 2021 at 6:25 PM Marek Olšák wrote:
> >
> > Daniel, imagine hardware that can only do what Windows does: future
> fences signalled by userspace whenever userspace wants, and no kernel
> queues like we ha
Daniel, imagine hardware that can only do what Windows does: future fences
signalled by userspace whenever userspace wants, and no kernel queues like
we have today.
The only reason why current AMD GPUs work is because they have a ring
buffer per queue with pointers to userspace command buffers fol
rand:
> > > Not going to comment on everything on the first pass...
> > >
> > > On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote:
> > >> Hi,
> > >>
> > >> This is our initial proposal for explicit fences everywhere and new
> memory m
ne fences would work across processes and how
resilient they would be to segfaults.
Marek
On Mon, Apr 19, 2021 at 11:48 AM Jason Ekstrand
wrote:
> Not going to comment on everything on the first pass...
>
> On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote:
> >
> > Hi,
Hi,
This is our initial proposal for explicit fences everywhere and new memory
management that doesn't use BO fences. It's a redesign of how Linux
graphics drivers work, and it can coexist with what we have now.
*1. Introduction*
(skip this if you are already sold on explicit fences)
The curren
Hi,
I can't answer this because our Mesa team doesn't work on LLVM and we don't
build libclc.
Marek
On Thu, Mar 4, 2021 at 10:20 PM Dieter Nützel wrote:
> Hello Marek,
>
> can't compile anything, here.
> Poor Intel Nehalem X3470.
>
> Trying LLVM 12-rc2 later.
>
> Greetings,
> Dieter
>
> llvm-p
OK. Reviewed-by: Marek Olšák
Marek
On Wed, Sep 2, 2020 at 6:31 AM Bas Nieuwenhuizen
wrote:
> On Fri, Aug 7, 2020 at 9:43 PM Marek Olšák wrote:
> >
> > On Tue, Aug 4, 2020 at 5:32 PM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >
On Wed, Aug 12, 2020 at 9:54 AM Daniel Vetter wrote:
> On Tue, Aug 11, 2020 at 09:42:11AM -0400, Marek Olšák wrote:
> > There are a few cases when the flags can change, for example DCC can be
> > disabled due to a hw limitation in the 3d engine. Modifiers give the
> > misle
There are a few cases when the flags can change, for example DCC can be
disabled due to a hw limitation in the 3d engine. Modifiers give the
misleading impression that they help with that, but they don't. They don't
really help with anything.
Marek
On Mon., Aug. 10, 2020, 08:30 Christian König, <
On Tue, Aug 4, 2020 at 5:32 PM Bas Nieuwenhuizen
wrote:
> This expose modifier support on GFX9+.
>
> Only modifiers that can be rendered on the current GPU are
> added. This is to reduce the number of modifiers exposed.
>
> The HW could expose more, but the best mechanism to decide
> what to expo
TMZ is more complicated. If there is a TMZ buffer used by a command buffer,
then all other used buffers must also be TMZ or read only. If no TMZ
buffers are used by a command buffer, then TMZ is disabled. If a context is
not secure, TMZ is also disabled. A context can switch between secure and
non-
: fix unrelated changes sent with the patch
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Daniel Stone
> Cc: Bas Nieuwenhuizen
> Cc: Dave Airlie
> Cc: Marek Olšák
> ---
> include/uapi/drm/drm_fourcc.h | 15 +++
> 1 file changed, 15 in
Hi Sasha,
I disagree with this. Bumping the driver version will have implications on
other new features, because it's like an ABI barrier exposing new
functionality.
Marek
On Thu, May 7, 2020 at 10:28 AM Sasha Levin wrote:
> From: Marek Olšák
>
> [ U
On Thu., Mar. 19, 2020, 06:51 Daniel Vetter, wrote:
> On Tue, Mar 17, 2020 at 11:01:57AM +0100, Michel Dänzer wrote:
> > On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> > > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer
> wrote:
> > >> On 2020-03-16 4:50 a.m
On Tue., Mar. 17, 2020, 06:02 Michel Dänzer, wrote:
> On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer
> wrote:
> >> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
> >>> The synchronization works because the Mes
On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote:
> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
> > The synchronization works because the Mesa driver waits for idle (drains
> > the GFX pipeline) at the end of command buffers and there is only 1
> > graphics queue, so
how implicit sync works, I'd like to have it corrected. People continue
> claiming that AMD is somehow special but I have yet to grasp what makes it
> so. (Not that anyone has bothered to try all that hard to explain it.)
>
>
> --Jason
>
> On March 13, 2020 21:03:21 Mar
There is no synchronization between processes (e.g. 3D app and compositor)
within X on AMD hw. It works because of some hacks in Mesa.
Marek
On Wed, Mar 11, 2020 at 1:31 PM Jason Ekstrand wrote:
> All,
>
> Sorry for casting such a broad net with this one. I'm sure most people
> who reply will g
For Mesa, we could run CI only when Marge pushes, so that it's a strictly
pre-merge CI.
Marek
On Sat., Feb. 29, 2020, 17:20 Nicolas Dufresne,
wrote:
> Le samedi 29 février 2020 à 15:54 -0600, Jason Ekstrand a écrit :
> > On Sat, Feb 29, 2020 at 3:47 PM Timur Kristóf
> wrote:
> > > On Sat, 2020
On Wed, Oct 16, 2019 at 9:48 AM Bas Nieuwenhuizen
wrote:
> This adds initial format modifiers for AMD GFX9 and newer GPUs.
>
> This is particularly useful to determine if we can use DCC, and whether
> we need an extra display compatible DCC metadata plane.
>
> Design decisions:
> - Always expos
with kernel
Marek Olšák (5):
include: update amdgpu_drm.h
amdgpu: add amdgpu_cs_query_reset_state2 for AMDGPU_CTX_OP_QUERY_STATE2
Bump the version to 2.4.100
Revert "libdrm: remove autotools support"
Bump the version to 2.4.100 for autotools
Niclas
Let's drop this patch. Mesa will use family_id.
Marek
On Wed, Sep 18, 2019 at 4:10 PM Marek Olšák wrote:
> On Wed, Sep 18, 2019 at 10:03 AM Michel Dänzer wrote:
>
>> On 2019-09-18 1:41 a.m., Marek Olšák wrote:
>> > drmVersion::name = amdgpu, radeon, intel, etc.
>
On Wed, Sep 18, 2019 at 10:03 AM Michel Dänzer wrote:
> On 2019-09-18 1:41 a.m., Marek Olšák wrote:
> > drmVersion::name = amdgpu, radeon, intel, etc.
> > drmVersion::desc = vega10, vega12, vega20, ...
> >
> > The common Mesa code will use name and desc to select th
gt;> Am 17.09.19 um 10:17 schrieb Daniel Vetter:
> >>>>> On Tue, Sep 17, 2019 at 10:12 AM Christian König
> >>>>> wrote:
> >>>>>> Am 17.09.19 um 07:47 schrieb Jani Nikula:
> >>>>>>> On Mon, 16 Sep 2019, Marek Olšák w
1 - 100 of 554 matches
Mail list logo
