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.koe...@amd.com wrote:
Drivers exporting fences need to provide a fence-signaled and a fence-wait
On Wed, Jul 23, 2014 at 8:52 AM, Christian König
christian.koe...@amd.com 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
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.koe...@amd.com wrote:
Drivers exporting fences need
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
maarten.lankho...@canonical.com 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()
Am 23.07.2014 09:09, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
maarten.lankho...@canonical.com 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
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
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
deathsim...@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
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
maarten.lankho...@canonical.com wrote:
Can we somehow avoid the need to call fence_signal() at all? The
interrupts at least on radeon are way to
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
deathsim...@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
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
deathsim...@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
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 with that
On Wed, Jul 23, 2014 at 9:37 AM, Christian König
christian.koe...@amd.com wrote:
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
deathsim...@vodafone.de wrote:
It's not a locking problem I'm talking about here. Radeons lockup
handling
kicks in
On Wed, Jul 23, 2014 at 9:58 AM, Christian König
deathsim...@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
Am 23.07.2014 10:07, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:58 AM, Christian König
deathsim...@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
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
deathsim...@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
Am 23.07.2014 10:01, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:37 AM, Christian König
christian.koe...@amd.com wrote:
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
deathsim...@vodafone.de wrote:
It's not a locking problem I'm talking about
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
maarten.lankho...@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
Am 23.07.2014 10:42, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
maarten.lankho...@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
On Wed, Jul 23, 2014 at 10:46 AM, Christian König
deathsim...@vodafone.de wrote:
Am 23.07.2014 10:42, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
In this case if the sync was to i915 the i915 lockup procedure would take
Am 23.07.2014 10:54, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:46 AM, Christian König
deathsim...@vodafone.de wrote:
Am 23.07.2014 10:42, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
In this case if the sync was to
On Wed, Jul 23, 2014 at 11:27 AM, Christian König
christian.koe...@amd.com 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
Am 23.07.2014 11:30, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:27 AM, Christian König
christian.koe...@amd.com 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
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
christian.koe...@amd.com 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
On Wed, Jul 23, 2014 at 11:36 AM, Christian König
christian.koe...@amd.com wrote:
Am 23.07.2014 11:30, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:27 AM, Christian König
christian.koe...@amd.com wrote:
You submit a job to the hardware and then block the job to wait for
radeon
to be
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
christian.koe...@amd.com wrote:
You submit a job to the hardware and then block the job to wait for radeon
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter daniel.vet...@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
On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes jbar...@virtuousgeek.org 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
Am 23.07.2014 11:44, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter daniel.vet...@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
On Wed, Jul 23, 2014 at 11:47 AM, Christian König
deathsim...@vodafone.de wrote:
Am 23.07.2014 11:44, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
The scheduler needs to keep track of a lot of fences, so I think we'll
have to register
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 daniel.vet...@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.
On Wed, Jul 23, 2014 at 12:13 PM, Christian König
christian.koe...@amd.com 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
On Wed, Jul 23, 2014 at 2:52 AM, Christian König
christian.koe...@amd.com 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
christian.koe...@amd.com
Am 23.07.2014 12:52, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 12:13 PM, Christian König
christian.koe...@amd.com 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
On Wed, Jul 23, 2014 at 2:36 PM, Christian König
christian.koe...@amd.com 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
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
christian.koe...@amd.com wrote:
And the dma-buf would still have fences belonging to both drivers, and it
would still call from outside the driver.
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
christian.koe...@amd.com wrote:
And the dma-buf would still have fences belonging to both drivers, and it
Hi again,
On my NV18 based laptop I experience artifacts related to text
(however, 2D performance is really great these days):
- With grayscale AA text is sometimes missing, often visible on the XFCE
desktop
- With subpixel (rgb) AA, even non-text related occur (icons are
misrendered, ...)
On Wed, Jul 23, 2014 at 10:32 AM, Clemens Eisserer linuxhi...@gmail.com wrote:
Hi again,
On my NV18 based laptop I experience artifacts related to text
(however, 2D performance is really great these days):
- With grayscale AA text is sometimes missing, often visible on the XFCE
desktop
-
On Wed, Jul 23, 2014 at 9:41 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Jul 23, 2014 at 10:32 AM, Clemens Eisserer linuxhi...@gmail.com
wrote:
Hi again,
On my NV18 based laptop I experience artifacts related to text
(however, 2D performance is really great these days):
- With
On Wed, Jul 23, 2014 at 10:52 AM, Patrick Baggett
baggett.patr...@gmail.com wrote:
On Wed, Jul 23, 2014 at 9:41 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Jul 23, 2014 at 10:32 AM, Clemens Eisserer linuxhi...@gmail.com
wrote:
Hi again,
On my NV18 based laptop I experience
Unfortunately I can't make that guarantee. Especially since I've
already tried and was unable to reproduce. I do have a bid on a NV17
or NV18 card on ebay, so just don't outbid me for it :)
Hah, fair enough. Maybe I should install one and join the fun...
Patrick
On Wed, 23 Jul 2014 11:47:15 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes jbar...@virtuousgeek.org
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
42 matches
Mail list logo
