Hi!
I have just compiled and installed the DRI cvs (7th mars 2003) on a umax
apus 3000 running suse linuxppc 7.1 and kernel 2.4.2. Compiling went fine
but i have two questions i would like to ask you.
1.) Everything works fine if i only run one display but when i try to run
two the X server won't
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 still
opts=debug
>cat /proc/kmsg > kmsg.txt
>start X from another console
>
>On Sat, 11 May 2002, Peter Andersson wrote:
>
I hope this will give you some information. At least i know that this
will be more informative than some of mine other mails.
When i ran the command "modprobe
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 adr
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:
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 "woul
>
>
>Yeah, can you try with the xscreensaver lament and glplanet hacks,
>tuxracer, armagetron, ... ?
>
I have just tried tuxracer and had the same problems, the only
difference is that the tetures are "less jagged". Its probably easier to
just look at the screenshot and you will see what i mean.
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 tr
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 bit game, does prboo
> 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
modu
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 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
the
> 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
> 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
>
>
>Try setting MACH64_VERBOSE back to zero in mach64_drv.h:
>
>#define MACH64_VERBOSE 0
>
>...and see if the jerkiness goes away.
>
>Also, could you try this:
>
>set MACH64_USE_DMA back to zero in mach64_drv.h, then change line 539 of
>mach64_state.c from:
>
>if ( mach64_do_wait_for_fi
>
>
>>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!!! T
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
_
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
> 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 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")
>
>
>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 actu
>
>
>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 ha
>>> 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:
>
>
>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 deco
>
>
>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 de
> Hi,
>
> I cvs updated mach64-0-0-4-branch last night and recompiled (previous
> update was on sunday). Right after starting glxgears the screen switched
> off (like with xset dpms force off) and the machine hung. The sysrq keys
> didn't work.
>
> Maybe Peter Anderson's problems are not P
>
>
>What PPC machine is this ? (sorry, I missed the beginning of the
>thread).
>
I am using an ibook "blueberry" with a 300mhz powerpc processor and ATI
rage 3D mobility 2X agp graphics board with 4mb of ram.
Peter
___
Dri-devel mailing list
[EM
> Peter, could you try this so that we could pin point where the fault
> occurred exactly. I don't know if it's needed to recompile the kernel
> to have more symbol information. On the x86 there is a specific option
> for that in the kernel configuration.
>
Sorry i can´t be of more help, but it
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 detai
Michel Dänzer wrote:
>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 a
>> - 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 tel
> Please do the following tasks via telnet and report back to the list:
> - Copy the Xfree86.0.log to a safe place and post it here.
Its attatched to this email.
>
> - Check if X is still running or not (ps -A | grep X) and point down
> it's pid, and if it is do:
>- do "gdb "
>-
>
>
>Please supply more information about the failure. Is there any message
>on the system log (usually /var/log/messages). Can you access the
>computer trhu network after the hang?
>
Yes, i can access the computer after the hang, via telnet and ftp.
Although i cannot shut down the computer via t
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
accelerate
>
>
>
>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)
>
>
>
>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 3
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 5625
kB video memory
The second problem is that the kernel identifies my graphi
After missing it several times on your home page i finally saw that
development for Ati Mach64 is underway. So i just thought i would
announce my interest in the project. I don´t know anything about writing
code but if you need some "test pilots" please let me know. I am
currently using an Ibo
38 matches
Mail list logo
