[Dri-devel] Reminder: IRC meeting log history - some logs are still missing
At http://dri.sourceforge.net/IRC-logs/ you will find these chat logs online: 20020121.txt22-Jan-2002 04:0062k 20020128.txt04-Feb-2002 11:0246k 20020204.txt07-Feb-2002 05:3441k 20020218.txt26-Feb-2002 16:2731k 20020225.txt26-Feb-2002 16:2737k I have heared that logs of the most recent chats do exist, but they are not yet submitted to the folks with access rights (i dont have developer rights on the dri project at SourceForge). But i think Michael (or some other developer) would care for this subject if you sent them the missing chatlogs via direct mail. Regards, Alex. -Original Message- From: Michel Dänzer [mailto:[EMAIL PROTECTED]] I moved all logs to http://dri.sourceforge.net/IRC-logs/ and added a FAQ entry about this. PS: Frank, the FAQ entries containing logs directly didn't work out so good because they are treated as HTML. Please remove them. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Access, was: Re: [Dri-devel] S3 Virge DRI completed (almost)
max wrote: On Monday 18 March 2002 20:59, Keith Whitwell wrote: What's your sourceforge login? It is 'sunmax'. Do you need pw too? Vale, - max P.S: tell me when you are done with my access. Thanks in advance. OK. Done. Let me know if you need help creating a branch for this. Make sure you read the CVS Policies document in the developer documentation section of dri.sf.net -- if in doubt, ask... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Reminder: IRC meeting log history - some logs arestill missing
On Die, 2002-03-19 at 15:58, Alexander Stohr wrote: At http://dri.sourceforge.net/IRC-logs/ you will find these chat logs online: 20020121.txt22-Jan-2002 04:0062k 20020128.txt04-Feb-2002 11:0246k 20020204.txt07-Feb-2002 05:3441k 20020218.txt26-Feb-2002 16:2731k 20020225.txt26-Feb-2002 16:2737k I have heared that logs of the most recent chats do exist, but they are not yet submitted to the folks with access rights (i dont have developer rights on the dri project at SourceForge). But i think Michael (or some other developer) would care for this subject if you sent them the missing chatlogs via direct mail. Absolutely, given time and any means to access the logs I'll put them up. -- 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-0-0-3-branch multitexture fix
I finally tracked down the last remaining major bug in the mach64 Mesa 4.x branch. The secondary texture filter wasn't being set in the correct register (was being set in scale_3d_cntl not tex_cntl), so it ended up enabling fog instead, which disables alpha blending! This was actually in the last branch too, so I'm not sure why this hadn't cropped up before (maybe I changed my quake settings and didn't remeber?). At any rate, the branch should now be at about the same state the previous branch was in. There are still some bugs remaining, and I plan on running glean and maybe some other test suites on the new branch as well. This would be a good time for testers to do a fresh checkout and look for bugs. When the trunk has stabilized, we can merge in any Mesa bugfixes too. So I think we can try to focus on the DMA work now. Frank, can you check in whatever you've got into the -dma branch? It doesn't matter if it's not done, I think it would be helpful for us to see where we stand now. One thing I want to try is using NOTEX or TINY vertices as well as textured verticies. It seems that mach64 ought to be able to handle those since spec_argb, z, argb, and x_y are sequential registers, and it could pump up our gears numbers a bit. ;) I'll see if I can get it to work with MMIO and if so, we could try those vertex formats with DMA as well. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 7500 Debug
Michel Dänzer wrote: On Die, 2002-03-19 at 08:22, Jean-Christophe Dubacq wrote: On Mon, Mar 18, 2002 at 09:18:47PM -0700, Jens Owen wrote: OK, I compiled the tcl-0-0 branch, installed it, and I still have two kind of bugs... X suddenly disappearing or hard lockups. How do I set debugging information ? http://dri.sourceforge.net/doc/DRIuserguide.html Thanks for the pointer. However, it happened again, even tough I had set Option NoAccel True # [bool] So this may not be the good mailing-list any more. I will try to use the LIBGL_DEBUG variable. But I am now thinking it could be a hardware issue. Very unlikely to be a driver problem indeed, as that option disables any 2D or 3D acceleration. 3D, too? I thought the NoAccel option only disabled 2D hardware rendering... -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Access, was: Re: [Dri-devel] S3 Virge DRI completed (almost)
On Tuesday 19 March 2002 15:58, Keith Whitwell wrote: OK. Done. Let me know if you need help creating a branch for this. Make sure you read the CVS Policies document in the developer documentation section of dri.sf.net -- if in doubt, ask... Keith mmm... I read through the CVS Policies doc, but being no CVS guru I am a bit confused. For the first time, I'd prefer you could suggest me the right cvs syntax to upload my branch. Just send me the list of CVS commands I will have to digit from my 'xc' dir. When I will commit Savage4 code, I will know something more on CVS so I will do it on my own. Promised. For the moment being, thanks in advance, vale, - max ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Virge DRI completed (almost)
On Tuesday 19 March 2002 10:31, you wrote:
yes, i compiled and installed it yesterday,
no problems compiling or anything, but am still having some problems.
all the gl demos i try only shows the first
frame(except one, Mesaimage which works ok, but it doesn't really do
anyhing except show a pixmap i think), then it locks up hard and i have to
reset the computer. The first frame looks great though =)
Yep. I feared that, I just had chance to test the code on my notebook, so I
hardcoded some timeout value. Everything we need to dig out the problem is in
s3v_dma.c, so try things in this order (just one at a time...)
* solution a) increase S3V_UDELAY to 1000 (1 is safe on Virge/MX, not so sure
on DX, VX, etc.). Recompile and try.
* solution b) we have a task queud in the timer task queue [s3v_dma_task],
which function is s3v_dma_check. In this function we issue a reset after we
have checked DMA buffer reading completion for 40 times. To see how many
times is (in average) taking on your machine, comment out the s3v_do_reset
after the line if (times40) {. Then uncomment printk(KERN_ERR *** buf
completed after %i... ... ...
Now run a program (it should not lock this time [it it does try in
conjunction with solution a]) and check the values printed: look for the
highest of the values (especially when running games like tuxracer or
quake2), and substitute it to the '40' I have hardcoded. The lower the value
the better the feeling.
*** The point is that sometimes Virge DMA engine stalls and you would have to
*** wait for ever for buffer completion, it will stop somewhere in the middle
*** of a buffer and won't go on until you reset. Maybe there is a better ***
*** solution for that. Any suggestion is welcome ; )
pseudo-soultion c) turn on S3V_DEBUG and send be the debug, so I will try to
find a best solution.
Note: if your machine is locking hard, it could be necessary to add an
udelay(1000) after printk in S3v_DEBUG, so we have some chance debug is being
written before lock happens. Good luck.
only thing in the log is 'and !s3v_dma_is_ready: -BAD-'
but that doesn't seem to affect anything, as it is also shown when i run
glxinfo.
That is normal. It just says that your DMA engine has been reset, when
s3v_dma was not ready. This will always happen the first time (at least on my
Virge/MX) since the write pointer of DMA is already a bit further of read
pointer (or viceversa?) [even if nothing has been written to card!], so when
you reset the pointer for the first time the code will just warn you, that
you issued a reset cmd when card was not ready (wp != rp).
i attached some logs if that helps
Logs seem ok. Could you tell me give more infos on your machine? (2mb virge
dx, + ...)
Linux 2.4.9-13smp
Are you running it on a SMP!? I am not sure my code is SMP-proof ; (
Could you try a more recent kernel? I am not a bleeding-edge geek, but I had
some problem with my code too with linux-2.4.x (x11). It runs fine with
2.4.18.
Option texbuffer_size 16384
If you are running demos with many texs, reserve a bit more memory to them.
If you are able to keep your so alive when running a gl app, could you please
send me a copy of cat /proc/dri/0/* dri.log (while gl app is executing)
Vale,
- max
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
