Hi Maarten,
try to implement this as a replacement for specifying the
RADEON_FENCE_JIFFIES_TIMEOUT on wait_event_*. And reset the timeout
every time radeon_fence_process is called and not only when any of the
sequences increment.
I don't have the time right now to look deeper into it or help
op 23-07-14 15:16, Maarten Lankhorst schreef:
> op 23-07-14 14:36, Christian K?nig schreef:
>> Am 23.07.2014 12:52, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
>>> wrote:
> And the dma-buf would still have fences belonging to both drivers, and it
> would
op 23-07-14 14:36, Christian K?nig schreef:
> Am 23.07.2014 12:52, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
>> wrote:
And the dma-buf would still have fences belonging to both drivers, and it
would still call from outside the driver.
>>>
>>> Calling
On Wed, Jul 23, 2014 at 2:36 PM, Christian K?nig
wrote:
> My idea was more that the fence framework provides a
> fence->process_signaling callback that is periodically called after
> enable_signaling is called to trigger manual signal processing in the
> driver.
>
> This would both be suitable as
Am 23.07.2014 12:52, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
> wrote:
>>> And the dma-buf would still have fences belonging to both drivers, and it
>>> would still call from outside the driver.
>>
>> Calling from outside the driver is fine as long as the driver
On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
wrote:
>
>> And the dma-buf would still have fences belonging to both drivers, and it
>> would still call from outside the driver.
>
>
> Calling from outside the driver is fine as long as the driver can do
> everything necessary to complete it's
Am 23.07.2014 11:55, schrieb Maarten Lankhorst:
> op 23-07-14 11:47, Christian K?nig schreef:
>> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
>>> wrote:
The scheduler needs to keep track of a lot of fences, so I think we'll
have to
op 23-07-14 11:47, Christian K?nig schreef:
> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
>> 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
On Wed, Jul 23, 2014 at 11:47 AM, Christian K?nig
wrote:
> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
>> 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
Am 23.07.2014 11:44, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
> 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
On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes
wrote:
>> We don't have the code yet ready, but that's the direction i915 will
>> move towards for the near future. Jesse is working on some patches
>> already.
>
> Yeah I'd like to get some feedback from Maarten on my bits so I can get
> them ready
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
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 doesn't
Am 23.07.2014 11:38, schrieb Maarten Lankhorst:
> op 23-07-14 11:36, Christian K?nig schreef:
>> Am 23.07.2014 11:30, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
>>> wrote:
You submit a job to the hardware and then block the job to wait for radeon
to be
On Wed, Jul 23, 2014 at 11:36 AM, Christian K?nig
wrote:
> Am 23.07.2014 11:30, schrieb Daniel Vetter:
>
>> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
>> wrote:
>>>
>>> You submit a job to the hardware and then block the job to wait for
>>> radeon
>>> to be finished? Well than this would
op 23-07-14 11:36, Christian K?nig schreef:
> Am 23.07.2014 11:30, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
>> wrote:
>>> You submit a job to the hardware and then block the job to wait for radeon
>>> to be finished? Well than this would indeed require a
Am 23.07.2014 11:30, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
> wrote:
>> You submit a job to the hardware and then block the job to wait for radeon
>> to be finished? Well than this would indeed require a hardware reset, but
>> wouldn't that make the whole
On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
wrote:
> You submit a job to the hardware and then block the job to wait for radeon
> to be finished? Well than this would indeed require a hardware reset, but
> wouldn't that make the whole problem even worse?
>
> I mean currently we block one
Am 23.07.2014 10:54, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 10:46 AM, Christian K?nig
> wrote:
>> Am 23.07.2014 10:42, schrieb Daniel Vetter:
>>
>>> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
>>> wrote:
In this case if the sync was to i915 the i915 lockup procedure would
On Wed, Jul 23, 2014 at 10:46 AM, Christian K?nig
wrote:
> Am 23.07.2014 10:42, schrieb Daniel Vetter:
>
>> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
>> wrote:
>>>
>>> In this case if the sync was to i915 the i915 lockup procedure would take
>>> care of itself. It wouldn't fix radeon,
Am 23.07.2014 10:42, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
> 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
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
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
>
Am 23.07.2014 10:01, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 9:37 AM, Christian K?nig
> wrote:
>> Am 23.07.2014 09:31, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig
>>> wrote:
It's not a locking problem I'm talking about here. Radeons lockup
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
>> 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
Am 23.07.2014 10:07, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 9:58 AM, Christian K?nig
> 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
On Wed, Jul 23, 2014 at 9:58 AM, Christian K?nig
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
On Wed, Jul 23, 2014 at 9:37 AM, Christian K?nig
wrote:
> Am 23.07.2014 09:31, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig
>> wrote:
>>>
>>> It's not a locking problem I'm talking about here. Radeons lockup
>>> handling
>>> kicks in when anything calls into the
> Regardless of the fence implementation, why would it be a good idea to do a
> full lockup recovery when some other driver is
> calling your wait function? That doesn't seem to be a nice thing to do, so I
> think a timeout is the best error you could return here,
> other drivers have to deal
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
>> 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,
Am 23.07.2014 09:32, schrieb Maarten Lankhorst:
> op 23-07-14 09:15, Christian K?nig schreef:
>> Am 23.07.2014 09:09, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
>>> wrote:
> Can we somehow avoid the need to call fence_signal() at all? The
> interrupts
Am 23.07.2014 09:31, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig
> 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
op 23-07-14 09:15, Christian K?nig schreef:
> Am 23.07.2014 09:09, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
>> wrote:
Can we somehow avoid the need to call fence_signal() at all? The
interrupts at least on radeon are way to unreliable for such a
On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig
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
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
Am 23.07.2014 09:09, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
> wrote:
>>> Can we somehow avoid the need to call fence_signal() at all? The interrupts
>>> at least on radeon are way to unreliable for such a thing. Can
>>> enable_signalling fail? What's the
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
wrote:
>> Can we somehow avoid the need to call fence_signal() at all? The interrupts
>> at least on radeon are way to unreliable for such a thing. Can
>> enable_signalling fail? What's the reason for fence_signaled() in the first
>> place?
>
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
wrote:
> Drivers exporting fences need to
On Wed, Jul 23, 2014 at 8:52 AM, Christian K?nig
wrote:
>> In the preliminary patches where I can sync radeon with other GPU's I've
>> been very careful in all the places that call into fences, to make sure that
>> radeon wouldn't try to handle lockups for a different (possibly also radeon)
>>
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
>>> wrote:
Drivers exporting fences need to provide a fence->signaled and a
fence->wait
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
>> wrote:
>>> Drivers exporting fences need to provide a fence->signaled and a fence->wait
>>> function, everything else like fence->enable_signaling or
On Wed, 23 Jul 2014 11:47:15 +0200
Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes
> wrote:
> >> We don't have the code yet ready, but that's the direction i915 will
> >> move towards for the near future. Jesse is working on some patches
> >> already.
> >
> > Yeah I'd like
On Wed, Jul 23, 2014 at 2:52 AM, Christian K?nig
wrote:
> 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
wrote:
>
>
On Tue, Jul 22, 2014 at 6:39 PM, Christian K?nig
wrote:
>> Maybe I've mixed things up a bit in my description. There is
>> fence_signal which the implementor/exporter of a fence must call when
>> the fence is completed. If the exporter has an ->enable_signaling
>> callback it can delay that call
On Tue, Jul 22, 2014 at 6:21 PM, Daniel Vetter
wrote:
> But like I've said fence->signaled is optional so you don't need this
> necessarily, as long as radeon eventually calls fence_signaled once
> the fence has completed.
Actually I've chatted a bit with Maarten about the different ways we
> Maybe I've mixed things up a bit in my description. There is
> fence_signal which the implementor/exporter of a fence must call when
> the fence is completed. If the exporter has an ->enable_signaling
> callback it can delay that call to fence_signal for as long as it
> wishes as long as
On Tue, Jul 22, 2014 at 5:59 PM, Christian K?nig
wrote:
> Am 22.07.2014 17:42, schrieb Daniel Vetter:
>
>> On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig
>> wrote:
>>>
>>> Drivers exporting fences need to provide a fence->signaled and a
>>> fence->wait
>>> function, everything else like
Am 22.07.2014 17:42, schrieb Daniel Vetter:
> On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig
> 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
On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig
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 wanting to use exported fences
Am 22.07.2014 17:17, schrieb Daniel Vetter:
> On Tue, Jul 22, 2014 at 3:45 PM, Christian K?nig
> 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.
>>
>>
Hey,
op 22-07-14 17:02, Christian K?nig schreef:
> Am 22.07.2014 16:44, schrieb Maarten Lankhorst:
>> op 22-07-14 15:45, Christian K?nig schreef:
>>> Am 22.07.2014 15:26, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote:
> Am 22.07.2014 13:57,
On Tue, Jul 22, 2014 at 3:45 PM, Christian K?nig
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
Am 22.07.2014 16:44, schrieb Maarten Lankhorst:
> op 22-07-14 15:45, Christian K?nig schreef:
>> Am 22.07.2014 15:26, schrieb Daniel Vetter:
>>> On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote:
Am 22.07.2014 13:57, schrieb Daniel Vetter:
> On Tue, Jul 22, 2014 at
op 22-07-14 15:45, Christian K?nig schreef:
> Am 22.07.2014 15:26, schrieb Daniel Vetter:
>> On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote:
>>> Am 22.07.2014 13:57, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
> On Tue, Jul 22,
Am 22.07.2014 15:26, schrieb Daniel Vetter:
> On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote:
>> Am 22.07.2014 13:57, schrieb Daniel Vetter:
>>> On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:
On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote:
> Am 22.07.2014 13:57, schrieb Daniel Vetter:
> >On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
> >>On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:
> >>>Am 22.07.2014 06:05, schrieb Dave Airlie:
>
54 matches
Mail list logo
