On Wed, 2005-03-16 at 17:46 -0500, Vladimir Dergachev wrote:
>
> So can we be sure that one can do arbitrary INREG() on Radeons without
> fear of lockup ?
I think so, in general.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http:
I backed out the RadeonWaitForIdleMMIO() out of radeon_mergedfb.c.
Also, I am no longer able to observe the lockup on my hardware that I saw
earlier, perhaps something else got fixed.
I am still curious to know what are the rules for accessing Radeon
registers, perhaps, when I have more spare ti
On Thu, 2005-03-17 at 03:25 +0200, Ville Syrjälä wrote:
> On Thu, Mar 17, 2005 at 12:12:58PM +1100, Benjamin Herrenschmidt wrote:
> >
> > > I understand you can't have userspace program the accelerator while
> > > someone else is doing the same thing. Oh and I now understand that the
> > > same
On Thu, Mar 17, 2005 at 12:12:58PM +1100, Benjamin Herrenschmidt wrote:
>
> > I understand you can't have userspace program the accelerator while
> > someone else is doing the same thing. Oh and I now understand that the
> > same really applies to direct framebuffer access due to the swapper.
> I understand you can't have userspace program the accelerator while
> someone else is doing the same thing. Oh and I now understand that the
> same really applies to direct framebuffer access due to the swapper.
And you can't have someone program the accelerator while somebody does
direct a
On Thu, Mar 17, 2005 at 10:30:01AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-16 at 23:08 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:
>
> > I haven't seen anyone coming forward with a design/code for the memory
> > manager.
> >
> > In
On Thu, 2005-03-17 at 02:14 +0200, Ville Syrjälä wrote:
> On Thu, Mar 17, 2005 at 10:27:56AM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
> > > > In the meantime, can yo
On Thu, Mar 17, 2005 at 10:27:56AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
> > > In the meantime, can you tell me more about your arbitration scheme ?
> >
> > There is
> Why don't we modify the new radoenfb driver to have a real
> arbitration/management layer. Directfb can continue to use the old
> driver. The rule is that you can't mix old and new style fbdev drivers
> in a system. Over time DirectFb and X can be fixed to use the new
> model.
>
> There is goin
On Thu, 2005-03-17 at 10:28 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-16 at 16:00 -0500, Michel DÃnzer wrote:
> > On Wed, 2005-03-16 at 21:51 +0200, Ville SyrjÃlà wrote:
> > >
> > > One thing just popped to my head though. If in the future we are going to
> > > allow graphics cards t
On Thu, 17 Mar 2005 10:26:57 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> On Wed, 2005-03-16 at 15:42 -0500, Michel Dänzer wrote:
> > On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjälä wrote:
> > >
> > > I don't see the current system slowly evolving into some superb future
> > > system
On Wed, 2005-03-16 at 23:08 +0200, Ville Syrjälä wrote:
> On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:
> I haven't seen anyone coming forward with a design/code for the memory
> manager.
>
> In the meantime I'm assuming that people might want to make some use of
> their dualhea
On Wed, 2005-03-16 at 16:00 -0500, Michel Dänzer wrote:
> On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote:
> >
> > One thing just popped to my head though. If in the future we are going to
> > allow graphics cards to render to system memory, using the swapper will no
> > longer work. I do
On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote:
> On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
> > In the meantime, can you tell me more about your arbitration scheme ?
>
> There is a lock associated with the graphics card. The lock is always
> taken before prog
On Wed, 2005-03-16 at 15:42 -0500, Michel Dänzer wrote:
> On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjälä wrote:
> >
> > I don't see the current system slowly evolving into some superb future
> > system with an in kernel memory manager. The current APIs just have too
> > many limitations. I thi
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote:
> This was about the DirectFB drivers.
>
> One thing just popped to my head though. If in the future we are going to
> allow graphics cards to render to system memory, using the swapper will no
> longer work. I don't see any other solution
Am Mittwoch, den 16.03.2005, 16:26 +0100 schrieb Felix Kühling:
> Am Mittwoch, den 16.03.2005, 17:35 +0300 schrieb Sergey Zharkov:
[snip]
> > What I'am afraid of is that savage_dri or savage_drv drivers writhe
> > something into the chip hardware that is not loaded there by kernel
> > modules start
On Wed, 2005-03-16 at 11:48 -0500, Adam Jackson wrote:
> On Wednesday 16 March 2005 09:09, Ville Syrjälä wrote:
> > On Wed, Mar 16, 2005 at 05:31:16PM +1100, Benjamin Herrenschmidt wrote:
> > > Well, do they "revert" it after atyfb/aty128fb/radeonfb set it then ?
> > > it's definitely set on mode s
I am quite certain, that, at least on mach64 hardware, an attempt to
access framebuffer by CPU while the GUI engine is active will result in a
hard lockup.
If this was true with Radeons, you'd get a lockup every time the
hardware cursor shape changes. I guess the memory controller has
improved...
On Wednesday 16 March 2005 08:46 am, Jerome Glisse wrote:
> On Tue, 15 Mar 2005 18:36:21 -0500, Jung-uk Kim <[EMAIL PROTECTED]>
wrote:
> > On Tuesday 15 March 2005 05:06 pm, Aapo Tahkola wrote:
> > > > After reading all the promising success stories about the
> > > > r300 project, I am
> > > > won
Vladimir Dergachev wrote:
Well, I thought I'd also point out that this solves the lockups I
was experiecing with the r300 driver, too :-)
Really ? And you can move cursor freely on r300 without lockups ?
I played almost a full game of neverputt... That hasn't happened
with the r300 driver in
On Wed, 16 Mar 2005 23:08:12 +0200, Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:
> > On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> > > On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote:
On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:
> On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote:
> > >
> > > > It's ugly, but that's not the point. The point is that all deployed
On Wed, Mar 16, 2005 at 04:00:26PM -0500, Michel Dänzer wrote:
> On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjälä wrote:
> >
> > One thing just popped to my head though. If in the future we are going to
> > allow graphics cards to render to system memory, using the swapper will no
> > longer wor
On Wed, 2005-03-16 at 21:51 +0200, Ville SyrjÃlà wrote:
>
> One thing just popped to my head though. If in the future we are going to
> allow graphics cards to render to system memory, using the swapper will no
> longer work. I don't see any other solution that having the CPU perform
> the byte
On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote:
> >
> > > It's ugly, but that's not the point. The point is that all deployed
> > > versions of X (and even current X.org CVS head still, in fact) m
On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
> In the meantime, can you tell me more about your arbitration scheme ?
There is a lock associated with the graphics card. The lock is always
taken before programming the hardware. Other things wanting access to the
hardware
On Wed, 2005-03-16 at 22:08 +0200, Ville SyrjÃlà wrote:
>
> I don't see the current system slowly evolving into some superb future
> system with an in kernel memory manager. The current APIs just have too
> many limitations. I think the memory manager must be the foundation of
> everything and
On Wed, 2005-03-16 at 15:35 -0500, Vladimir Dergachev wrote:
>
> On Wed, 16 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
>
> >
> > Disclaimer: I don't pretend to understand 100% how all this stuff works
> > either, but I think my understanding has improved a little recently. :)
>
> Michel, I think
On Wed, 16 Mar 2005, Michel [ISO-8859-1] Dänzer wrote:
Disclaimer: I don't pretend to understand 100% how all this stuff works
either, but I think my understanding has improved a little recently. :)
Michel, I think we are misunderstanding each other.
I am not talking about synchronization of drawi
http://bugme.osdl.org/show_bug.cgi?id=4337
--- Additional Comments From [EMAIL PROTECTED] 2005-03-16 12:14 ---
Nevermind, after looking at the log you already pasted, I don't think my patch
will give us any additional info. It looks like AGP at least thinks it
initialized properly,
On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote:
>
> > It's ugly, but that's not the point. The point is that all deployed
> > versions of X (and even current X.org CVS head still, in fact) make this
> > assumption.
>
> Oh, that's fine and that's not a problem. I will only
http://bugme.osdl.org/show_bug.cgi?id=4337
--- Additional Comments From [EMAIL PROTECTED] 2005-03-16 11:58 ---
Created an attachment (id=4733)
--> (http://bugme.osdl.org/attachment.cgi?id=4733&action=view)
debug output for agp backend
--- You are receiving this mail because: --
http://bugme.osdl.org/show_bug.cgi?id=4337
--- Additional Comments From [EMAIL PROTECTED] 2005-03-16 11:55 ---
For some reason the informational printks were deleted. Can you try the
attached patch and see what it prints in your syslog?
Jesse
--- You are receiving this mail
On Wed, Mar 16, 2005 at 12:51:27PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-16 at 03:47 +0200, Ville Syrjälä wrote:
>
> > There's also the case with Matrox Millennium I/II cards. They must place
> > the visible frame buffer so that no line crosses the boundary of memory
> > banks.
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2747
Summary: Indirect rendering function glGetProgramStringARB fails.
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2746
Summary: Indirect rendering function for glVertexAttrib4bvARB is
> "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
Helge> I have reported this before, but now I have some more data. I
Helge> have an office pc with this video card: VGA compatible
Helge> controller: ATI Technologies Inc Radeon RV100 QY [Radeon
Helge> 7000/VE]
FWIW, I have exactly the s
On Wednesday 16 March 2005 09:09, Ville SyrjÃlà wrote:
> On Wed, Mar 16, 2005 at 05:31:16PM +1100, Benjamin Herrenschmidt wrote:
> > Well, do they "revert" it after atyfb/aty128fb/radeonfb set it then ?
> > it's definitely set on mode switch.
>
> The point is that there can be offscreen surfaces wi
> I found a related bug: http://bugzilla.kernel.org/show_bug.cgi?id=3864.
> Though that user was not getting lockups, just some distortions.
> Probably with different graphics hardware (no details in the report).
> > - 2.1.8.2 . Hardware is Twinhead Efio 121A laptop Via KN266 chipset,
> > Athlon
On Wed, 16 Mar 2005 14:52:39 +0100, Helge Hafting
<[EMAIL PROTECTED]> wrote:
> No usb. The mouse is connected to the ps/2 mouse port. As I mentioned,
> this is
> not a recent problem. I could never load dri on this machine without
> such a crash. I can check whether the IRQ gets shared though.
Helge Hafting wrote:
Since it crashes even without 3d sometimes, the problem does not
seem to be related to dri (as in, dri driver).
Stable as rock, _if_ Load "dri" is commented out from xorg.conf (or
from XF86Config-4)
Well, commenting that out makes the 2d ddx driver not to use the CP, drm
etc
Roland Scheidegger wrote:
Helge Hafting wrote:
I have reported this before, but now I have some more data.
I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
[Radeon 7000/VE]
In previous reports I found that starting xfree or xorg with dri su
Roland Scheidegger wrote:
Helge Hafting wrote:
I have reported this before, but now I have some more data.
I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
[Radeon 7000/VE]
In previous reports I found that starting xfree or xorg with dri su
Am Mittwoch, den 16.03.2005, 17:35 +0300 schrieb Sergey Zharkov:
> Felix,
>
> Unfortunately I never posted a bug for kernel and have no idea how to do
> that.
I found a related bug: http://bugzilla.kernel.org/show_bug.cgi?id=3864.
Though that user was not getting lockups, just some distortions.
P
On Tue, 15 Mar 2005 18:36:21 -0500, Jung-uk Kim <[EMAIL PROTECTED]> wrote:
> On Tuesday 15 March 2005 05:06 pm, Aapo Tahkola wrote:
> > > After reading all the promising success stories about the r300
> > > project, I am
> > > wondering whether anybody successfully tried it on a *BSD.
> > > Some ti
On Wed, Mar 16, 2005 at 05:31:16PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-16 at 00:21 -0500, Michel Dänzer wrote:
>
> > > >
> > > > Actually people do use it on big-endian systems but since neither the
> > > > mach64, ati128 or radeon drivers play with the swapper settings I can
Felix,
I've tried some coding to make savage resume looking at radeon resume
code but failed completely :(( Unfortunately I'am ABAP/4 developer - not
a C guru.
The only thing that may help real dri developers to suggest how to
resume - when I switched DMA mode from command or vertex to "None" i
Am Mittwoch, den 16.03.2005, 15:17 +0300 schrieb Sergey Zharkov:
> Setting BusType to "PCI" and even BusType AGP with DmaType PCI helps -
> the thing resumes. So it seems to be a bug in AGP dma resuming. But not
> in kernel one - there is a resume code in via-agp driver, that worked
> for DRI 1.0
Helge Hafting wrote:
I have reported this before, but now I have some more data.
I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
7000/VE]
In previous reports I found that starting xfree or xorg with dri support
cause a hang after a
Am Mittwoch, den 16.03.2005, 14:47 +0300 schrieb Sergey Zharkov:
> Felix,
>
> I've tried some coding to make savage resume looking at radeon resume
> code but failed completely :(( Unfortunately I'am ABAP/4 developer - not
> a C guru.
>
> The only thing that may help real dri developers to sugge
I have reported this before, but now I have some more data.
I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
7000/VE]
In previous reports I found that starting xfree or xorg with dri support
cause a hang after a little while. It se
On Tue, 15 Mar 2005 23:48:54 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-03-16 at 00:17 +0100, Richard Stellingwerff wrote:
> >
> > Anyway, the driver works, but it's VERY unstable for me.
>
> If you're using MergedFB (which includes clone mode), see the current
> thread '[r200]
53 matches
Mail list logo
