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:One thing I've forgotten: The i915 scheduler that's floating around runs
Am 22.07.2014 06:05, schrieb Dave Airlie:I guess I've lost context a bit, but which atomic entry point are we
On 9 July 2014 22:29, Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx> wrote:Which is exactly what I criticized from the very first beginning. Good to
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>From what I can see this is still suffering from the problem that we
---
drivers/gpu/drm/radeon/radeon.h | 15 +-
drivers/gpu/drm/radeon/radeon_device.c | 60 ++++++++-
drivers/gpu/drm/radeon/radeon_fence.c | 223 ++++++++++++++++++++++++++------
3 files changed, 248 insertions(+), 50 deletions(-)
need to find a proper solution to,
My summary of the issues after talking to Jerome and Ben and
re-reading things is:
We really need to work out a better interface into the drivers to be
able to avoid random atomic entrypoints,
know that I'm not the only one thinking that this isn't such a good idea.
talking about? Afaics the only one that's mandatory is the is
fence->signaled callback to check whether a fence really has been
signalled. It's used internally by the fence code to avoid spurious
wakeups. Afaik that should be doable already on any hardware. If that's
not the case then we can always track the signalled state in software and
double-check in a worker thread before updating the sw state. And wrap
this all up into a special fence class if there's more than one driver
needing this.
its bottom half from irq context. So I really want to be able to check
fence state from irq context and I also want to make it possible
(possible! not mandatory) to register callbacks which are run from any
context asap after the fence is signalled.
If the radeon hw/driver doesn't want to cope with that complexity we can
fully insolate it with the sw tracked fence state if you don't like
Maarten's radeon implementation. But forcing everyone to forgoe this just
because you don't like it and don't want to use it in radeon doesn't sound
right.