Re: [Dri-devel] mach64-0-0-7 branch illness and snapshots..
-X starts up fine now, window manager comes up, etc. -xvinfo reports xv working, playing mpeg with mplayer confirms this. -glxinfo reports correct info -glxgears locks up. Rest of X is locked, but mouse can be moved around. I can ssh in, but can't seem to kill the X server. A reboot is required to get the screen working again. wierd is their anything in dmesg? send me a copy of it .. I've just had a game of tuxracer and it works great for me .. I've also started two glxgears side by side ... and exited them.. does gears lock up after you try to exit it or straight away? if it is on exit, I'd re-build the tree and confirm yuou have the latest 2d driver as that is what was happening me before about 8 hours ago.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] UT2004 demo
Hi all. Just downloaded the UT2004 demo, and tried it out under XFree86-4.3.99.902. I'm pleasantly surprised. It runs quite nicely, and I can't spot any rendering bugs ( though I wasn't looking closely - I was more interested in shooting at things ). Anyway, congrats to all those responsible for the Radeon driver! One small issue I have is with the menu text. It's very blurry, and very hard to read. It looks a bit like the text has been shrunk to a very small size, and then blown back out to original size again. But it also just looks a bit ... 'blurry'. Has anyone tried UT2004 out yet, and if so, what card what version of XFree are you using, and do your menus display properly? Thanks! Dan --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 tcl and ut2003_demo, (since using MULT instead of PREMULT...)
Oops! I mean of course ut2004demo, not 2003. -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] blend color...
Ok, I was wrong that the radeon driver also doesn't implement this correctly. It just always uses a fallback, it just doesn't support it in hardware. That said, I'm wondering what's the purpose of announcing ARB_imaging support, at least out of the three blend extensions this includes (EXT_blend_color, EXT_blend_minmax, EXT_blend_subtract) two aren't supported at all and the third (blend_subtract) only half. Rasterization fallbacks are evil... On the R200, the RB3D_BLENDCOLOR register works correctly. The color format seems to be RGBA though, at least limited testing shows the values need to be supplied in that order (same as for other colors such as fog). Roland btw sorry for the new thread, but I don't have access to the old thread here. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 tcl and ut2003_demo, (since using MULT instead of PREMULT...)
Am 2004.02.14 00:11:35 +0100 schrieb(en) Roland Scheidegger: Andreas Stenglein wrote: Just tried ut2003 on R100 with current DRI+MESA cvs HEAD. Now with the MULT-code in radeon_state.c radeon_state_init.c (change lighting to use MULT instead of PREMULT ...) the shading/lighting of warriors changed a little bit in tcl-mode. It's been buggy before in tcl-mode, but differently. Now it is better visible at startup, when the warrior jumps through the logo. And it is visible for example when spectating some bot. This looks OK in non-tcl-mode. What exactly does it look like? Does it flicker or so? Just the other yes, it could be described as flickering shading of the model. day, I've noticed not even the good old tuxracer runs correct on the R100 on my 2nd PC - the ice areas flickered a lot, but it runs fine on R200. The lighting changes didn't make a difference at all though in that game. I just hope UT2004 doesn't run even worse, I was too afraid to download the demo yet ;-). Roland greetings, Andreas --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Savage driver issues
Hi, First i would like to say that Alex and Felix are doing a great job with savage driver and every day it's getting better. I found some problems here with my savage4, now the textures are showing correctly and working just fine but i did some tests with Chromium BSU and it lockup on the main menu after sometime, it can be from 5 to 15 seconds to get the lockup but the game works just fine it only lockup on the main menu, but some days ago it was working without problems, i just got this problem after i got the latest driver from CVS. Another problem is with VESA fb, when i'm using vesafb and start XFree86 when a got back to text mode (quit XFree86) my screen is corrupted and i need to reboot because i cant see anything. Did you got this problem too? I also tried to play a game called GLtron and it locked up too after playing it for a minute. bye. Rafael Máximo --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: GATOS and DRI merge
Hi Hod, There is an easy way to generate patch with GATOS-specific changes: Checkout HEAD (and/or tv_output) branches from GATOS CVS. Checkout orig branch - this is the original XFree86 code we started from. diff -u one against the other. The changes should classify as following: 1. New code - i.e. theatre.c files and others 2. *_video.c files - these are heavily modified. Take care of atixv.c - Marc Aurele merged part of GATOS code into XFree86 3. *_driver.c files were modified to allow for new options 4. there should be changes to DRI that programs memory controller to move apertures (from chips point of view) so as to allow for PCI DMA. These are matched by changes in drm-kernel and Mesa driver. They are just a few lines. All of these are best thrown out and instead new code should make use of ability of DRI CVS to change these settings dynamically. 5. They are might be a few fixes (1 or 2) that are, strictly speaking, outside the scope of GATOS code (like DPMS and such) and were backported from XFree86 CVS tree. If they are indeed there they should be easy to spot. best Vladimir Dergachev On Wed, 11 Feb 2004, Hod McWuff wrote: On Wed, 2004-02-11 at 19:03, Michel Dänzer wrote: On Thu, 2004-02-12 at 00:26, Hod McWuff wrote: On Wed, 2004-02-11 at 17:28, Michel Dänzer wrote: By the way, where can I find a three-way merge tool? ;) I like meld, for example. I'll look into it. By the way, is there an index of CVS tags by date? Or should I just try to pull something by a date near when the first Gatos commits were made? I've found Gatos-related changes in radeon_cp.c, radeon_drv.h, and radeon_state.c. I've reimplemented what changes I could find... They're mostly superfluous AFAICT. Again, the DRM in current DRI CVS should basically work with the GATOS 2D driver, that one just needs to set up things similarly to how the 2D driver in DRI CVS does. I see two types of changes; adding dev_priv-fb_offset, and doing some bit masking. There's also the spot in radeon_cp where it appears to write a couple of new initializations to the card. You're sure those are superfluous? They're the only substantial differences I've been able to pick out thus far. OTOH, they haven't produced the desired result yet. Just to make sure we're on the same page, I'm doing all of my testing with XFree 4.3.0 plus Gatos ati.2. In all cases except in between the patch states I've outlined, 2D and TV (xawtv) work just fine. The only variable is whether DRI connects to DRM, whether it produces visible output, whether it locks on some apps or not. Software rendering, of course, works fine as long as the DRI isn't connected to a faulty DRM. The DRM and 3D driver in current DRI CVS should theoretically be able to work with their 2D driver. Its aperture setup may have to be changed slightly though. The one in 2.6.2 works with 2D (after faking the version number) Faking the version number is obviously a bad idea. The GATOS 2D driver The Gatos 3D driver won't even try to work unless the DRM version number is 1.100.0 or better. should work with the 1.10.0 radeon DRM with the changes described above. Those changes are exactly what I'm trying to isolate and port to the current CVS DRM. The GATOS 3D driver only works with the old GATOS DRM and 2D driver, but the 3D driver in current DRI CVS should work with anything, or at least fail gracefully. It fails gracefully, meaning the XFree logs show it rejecting the DRM outright. If I change the version number, things seem to work but the windows are always full of unchanging black. I realize you know better than I what does and doesn't work. The issue I'm trying to address is why, so that shortly we can have everything in the does-work category. 2.6.2-update.patch merges current DRI CVS into the 2.6.2 tree BTW, AFAIK the DRM in the -mm kernel tree is already fairly up to date. Good to know, but I'm more comfortable hacking against the vanilla tree, and it makes no sense to develop a patch against an obsolete version. I will look at the DRM changes in -mm compared to what I just merged, though. Some of the stuff in DRI CVS is only needed for compatibility with older kernels etc. I noticed that, but those are easy to strip back out later. An overloaded source makes it a little easier to pick out the kernel version differences from DRM version differences. As an aside though, perhaps a unified source is a good idea. It would make it tri --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list
Re: [Dri-devel] Savage driver issues
--- Rafael Maximo [EMAIL PROTECTED] wrote: Hi, First i would like to say that Alex and Felix are doing a great job with savage driver and every day it's getting better. I found some problems here with my savage4, now the textures are showing correctly and working just fine but i did some tests with Chromium BSU and it lockup on the main menu after sometime, it can be from 5 to 15 seconds to get the lockup but the game works just fine it only lockup on the main menu, but some days ago it was working without problems, i just got this problem after i got the latest driver from CVS. Hmmm... I had no problems with chromium BSU here last time I played. Another problem is with VESA fb, when i'm using vesafb and start XFree86 when a got back to text mode (quit XFree86) my screen is corrupted and i need to reboot because i cant see anything. Yeah, this is a know problem with kernel framebuffers. I can't seem to get the right combo of save and restore to restore the same text console that existed before starting X, so I just used the bios settextmode() call. it works for vga consoles, but not FB consoles. I'm looking for a fix and as soon as I figure it out, I'll update cvs. Did you got this problem too? I also tried to play a game called GLtron and it locked up too after playing it for a minute. I haven't tried gltron. I'll give it a look next time I get a chance. Thanks for testing and the report. Alex bye. Rafael Máximo __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage driver issues
At 02:06 PM 14/2/2004, Alex Deucher wrote: --- Rafael Maximo [EMAIL PROTECTED] wrote: I found some problems here with my savage4, now the textures are showing correctly and working just fine but i did some tests with Chromium BSU and it lockup on the main menu after sometime, it can be from 5 to 15 seconds to get the lockup but the game works just fine it only lockup on the main menu, but some days ago it was working without problems, i just got this problem after i got the latest driver from CVS. Hmmm... I had no problems with chromium BSU here last time I played. It only happen on the main menu, if i start the game quickly i can play without problems but if i take some time on the main menu it lockup. bye. Rafael Máximo --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GATOS and DRI merge attempts
On Sat, 2004-02-14 at 10:41, Dieter Nützel wrote: Do you get an empty/black window only? Yes! That's exactly what I'm getting... Then it could be the same bug as with quake3-smp (multiple contexts) introduced in June/July by Ian. I'm hunting on it... Greetings, Dieter --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] UT2004 demo
Has anyone tried UT2004 out yet, and if so, what card what version of XFree are you using, and do your menus display properly? I believe the OpenGL renderer drops miplevels there were it shouldn't when it decompresses the DXT textures. I'll fix that for the full game. -- Daniel, Epic Games Inc. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: GATOS and DRI merge
On Sat, 2004-02-14 at 10:53, Vladimir Dergachev wrote:
Checkout HEAD (and/or tv_output) branches from GATOS CVS.
Checkout orig branch - this is the original XFree86 code we started
from.
diff -u one against the other.
Doing that now. I'd been working against a pristine copy of X-4.3.0.
The changes should classify as following:
1. New code - i.e. theatre.c files and others
Plus the various tuner drivers. These were indeed easy ;) although, I
might have to put some more thought into merging the Imakefiles.+
2. *_video.c files - these are heavily modified. Take care of atixv.c -
Marc Aurele merged part of GATOS code into XFree86
Yes, I noticed that... these files were *FULL* of conflicts against the
current DRI CVS... to the extent that I'm worried about being able to
untangle them. Something like 140K of .rej files between radeon_video.c
and atixv.c. It would help to know from the DRI folks, if they've done
any major structural changes or if this is just bugfixes and minor code
movement.
3. *_driver.c files were modified to allow for new options
There were some conflicts here, but nothing I can't sift out by hand.
4. there should be changes to DRI that programs memory controller to
move apertures (from chips point of view) so as to allow for PCI DMA.
These are matched by changes in drm-kernel and Mesa driver. They
are just a few lines.
All of these are best thrown out and instead new code should make use
of ability of DRI CVS to change these settings dynamically.
OK, can someone give me an idea of what calls I'm looking for, and what
they should be doing instead? Are we talking strictly about what's in
{radeon,r128}_dri.c?
From what I understand the changes in this area are the main cause of my
problems. I can isolate what Gatos changed in this file, sure, but I
have no idea what to replace it with.
5. They are might be a few fixes (1 or 2) that are, strictly speaking,
outside the scope of GATOS code (like DPMS and such) and were
backported from XFree86 CVS tree. If they are indeed there they should
be easy to spot.
I'm guessing the changes to atiprobe.c fall into this category
atiregs.h seems to mostly be this sort of change, I'll have to pick
through by hand to be sure... also there seem to have been a few
endianness fixes merged in.
Thanks for responding,
- Hod McWuff
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch illness and snapshots..
Yeah, got a couple things here. First, the dmesg. the dma test is failing. It worked fine on the old branch. This of course happens when starting X. Here's a dmesg clip: -- agpgart: Putting AGP V2 device at :00:00.0 into 2x mode agpgart: Putting AGP V2 device at :01:00.0 into 2x mode [drm] descriptor ring: cpu addr 0xcc878000, bus addr: 0xe000 [drm] mach64_do_wait_for_idle failed! GUI_STAT=0x0081 [drm] [drm] ring contents: [drm] head_addr: 0x head: 0 tail: 0 [drm] 0xe000: 0x007ffe48 0x06134000 0xcff8 0x (head) (tail) [drm] 0xe010: 0x 0x 0x 0x [drm] 0xe020: 0x 0x 0x 0x [drm] 0xe030: 0x 0x 0x 0x [drm] ... [drm] 0xe0003fd0: 0x 0x 0x 0x [drm] 0xe0003fe0: 0x 0x 0x 0x [drm] 0xe0003ff0: 0x 0x 0x 0x [drm] [drm] [drm]BM_GUI_TABLE = 0xe000 [drm] [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 [drm] BM_SYSTEM_MEM_ADDR = 0xe000 [drm] BM_COMMAND = 0x [drm] [drm] BM_STATUS = 0x834860ca [drm]BUS_CNTL = 0x7b33a111 [drm] FIFO_STAT = 0x [drm]GUI_STAT = 0x0081 [drm]SRC_CNTL = 0x0f00 [drm] mach64_do_wait_for_idle failed (result=-16) [drm] [drm]AGP_BASE = 0xe000 [drm]AGP_CNTL = 0x0002003e [drm] ALPHA_TST_CNTL = 0x0470 [drm] [drm] BM_COMMAND = 0x [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 [drm]BM_GUI_TABLE = 0xe000 [drm] BM_STATUS = 0x834860ca [drm] BM_SYSTEM_MEM_ADDR = 0xe000 [drm] BM_SYSTEM_TABLE = 0x4cb8 [drm]BUS_CNTL = 0x7b33a111 [drm] [drm] CLR_CMP_CLR = 0x [drm]CLR_CMP_CNTL = 0x [drm] CONFIG_CHIP_ID = 0xdc004c42 [drm] CONFIG_CNTL = 0x3f46 [drm]CONFIG_STAT0 = 0x00a10095 [drm]CONFIG_STAT1 = 0x [drm]CONFIG_STAT2 = 0x0200 [drm] CRC_SIG = 0x [drm] CUSTOM_MACRO_CNTL = 0x003c0171 [drm] [drm] DP_BKGD_CLR = 0x [drm] DP_FRGD_CLR = 0x [drm] DP_MIX = 0x00070003 [drm]DP_PIX_WIDTH = 0x01000404 [drm] DP_SRC = 0x0100 [drm] DP_WRITE_MASK = 0x [drm] DSP_CONFIG = 0x00370a09 [drm] DSP_ON_OFF = 0x0158072e [drm]DST_CNTL = 0x0023 [drm] DST_OFF_PITCH = 0x1900 [drm] [drm]EXT_MEM_CNTL = 0x64000c01 [drm] [drm] FIFO_STAT = 0x [drm] [drm] GEN_TEST_CNTL = 0x0100 [drm]GUI_CMDFIFO_DATA = 0x017c020b [drm] GUI_CMDFIFO_DEBUG = 0x00248026 [drm]GUI_CNTL = 0x0001 [drm]GUI_STAT = 0x0081 [drm] GUI_TRAJ_CNTL = 0x0023 [drm] [drm] HOST_CNTL = 0x [drm]HW_DEBUG = 0x48803800 [drm] [drm] MEM_ADDR_CONFIG = 0x0101 [drm]MEM_BUF_CNTL = 0x00382848 [drm] [drm]PAT_REG0 = 0x [drm]PAT_REG1 = 0x [drm] [drm] SC_LEFT = 0x [drm]SC_RIGHT = 0x031f [drm] SC_TOP = 0x [drm] SC_BOTTOM = 0x0a3c [drm] [drm] SCALE_3D_CNTL = 0x [drm]SCRATCH_REG0 = 0x04100400 [drm]SCRATCH_REG1 = 0x [drm] SETUP_CNTL = 0x3100 [drm]SRC_CNTL = 0x0f00 [drm] [drm]TEX_CNTL = 0x [drm] TEX_SIZE_PITCH = 0x [drm]TIMER_CONFIG = 0x [drm] [drm] Z_CNTL = 0x0110 [drm] Z_OFF_PITCH = 0x19062a20 [drm] [drm] resetting engine ... [drm] freeing data buffer memory. [drm] DMA test failed (ret=-16), using pseudo-DMA mode --- As for the glxgears thing, I got some output from it when I ran it with gdb from an ssh session: glxgears: vblank.c:338: driWaitForVBlank: Assertion `interval != (unsigned)-1' failed. I got some patchy backtrace action too: (gdb) bt #0 0x4021e031 in kill () from /lib/libc.so.6 #1 0x4018b49e in pthread_kill () from /lib/libpthread.so.0 #2 0x0006 in ?? () #3 0xb668 in ?? () #4 0x4018b454 in pthread_kill () from /lib/libpthread.so.0 #5 0x40009a00 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #6 0x080515d8 in ?? () #7 0xb688 in ?? () #8 0x4018b7a3 in raise () from /lib/libpthread.so.0 #9 0x4021de1c in raise () from /lib/libc.so.6 #10 0x4021f2a7 in abort () from /lib/libc.so.6 #11 0x4021777e in __assert_fail () from /lib/libc.so.6 #12 0x4044d34a in driWaitForVBlank (priv=0x8050cd8, vbl_seq=0x40192e40, flags=4294967295, missed_deadline=0xb86b ) at vblank.c:338 #13 0x40451d2a in mach64CopyBuffer (dPriv=0x8050cd8) at mach64_ioctl.c:309 #14 0x40453887 in mach64SwapBuffers (dPriv=0x8050cd8) at mach64_screen.c:285 #15 0x4034f4a3 in driSwapBuffers
Re: [Dri-devel] UT2004 demo
Jacek Popawski wrote: On Sat, Feb 14, 2004 at 07:38:58PM +1100, Daniel Kasak wrote: Just downloaded the UT2004 demo, and tried it out under XFree86-4.3.99.902. I'm pleasantly surprised. It runs quite nicely, What about speed? On my R200 (Athlon 1800 XP, low settings) it is slow like hell. What is your hardware and settings? The menu animations ( the background scrolling text ) is a little jerky compared to Windows. Yeah, the game also runs slower than under Windows - I've got a Windows box wth an Athlon 1800 XP and a Geforce 2 MX, and it performs considerably better. I expected this after reading the bit about the game being designed for D3D, and the OpenGL renderer being unsupported ( under Windows ). Unfortunate, but I suppose they have their reasons. Maybe ( hopefully ) performance will improve. Anyway, it's certainly not slow as hell. It's respectable - just not silky smooth. It's certainly better than nothing :) If enough people use the Linux client, maybe for UT2005 they will say that the D3D renderer is unsupported and only included in case your OpenGL drivers suck! I've got an Athlon 2100 XP, a Radeon 64MB DDR ( R100 ), and XFree86-4.3.99.902: OpenGL renderer string: Mesa DRI Radeon 20030328 AGP 4x x86/MMX+/3DNow!+/SSETCL OpenGL version string: 1.2 Mesa 5.0.2 My game settings are whatever the defaults are. I can't read any of the menus, so I haven't bothered screwing with anything ( apart from invert mouse ... I made a point of finding that ). Maybe you should try a snapshot of the new XFree86? Dan --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] UT2004 demo
Am Samstag, 14. Februar 2004 23:22 schrieb Daniel Vogel: With or without S3TC? Without S3TC. I checked in a fix so the retail version and any subsequent patches to the demo version will have the fix. UT2004 was to new for me...;-) Should I download it, now or should I wait some hours after your fix is in? Now I talk about UT2003_demo. http://marc.theaimsgroup.com/?l=dri-develm=107641685118242w=2 And latest update. http://marc.theaimsgroup.com/?l=dri-develm=107654130503322w=2 I'm not sure I understand what you want me to comment on? Could you elaborate. I ask if you have any idea why it (r200 with new lightning, e.g. hardware accelerated TCL) hangs immediately in Capture the Flag - Citadel when I use the mouse (only put my hand on it and have some nervous fingers is enough), but runs fine with cursor keys and both of it in all other demo levels. Are there any special hardware requirements in Citadel (maybe TMU3/6 or the like) which aren't needed in the other levels? Or is 2206 buggy? SMP system, here? Thanks, Dieter --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Savage DRI hangs when loaded by an application
Hi all, I'm experiencing some problem with my Savage2000(Viper II) card and DRI. Just for the records, I followed all recomendation I could find in and out of this list. First of all I recompiled my kernel(vanilla 2.4.24, since fedora/redhat kernel-source has some incompatibilities) without DRM, since DRM will be compiled and installed by DRI CVS(recommended by http://dri.sourceforge.net/doc/DRIcompile.html). Then I made the necessary changes to DRI to recognize the SAVAGE2000 card(as posted on this list: xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c and xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/savage.h) and I could get DRI to compile without errors. Then I run make install and modified modules.conf to load agpgart and the savage kernel driver on XFree86 probing. Restarted X and it worked perfectly. The relevant messages on XFree86.log.0 are: XFree86 Version 4.3.99.12 (DRI trunk) Release Date: 10 September 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.24savage i686 [ELF] Current Operating System: Linux thor.home 2.4.24savage #3 Sex Fev 13 13:23:47 BRST 2004 i686 Build Date: 14 February 2004 Changelog Date: 10 September 2003 ... (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel abnt2 (**) XKB: model: abnt2 (**) Option XkbLayout br (**) XKB: layout: br (==) Keyboard: CustomKeycode disabled ... (II) LoadModule: fbdevhw (II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a (II) Module fbdevhw: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 0.0.2 ABI class: XFree86 Video Driver, version 0.7 (II) LoadModule: glx (II) Loading /usr/X11R6/lib/modules/extensions/libglx.a (II) Module glx: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module GLcore (II) LoadModule: GLcore (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a (II) Module GLcore: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension GLX (II) LoadModule: record (II) Loading /usr/X11R6/lib/modules/extensions/librecord.a (II) Module record: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.13.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.2 ... (II) LoadModule: dri (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a (II) Module dri: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module drm (II) LoadModule: drm (II) Loading /usr/X11R6/lib/modules/linux/libdrm.a (II) Module drm: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: savage (II) Loading /usr/X11R6/lib/modules/drivers/savage_drv.o (II) Module savage: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.1.27 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.7 ... (II) SAVAGE: driver (version 1.1.27a) for S3 Savage chipsets: Savage4, Savage3D, Savage3D-MV, Savage2000, Savage/MX-MV, Savage/MX, Savage/IX-MV, Savage/IX, ProSavage PM133, ProSavage KM133, ProSavage PN133, ProSavage KN133, SuperSavage/MX 128, SuperSavage/MX 64, SuperSavage/MX 64C, SuperSavage/IX 128, SuperSavage/IX 128, SuperSavage/IX 64, SuperSavage/IX 64, SuperSavage/IXC 64, SuperSavage/IXC 64, ProSavage DDR, ProSavage DDR-K (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (--) Chipset Savage2000 found ... (II) Setting vga for screen 0. (II) Loading sub module vgahw (II) LoadModule: vgahw (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.7 (**) SAVAGE(0): Depth 24, (--) framebuffer bpp 32 (==) SAVAGE(0): RGB weight 888 (==) SAVAGE(0): Default visual is TrueColor (II) SAVAGE(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (==) SAVAGE(0): Using AGP 4x mode (==) SAVAGE(0): Using HW cursor (==) SAVAGE(0): Using video BIOS to set modes (II) Loading sub module int10 (II) LoadModule: int10 (II) Loading /usr/X11R6/lib/modules/linux/libint10.a (II) Module int10: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.7 (II) SAVAGE(0): Primary V_BIOS segment is: 0xc000 (II) Loading sub module vbe (II) LoadModule: vbe (II) Loading /usr/X11R6/lib/modules/libvbe.a (II) Module vbe: vendor=The XFree86 Project compiled for 4.3.99.12,
Re: [Dri-devel] Re: GATOS and DRI merge
2. *_video.c files - these are heavily modified. Take care of atixv.c -
Marc Aurele merged part of GATOS code into XFree86
Yes, I noticed that... these files were *FULL* of conflicts against the
current DRI CVS... to the extent that I'm worried about being able to
untangle them. Something like 140K of .rej files between radeon_video.c
and atixv.c. It would help to know from the DRI folks, if they've done
any major structural changes or if this is just bugfixes and minor code
movement.
for radeon_video.c and r128_video.c this should be easy. The rejects are
likely caused not by modified code but by modified surroundings, so that
patch does not know where to insert new code.
They way I work through these is to open new radeon_video.c,
radeon_video.c from current gatos code and rejects and work one by one
to resolve the conflicts.
For example, the functions that initialized and access i2c bus can be
copied as is, whatever the modifications in surrounding code.
On the other hand the function that creates PortPrivPtr struct is best
changed so that attribute allocation (xv? variables) happens anew
on each reset of the Xserver.
move apertures (from chips point of view) so as to allow for PCI DMA.
These are matched by changes in drm-kernel and Mesa driver. They
are just a few lines.
All of these are best thrown out and instead new code should make use
of ability of DRI CVS to change these settings dynamically.
OK, can someone give me an idea of what calls I'm looking for, and what
they should be doing instead? Are we talking strictly about what's in
{radeon,r128}_dri.c?
From what I understand the changes in this area are the main cause of my
problems. I can isolate what Gatos changed in this file, sure, but I
have no idea what to replace it with.
There are two areas in xf86 driver: radeon_*dri.c and (AFAIK)
radeon_accel.c or similar.
Only radeon has such code, r128 does not have memory controller like
radeon does.
There are two areas: code that checks for compatible DRM. You don't need
it.
Code that handles trasferred apertures - this code looks like it adds a
constant value (aperture location in PCI address space) to some values,
but not others.
You need to ask DRM driver to transfer aperture to the same position
(so that video ram is at physical PCI adddress from the point of view of
radeon memory controller and AGP memory is right after it) and add
constants in the exact same places.
However, take note that since DRM driver in DRI CVS is aware of the
transferred apertures some of the additions would not be necessary as they
are done by the driver anyway.
As I remember that additions classify as following:
1. Some registers are simply set to physical PCI aperture, instead of 0
as they are now. For example, RADEON_OVERLAY_BASE_ADDR and
RADEON_DISPLAY_BASE_ADDR
2. Some registers have a constant value added, for example
RADEON_MC_AGP_LOCATION
3. You need to add a value to some, but not all values that refer to
data used by graphics engine.
The reason is that some values are offsets with respect to *BASE_ADDR
registers and some are not.
1. Texture locations are absolute - this allows (in principle)
to load texture from any of video ram, agp space or using PCI DMA
2. Vertex lists are absolute
3. There is a copy command that takes absolute arguments
so you can use it transfer data between video ram, AGP and PCI
spaces.
As a rule, an absolute register needs to be 32 bit - it cannot be 20
bit for example, as the apertures are often located at high addresses.
So if you see a register that is only 20bit wide there is no reason to
adjust it.
When I was modifying the driver I was able to progress along the
following milestones:
1. Move the aperture locations and get regular 2d operations
working without DRM driver (disable it or something)
2. Get overlay working - usually involves setting
RADEON_OVERLAY_BASE_ADDR correctly.
3. Enable DRM driver and get 2d operations working.
4. Get glxgears working - this means vertex lists work.
5. Get Quake working - this means texture now work.
6. At this point I believed that everything works, so I released
the code.
7. Receive bug reports (especially about Blender, Wolf3d and
some other apps).
8. After much digging it turns out that Mesa3d driver like to
do memcpy from one place of video RAM to another for
buffer swap or similar. This needs to be modified - but this
might already be implemented in DRI CVS.
5. They are might be a few fixes (1 or 2) that are, strictly speaking,
outside the scope of GATOS code (like DPMS and such) and were
backported from XFree86 CVS tree. If they are indeed there they should
be easy to
Re: [Dri-devel] UT2004 demo
Am Samstag, 14. Februar 2004 23:38 schrieb Daniel Kasak: Jacek Popawski wrote: On Sat, Feb 14, 2004 at 07:38:58PM +1100, Daniel Kasak wrote: Just downloaded the UT2004 demo, and tried it out under XFree86-4.3.99.902. I'm pleasantly surprised. It runs quite nicely, What about speed? On my R200 (Athlon 1800 XP, low settings) it is slow like hell. What is your hardware and settings? The menu animations ( the background scrolling text ) is a little jerky compared to Windows. Yeah, the game also runs slower than under Windows - I've got a Windows box wth an Athlon 1800 XP and a Geforce 2 MX, and it performs considerably better. I expected this after reading the bit about the game being designed for D3D, and the OpenGL renderer being unsupported ( under Windows ). Unfortunate, but I suppose they have their reasons. Maybe ( hopefully ) performance will improve. Anyway, it's certainly not slow as hell. It's respectable - just not silky smooth. It's certainly better than nothing :) If enough people use the Linux client, maybe for UT2005 they will say that the D3D renderer is unsupported and only included in case your OpenGL drivers suck! I've got an Athlon 2100 XP, a Radeon 64MB DDR ( R100 ), and XFree86-4.3.99.902: OpenGL renderer string: Mesa DRI Radeon 20030328 AGP 4x x86/MMX+/3DNow!+/SSETCL OpenGL version string: 1.2 Mesa 5.0.2 My game settings are whatever the defaults are. I can't read any of the menus, so I haven't bothered screwing with anything ( apart from invert mouse ... I made a point of finding that ). Maybe you should try a snapshot of the new XFree86? Try with latest DRI-Devel (new revolutionary lighting). But sadly your r100 wouldn't be much faster with it. r200+ are. Maybe you test the S3TC patch, too ;-) Greetings, Dieter --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] UT2004 demo
UT2004 was to new for me...;-) Should I download it, now or should I wait some hours after your fix is in? We have no plans to patch the UT2004 demo at this point so you shouldn't wait. I was merely mentioning that if we do, it's going to be fixed and the fix is also going to be in the retail version. accelerated TCL) hangs immediately in Capture the Flag - Citadel when I use the mouse (only put my hand on it and have some nervous fingers is enough), but runs fine with cursor keys and both of it in all other demo levels. That's odd - no idea. -- Daniel, Epic Games Inc. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage DRI hangs when loaded by an application
# lspci -n 00:00.0 Class 0600: 8086:1130 (rev 02) 00:01.0 Class 0604: 8086:1131 (rev 02) 00:1e.0 Class 0604: 8086:244e (rev 02) 00:1f.0 Class 0601: 8086:2440 (rev 02) 00:1f.1 Class 0101: 8086:244b (rev 02) 00:1f.2 Class 0c03: 8086:2442 (rev 02) 00:1f.3 Class 0c05: 8086:2443 (rev 02) 00:1f.4 Class 0c03: 8086:2444 (rev 02) 01:00.0 Class 0300: 5333:9102 (rev 02) 02:0a.0 Class 0400: 11de:6057 (rev 01) 02:0b.0 Class 0200: 10ec:8139 (rev 10) 02:0c.0 Class 0401: 1102:0002 (rev 07) 02:0c.1 Class 0980: 1102:7002 (rev 07) 02:0e.0 Class 0100: 9004:8178 (rev 01) My Viper II (Savage 2000) card is 01:00.0 Class 0300: 5333:9102 (rev 02) Best Regards, Cristiano Duarte --- Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage DRI hangs when loaded by an application
Hi Cristiano, short answer to a long mail: The Savage driver does not support Savage2000 chips at the moment. We have no hardware documentation nor a reference driver implementation. Unless this changes it's unlikely that Savage2000 support will be available any time soon. :-/ At the moment the driver is known to work (more or less) with Savage4, ProSavageDDR and Twister chips. I'm working on support for older Savage3D-based chips. Best regards, Felix On Sat, 14 Feb 2004 21:35:57 -0200 cunha17 [EMAIL PROTECTED] wrote: Hi all, I'm experiencing some problem with my Savage2000(Viper II) card and DRI. Just for the records, I followed all recomendation I could find in and out of this list. [snip] --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 2.6.3-rc2 DRM module seems to be faster as the DRI one
mtrr: 0xe000,0x400 overlaps existing 0xe000,0x100 request_module: failed /sbin/modprobe -- char-major-226-0. error = 256 Do I something missing in /etc/modprobe.conf? Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected AMD 760MP chipset agpgart: Maximum main memory to use for agp memory: 941M agpgart: AGP aperture is 64M @ 0xe800 [drm] Initialized radeon 1.9.0 20020828 on minor 0 mtrr: 0xe000,0x400 overlaps existing 0xe000,0x100 agpgart: Found an AGP 2.0 compliant device at :00:00.0. agpgart: Putting AGP V2 device at :00:00.0 into 2x mode agpgart: Putting AGP V2 device at :01:05.0 into 2x mode [drm] Loading R200 Microcode I have this in /etc/X11/XF86Config: Section Device BoardNameRadeon 8500 QL BusID1:5:0 Driver radeon Identifier Device[0] Option EnablePageflip Option DPMS OptionAGPFastWrite 1 OptionAGPMode 4 Screen 0 Option Rotate on VendorName ATI EndSection ipers is faster (nearly as fast as last years best numbers). But system lock up (SYSRQ works) after some xscreensaver tests. The xscreensaver flickering is a KDE (3.2) problem. KDE seems to be using xscreensaver without double buffering. Why this? And ugh, what's that: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. request_module: failed /sbin/modprobe -- char-major-10-250. error = 256 Thanks, Dieter --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: GATOS and DRI merge
On Sun, 2004-02-15 at 00:45, Vladimir Dergachev wrote: Code that handles trasferred apertures - this code looks like it adds a constant value (aperture location in PCI address space) to some values, but not others. You need to ask DRM driver to transfer aperture to the same position (so that video ram is at physical PCI adddress from the point of view of radeon memory controller and AGP memory is right after it) and add constants in the exact same places. However, take note that since DRM driver in DRI CVS is aware of the transferred apertures some of the additions would not be necessary as they are done by the driver anyway. As I remember that additions classify as following: [...] Current DRI CVS basically takes care of all this. AFAICT, the only thing that may need to be added to RADEONSetFBLocation() (or wherever) is a decision between DRI and video capturing if the DRM is older than 1.10.0. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Slow Mtex in DRI
I have found something disterbing about DRI and was hoping you would be able to give a solution. It turns out, through recent QuakeForge changes, the DRI is faster in multipass rendering than with multitexture (mtex) rendering. The samemethod,and with no alteration to the code, withnVidia drivers in linux shows mtex is faster. It was also shown that mtexrendering was faster in windows with the same code than multipass using ATI catalyst drivers, and for nVidia, with the difference being from 10 to 30% performance improvement overall with multitexture compaired with multipass rendering. This test was done showing consistant results with several machines,multiple runs, and same process runs (switching mtex of and on in the same process).This was also seen in linux for nVidia. Can you please suggest anything that could improve performance in DRIso that multitexture is faster than multipass as seen with nVidia in linux, and nVidia and ATI in windows. Thanks in advance Chris Ison
Re: [Dri-devel] Savage DRI hangs when loaded by an application
--- cunha17 [EMAIL PROTECTED] wrote: Hi all, I'm experiencing some problem with my Savage2000(Viper II) card and DRI. Just for the records, I followed all recomendation I could find in and out of this list. First of all I recompiled my kernel(vanilla 2.4.24, since fedora/redhat kernel-source has some incompatibilities) without DRM, since DRM will be compiled and installed by DRI CVS(recommended by http://dri.sourceforge.net/doc/DRIcompile.html). Then I made the necessary changes to DRI to recognize the SAVAGE2000 card(as posted on this list: xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c and xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/savage.h) and I could get DRI to compile without errors. [snip] To elaborate on what felix said, savage2000 is a different beast than any of the other savages. regarding the 2D driver, I have no idea how its bitmap descripters are laid out. The 3D engine is a whole nother ball of wax... if you want to play around with it you may be able to get something working, but that assumes its 3D engine operates similar to prosavage or savage4. Just knowing how many weird little differences there are in the 3D engines of savage4 and prosavage does not bode well for savage2000 support. Anyway, if you want to play with it a bit, here's what you can try (names may be sightly off, I don't have the code in front of me at the moment): In savage_accel.c, take a look at the SavageSetGBD() function. right now, I know nothing about setting up the GBD on savage2000, so I just defaulted to Tim's method. if you want you can try messing with the case statement that calls the chip specific setGBD functions, try moving savage2000 to have it call setGBD_twister or setGBD_pm() (supersavage) functions instead. then in savage_dri.c, one of the functions (I forget the name offhand) sets up the bitmap descriptors for the front/depth/back buffers and the tile registers. Try adding savage2000 to the if statements for prosavage and twister. then rebuild and see what you get. If that doesn't work, then you are probably out of luck unfortunately. Alex __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
