search for: deathsimpl

Am 23.07.2014 09:31, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig > <deathsimple at vodafone.de> wrote: >> It's not a locking problem I'm talking about here. Radeons lockup handling >> kicks in when anything calls into the driver from the outside, if you have a >> fence wait function that's called from the outside but doesn't handle >&gt...

...g is locked up and we don't get a chance to recover. Christian. Am 23.07.2014 09:51, schrieb Maarten Lankhorst: > op 23-07-14 09:37, Christian K?nig schreef: >> Am 23.07.2014 09:31, schrieb Daniel Vetter: >>> On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig >>> <deathsimple at vodafone.de> wrote: >>>> It's not a locking problem I'm talking about here. Radeons lockup handling >>>> kicks in when anything calls into the driver from the outside, if you have a >>>> fence wait function that's called from the outside but do...

Am 23.07.2014 10:07, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 9:58 AM, Christian K?nig > <deathsimple at vodafone.de> wrote: >> Just imagine an application using prime is locking up Radeon and because of >> that gets killed by the user. Nothing else in the system would use the >> Radeon hardware any more and so radeon gets only called by another driver >> waiting patient...

Am 23.07.2014 09:06, schrieb Maarten Lankhorst: > op 23-07-14 08:52, Christian K?nig schreef: >> Am 23.07.2014 08:40, schrieb Maarten Lankhorst: >>> op 22-07-14 17:59, Christian K?nig schreef: >>>> Am 22.07.2014 17:42, schrieb Daniel Vetter: >>>>> On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig >>>>> <christian.koenig at amd.com>

On Wed, Jul 23, 2014 at 10:46 AM, Christian K?nig <deathsimple at vodafone.de> wrote: > Am 23.07.2014 10:42, schrieb Daniel Vetter: > >> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst >> <maarten.lankhorst at canonical.com> wrote: >>> >>> In this case if the sync was to i915 the i915 lockup procedure would tak...

On Tue, Jul 22, 2014 at 3:45 PM, Christian K?nig <deathsimple at vodafone.de> wrote: >> Would that be something you can agree to? > > > No, the whole enable_signaling stuff should go away. No callback from the > driver into the fence code, only the other way around. > > fence->signaled as well as fence->wait should become man...

On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig <deathsimple at vodafone.de> wrote: > It's not a locking problem I'm talking about here. Radeons lockup handling > kicks in when anything calls into the driver from the outside, if you have a > fence wait function that's called from the outside but doesn't handle > lockups you es...

op 23-07-14 09:37, Christian K?nig schreef: > Am 23.07.2014 09:31, schrieb Daniel Vetter: >> On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig >> <deathsimple at vodafone.de> wrote: >>> It's not a locking problem I'm talking about here. Radeons lockup handling >>> kicks in when anything calls into the driver from the outside, if you have a >>> fence wait function that's called from the outside but doesn't ha...

On Wed, Jul 23, 2014 at 9:58 AM, Christian K?nig <deathsimple at vodafone.de> wrote: > Just imagine an application using prime is locking up Radeon and because of > that gets killed by the user. Nothing else in the system would use the > Radeon hardware any more and so radeon gets only called by another driver > waiting patiently for radeon to...

On Wed, Jul 23, 2014 at 9:37 AM, Christian K?nig <christian.koenig at amd.com> wrote: > Am 23.07.2014 09:31, schrieb Daniel Vetter: >> On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig >> <deathsimple at vodafone.de> wrote: >>> >>> It's not a locking problem I'm talking about here. Radeons lockup >>> handling >>> kicks in when anything calls into the driver from the outside, if you >>> have a >>> fence wait function that's cal...

op 23-07-14 10:20, Christian K?nig schreef: > Am 23.07.2014 10:07, schrieb Daniel Vetter: >> On Wed, Jul 23, 2014 at 9:58 AM, Christian K?nig >> <deathsimple at vodafone.de> wrote: >>> Just imagine an application using prime is locking up Radeon and because of >>> that gets killed by the user. Nothing else in the system would use the >>> Radeon hardware any more and so radeon gets only called by another driver >>>...

Am 23.07.2014 10:54, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 10:46 AM, Christian K?nig > <deathsimple at vodafone.de> wrote: >> Am 23.07.2014 10:42, schrieb Daniel Vetter: >> >>> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst >>> <maarten.lankhorst at canonical.com> wrote: >>>> In this case if the sync was to i915 the i915 lockup procedure wo...

On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > In this case if the sync was to i915 the i915 lockup procedure would take care of itself. It wouldn't fix radeon, but it would at least unblock your intel card again. I haven't specifically added a special case to attempt to unblock external fences, but I've considered it. :-)

Am 23.07.2014 11:44, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: >> The scheduler needs to keep track of a lot of fences, so I think we'll >> have to register callbacks, not a simple wait function. We must keep >> track of all the non-i915 fences for all oustanding batches. Also, the >> scheduler

Am 22.07.2014 17:17, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 3:45 PM, Christian K?nig > <deathsimple at vodafone.de> wrote: >>> Would that be something you can agree to? >> >> No, the whole enable_signaling stuff should go away. No callback from the >> driver into the fence code, only the other way around. >> >> fence->signaled as well as fence->wai...

On Tue, Jul 22, 2014 at 5:59 PM, Christian K?nig <deathsimple at vodafone.de> wrote: > Am 22.07.2014 17:42, schrieb Daniel Vetter: > >> On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig >> <christian.koenig at amd.com> wrote: >>> >>> Drivers exporting fences need to provide a fence->signaled and a >>> f...

...is signaled or not. To guarantee that a fence is signaled after enable_signaling is called we would need to fire up a kernel thread which periodically calls fence->signaled. Christian. Am 22.07.2014 18:21, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 5:59 PM, Christian K?nig > <deathsimple at vodafone.de> wrote: >> Am 22.07.2014 17:42, schrieb Daniel Vetter: >> >>> On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig >>> <christian.koenig at amd.com> wrote: >>>> Drivers exporting fences need to provide a fence->signaled and a >&gt...

Am 02.06.2014 15:14, schrieb Maarten Lankhorst: > This makes it possible to wait for a specific amount of time, > rather than wait until infinity. > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > Splitted out version, I've noticed that I forgot to convert > radeon_fence_wait_empty to long r, fixed. >

Am 22.07.2014 17:42, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >> Drivers exporting fences need to provide a fence->signaled and a fence->wait >> function, everything else like fence->enable_signaling or calling >> fence_signaled() from the driver is optional. >> >> Drivers

https://bugs.freedesktop.org/show_bug.cgi?id=89969 Bug ID: 89969 Summary: vaDriverInit fails with gallium/nouveau driver Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at