On Tue, 30 Apr 2002 18:25:03 -0400 (EDT)
Leif Delgass <[EMAIL PROTECTED]> wrote:
> On Tue, 30 Apr 2002, José Fonseca wrote:
>
> > On 2002.04.30 13:41 Felix Kühling wrote:
> > > Hi,
> > >
> > > I tried DMA on the mach64-0-0-4-branch now. All the gl application seem
> > > to work fine. But after
OK, I've checked in my changes and here's what I added:
The bus master test now uses the pci pool already allocated by dma_init
rather than creating another temporary one. It allocates the data buffer
from the pool, but we could change this to make it grab a buffer from the
freelist of mapped
On 2002.04.30 22:33 Sergey V. Udaltsov wrote:
> Hi
>
> I cleaned up all modules and run 0-0-4 from clean state - still same
> lockup on X termination. Actully, I get the lockup not in termination
> but in attempts to switch to any textual console.:(
Do you use some framebuffer device?
>
> > Th
On 2002.05.01 00:01 Michel Dänzer wrote:
> On Wed, 2002-05-01 at 00:43, José Fonseca wrote:
> >
> > I attached a complete diff that should do the right thing. I believe
> this
> > is the only way to do this in a portable fashion, even if results in
> some
> > redundant work being done on bigendian
On Wed, 2002-05-01 at 00:43, José Fonseca wrote:
>
> I attached a complete diff that should do the right thing. I believe this
> is the only way to do this in a portable fashion, even if results in some
> redundant work being done on bigendian machines.
Don't worry about that, as I said, at le
Hi
I cleaned up all modules and run 0-0-4 from clean state - still same
lockup on X termination. Actully, I get the lockup not in termination
but in attempts to switch to any textual console.:(
> The reason is that I've changed the dripkg/install scripts sometime, and I
Could you please give me
On Tue, 30 Apr 2002, Leif Delgass wrote:
> On 1 May 2002, Michel Dänzer wrote:
>
> > On Tue, 2002-04-30 at 23:53, Leif Delgass wrote:
> > > On Tue, 30 Apr 2002, José Fonseca wrote:
> > >
> > > > On 2002.04.30 22:07 José Fonseca wrote:
> > > > > ... Next in mach64_drv.h, let's try the following
On 1 May 2002, Michel Dänzer wrote:
> On Tue, 2002-04-30 at 23:53, Leif Delgass wrote:
> > On Tue, 30 Apr 2002, José Fonseca wrote:
> >
> > > On 2002.04.30 22:07 José Fonseca wrote:
> > > > ... Next in mach64_drv.h, let's try the following definitions for the
> > > > MMIO:
> > > >
> > > > #d
On Wed, 2002-05-01 at 00:36, Michel Dänzer wrote:
> On Tue, 2002-04-30 at 23:53, Leif Delgass wrote:
> > On Tue, 30 Apr 2002, José Fonseca wrote:
> >
> > > On 2002.04.30 22:07 José Fonseca wrote:
> > > > ... Next in mach64_drv.h, let's try the following definitions for the
> > > > MMIO:
> > > >
On 2002.04.30 22:53 Leif Delgass wrote:
> ...
>
> There's a wrinkle for the vertex buffers though. The register offsets
> and
> data in the buffer have already been swapped to little-endian, whereas
> the
> state updates and such using the DMA* macros (which in turn use
> MACH64_WRITE) pass data
On Tue, 2002-04-30 at 23:53, Leif Delgass wrote:
> On Tue, 30 Apr 2002, José Fonseca wrote:
>
> > On 2002.04.30 22:07 José Fonseca wrote:
> > > ... Next in mach64_drv.h, let's try the following definitions for the
> > > MMIO:
> > >
> > > #define MACH64_READ(reg)readl(MACH64_ADDR(reg))
On Tue, 30 Apr 2002, José Fonseca wrote:
> On 2002.04.30 13:41 Felix Kühling wrote:
> > Hi,
> >
> > I tried DMA on the mach64-0-0-4-branch now. All the gl application seem
> > to work fine. But after switching to another console and back (without
> > running a gl app at the same time:) the gl ap
On Tue, 2002-04-30 at 23:07, José Fonseca wrote:
>
> The use of readl/writel just by itself introduces a novelty, since
> according to
>
>http://132.248.28.115/Bibliografia/ArticulosComputo/linux-mag-1999/Linux%20Magazine%20%20July%201999%20%20GEARHEADS%20ONLY%20%20How%20To%20Make%20Sure%20Your
On Tue, 30 Apr 2002, José Fonseca wrote:
> On 2002.04.30 22:07 José Fonseca wrote:
> > ... Next in mach64_drv.h, let's try the following definitions for the
> > MMIO:
> >
> > #define MACH64_READ(reg) readl(MACH64_ADDR(reg))
> > #define MACH64_WRITE(reg,val) writel(MACH64_ADDR(val, reg)
On 2002.04.30 22:07 José Fonseca wrote:
> ... Next in mach64_drv.h, let's try the following definitions for the
> MMIO:
>
> #define MACH64_READ(reg)readl(MACH64_ADDR(reg))
> #define MACH64_WRITE(reg,val) writel(MACH64_ADDR(val, reg))
>
Sorry, i've mistaken writting it. It's inste
Peter,
First undo the changes that you made since the last lock, i.e., define
MACH64_USE_DMA to 0 in mach64_drv.h and use "mach64_do_wait_for_fifo(
dev_priv, 16 )" instead of "mach64_do_wait_for_idle( dev_priv )" in
mach64_state.c. Next in mach64_drv.h, let's try the following definitions
for
On 2002.04.30 13:41 Felix Kühling wrote:
> Hi,
>
> I tried DMA on the mach64-0-0-4-branch now. All the gl application seem
> to work fine. But after switching to another console and back (without
> running a gl app at the same time:) the gl app's window is just black
> after starting it, full CPU
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00B3_81A04E8E.B7871A65"
Hi,
I've been lurking on this list for a couple weeks, and I looked at the
archives, seeing that the "X locks when switching to vt and back to X
with radeon mobility and dri enabled" problem is a known one. At the
moment I disabled dri and everything is working fine (I'm using 4.2.0
from Mandrake
On Tue, 30 Apr 2002, José Fonseca wrote:
> On 2002.04.30 10:54 Sergey V. Udaltsov wrote:
> > > No. There isn't any yet. But we can arrange to something be printed
> > on
> > > the system log when the DMA is enabled on runtime.
> > That would be nice. Also, Leif offered to turn DMA on if bus mas
On Tue, 2002-04-30 at 17:47, Jose Fonseca wrote:
> On Tue, 2002-04-30 at 15:49, Michel Dänzer wrote:
> > On Tue, 2002-04-30 at 15:26, José Fonseca wrote:
> > > On 2002.04.30 14:16 Michel Dänzer wrote:
> > > > On Tue, 2002-04-30 at 10:45, José Fonseca wrote:
> > > > > This is still not very cl
On Tue, 2002-04-30 at 15:49, Michel Dänzer wrote:
> On Tue, 2002-04-30 at 15:26, José Fonseca wrote:
> > On 2002.04.30 14:16 Michel Dänzer wrote:
> > > On Tue, 2002-04-30 at 10:45, José Fonseca wrote:
> > > > This is still not very clear - yesterday we
> > > > discussed this in the IRC meetin
On Tue, 2002-04-30 at 15:26, José Fonseca wrote:
> On 2002.04.30 14:16 Michel Dänzer wrote:
> > On Tue, 2002-04-30 at 10:45, José Fonseca wrote:
> > > This is still not very clear - yesterday we
> > > discussed this in the IRC meeting -, because the colors are ok. Looking
> > > careful to the
On 2002.04.30 14:16 Michel Dänzer wrote:
> On Tue, 2002-04-30 at 10:45, José Fonseca wrote:
> > This is still not very clear - yesterday we
> > discussed this in the IRC meeting -, because the colors are ok. Looking
> > careful to the picture is seems that we have to word swap and not byte
>
On Tue, 2002-04-30 at 10:45, José Fonseca wrote:
> On 2002.04.30 09:36 Peter Andersson wrote:
> >> To describe my problem with the open gl rendering every other vertical
> >> "pixel row" is jagged. It looks similar to the fields in a frozen video
> >> frame if you know what i mean, only these f
Hi,
I tried DMA on the mach64-0-0-4-branch now. All the gl application seem
to work fine. But after switching to another console and back (without
running a gl app at the same time:) the gl app's window is just black
after starting it, full CPU load in the kernel and the X-server reacts
very slow
> In the previous 0-0-3 branch we almost never messed with the DRM, so it
> was binary compatible between all snapshots. Now is exactly the opposite.
> Nevertheless you shouldn't need to stop X if you're running your distro X.
> You need only if you are running X from a mach64 branch, because i
On 2002.04.30 10:54 Sergey V. Udaltsov wrote:
> > It seems that the mach64 kernel moduled wasn't replaced from memory,
> > causing a kernel oops. Usually you need to run install.sh without X
> > running (I usually do init 3).
> Well, at least with 0-0-3 I managed to do in without stopping X. Just
Adam K Kirchhoff wrote:
>
> I haven't had much chance to do testing recently, but hopefully tonight.
>
...
> Gltron has some issues when you tell it to use halo trails. This
> *really* hurts performance, especially when you have more than one trail
> on the screen. Interestingly, this
> It seems that the mach64 kernel moduled wasn't replaced from memory,
> causing a kernel oops. Usually you need to run install.sh without X
> running (I usually do init 3).
Well, at least with 0-0-3 I managed to do in without stopping X. Just
"install.sh" and restarting X was enough. OK, if you
On 2002.04.30 09:38 Sergey V. Udaltsov wrote:
> > From this moment the mach64 binary snapshots in
> > http://dri.sourceforge.net/snapshots/bleeding-edge/ are taken from the
> > 0-0-4 branch.
> Thanks. Just tried. Well, it seems 0-0-4 has long way to go:)
> First, I just run "install.sh" and resta
On 2002.04.30 09:36 Peter Andersson wrote:
>> To describe my problem with the open gl rendering every other vertical
>> "pixel row" is jagged. It looks similar to the fields in a frozen video
>> frame if you know what i mean, only these fields are horiziotal.
>> Perhaps the screenshot will spe
> From this moment the mach64 binary snapshots in
> http://dri.sourceforge.net/snapshots/bleeding-edge/ are taken from the
> 0-0-4 branch.
Thanks. Just tried. Well, it seems 0-0-4 has long way to go:)
First, I just run "install.sh" and restarted X. I got segmentation fault
on glxinfo - after di
> To describe my problem with the open gl rendering every other
> vertical "pixel row" is jagged. It looks similar to the fields in a
> frozen video frame if you know what i mean, only these fields are
> horiziotal. Perhaps the screenshot will speak more clearly.
>
> Nice effect! ;-)
>
> It's
On 2002.04.30 08:25 Kaz Sasayama wrote:
> One more question. Why must so much memory be reserved at the X server
> startup? Can it be allocated at run time instead?
I think it could. There are comments in the code in that sense, but it's
note yet implemented, and is one of those last things t
One more question. Why must so much memory be reserved at the X server
startup? Can it be allocated at run time instead?
Leif Delgass wrote:
>I have an 8MB card, and I run the X server at 1024x768 @ 16-bit depth or
>800x600 @ 24-bit depth. You need enough memory for 3 times the virtual
>scre
36 matches
Mail list logo
