We plan to proceed with the branch rename tomorrow mid-day (US Pacific
time) tomorrow, May 5.
If all goes well, this MR will merge,
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10474
and the master branch will be locked from further changes.
The main branch will then be created
On Tue, May 4, 2021 at 12:16 PM Marek Olšák wrote:
>
> 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
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
On Tue, May 04, 2021 at 02:48:35PM +0200, Christian König wrote:
> Am 04.05.21 um 13:13 schrieb Daniel Vetter:
> > On Tue, May 4, 2021 at 12:53 PM Christian König
> > wrote:
> > > Am 04.05.21 um 11:47 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > > Yeah, it just takes to long for the preemption
Am 04.05.21 um 13:13 schrieb Daniel Vetter:
On Tue, May 4, 2021 at 12:53 PM Christian König
wrote:
Am 04.05.21 um 11:47 schrieb Daniel Vetter:
[SNIP]
Yeah, it just takes to long for the preemption to complete to be really
useful for the feature we are discussing here.
As I said when the
On Tue, May 4, 2021 at 12:53 PM Christian König
wrote:
>
> Am 04.05.21 um 11:47 schrieb Daniel Vetter:
> > [SNIP]
> >> Yeah, it just takes to long for the preemption to complete to be really
> >> useful for the feature we are discussing here.
> >>
> >> As I said when the kernel requests to
Am 04.05.21 um 11:47 schrieb Daniel Vetter:
[SNIP]
Yeah, it just takes to long for the preemption to complete to be really
useful for the feature we are discussing here.
As I said when the kernel requests to preempt a queue we can easily expect a
timeout of ~100ms until that comes back. For
On Tue, May 04, 2021 at 11:14:06AM +0200, Christian König wrote:
> Am 04.05.21 um 10:27 schrieb Daniel Vetter:
> > On Tue, May 4, 2021 at 10:09 AM Christian König
> > wrote:
> > > Am 04.05.21 um 09:32 schrieb Daniel Vetter:
> > > > On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote:
Am 04.05.21 um 10:27 schrieb Daniel Vetter:
On Tue, May 4, 2021 at 10:09 AM Christian König
wrote:
Am 04.05.21 um 09:32 schrieb Daniel Vetter:
On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote:
Unfortunately as I pointed out to Daniel as well this won't work 100%
reliable
On Tue, May 4, 2021 at 10:09 AM Christian König
wrote:
>
> Am 04.05.21 um 09:32 schrieb Daniel Vetter:
> > On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote:
> >> Unfortunately as I pointed out to Daniel as well this won't work 100%
> >> reliable either.
> > You're claiming this,
Am 04.05.21 um 09:32 schrieb Daniel Vetter:
On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote:
Unfortunately as I pointed out to Daniel as well this won't work 100%
reliable either.
You're claiming this, but there's no clear reason why really, and you
did't reply to my last mail
On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote:
> Unfortunately as I pointed out to Daniel as well this won't work 100%
> reliable either.
You're claiming this, but there's no clear reason why really, and you
did't reply to my last mail on that sub-thread, so I really don't get
Unfortunately as I pointed out to Daniel as well this won't work 100%
reliable either.
See the signal on the ring buffer needs to be protected by manipulation
from userspace so that we can guarantee that the hardware really has
finished executing when it fires.
Protecting memory by
13 matches
Mail list logo
