I have tried out the recent branch of DRI and found out that the
textures looks great! So does the open-GL for some apps that aren´t as
demanding on the hardware (doom, hexen etc). Quake 2 hogs all cpu and
locks the xserver (at least i think the x-server locks because i can´t
kill it). I
You are fast, i never would have thought you would answer this fast!
Leif Delgass wrote:
It looks like there's a problem with the drm initialization. Could you
send the kmsg output with debugging turned on:
close X
become root
rmmod mach64
modprobe mach64 drm_opts=debug
cat /proc/kmsg
I have tried the new cvs version of the mach64 -0-0-04 branch and the X
server can´t start. I have included the XF86 log as an attatchment, if
someone is interested in looking into this. As you know i don´t know
anything about programming so if you write to me keep in mind that you
have to
It looks like there's a problem with the drm initialization. Could you
send the kmsg output with debugging turned on:
close X
become root
rmmod mach64
modprobe mach64 drm_opts=debug
cat /proc/kmsg kmsg.txt
start X from another console
On Sat, 11 May 2002, Peter Andersson wrote:
I have
José Fonseca wrote:
On 2002.05.03 04:13 Peter Andersson wrote:
...
I have just downloaded and installed the latest cvs source (i assume
that you have applied the patch), at least i thought so when
comparing the patch with the would be patched files (mach64_drv.h
and mach64_state.c).
On Sat, 4 May 2002, José Fonseca wrote:
On 2002.05.04 11:35 Peter Andersson wrote:
José Fonseca wrote:
...
Peter, this is a regression. There may be two causes for this:
a) The use of readl/writel somehow poses even further problems.
b) Recent changes on the CVS broke
Leif Delgass wrote:
On Sat, 4 May 2002, José Fonseca wrote:
On 2002.05.04 11:35 Peter Andersson wrote:
José Fonseca wrote:
...
Peter, this is a regression. There may be two causes for this:
a) The use of readl/writel somehow poses even further problems.
b) Recent changes on the CVS broke
On 2002.05.03 04:13 Peter Andersson wrote:
...
I have just downloaded and installed the latest cvs source (i assume
that you have applied the patch), at least i thought so when comparing
the patch with the would be patched files (mach64_drv.h and
mach64_state.c). But i might be mistaken
On Wed, 2002-05-01 at 19:30, Peter Andersson wrote:
Michael, have you got hold of the screenshot or would you like me to re
send it to you?
I've seen it now, thanks.
I realized that Doom was an 8 bit game, does prboom use 8 bit textures?
That would explain how the columns get swapped.
--
On Fri, May 03, 2002 at 01:14:21AM +0200, Peter Andersson wrote:
Michel Dänzer wrote:
On Wed, 2002-05-01 at 19:30, Peter Andersson wrote:
Michael, have you got hold of the screenshot or would you like me to re
send it to you?
I've seen it now, thanks.
I realized that Doom was an 8
José Fonseca wrote:
On 2002.05.01 23:11 Peter Andersson wrote:
Leif Delgass wrote:
On Wed, 1 May 2002, Peter Andersson wrote:
I have compiled the new kernel drivers and get the following error
when trying to run glxgears:
Error flushing vertex buffer: return = -16
Peter
That
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
On Wed, 1 May 2002, Peter Andersson wrote:
Sorry about the lateness of my reply but i have been away over night and
didn´t get this mail until just recently. The patch fails when patching
mach64_state.c. It exits with HUNK #2 FAILED at 535 and i am not
comfortable with applying the
On Wed, 1 May 2002, Leif Delgass wrote:
Try the attached patch. It's merged with the current changes so it should
apply. I checked in some changes after Jose made his original patch.
Oops, I had an errant semicolon there. Try this one. Patch with:
patch -p0 -i mach64-endian-mmio-3.diff
I have compiled the new kernel drivers and get the following error when
trying to run glxgears:
Error flushing vertex buffer: return = -16
Peter
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
On Wed, 1 May 2002, Peter Andersson wrote:
I have compiled the new kernel drivers and get the following error when
trying to run glxgears:
Error flushing vertex buffer: return = -16
Peter
That means the engine is locking up. Either wait_for_idle fails (DMA)
or wait_for_fifo fails
Leif Delgass wrote:
On Wed, 1 May 2002, Peter Andersson wrote:
I have compiled the new kernel drivers and get the following error when
trying to run glxgears:
Error flushing vertex buffer: return = -16
Peter
That means the engine is locking up. Either wait_for_idle fails (DMA)
or
On 2002.05.01 23:11 Peter Andersson wrote:
Leif Delgass wrote:
On Wed, 1 May 2002, Peter Andersson wrote:
I have compiled the new kernel drivers and get the following error
when trying to run glxgears:
Error flushing vertex buffer: return = -16
Peter
That means the engine is
Well, it should work on both cases, but the patch was meant to test
with MACH_USE_DMA set to 0. Again, it should work with set as 1
(otherwise means a regression), but we wanted that it also worked with
set as 0.
I have just changed the MACH_USE_DMA to 0 and recompiled the kernel
modules
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
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
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
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
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
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 -
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 Tue, 2002-04-30 at 23:07, José Fonseca wrote:
The use of readl/writel just by itself introduces a novelty, since
according to
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
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
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
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)
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
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.
I did as you asked and commented out the line:
drmMach64FlushVertexBuffer( fd, prim, buffer-idx, buffer-used, 1 );
in xc/lib/GL/mesa/src/drv/mach64/mach64_ioctl.c
And as you predicted i got the error message:
Error: Could not get new VB... exiting,
Peter
On Mon, 29 Apr 2002, José Fonseca wrote:
On 2002.04.29 15:37 Peter Andersson wrote:
I did as you asked and commented out the line:
drmMach64FlushVertexBuffer( fd, prim, buffer-idx, buffer-used, 1 );
in xc/lib/GL/mesa/src/drv/mach64/mach64_ioctl.c
And as you predicted i got the
One thing that we can do to check that is in
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/mach64_drv.h
enable DMA my making
#define MACH64_USE_DMA 1
#define MACH64_VERBOSE 1
and redirect /proc/kmsg to a file.
It works!!! This is so cool :-) .
On Mon, 29 Apr 2002, Peter Andersson wrote:
One thing that we can do to check that is in
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/mach64_drv.h
enable DMA my making
#define MACH64_USE_DMA 1
#define MACH64_VERBOSE 1
and redirect /proc/kmsg
On 2002.04.29 19:30 Peter Andersson wrote:
...
It works!!! This is so cool :-) . I can run glxgears without a computer
Great!
crash or hang. It runs a bit jerky though, the gears spin for about a
second then the computer hangs for a second then the gears start
spinning again for a
On 2002.04.29 21:22 Peter Andersson wrote:
Leif Delgass wrote:
On Mon, 29 Apr 2002, Peter Andersson wrote:
...
Just to clarify, do you mean both things worked? If changing the
_wait_for_fifo to _wait_for_idle worked, I think we should keep it that
way so we have stable MMIO to fall
Thanks for the info, I know testing this can be a pain with all the
reboots. :)
It´s no problem, and its certainly worth it when you guys get this thing
working!
Well, it looks like the _dispatch_clear completes without a
problem. Could you run ksymoops on the syslog? That will decode the
The DMA test should work however, so if you update from cvs and this is working,
that's
a good start.
If it works, you should see all zeros for the registers
before the transfer and 0x, 0x, etc. after the transfer.
I suppose this is what you are talking about:
Apr 27
On Sun, 28 Apr 2002, Peter Andersson wrote:
Leif Delgass wrote:
On Sun, 28 Apr 2002, Peter Andersson wrote:
Well, it looks like the _dispatch_clear completes without a
problem. Could you run ksymoops on the syslog? That will decode the back
trace from the oops (it's best to run it
On Sun, 28 Apr 2002, Leif Delgass wrote:
On Sun, 28 Apr 2002, Peter Andersson wrote:
Leif Delgass wrote:
On Sun, 28 Apr 2002, Peter Andersson wrote:
Well, it looks like the _dispatch_clear completes without a
problem. Could you run ksymoops on the syslog? That will decode the
OK, I found out what was causing the oops, but I'm not sure why yet. It
was in mach64_dma_vertex:
buf_priv-prim = vertex.prim;
buf_priv-discard = vertex.discard;
I've disabled these lines until I can figure out what's wrong. Peter can
you update cvs and try it again?
Now i have
On Mon, 29 Apr 2002, Peter Andersson wrote:
OK, I found out what was causing the oops, but I'm not sure why yet. It
was in mach64_dma_vertex:
buf_priv-prim = vertex.prim;
buf_priv-discard = vertex.discard;
I've disabled these lines until I can figure out what's wrong. Peter can
hmmm.. OK, here are some questions for you: Did you actually see the
gears being drawn, or just the window with a black background?
I saw the gears. Previously when it crashed to xmon i only saw the
window with the black background. So this is the first time for me when
the gears actually
On 2002.04.29 00:33 Peter Andersson wrote:
hmmm.. OK, here are some questions for you: Did you actually see the
gears being drawn, or just the window with a black background?
I saw the gears. Previously when it crashed to xmon i only saw the
window with the black background. So this is
On Mon, 29 Apr 2002, José Fonseca wrote:
On 2002.04.29 00:33 Peter Andersson wrote:
hmmm.. OK, here are some questions for you: Did you actually see the
gears being drawn, or just the window with a black background?
I saw the gears. Previously when it crashed to xmon i only saw the
On Sun, 28 Apr 2002, Leif Delgass wrote:
On Mon, 29 Apr 2002, José Fonseca wrote:
On 2002.04.29 00:33 Peter Andersson wrote:
hmmm.. OK, here are some questions for you: Did you actually see the
gears being drawn, or just the window with a black background?
I saw the gears.
I said that u had to make ctrl-alt-del. This in PowerPC means what?
Can u still ssh? If yes a backtrace from glxgears would be great.
I can in no way connect to the computer at all, not via telnet or any
other remote terminal. Ctrl-alt-del (actually its
ctrl-apple-button-powerbutton) in
On 2002.04.29 01:29 Peter Andersson wrote:
I said that u had to make ctrl-alt-del. This in PowerPC means what? Can
u still ssh? If yes a backtrace from glxgears would be great.
I can in no way connect to the computer at all, not via telnet or any
other remote terminal. Ctrl-alt-del
mmm.. don't see why it didn't work. Well, from a ssh session do:
export DISPLAY=:0.0
DRI_MACH64_DEBUG=sync,api,msg,ioctl glxgears
Here is the output from the telnet session. Unfortunatley my telnet
client doesn´t have any scrollbar (do you know of any windows compatible
that do?). This
I found a better telnet client so here are the complete debug log...
Peter
mach64DDEnable( GL_CULL_FACE = GL_TRUE )
FLUSH_BATCH in mach64DDEnable
mach64DDEnable( GL_LIGHTING = GL_TRUE )
mach64UpdateSpecularLighting:
mach64DDEnable( GL_LIGHT0 = GL_TRUE )
mach64DDEnable( GL_DEPTH_TEST = GL_TRUE
On 2002.04.26 12:42 Michel Dänzer wrote:
On Fri, 2002-04-26 at 00:41, Peter Andersson wrote:
Vector 800 at pc - d58fb02c , lr -d58fb64
mxr - 9032, xp -4200
current - c99fc000, pid - 1077, comm -glxgears
mon
...
This is the xmon (simple kernel debugger) prompt.
So this
On Sat, 2002-04-27 at 09:50, José Fonseca wrote:
On 2002.04.26 12:42 Michel Dänzer wrote:
On Fri, 2002-04-26 at 00:41, Peter Andersson wrote:
I tried the backtrace option but it only produced a bunch of numbers
and
letters, and since i am not exactly sure if i am able to read them
On 2002.04.27 09:26 Michel Dänzer wrote:
On Sat, 2002-04-27 at 09:50, José Fonseca wrote:
...
In the mean while I'll try look at the last kmsg debug statements to
see if I found any further clue.
Isn't it the buglet Leif fixed tonight?
I don't see how. The function in which Leif
On 2002.04.27 15:33 Benjamin Herrenschmidt wrote:
I don't see how. The function in which Leif fixed the big had a debug
output statement which would appear in the kmsg if it was the last one.
From what I've read the *_nopage functions are associated with
accessing
memory maped regions.
On 2002.04.27 17:31 Leif Delgass wrote:
On 27 Apr 2002, Michel Dänzer wrote:
...
Isn't it the buglet Leif fixed tonight?
I changed virt_to_phys to virt_to_bus like you suggested, but that's in
the _dispatch_vertex. In the system log that Peter posted, the last
message before the
On Sat, 27 Apr 2002, José Fonseca wrote:
On 2002.04.27 15:33 Benjamin Herrenschmidt wrote:
I don't see how. The function in which Leif fixed the big had a debug
output statement which would appear in the kmsg if it was the last one.
From what I've read the *_nopage functions are
thread). On some PPC's like PReP, the mapping between bus addresses
and CPU physical addresses on PCI isn't 1:1 and the system RAM is
not mapped at 0 for bus mastering PCI devices. If you use the PCI
DMA API, things are ok. If you aren't, then some tweaks may be needed.
(See the definition
On Sat, 2002-04-27 at 18:31, Leif Delgass wrote:
When we get the MMIO path working for ppc, I think we'll still have to
make some changes for DMA. When filling the vertex buffers and setting up
the descriptor tables, won't we have to convert to little-endian?
Yes, unless the chip can
Peter, if you set
MACH64_VERBOSE to 1 in mach64_drv.h and rebuild the DRM, you should see a
debug statement for each register access. This could help us find the
problem. That being said though, I don't see where the _vm_dma_nopage
comes in between _dispatch_clear and the missing debug
On Sun, 28 Apr 2002, Peter Andersson wrote:
Peter, if you set
MACH64_VERBOSE to 1 in mach64_drv.h and rebuild the DRM, you should see a
debug statement for each register access. This could help us find the
problem. That being said though, I don't see where the _vm_dma_nopage
comes
On Sun, 28 Apr 2002, Leif Delgass wrote:
If it works, you should see the same 7 VERTEX_ register values in the
system log before and after the test.
Sorry, I meant to say that you should see all zeros for the registers
before the transfer and 0x, 0x, etc. after the transfer.
On Fri, 2002-04-26 at 00:41, Peter Andersson wrote:
Vector 800 at pc - d58fb02c , lr -d58fb64
mxr - 9032, xp -4200
current - c99fc000, pid - 1077, comm -glxgears
mon
When i type ? the following menu rolls up:
d dump bytes
didump instructions
dfdump float values
dd
On 2002.04.25 19:23 Leif Delgass wrote:
...
Jose, I just tried removing agpgart before starting X, and I'm getting a
kernel NULL pointer dereference. I think it's because we are using
dev_priv-buffers-handle to read the vertex buffers -- for PCI, there's
no DRM_FIND_MAP for
Please do the following tasks via telnet and report
back to the list:
- See if there is any application consuming all processor (top).
- Copy the Xfree86.0.log to a safe place and post it here.
- Check if X is still running or not (ps -A | grep X) and
point down
it's pid, and if
- Do the same steps as above with your opengl application.
I can´t see that because i have to kill it before the computer (telnet) responds
to any commands. At least i think i am killing it (i am
pressing the x button and then things seem to work again (if you are
using telnet)..
On Thu, 2002-04-25 at 14:52, Peter Andersson wrote:
- Do the same steps as above with your opengl application.
I can´t see that because i have to kill it before the computer (telnet)
responds to any commands. At least i think i am killing it (i am
pressing the x button and then
On Thu, 2002-04-25 at 14:27, Alexander Stohr wrote:
Please do the following tasks via telnet and report
back to the list:
- See if there is any application consuming all processor (top).
- Copy the Xfree86.0.log to a safe place and post it here.
- Check if X is still running or
Perhaps this will solve some questions about what happens when the
system craches when i run glxgears. After close inspection of the screen
i get aftewards i have been able to make out the following by trying to
combine the symbols in the two windows. But don´t trust the numbers or
any
I looked at your XFree86-log. It says you're using 32 bit color depth.
Try 16. That will reduce the amount of memory used by 2d and also
increase 3d performance a lot.
You are so right! I set the resolution to 16 bit and everything worked
as it should! I now have hardware accalerated 3D. I
On 2002.04.24 07:06 Felix Kühling wrote:
On Wed, 24 Apr 2002 07:44:59 +0200
Peter Andersson [EMAIL PROTECTED] wrote:
Okey, i think i have located some of the problems one is that there
only are 4mb of sdram on my Mach64 graphics board and that the driver
requests:
(WW) ATI(0): DRI
On Wed, 2002-04-24 at 07:44, Peter Andersson wrote:
The second problem is that the kernel identifies my graphicsboard as pci
while it is in fact agp. This might be due to a problem i had while
compiling the kernel, agpgart didn´t know what to do with flush_cache
for ppc so i had to cheat
On 2002.04.24 09:34 Michel Dänzer wrote:
...
Anyway, MACH64_{READ,WRITE} will likely have to be changed to use
{in,out}_le32 (in mach64_drv.h) for it to work on PPC.
As Peter managed to get everything to compile, yesterday I was looking
into this but when looking at r128_drv.h but it
Anyway, MACH64_{READ,WRITE} will likely have to be changed to use
{in,out}_le32 (in mach64_drv.h) for it to work on PPC.
You are probably right here because although the driver is loaded it
hangs when i try to use OpenGL applications, so far i have only tried
games prboom (doom clone) and
On Wed, 2002-04-24 at 10:52, José Fonseca wrote:
On 2002.04.24 09:34 Michel Dänzer wrote:
...
Anyway, MACH64_{READ,WRITE} will likely have to be changed to use
{in,out}_le32 (in mach64_drv.h) for it to work on PPC.
As Peter managed to get everything to compile, yesterday I was
On 2002.04.24 12:41 Michel Dänzer wrote:
On Wed, 2002-04-24 at 10:52, José Fonseca wrote:
On 2002.04.24 09:34 Michel Dänzer wrote:
...
Anyway, MACH64_{READ,WRITE} will likely have to be changed to use
{in,out}_le32 (in mach64_drv.h) for it to work on PPC.
As Peter managed to
On Wed, 2002-04-24 at 12:57, Peter Andersson wrote:
Anyway, MACH64_{READ,WRITE} will likely have to be changed to use
{in,out}_le32 (in mach64_drv.h) for it to work on PPC.
You are probably right here because although the driver is loaded it
hangs when i try to use OpenGL applications,
I have applied the patch and recompiled the entire dri tree and still
experience the same problems, eg the computer hangs when i try to use
open gl applications. Could this be a result of the program trying to
use the xv display method? As i have understood there are no hardware
accelerated
On Wed, 2002-04-24 at 18:33, Peter Andersson wrote:
I have applied the patch and recompiled the entire dri tree and still
This is not necessary. Once you build it once, you just need to go the
directory where the change was and make
make
su -c make install
unless it's in the kernel
On Wed, 24 Apr 2002 07:44:59 +0200
Peter Andersson [EMAIL PROTECTED] wrote:
Okey, i think i have located some of the problems one is that there
only are 4mb of sdram on my Mach64 graphics board and that the driver
requests:
(WW) ATI(0): DRI static buffer allocation failed -- need at least
82 matches
Mail list logo
