Re: [Dri-devel] Mach64 and DMA
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 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 slowly. I get the following kind of messages in/var/log/kern.log > > > repeatedly (about one of these blocks per second): > > > > > > Apr 30 14:24:19 viking kernel: [drm] failed! GUI_STAT=0x0201 > > > Apr 30 14:24:19 viking kernel: [drm] mach64_do_wait_for_idle failed > > > Apr 30 14:24:19 viking kernel: [drm] resetting engine ... > > > > This is odd. The card never gets idle but X keeps working so the card is > > not locked. > > Well, once a DMA pass fails, you've got to reboot to get DMA back, so the > engine reset allows things to continue, but it'll keep locking up. The > right thing to do at this point is probably to bail out rather than switch > to MMIO, since it indicates a problem with DMA. I guess we'll need to add > a return value to _dispatch_vertex and have _dma_vertex return an error > code. Sorry, I forgot to mention that, for me it was sufficient to restart the X-server to get DMA working again. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time!
[Dri-devel] mach64 DMA/MMIO modes
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 DMA buffers. I pared down the syslog output of the test and moved most of it into debug statements, so you can still get the full output with drm_opts=debug. If the DMA test succeeds, DMA is enabled otherwise the driver will fall back to MMIO, and the syslog will show which is used. This test is only done on X server startup. You can still force MMIO mode at compile time by defining MACH64_USE_DMA to 0 in mach64_drv.h. I added a return code to _dispatch_vertex and made the flush function in the Mesa client check it and bail out on an error. If the wait for idle fails (DMA) or wait for FIFO fails (MMIO), the DRM will return -EBUSY and the Mesa client will cause the app to exit with a message including the return code. This is needed now for DMA because it's synchronous. So, in the event of a lockup, the engine will reset. If you restart X, you'll get MMIO mode (assuming the DMA test fails), but you'll need to cold restart to get DMA back. -- Leif Delgass http://www.retinalburn.net
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
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? > > > The reason is that I've changed the dripkg/install scripts sometime, > and I > Could you please give me a tip - which lines exactly you changed last > days... There were almost none in the install actually, but quite a few in dripkg, but if you removed all the mentioned files and the installation script ran fine without complains then that's most likely not the problem. The GATOS ati.2 doesn't seem to be either since the driver has the same name and would be overwritten. In 4 hrs a new snapshot should appear (with DMA enabled too). Please try it again. If nothing changes, then we'll need to make some heavy debugging, as with the PowerPC ;-) You can start to give us the last lines of /var/log/messages, as I think that there should be a kernel oops in there. The XFree86.log may be interesting too. > > Regards, > > Sergey > José Fonseca
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 machines. > > Don't worry about that, as I said, at least PPC has special instructions > to handle this. > > > I also avoided to increment the pointer inside the macros, just in case > the > > le32_to_cpu macro reuses it's argument. > > Certainly can't hurt... > > > > +#define MACH64_WRITE(reg,val) writel(val, MACH64_ADDR(reg)) > ^^^ > ...neither can braces here... > Ok. Added in my local tree for later CVS submission. > > > ... > > This looks overly complicated though. I'd just do this: > > @@ -544,7 +545,8 @@ > > --fifo; > /* data is already > little-endian */ > - MACH64_DEREF(reg) = > *p++; > + MACH64_WRITE(reg, > le32_to_cpu(*p)); > + p++; > used--; > > reg += 4; > > (sorry, my mailer probably wraps some lines) > The above complication was just to avoid use statements as macro arguments, but if you think that will never cause any problem, then this is just fine by me too. Peter, you do not need to bother with these details thought, as they are mostly comestic. Simply apply the previous patch and check if it works. Afterwards I'll commit the final result of all this discussion to CVS. José Fonseca ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 least PPC has special instructions
to handle this.
> I also avoided to increment the pointer inside the macros, just in case the
> le32_to_cpu macro reuses it's argument.
Certainly can't hurt...
> +#define MACH64_WRITE(reg,val)writel(val, MACH64_ADDR(reg))
^^^
...neither can braces here...
> @@ -535,17 +536,21 @@
> reg = MMSELECT( reg );
>
> while ( count && used ) {
> + u32 data;
> +
> if ( !fifo ) {
> if ( mach64_do_wait_for_fifo(
>dev_priv, 16 ) < 0 )
> return;
>
> fifo = 16;
> }
> -
> --fifo;
> - /* data is already little-endian */
> - MACH64_DEREF(reg) = *p++;
> +
> + data = le32_to_cpu(*p);
> + p++;
> used--;
> +
> + MACH64_WRITE(reg, data);
>
> reg += 4;
> count--;
This looks overly complicated though. I'd just do this:
@@ -544,7 +545,8 @@
--fifo;
/* data is already
little-endian */
- MACH64_DEREF(reg) =
*p++;
+ MACH64_WRITE(reg,
le32_to_cpu(*p));
+ p++;
used--;
reg += 4;
(sorry, my mailer probably wraps some lines)
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us:
[EMAIL PROTECTED]
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
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 a tip - which lines exactly you changed last days... Regards, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 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 instead > > > > > > > > #define MACH64_READ(reg)readl(MACH64_ADDR(reg)) > > > > #define MACH64_WRITE(reg,val) writel(val, MACH64_ADDR(reg)) > > > > > > 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 to the macros in cpu endianess. So in the > > > pseudo-DMA code in _dispatch_vertex, I changed the > > > > > > MACH64_WRITE(reg, *p++); > > > > > > to > > > > > > MACH64_DEREF(reg) = *p++; > > > > Maybe better > > > > MACH64_WRITE(le32_to_cpu(*p++), reg); > > > > ? > > > > > because the value (*p) is already little-endian, whereas the register > > > address has to be swapped from little-endian back to big-endian for the > > > MMSELECT(reg). So wouldn't you have to swap the value back to big-endian > > > as well in order to use this modified MACH64_WRITE macro? > > > > Yes, but it's already done correctly AFAICS on mach64_state.c line 530: > > > > reg = le32_to_cpu(*p++); > > > > That's the register address (addresses and data are interleaved in the > buffer pointed to by p). The data isn't swapped back to little-endian, arrggh! I mean to saw back to big-endian. All this swapping has me dizzy. ;) Anyway, Jose's patch looks good. > but your suggestion above should work (just need to switch the args): > > MACH64_WRITE(reg, le32_to_cpu(*p++)); > > -- Leif Delgass http://www.retinalburn.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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: > > > > > > > > #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 instead > > > > > > #define MACH64_READ(reg) readl(MACH64_ADDR(reg)) > > > #define MACH64_WRITE(reg,val) writel(val, MACH64_ADDR(reg)) > > > > 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 to the macros in cpu endianess. So in the > > pseudo-DMA code in _dispatch_vertex, I changed the > > > > MACH64_WRITE(reg, *p++); > > > > to > > > > MACH64_DEREF(reg) = *p++; > > Maybe better > > MACH64_WRITE(le32_to_cpu(*p++), reg); > > ? > > > because the value (*p) is already little-endian, whereas the register > > address has to be swapped from little-endian back to big-endian for the > > MMSELECT(reg). So wouldn't you have to swap the value back to big-endian > > as well in order to use this modified MACH64_WRITE macro? > > Yes, but it's already done correctly AFAICS on mach64_state.c line 530: > > reg = le32_to_cpu(*p++); > That's the register address (addresses and data are interleaved in the buffer pointed to by p). The data isn't swapped back to little-endian, but your suggestion above should work (just need to switch the args): MACH64_WRITE(reg, le32_to_cpu(*p++)); -- Leif Delgass http://www.retinalburn.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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: > > > > > > > > #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 instead > > > > > > #define MACH64_READ(reg) readl(MACH64_ADDR(reg)) > > > #define MACH64_WRITE(reg,val) writel(val, MACH64_ADDR(reg)) > > > > 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 to the macros in cpu endianess. So in the > > pseudo-DMA code in _dispatch_vertex, I changed the > > > > MACH64_WRITE(reg, *p++); > > > > to > > > > MACH64_DEREF(reg) = *p++; > > Maybe better > > MACH64_WRITE(le32_to_cpu(*p++), reg); > > ? Whoops, should be: MACH64_WRITE(reg, le32_to_cpu(*p++)); of course... the difference in the order of arguments between this and read/writel is confusing... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 to the macros in cpu endianess. So in the
> pseudo-DMA code in _dispatch_vertex, I changed the
>
> MACH64_WRITE(reg, *p++);
>
> to
>
> MACH64_DEREF(reg) = *p++;
>
> because the value (*p) is already little-endian, whereas the register
> address has to be swapped from little-endian back to big-endian for the
> MMSELECT(reg). So wouldn't you have to swap the value back to big-endian
> as well in order to use this modified MACH64_WRITE macro?
yes, indeed. I never check how you implemented that so I overlooked.
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. I also avoided to
increment the pointer inside the macros, just in case the le32_to_cpu
macro reuses it's argument.
Peter, apply it by making something like
patch -p1 -i mach64-endian-mmio.diff
in the xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and
report back to us when you have time.
José Fonseca
Index: mach64_drv.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_drv.h,v
retrieving revision 1.1.6.3.2.10
diff -u -r1.1.6.3.2.10 mach64_drv.h
--- mach64_drv.h30 Apr 2002 12:21:20 - 1.1.6.3.2.10
+++ mach64_drv.h30 Apr 2002 22:37:35 -
@@ -354,9 +354,8 @@
#define MACH64_ADDR(reg) (MACH64_BASE(reg) + reg)
-#define MACH64_DEREF(reg) *(volatile u32 *)MACH64_ADDR(reg)
-#define MACH64_READ(reg) le32_to_cpu(MACH64_DEREF(reg))
-#define MACH64_WRITE(reg,val) do { MACH64_DEREF(reg) = cpu_to_le32(val); } while (0)
+#define MACH64_READ(reg) readl(MACH64_ADDR(reg))
+#define MACH64_WRITE(reg,val) writel(val, MACH64_ADDR(reg))
#define DWMREG00x0400
Index: mach64_state.c
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_state.c,v
retrieving revision 1.1.6.4.2.16
diff -u -r1.1.6.4.2.16 mach64_state.c
--- mach64_state.c 28 Apr 2002 18:48:59 - 1.1.6.4.2.16
+++ mach64_state.c 30 Apr 2002 22:37:36 -
@@ -527,7 +527,8 @@
while ( used ) {
u32 reg, count;
- reg = le32_to_cpu(*p++);
+ reg = le32_to_cpu(*p);
+ p++;
used--;
count = (reg >> 16) + 1;
@@ -535,17 +536,21 @@
reg = MMSELECT( reg );
while ( count && used ) {
+ u32 data;
+
if ( !fifo ) {
if ( mach64_do_wait_for_fifo(
dev_priv, 16 ) < 0 )
return;
fifo = 16;
}
-
--fifo;
- /* data is already little-endian */
- MACH64_DEREF(reg) = *p++;
+
+ data = le32_to_cpu(*p);
+ p++;
used--;
+
+ MACH64_WRITE(reg, data);
reg += 4;
count--;
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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)) > > > #define MACH64_WRITE(reg,val) writel(MACH64_ADDR(val, reg)) > > > > > > > Sorry, i've mistaken writting it. It's instead > > > > #define MACH64_READ(reg)readl(MACH64_ADDR(reg)) > > #define MACH64_WRITE(reg,val) writel(val, MACH64_ADDR(reg)) > > 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 to the macros in cpu endianess. So in the > pseudo-DMA code in _dispatch_vertex, I changed the > > MACH64_WRITE(reg, *p++); > > to > > MACH64_DEREF(reg) = *p++; Maybe better MACH64_WRITE(le32_to_cpu(*p++), reg); ? > because the value (*p) is already little-endian, whereas the register > address has to be swapped from little-endian back to big-endian for the > MMSELECT(reg). So wouldn't you have to swap the value back to big-endian > as well in order to use this modified MACH64_WRITE macro? Yes, but it's already done correctly AFAICS on mach64_state.c line 530: reg = le32_to_cpu(*p++); PS: http://www.byteswap.net/mikesnotes/2002/getting-started/ is a nice introductory article about cross-platform lowlevel programming. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 and DMA
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 app's window is just black > > after starting it, full CPU load in the kernel and the X-server reacts > > very slowly. I get the following kind of messages in/var/log/kern.log > > repeatedly (about one of these blocks per second): > > > > Apr 30 14:24:19 viking kernel: [drm] failed! GUI_STAT=0x0201 > > Apr 30 14:24:19 viking kernel: [drm] mach64_do_wait_for_idle failed > > Apr 30 14:24:19 viking kernel: [drm] resetting engine ... > > This is odd. The card never gets idle but X keeps working so the card is > not locked. Well, once a DMA pass fails, you've got to reboot to get DMA back, so the engine reset allows things to continue, but it'll keep locking up. The right thing to do at this point is probably to bail out rather than switch to MMIO, since it indicates a problem with DMA. I guess we'll need to add a return value to _dispatch_vertex and have _dma_vertex return an error code. > We really need to add variable that indicated if DMA is working or not so > that we can fallback to MMIO when it fails. I'm almost done with this. What I'm doing is enabling/disabling DMA only at X server start up. As I said above, I don't think it makes sense to switch from DMA to MMIO while the server is running, because if a lock-up happens, that indicates a bug we need to know about. For that matter, it's still a bug if it DMA fails at server start-up, but it will let you run the X server if DMA has been messed up, fall back to MMIO, and the system log will indicate which mode is being used. I'll check this in soon. > I wonder if these different behaviours regarding the FIFO & DMA are > related to specific mach64 chip versions? > > > > > I also wanted to try it without DMA. But just changing the #define > > MACH64_DMA in mach64_drv.h didn't trigger any recompiling. Is there > > something wrong with the dependencies? > > > > Yep. You can't depend on dependencies. Verytime I mess in a header I do > > make -f Makefile.linux clean mach64.o > > > > Regards, > >Felix > > > > José Fonseca > > ___ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: >[EMAIL PROTECTED] > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Leif Delgass http://www.retinalburn.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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%20Driver%20Will%20Work%20On%20The%20Power%20Macintosh.htm
>
> it issues a special instruction to deal with the memory ordering in the IO.
So {read,write}l are what I thought {in,out}_le32 were. (The former are
defined as the latter on PPC so I knew it all along ;)
> Early this day I had sent a post to linux-kernel,
> http://www.ussg.iu.edu/hypermail/linux/kernel/0204.3/0914.html, and they
> also confirmed that the ordering is guaranteed by readl/writel macros in
> what concerns the compiler and the memory. The bus is another story (and
> it can't be solved with memory barriers), but let's see if this works
> first.
This is all the DDX driver uses so it should be fine. If there are still
problems with the FIFO then they must be something different.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us:
[EMAIL PROTECTED]
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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)) > > > > Sorry, i've mistaken writting it. It's instead > > #define MACH64_READ(reg) readl(MACH64_ADDR(reg)) > #define MACH64_WRITE(reg,val) writel(val, MACH64_ADDR(reg)) > 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 to the macros in cpu endianess. So in the pseudo-DMA code in _dispatch_vertex, I changed the MACH64_WRITE(reg, *p++); to MACH64_DEREF(reg) = *p++; because the value (*p) is already little-endian, whereas the register address has to be swapped from little-endian back to big-endian for the MMSELECT(reg). So wouldn't you have to swap the value back to big-endian as well in order to use this modified MACH64_WRITE macro? -- Leif Delgass http://www.retinalburn.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 instead #define MACH64_READ(reg)readl(MACH64_ADDR(reg)) #define MACH64_WRITE(reg,val) writel(val, MACH64_ADDR(reg)) José Fonseca ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 the MMIO:
#define MACH64_READ(reg) readl(MACH64_ADDR(reg))
#define MACH64_WRITE(reg,val)writel(MACH64_ADDR(val, reg))
Just tell if it worked or you've noticed any difference.
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%20Driver%20Will%20Work%20On%20The%20Power%20Macintosh.htm
it issues a special instruction to deal with the memory ordering in the IO.
Early this day I had sent a post to linux-kernel,
http://www.ussg.iu.edu/hypermail/linux/kernel/0204.3/0914.html, and they
also confirmed that the ordering is guaranteed by readl/writel macros in
what concerns the compiler and the memory. The bus is another story (and
it can't be solved with memory barriers), but let's see if this works
first.
Since the last replies weren't yet on the linux-kernel archive, I've
include them in the end of this document.
Regards,
José Fonseca
- Begin Forwarded Message -
Date: 2002.04.30 21:01
Subject: Re: How to write portable MMIO code?
From: Jesse Barnes <[EMAIL PROTECTED]>
To: Kai Germaschewski <[EMAIL PROTECTED]>
CC: José Fonseca <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
On Tue, Apr 30, 2002 at 02:41:56PM -0500, Kai Germaschewski wrote:
> Well, my understanding is the following: (if I get something wrong,
> hopefully somebody who's reading this will correct me)
>
> the barrier(), {,r,w}mb() stuff is for actually for normal memory
> accesses.
>
> About barrier():
>
> If you have
>
> *p1 = 1; *p2 = 2;
>
> the compiler may decide to reorder this to (if it knows that p1 != p2)
>
> *p2 = 2; *p1 = 1;
>
> A barrier() in between will inhibit this reordering.
>
> For some archs, even the barrier() is not sufficient to serialize the
> accesses to RAM. The compiler may generate something like
>
> mov [p1], 1
> mov [p2], 2
>
> but on e.g. alpha (where the asm would look differently ;-), the
processor
> may decide to put the second instruction on the memory bus before the
> first one. Only an mb in between will guarantee the ordering on the
> memory bus.
That's a good summary of the memory ordering issues one normally runs
into.
> Now, for IO, basically the same holds, though I wouldn't want to
guarantee
> that the macros designed for the memory bus would work on the PCI bus as
> expected.
Right. In fact, waiting on I/O busses can take a bit longer than
making sure the processor executes memory transactions in the order
you'd like.
> However, I do *believe*, that the readl/writel functions implicitly do
the
> right thing and introduce barriers where needed. On x86 e.g., the macros
> do a cast to (volatile *), which will ensure that these functions are
> compiled without reordering. As x86 is strongly ordered, no additional
> mb() or whatever is necessary (nor does it exist) to make sure that this
> ordering will propagate to the PCI bus.
Right, readl/writel will order things wrt the compiler and
processor, but not necessarily the I/O bus. On IA64, we've introduced
mmiob() to address this. It acts just like mb(), but wrt I/O address
space. The ia64 patch for 2.5 includes some documentation about it,
I'd love to see other arches implement something similar (even as a
simple nop) so that machines with weakly ordered I/O busses will work
as expected.
Jesse
- End Forwarded Message -
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us:
[EMAIL PROTECTED]
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 and DMA
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 load in the kernel and the X-server reacts > very slowly. I get the following kind of messages in/var/log/kern.log > repeatedly (about one of these blocks per second): > > Apr 30 14:24:19 viking kernel: [drm] failed! GUI_STAT=0x0201 > Apr 30 14:24:19 viking kernel: [drm] mach64_do_wait_for_idle failed > Apr 30 14:24:19 viking kernel: [drm] resetting engine ... This is odd. The card never gets idle but X keeps working so the card is not locked. We really need to add variable that indicated if DMA is working or not so that we can fallback to MMIO when it fails. I wonder if these different behaviours regarding the FIFO & DMA are related to specific mach64 chip versions? > > I also wanted to try it without DMA. But just changing the #define > MACH64_DMA in mach64_drv.h didn't trigger any recompiling. Is there > something wrong with the dependencies? > Yep. You can't depend on dependencies. Verytime I mess in a header I do make -f Makefile.linux clean mach64.o > Regards, >Felix > José Fonseca ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] >>>Free investment info.<<
Warning Unable to process data: multipart/mixed;boundary="=_NextPart_000_00B3_81A04E8E.B7871A65"
[Dri-devel] radeon mobility and vt problems
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 8.2), but I'd like to know if there is some hint on what the bug is (I haven't seen a message about this since April 15th). Thanks for the great work you're doing on dri, Alan -- The hacker: someone who figured things out and made something cool happen. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
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 mastering > > is detected. Is it possible to do it in today/tommorow snapshots? Just > > to test... > > Putting the check will take a little more than that (I have a paper > submission deadline in 1 June and I'm barely starting to do the research I > proposed to do in that paper, so I'm a great deal of pressure to get > results ASAP), but I can put the DMA by default so that the interested > ones can try. In the worst case, they can always use the > mach64-0-0-3-branch. I'll work on this, it should be fairly simple to do. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 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
> > > > > swap. Perhaps because within a pixel, the color disposition isn't
> > > > changed
> > > > > across little/big endian architectures.
> > > >
> > > > I was going to explain this is due to 32 bit swapping exchanging 16 bit
> > > > texels, but on second thought it should work if both the texture and
> > > > framebuffer use the same bpp.
> > > >
> > > > Where can I see that screenshot? :)
> > >
> > > Is in Peter's last message with attachement.
> >
> > I don't seem to have gotten that.
>
> It seems that the mailing list eat it! I attached it again.
Thanks, let's see if this one gets through the list, maybe not due to
its size.
It looks as I expected, however I still wonder how this comes with 16
bit textures in depth 16 (right?).
> > > I still don't know how to define the MMIO to be portable... Shouldn't we
> > > use the read/write* macros instead of cpu_to_le32/le32_to_cpu?
> >
> > Good idea! I've been missing those.
> >
> > > Shouldn't be a wmb() on writes and a mb() on reads ?
> >
> > Most definitely.
> >
> > > Everywhere I look I read a different way of how to do... it's insane!
> >
> > Indeed, so let me repeat my proposal to do something like this for all
> > drivers on all architectures:
> >
> > #define ##_READ(reg)(_##_READ(##_ADDR(reg)))
> > static inline u32 _##_READ(u32 *addr)
> > {
> > mb();
> > return readl(addr);
> > }
> > #define ##_WRITE(reg,val) \
> > do {\
> > wmb(); \
> > writel(val,##_ADDR(reg)); \
> > } while (0)
> >
>
> This I like it more. Although it's the safe bet (and doesn't affect the
> x86 architecture), it's a little overkill to have wmb() in every write.
> It's only needed when the order of writes do matter.
Which tends to be the case for register writes, doesn't it?
> On the other hand the bulk of data is sent via DMA anyway.
>
> > (I wonder if the wmb() shouldn't rather be after the writel() in
> > ##_WRITE() ...)
> >
>
> It's the same, since in a set of writes there will be always one extra
> wmb() either at the beginning or the end.
But the one at the beginning is really useless IMHO while the one at the
end assures that the last write hits the bus. This is what the DDX MMIO
macros do.
> > Looks like this could even be templated?
>
> I don't think that the C preprocessor would allow templates in the
> macros names...
You're probably right, maybe a preprocessor wizard can think of a way?
Anyway, looking at that code I wonder why not use inline functions for
both?
static inline u32 mmio_in32(u32 *addr) {
mb();
return readl(addr);
}
static void mmio_out32(u32 *addr, u32 val) {
writel(val, addr);
wmb();
}
and then
#define ##_READ(reg)mmio_in32(##_ADDR(reg))
#define ##_WRITE(reg,val) mmio_out32(##_ADDR(reg),val)
That way the compiler might help us spot errors. Any drawbacks?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 meeting -, because the colors are ok. Looking
> > > > careful to the picture is seems that we have to word swap and not byte
> > > > swap. Perhaps because within a pixel, the color disposition isn't
> > > changed
> > > > across little/big endian architectures.
> > >
> > > I was going to explain this is due to 32 bit swapping exchanging 16 bit
> > > texels, but on second thought it should work if both the texture and
> > > framebuffer use the same bpp.
> > >
> > > Where can I see that screenshot? :)
> >
> > Is in Peter's last message with attachement.
>
> I don't seem to have gotten that.
>
It seems that the mailing list eat it! I attached it again, but the list said that my
message awaited approval for being too big... !
>
> > I still don't know how to define the MMIO to be portable... Shouldn't we
> > use the read/write* macros instead of cpu_to_le32/le32_to_cpu?
>
> Good idea! I've been missing those.
>
> > Shouldn't be a wmb() on writes and a mb() on reads ?
>
> Most definitely.
>
> > Everywhere I look I read a different way of how to do... it's insane!
>
> Indeed, so let me repeat my proposal to do something like this for all
> drivers on all architectures:
>
> #define ##_READ(reg) (_##_READ(##_ADDR(reg)))
> static inline u32 _##_READ(u32 *addr)
> {
> mb();
> return readl(addr);
> }
> #define ##_WRITE(reg,val) \
> do { \
> wmb(); \
> writel(val,##_ADDR(reg)); \
> } while (0)
>
This I like it more. Although it's the safe bet (and doesn't affect the
x86 architecture), it's a little overkill to have wmb() in every write.
It's only needed when the order of writes do matter. On the other hand
the bulk of data is sent via DMA anyway.
> (I wonder if the wmb() shouldn't rather be after the writel() in
> ##_WRITE() ...)
>
It's the same, since in a set of writes there will be always one extra
wmb() either at the beginning or the end.
> Looks like this could even be templated?
>
I don't think that the C preprocessor would allow templates in the
macros names...
Jose Fonseca
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 picture is seems that we have to word swap and not byte
> > > swap. Perhaps because within a pixel, the color disposition isn't
> > changed
> > > across little/big endian architectures.
> >
> > I was going to explain this is due to 32 bit swapping exchanging 16 bit
> > texels, but on second thought it should work if both the texture and
> > framebuffer use the same bpp.
> >
> > Where can I see that screenshot? :)
>
> Is in Peter's last message with attachement.
I don't seem to have gotten that.
> I still don't know how to define the MMIO to be portable... Shouldn't we
> use the read/write* macros instead of cpu_to_le32/le32_to_cpu?
Good idea! I've been missing those.
> Shouldn't be a wmb() on writes and a mb() on reads ?
Most definitely.
> Everywhere I look I read a different way of how to do... it's insane!
Indeed, so let me repeat my proposal to do something like this for all
drivers on all architectures:
#define ##_READ(reg)(_##_READ(##_ADDR(reg)))
static inline u32 _##_READ(u32 *addr)
{
mb();
return readl(addr);
}
#define ##_WRITE(reg,val) \
do {\
wmb(); \
writel(val,##_ADDR(reg)); \
} while (0)
(I wonder if the wmb() shouldn't rather be after the writel() in
##_WRITE() ...)
Looks like this could even be templated?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 > > swap. Perhaps because within a pixel, the color disposition isn't > changed > > across little/big endian architectures. > > I was going to explain this is due to 32 bit swapping exchanging 16 bit > texels, but on second thought it should work if both the texture and > framebuffer use the same bpp. > > Where can I see that screenshot? :) > Is in Peter's last message with attachement. I still don't know how to define the MMIO to be portable... Shouldn't we use the read/write* macros instead of cpu_to_le32/le32_to_cpu? Shouldn't be a wmb() on writes and a mb() on reads ? Everywhere I look I read a different way of how to do... it's insane! José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 fields are horiziotal. > >> Perhaps the screenshot will speak more clearly. > >> > >> Nice effect! ;-) > >> > >> It's probably the textures that must be byte swapped too. > > > > Do you mean the "texture mapping drivers" in DRI or in the program > > (prboom)? If i run the program with indirect rendering the textures work > > ok. I had the same problems when running quake. > > I meant in the drivers. 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 > swap. Perhaps because within a pixel, the color disposition isn't changed > across little/big endian architectures. I was going to explain this is due to 32 bit swapping exchanging 16 bit texels, but on second thought it should work if both the texture and framebuffer use the same bpp. Where can I see that screenshot? :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 and DMA
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 slowly. I get the following kind of messages in/var/log/kern.log repeatedly (about one of these blocks per second): Apr 30 14:24:19 viking kernel: [drm] failed! GUI_STAT=0x0201 Apr 30 14:24:19 viking kernel: [drm] mach64_do_wait_for_idle failed Apr 30 14:24:19 viking kernel: [drm] resetting engine ... Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm]AGP_BASE = 0xd000 Apr 30 14:24:19 viking kernel: [drm]AGP_CNTL = 0x0003003e Apr 30 14:24:19 viking kernel: [drm] ALPHA_TST_CNTL = 0x0470 Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm] BM_COMMAND = 0x40001000 Apr 30 14:24:19 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ffe48 Apr 30 14:24:19 viking kernel: [drm]BM_GUI_TABLE = 0x003e4000 Apr 30 14:24:19 viking kernel: [drm] BM_STATUS = 0x130860ca Apr 30 14:24:19 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0xd000 Apr 30 14:24:19 viking kernel: [drm] BM_SYSTEM_TABLE = 0x9360cb02 Apr 30 14:24:19 viking kernel: [drm]BUS_CNTL = 0x7b3fa051 Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm] CLR_CMP_CLR = 0x Apr 30 14:24:19 viking kernel: [drm]CLR_CMP_CNTL = 0x Apr 30 14:24:19 viking kernel: [drm] CONFIG_CHIP_ID = 0x2700474d Apr 30 14:24:19 viking kernel: [drm] CONFIG_CNTL = 0x3506 Apr 30 14:24:19 viking kernel: [drm]CONFIG_STAT0 = 0x0096 Apr 30 14:24:19 viking kernel: [drm]CONFIG_STAT1 = 0x Apr 30 14:24:19 viking kernel: [drm]CONFIG_STAT2 = 0x Apr 30 14:24:19 viking kernel: [drm] CRC_SIG = 0x Apr 30 14:24:19 viking kernel: [drm] CUSTOM_MACRO_CNTL = 0x007f0779 Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm] DP_BKGD_CLR = 0x Apr 30 14:24:19 viking kernel: [drm] DP_FRGD_CLR = 0x Apr 30 14:24:19 viking kernel: [drm] DP_MIX = 0x00070007 Apr 30 14:24:19 viking kernel: [drm]DP_PIX_WIDTH = 0x40040444 Apr 30 14:24:19 viking kernel: [drm] DP_SRC = 0x0505 Apr 30 14:24:19 viking kernel: [drm] DP_WRITE_MASK = 0x Apr 30 14:24:19 viking kernel: [drm] DSP_CONFIG = 0x003b057f Apr 30 14:24:19 viking kernel: [drm] DSP_ON_OFF = 0x0158054a Apr 30 14:24:19 viking kernel: [drm]DST_CNTL = 0x0003 Apr 30 14:24:19 viking kernel: [drm] DST_OFF_PITCH = 0x14012c00 Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm]EXT_MEM_CNTL = 0xecf1 Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm] FIFO_STAT = 0x Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm] GEN_TEST_CNTL = 0x0180 Apr 30 14:24:19 viking kernel: [drm]GUI_CMDFIFO_DATA = 0x14012c00 Apr 30 14:24:19 viking kernel: [drm] GUI_CMDFIFO_DEBUG = 0x0040 Apr 30 14:24:19 viking kernel: [drm]GUI_CNTL = 0x Apr 30 14:24:19 viking kernel: [drm]GUI_STAT = 0x0200 Apr 30 14:24:19 viking kernel: [drm] GUI_TRAJ_CNTL = 0x0003 Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm] HOST_CNTL = 0x Apr 30 14:24:19 viking kernel: [drm]HW_DEBUG = 0x48833800 Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm] MEM_ADDR_CONFIG = 0x00200213 Apr 30 14:24:19 viking kernel: [drm]MEM_BUF_CNTL = 0x00382848 Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm] SCALE_3D_CNTL = 0x0b41000f Apr 30 14:24:19 viking kernel: [drm]SCRATCH_REG0 = 0x04900400 Apr 30 14:24:19 viking kernel: [drm]SCRATCH_REG1 = 0x Apr 30 14:24:19 viking kernel: [drm] SETUP_CNTL = 0x3100 Apr 30 14:24:19 viking kernel: [drm]SRC_CNTL = 0x0f00 Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm]TEX_CNTL = 0x Apr 30 14:24:19 viking kernel: [drm] TEX_SIZE_PITCH = 0x Apr 30 14:24:19 viking kernel: [drm]TIMER_CONFIG = 0x Apr 30 14:24:19 viking kernel: [drm] Apr 30 14:24:19 viking kernel: [drm] Z_CNTL = 0x0110 Apr 30 14:24:19 viking kernel: [drm] Z_OFF_PITCH = 0x14025800 Apr 30 14:24:19 viking kernel: [drm] I also wanted to try it without DMA. But just changing the #define MACH64_DMA in mach64_drv.h didn't trigger any recompiling. Is there something wrong with the dependencies? Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
> 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 in this
> situation the kernel module is being used and the install.sh script will
> surely fail to remove it from memory.
I run ATI.2 drivers from GATOS. AFAIK this should not cause problems,
should it?
> Please check that the mach64.o in the kernel, the mach64_dri.so and the
> ati_{drv,misc}.o files in your system were indeed updated by install.sh
> script. (They path should popup if you run "locate" with their name).
OK. I will do and report.
> Putting the check will take a little more than that (I have a paper
> submission deadline in 1 June and I'm barely starting to do the research I
> proposed to do in that paper, so I'm a great deal of pressure to get
Best luck with this.
> results ASAP), but I can put the DMA by default so that the interested
> ones can try. In the worst case, they can always use the
> mach64-0-0-3-branch.
For me it's OK. I'm just afraid I'm not the only tester in town:)
> PS: Don't remove the working mach64-0-0-3 snapshot that you may have, as
> they will eventually get deleted from the DRI website.
Thanks for warning. BTW, probably it would make sense to move them to
separate directory - so people would know where to look more-less
"stable":) drivers... Also, even after purging, the latest 0-0-3
snapshot would be nice to leave on FTP. Just in case... 1.5M is not very
large volume...
Cheers,
Sergey
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How much video memory is needed?
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
> "install.sh" and restarting X was enough. OK, if you tell 0-0-4
> _requires_ me to stop X before installing...
>
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 in this
situation the kernel module is being used and the install.sh script will
surely fail to remove it from memory.
> > There shouldn't be much difference since DMA is off. (DMA at this time
> > even slows things more)
> I am aware of it. So I do not expect too much:)
>
> > > better than 191 in Mesa). Anyway, X is still unable to shut down
> > > gracefully - at "killall X" in xterm I get frozen screen (though
> > > Ctl-Alt-Del works as if I were in console).
> > mmm.. I don't see what it could be.
> Is there any way I can help do find the reason?
>
> > As said, there could be some problems with the install.sh not replacing
>
> > everything properly. That's the more likely.
> Again, how can I debug this?
Please check that the mach64.o in the kernel, the mach64_dri.so and the
ati_{drv,misc}.o files in your system were indeed updated by install.sh
script. (They path should popup if you run "locate" with their name).
The reason is that I've changed the dripkg/install scripts sometime, and I
didn't receive any feedback (positive or negative) so something could be
going wrong and it's best to be sure of that before looking for other
explanations - especially since no one who built directly from CVS
experienced that so far.
>
> > 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 mastering
> is detected. Is it possible to do it in today/tommorow snapshots? Just
> to test...
Putting the check will take a little more than that (I have a paper
submission deadline in 1 June and I'm barely starting to do the research I
proposed to do in that paper, so I'm a great deal of pressure to get
results ASAP), but I can put the DMA by default so that the interested
ones can try. In the worst case, they can always use the
mach64-0-0-3-branch.
PS: Don't remove the working mach64-0-0-3 snapshot that you may have, as
they will eventually get deleted from the DRI website.
>
> Cheers,
>
> Sergey
>
José Fonseca
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Status of tcl branch
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 isn't a problem with the Radeon > Mobility M6 that I have, so it seems to be a tcl related issue. Can you run this with "RADEON_DEBUG=fallback" and report the results? Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
> 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 tell 0-0-4 _requires_ me to stop X before installing... > There shouldn't be much difference since DMA is off. (DMA at this time > even slows things more) I am aware of it. So I do not expect too much:) > > better than 191 in Mesa). Anyway, X is still unable to shut down > > gracefully - at "killall X" in xterm I get frozen screen (though > > Ctl-Alt-Del works as if I were in console). > mmm.. I don't see what it could be. Is there any way I can help do find the reason? > As said, there could be some problems with the install.sh not replacing > everything properly. That's the more likely. Again, how can I debug this? > 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 mastering is detected. Is it possible to do it in today/tommorow snapshots? Just to test... Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How much video memory is needed?
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 restarted X. I got segmentation fault > on glxinfo - after displaying most (or all?) of the info in xterm. Then > glxgears just did not want to start - some drmMach64Clean... (sorry, I > forget to write it down) returned -22. What could this be? > > Well, then I wanted to stop X and switched to vconsole 1 - and the whole > display froze (but not the whole system!) - so I managed to reboot > correctly. > 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). > After this point, I managed to run X and even run glxgears and glxinfo > without problems (though glxgears gives 268fps vs 286 in 0-0-3 - anyway, There shouldn't be much difference since DMA is off. (DMA at this time even slows things more) > better than 191 in Mesa). Anyway, X is still unable to shut down > gracefully - at "killall X" in xterm I get frozen screen (though > Ctl-Alt-Del works as if I were in console). mmm.. I don't see what it could be. > > In XFree86.0.log DRM is reported "on" (glxinfo has same idea). > > Well, later I will play more... As said, there could be some problems with the install.sh not replacing everything properly. That's the more likely. > > BTW, is there any way to check whether DMA is on or off? Can I see it in > /proc/dma? 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. > > Thanks for your efforts, > > Lazy tester Sergey > :) José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
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 speak more clearly. >> >> Nice effect! ;-) >> >> It's probably the textures that must be byte swapped too. > > Do you mean the "texture mapping drivers" in DRI or in the program > (prboom)? If i run the program with indirect rendering the textures work > ok. I had the same problems when running quake. > > Peter > I meant in the drivers. 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 swap. Perhaps because within a pixel, the color disposition isn't changed across little/big endian architectures. Another thing that was suggested was to put memory barriers to avoid processor memory cache when accessing the memory-maped IO registers, which could be causing the noticed behaviour without DMA. I'll come back to you again when these things are commited to CVS. José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How much video memory isneeded?
> 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 displaying most (or all?) of the info in xterm. Then glxgears just did not want to start - some drmMach64Clean... (sorry, I forget to write it down) returned -22. What could this be? Well, then I wanted to stop X and switched to vconsole 1 - and the whole display froze (but not the whole system!) - so I managed to reboot correctly. After this point, I managed to run X and even run glxgears and glxinfo without problems (though glxgears gives 268fps vs 286 in 0-0-3 - anyway, better than 191 in Mesa). Anyway, X is still unable to shut down gracefully - at "killall X" in xterm I get frozen screen (though Ctl-Alt-Del works as if I were in console). In XFree86.0.log DRM is reported "on" (glxinfo has same idea). Well, later I will play more... BTW, is there any way to check whether DMA is on or off? Can I see it in /proc/dma? Thanks for your efforts, Lazy tester Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
> 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 probably the textures that must be byte swapped too. Do you mean the "texture mapping drivers" in DRI or in the program (prboom)? If i run the program with indirect rendering the textures work ok. I had the same problems when running quake. Peter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64: How much video memory is needed?
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 to do. José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64: How much video memory is needed?
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 >screen size at the given depth (front, back, and depth buffers), plus >textures and pixmap cache. > -- "Free software is not for free." Kaz Sasayama <[EMAIL PROTECTED]>; Screen Name: kazssym Hyper Linux Systems (Hypercore Software Design, Ltd.) http://www.hypercore.co.jp/> ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
