> Doing it without software methods means you need to have a semaphore
> that "exists" in the cpu domain and therefore cannot be used again
> until the cpu is sure it's done. So that will probably require a
> rotating queue of several semaphores and a fallback to cpu waiting.
Why would it need a s
> The card also keeps some internal FIFO caches, so it seems to me that
> getting that safe of races and efficient at the same time could be a bit
> non-trivial.
Are they flushable?
It seems this *might* do the job:
if (!pfifo->cache_flush(dev))
return;
pfifo->reassign(dev, false);
pfifo->cache_fl
http://bugs.freedesktop.org/show_bug.cgi?id=26145
bjaglin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugzilla.kernel.org/show_bug.cgi?id=15030
--- Comment #7 from Alex Deucher 2010-01-22 00:39:24
---
Does this work any better with the latest atom parser updates in
drm-radeon-testing:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-tes
http://bugs.freedesktop.org/show_bug.cgi?id=26145
--- Comment #1 from Alex Deucher 2010-01-21 16:31:55 PST ---
Created an attachment (id=32759)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32759)
fix get_engine/memory clock functions
This patch should do the trick.
--
Configure bu
>From 7cd86c7f89de8f18a678dde692b759f1bc6c911f Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 21 Jan 2010 19:28:18 -0500
Subject: [PATCH] drm/radeon/kms: fix legacy get_engine/memory clock
Fix a bad shift in the post div.
Should fix fdo bug 26145
Signed-off-by: Alex Deucher
---
driver
>From 70b680b7be5bf129296774a1f498375365595626 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 21 Jan 2010 17:14:49 -0500
Subject: [PATCH] drm/radeon/kms/atom: atom parser fixes
Only reset the reg block on the initial execute
table call; nested calls require the reg block not be
reset on e
>From 52820729c70e23b4841e47476d54a52cdb9a8322 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 21 Jan 2010 16:50:30 -0500
Subject: [PATCH] drm/radeon/kms/atom: fix crtc lock ordering
This makes crtc_prepare and crtc_commit match.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/at
Luca Barbieri writes:
>> The card also keeps some internal FIFO caches, so it seems to me that
>> getting that safe of races and efficient at the same time could be a bit
>> non-trivial.
>
> Are they flushable?
> It seems this *might* do the job:
> if (!pfifo->cache_flush(dev))
> return;
> pfifo-
http://bugs.freedesktop.org/show_bug.cgi?id=26159
Alex Deucher changed:
What|Removed |Added
Component|Drivers/DRI/R600|DRM/Radeon
Product|Mesa
http://bugs.freedesktop.org/show_bug.cgi?id=26159
Summary: Radeon 3200HD - HDMI works only with mplayer
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priori
Luca Barbieri writes:
>>> If not, it could possibly be hacked around by reading from a DMA
>>> object at the address of the fence sequence number and then resizing
>>> the DMA object so that addresses from a certain point on would trigger
>>> a protection fault interrupt.
>>
>> I don't think you
On Thu, Jan 21, 2010 at 4:56 PM, Luca Barbieri wrote:
>> Doing it without software methods means you need to have a semaphore
>> that "exists" in the cpu domain and therefore cannot be used again
>> until the cpu is sure it's done. So that will probably require a
>> rotating queue of several semap
On Wed, 20 Jan 2010, Tomas M. wrote:
> since 2.6.32 you can change the resolution with video=VGA-1:640x480 boot
> parameter and emulate the old behaviour.
That works even with Fedora-12, which uses a 2.6.31-based kernel.
Thanks.
Alan Stern
---
>> If not, it could possibly be hacked around by reading from a DMA
>> object at the address of the fence sequence number and then resizing
>> the DMA object so that addresses from a certain point on would trigger
>> a protection fault interrupt.
>
> I don't think you can safely modify a DMA object
On Thu, Jan 21, 2010 at 3:44 PM, Francisco Jerez wrote:
> Luca Barbieri writes:
>
>>> Nvidia cards have a synchronization primitive that could be used to
>>> synchronize several FIFOs in hardware (AKA semaphores, see [1] for an
>>> example).
>>
>> Does this operate wholly on the GPU on all nVidia
I'm not sure I understand your proposal correctly.
It seems your proposoal is similar to mine, replacing the term "fence
nodes" with "ttm transactions", but I'm not sure if I understand it
correctly
Here is some pseudocode for a improved, simplified version of my proposal.
It is modified so that t
Yuan, Shengquan wrote:
> On Wed, Jan 20, 2010 at 6:48 PM, Thomas Hellstrom wrote:
>
>> Yuan,
>> This looks like an old leftover from a previous cleanup.
>>
>> Although, when I look at the code, it seems save_flags should be removed
>> completely.
>> Can you take a look at that and respin the pa
> Nvidia cards have a synchronization primitive that could be used to
> synchronize several FIFOs in hardware (AKA semaphores, see [1] for an
> example).
Does this operate wholly on the GPU on all nVidia cards?
It seems that at least on some GPUs this will trigger "software
methods" that are basi
> At a first glance:
>
> 1) We probably *will* need a delayed destroyed workqueue to avoid wasting
> memory that otherwise should be freed to the system. At the very least, the
> delayed delete process should optionally be run by a system shrinker.
You are right. For VRAM we don't care since we are
http://bugs.freedesktop.org/show_bug.cgi?id=23993
--- Comment #17 from James Broadhead 2010-01-21
06:49:55 PST ---
... and the ubuntu bug leads me to this :
https://bugs.freedesktop.org/show_bug.cgi?id=24414
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
http://bugs.freedesktop.org/show_bug.cgi?id=23993
James Broadhead changed:
What|Removed |Added
CC||[email protected]
--- Commen
Luca Barbieri writes:
>> Nvidia cards have a synchronization primitive that could be used to
>> synchronize several FIFOs in hardware (AKA semaphores, see [1] for an
>> example).
>
> Does this operate wholly on the GPU on all nVidia cards?
>
> It seems that at least on some GPUs this will trigger
http://bugs.freedesktop.org/show_bug.cgi?id=23993
--- Comment #15 from Dennis Nezic 2010-01-21
06:44:26 PST ---
Are there any NON-gentoo users seeing this bug? :P
(Just to throw in a few more stats, I'm running vanilla kernel sources
2.6.33_rc3, and my vcard is: RADEON(0): Chipset: "ATI Mo
http://bugs.freedesktop.org/show_bug.cgi?id=23993
--- Comment #14 from Dennis Nezic 2010-01-21
06:40:04 PST ---
Are there any NON-gentoo users seeing this bug? :P
(Just to throw in a few more stats, I'm running vanilla kernel sources
2.6.33_rc3, and my vcard is: RADEON(0): Chipset: "ATI Mo
http://bugs.freedesktop.org/show_bug.cgi?id=23993
--- Comment #13 from James Broadhead 2010-01-21
06:34:10 PST ---
Seeing this as well, running xbmc initially, but tested with extreme-tuxracer
with the same effects.
Environment:
gentoo x86 2.6.31-gentoo-r6
media-tv/xbmc-9.11-r1 (Confluen
http://bugs.freedesktop.org/show_bug.cgi?id=23993
--- Comment #12 from James Broadhead 2010-01-21
06:31:28 PST ---
Created an attachment (id=32756)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32756)
xorg log (jamesbroadhead)
--
Configure bugmail: http://bugs.freedesktop.org/userp
Luca Barbieri writes:
>> At a first glance:
>>
>> 1) We probably *will* need a delayed destroyed workqueue to avoid wasting
>> memory that otherwise should be freed to the system. At the very least, the
>> delayed delete process should optionally be run by a system shrinker.
> You are right. For
http://bugs.freedesktop.org/show_bug.cgi?id=23993
--- Comment #11 from James Broadhead 2010-01-21
06:29:35 PST ---
Created an attachment (id=32755)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32755)
dmesg output (jamesbroadhead)
--
Configure bugmail: http://bugs.freedesktop.org/u
Luca Barbieri wrote:
>> At a first glance:
>>
>> 1) We probably *will* need a delayed destroyed workqueue to avoid wasting
>> memory that otherwise should be freed to the system. At the very least, the
>> delayed delete process should optionally be run by a system shrinker.
>>
> You are right.
Luca Barbieri wrote:
>> We had to do a similar thing in the
>> Poulsbo driver and it turned out that we could save a significant amount of
>> CPU by using a delayed workqueue, collecting objects and destroying them
>> periodically.
>>
> Yes, indeed, we don't really care about a fence expiring
Jerome Glisse wrote:
> On Thu, Jan 21, 2010 at 04:49:39AM +0100, Luca Barbieri wrote:
>
>>> We had to do a similar thing in the
>>> Poulsbo driver and it turned out that we could save a significant amount of
>>> CPU by using a delayed workqueue, collecting objects and destroying them
>>> periodi
On Thu, Jan 21, 2010 at 04:49:39AM +0100, Luca Barbieri wrote:
> > We had to do a similar thing in the
> > Poulsbo driver and it turned out that we could save a significant amount of
> > CPU by using a delayed workqueue, collecting objects and destroying them
> > periodically.
> Yes, indeed, we don
33 matches
Mail list logo
