Re: PPC r300 texture
Vladimir Dergachev writes: > I am a bit puzzled with your patch - do you really need to hard code > format field in r300_state.c ? I find that with that line there, it works moderately well (textures look mostly correct although dithered at the edges), but with that line commented out, textures just display random noise. I agree it looks like that line shouldn't be needed, and it would be interesting to track down exactly what is going on. Paul. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PPC r300 texture
Hi Jerome, I am a bit puzzled with your patch - do you really need to hard code format field in r300_state.c ? If not, please commit the modification for the texture format table, it looks fine to me. (and not really a hack ;) ) best Vladimir Dergachev On Mon, 14 Feb 2005, Jerome Glisse wrote: Hi, Attached is patch, an ugly hack that should give you texture on ppc, at least here i got texture and could play to tuxracer and see glexcess (i don't think there is a q3 for ppc on linux thus i test with glexcess and few others progs). So please test it and tell me the result :) What i still have to figure is why this is second entry of tx_table that is used, thus why there is a 1 somewhere while we should have a 0. But i haven't fully understand how choose texture format work with mesa & r300, if anyone could provide me a hint :). best, Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon big endian patch
On Sun, 2005-02-13 at 19:25 -0500, Michel Dänzer wrote: > On Mon, 2005-02-14 at 09:07 +1100, Benjamin Herrenschmidt wrote: > > On Sat, 2005-02-12 at 23:56 -0500, Michel Dänzer wrote: > > > On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote: > > > > > > > > Those are still incorrect as they totally lack memory barriers... > > > > > > INREG() doesn't (or does it?), and it's the only one used by the 3D > > > drivers. > > > > Hrm.. in fact, you are always writing to indirect buffers here, right ? > > > > If this is true, all you need is a barrier between the last store to it > > and whatever store makes the buffer visible to the chip. If you use only > > uncached access (like AGP GART), then only an eieio is necessary, > > Yes, the DRM does this, always has... > > > but if you use PCI GART which works with a cacheable mapping in main > > memory, you probably need a full sync. > > Hasn't seemed necessary all these years. Because you were lucky enough :) But CPUs like the 970 are much more aggressive with re-ordering of stores and speculation of loads... Ben. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon big endian patch
On Mon, 2005-02-14 at 09:07 +1100, Benjamin Herrenschmidt wrote: > On Sat, 2005-02-12 at 23:56 -0500, Michel DÃnzer wrote: > > On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote: > > > > > > Those are still incorrect as they totally lack memory barriers... > > > > INREG() doesn't (or does it?), and it's the only one used by the 3D > > drivers. > > Hrm.. in fact, you are always writing to indirect buffers here, right ? > > If this is true, all you need is a barrier between the last store to it > and whatever store makes the buffer visible to the chip. If you use only > uncached access (like AGP GART), then only an eieio is necessary, Yes, the DRM does this, always has... > but if you use PCI GART which works with a cacheable mapping in main > memory, you probably need a full sync. Hasn't seemed necessary all these years. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
PPC r300 texture
Hi, Attached is patch, an ugly hack that should give you texture on ppc, at least here i got texture and could play to tuxracer and see glexcess (i don't think there is a q3 for ppc on linux thus i test with glexcess and few others progs). So please test it and tell me the result :) What i still have to figure is why this is second entry of tx_table that is used, thus why there is a 1 somewhere while we should have a 0. But i haven't fully understand how choose texture format work with mesa & r300, if anyone could provide me a hint :). best, Jerome Glisse ppctexture Description: Binary data
Re: [Fwd: Snapshot build failed]
Am Sonntag, den 13.02.2005, 13:39 -0500 schrieb Michel Dänzer: > On Sun, 2005-02-13 at 18:38 +0100, Felix Kühling wrote: > > > > r200_screen.c: In function `r200CreateScreen': > > r200_screen.c:407: error: `addr' undeclared (first use in this function) > > Whoops, my bad, should be fixed now. I wonder how that built for me... Thanks. BTW, I changed cron job to send automatic failure mails directly to dri-devel now. They are sent only once every day and only when a snapshot fails. Complete build log files will be uploaded to http://dri.freedesktop.org/snapshots/log. Regards, Felix -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
UT, Marbleblast, and Orbz) die with: r300_check_render: fallback:ctx->Texture.Unit[i].Enabled Could you disable multitexturing in these games ? GLTron and Blender die with: r300_check_render: fallback:ctx->Line.SmoothFlag Don't know about this one - see what happens when you comment out this fallback. NWN starts up, and doesn't crash, but is definitely unplayable: http://68.44.156.246/nwn.png (warning: 1 meg PNG on a slow connection). Q3A displays similar problems in the menu screen, and level loading screen, but dies once the level is loaded with the same Texture.Unit error. Quake2 is similar. Q3A works if you disable certain features in q3aconfig file - (go to .q3a/base3q/q3aconfig) - check r300_dri webpage for suggestions. best Vladimir Dergachev Frankly, I'm thrilled at the handful of games that are now working! Adam --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Hello, These are the games I've tried with the latest CVS from this afternoon: Neverputt and neverball play, but some debug output gets displayed: --snip-- :p You can get neverball working much more smootly by switching everything to low in the menu screen. Ignore the warn once messages, they're more of a reminder of what needs to be done still. Chromium works. UT, Marbleblast, and Orbz) die with: r300_check_render: fallback:ctx->Texture.Unit[i].Enabled I believe we're still only letting one texture pass through the pipeline, I'm not sure why the fallback is causing a segfault though. Q3A displays similar problems in the menu screen, and level loading screen, but dies once the level is loaded with the same Texture.Unit error. Quake2 is similar. You need to disable compiled vertex arrays, and multitexturing in your q3config.cfg file. Q3 should be very playable, with a couple of glitches. Frankly, I'm thrilled at the handful of games that are now working! Adam Great! Thankyou for testing on some (afaik) untested programs. Cheers, Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon big endian patch
On Sat, 2005-02-12 at 23:56 -0500, Michel Dänzer wrote: > On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote: > > > > Those are still incorrect as they totally lack memory barriers... > > INREG() doesn't (or does it?), and it's the only one used by the 3D > drivers. Hrm.. in fact, you are always writing to indirect buffers here, right ? If this is true, all you need is a barrier between the last store to it and whatever store makes the buffer visible to the chip. If you use only uncached access (like AGP GART), then only an eieio is necessary, but if you use PCI GART which works with a cacheable mapping in main memory, you probably need a full sync. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: another r300 compilation problem
Jerome Glisse wrote: Do you have lastest Mesa checkout ? Maybe Michel has applied the wrong patch to mesa cvs. I will check this. I've cvs-ed it this afternoon, but looking to "Re: [Fwd: Snapshot build failed]" seems that michel will fix it soon. -- Laera Dario Undergraduate student at Computer Science University of Bologna ICQ# 203250303 /==/ http://laera.web.cs.unibo.it Mail to: laera_at_cs.unibo.it pennytommy_at_libero.it --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 success stories
These are the games I've tried with the latest CVS from this afternoon: Neverputt and neverball play, but some debug output gets displayed: *WARN_ONCE* File r300_state.c function r300GenerateTexturePixelShader line 1600 ModeRGB==GL_MODULATE is possibly broken. *** *WARN_ONCE* File r300_state.c function r300GenerateTexturePixelShader line 1635 ModeA==GL_MODULATE is possibly broken. *** *WARN_ONCE* File r300_state.c function r300GenerateTexturePixelShader line 1620 ModeA==GL_REPLACE is possibly broken. *** *WARN_ONCE* File r300_render.c function r300_get_num_verts line 246 user error: 2048 is not a valid number of vertices for primitive T ! *** *WARN_ONCE* File r300_render.c function r300_get_num_verts line 241 user error: Need more than 0 vertices to draw primitive TF ! *** *WARN_ONCE* File r300_state.c function r300_setup_textures line 1322 Mismatch between render_inputs and ctx->Texture.Unit[i].Enabled value. *** Tuxracer mostly works. The ice looks a bizarre, but the game is playable :-) I get many of the same WARN_ONCE errors. Chromium works. UT, Marbleblast, and Orbz) die with: r300_check_render: fallback:ctx->Texture.Unit[i].Enabled GLTron and Blender die with: r300_check_render: fallback:ctx->Line.SmoothFlag NWN starts up, and doesn't crash, but is definitely unplayable: http://68.44.156.246/nwn.png (warning: 1 meg PNG on a slow connection). Q3A displays similar problems in the menu screen, and level loading screen, but dies once the level is loaded with the same Texture.Unit error. Quake2 is similar. Frankly, I'm thrilled at the handful of games that are now working! Adam --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: another r300 compilation problem
On Sun, 13 Feb 2005 19:02:40 +0100, Dario Laera <[EMAIL PROTECTED]> wrote: > Fionn Behrens wrote: > --- Mesa/src/mesa/drivers/dri/radeon/server/radeon_macros.h 2005-02-12 > 21:37:07.0 +0100 > +++ Mesa.up/src/mesa/drivers/dri/radeon/server/radeon_macros.h 2005-02-13 > 17:24:40.288843552 +0100 > @@ -45,7 +45,7 @@ > # define MMIO_IN8(base, offset) \ > *(volatile unsigned char *)(((unsigned char*)(base)) + (offset)) > # define MMIO_IN32(base, offset) \ > - read_MMIO_LE32(base, addr) > + read_MMIO_LE32(base, offset) > # define MMIO_OUT8(base, offset, val) \ > *(volatile unsigned char *)(((unsigned char*)(base)) + (offset)) = > (val) > # define MMIO_OUT32(base, offset, val) \ Do you have lastest Mesa checkout ? Maybe Michel has applied the wrong patch to mesa cvs. I will check this. Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 vb path
On Sun, 13 Feb 2005 20:14:20 +0100, Dario Laera <[EMAIL PROTECTED]> wrote: > I've tried it on ppc, it works very well, now I get 1000 fps in vb path > against 750 with immediate path. > About tuxracer I'm getting the same result as some days ago: > http://laera.web.cs.unibo.it/dri/tuxracer.png I know why you get this, basicly the driver just think that it doen't know the texture format while in fact it know it. I am looking to that and try to find how to correct that, but i fear i won't have time. Btw i you ask for cvs checkout at 15/01/2005 you should see texture. (cvs flags : -PD "2005/01/15") best, Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Experiment on ppc
On Sun, 13 Feb 2005 18:22:43 +0100, Dario Laera <[EMAIL PROTECTED]> wrote: > Jerome Glisse wrote: > >>Then I've tried the r300_demo(v_0_0_1): I've wrote an ugly fix that just > >>works for > >>me for an endianess problem > > > > > > Please use lastest r300_demo as i commited patch > > for big endian & PPC. Anyway help is welcome for PPC :) > > where are all that files? Also removing that from the makefile, I get > this error: > > I guess you've forgot to upload some files ;) Yes i forget to upload the files :) How stupid i am. Now its done but public cvs lag a bit, i guess you would have to wait a little bit until public cvs give you all this cute files. best, Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 vb path
Dario Laera wrote: Ben Skeggs wrote: Hello, I've attached a patch with a port of the r200 vertex buffer code for the r300 driver. The performance of the vertex buffer codepath is now roughly the same as the immediate path, and tuxracer now seems to be rendered almost correctly. I've tried it on ppc, it works very well, now I get 1000 fps in vb path against 750 with immediate path. About tuxracer I'm getting the same result as some days ago: http://laera.web.cs.unibo.it/dri/tuxracer.png Trying other games based on sdl, I get this error: "Fatal signal: Segmentation Fault (SDL Parachute Deployed)" I'm the only one getting this error? I don't exclude my system have broken libsdl. This has nothing to do with SDL. It's just SDL catching a segmentation fault in the program. It does this so that it can do some cleanup even when program crashes. If you don't want that behaviour, add the SDL_INIT_NOPARACHUTE flag to SDL_Init() and recompile the code. This also has the side effect of allowing debugging with gdb, which you are probably interested in. Stephane --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 vb path
Ben Skeggs wrote: Hello, I've attached a patch with a port of the r200 vertex buffer code for the r300 driver. The performance of the vertex buffer codepath is now roughly the same as the immediate path, and tuxracer now seems to be rendered almost correctly. I've tried it on ppc, it works very well, now I get 1000 fps in vb path against 750 with immediate path. About tuxracer I'm getting the same result as some days ago: http://laera.web.cs.unibo.it/dri/tuxracer.png Trying other games based on sdl, I get this error: "Fatal signal: Segmentation Fault (SDL Parachute Deployed)" I'm the only one getting this error? I don't exclude my system have broken libsdl. Bye, dario. -- Laera Dario Undergraduate student at Computer Science University of Bologna ICQ# 203250303 /==/ http://laera.web.cs.unibo.it Mail to: laera_at_cs.unibo.it pennytommy_at_libero.it --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Snapshot build failed]
On Sun, 2005-02-13 at 18:38 +0100, Felix KÃhling wrote: > > r200_screen.c: In function `r200CreateScreen': > r200_screen.c:407: error: `addr' undeclared (first use in this function) Whoops, my bad, should be fixed now. I wonder how that built for me... -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Experiment on ppc
Jerome Glisse wrote: Then I've tried the r300_demo(v_0_0_1): I've wrote an ugly fix that just works for me for an endianess problem Please use lastest r300_demo as i commited patch for big endian & PPC. Anyway help is welcome for PPC :) From the actual Makefile: CFILES=r300_demo.c r300_lib.c cmdline.c r300_vtxbuf.c r300_triangles.c r300_bitblt.c r300_pipeline.c\ r300_texfloat.c where are all that files? Also removing that from the makefile, I get this error: gcc -Wall -pipe -O2 -g -Ilibdrm -DPACKAGE=\"r300_demo\" -DVERSION=\"0.0.2-cvs\" libdrm/libdrm.o -lm r300_demo.c r300_lib.c cmdline.c -o r300_demo /tmp/ccHOGpbj.o(.text+0xd90): In function `main': /usr/src/r300_demo/r300_demo.c:464: undefined reference to `EmitBITBLT' /tmp/ccHOGpbj.o(.text+0xda0):/usr/src/r300_demo/r300_demo.c:467: undefined reference to `test_triangles' /tmp/ccHOGpbj.o(.text+0xdb0):/usr/src/r300_demo/r300_demo.c:470: undefined reference to `test_tex_bitblt' /tmp/ccHOGpbj.o(.text+0xdc0):/usr/src/r300_demo/r300_demo.c:474: undefined reference to `test_tex_triangles' /tmp/ccHOGpbj.o(.text+0xdd0):/usr/src/r300_demo/r300_demo.c:477: undefined reference to `test_vb_triangles' /tmp/ccHOGpbj.o(.text+0xde0):/usr/src/r300_demo/r300_demo.c:480: undefined reference to `test_eb_triangles' /tmp/ccHOGpbj.o(.text+0xdf0):/usr/src/r300_demo/r300_demo.c:483: undefined reference to `test_immd_triangles' /tmp/ccHOGpbj.o(.text+0xe00):/usr/src/r300_demo/r300_demo.c:486: undefined reference to `test_idx_triangles' /tmp/ccHOGpbj.o(.text+0xe10):/usr/src/r300_demo/r300_demo.c:489: undefined reference to `test_tex_immd_triangles' /tmp/ccHOGpbj.o(.text+0xe20):/usr/src/r300_demo/r300_demo.c:492: undefined reference to `float_demo1' /tmp/ccytyEvb.o(.text+0x3a22): In function `init_textured_primitive': /usr/src/r300_demo/r300_lib.c:825: undefined reference to `SINGLE_TEXTURE_PIPELINE' /tmp/ccytyEvb.o(.text+0x3a32):/usr/src/r300_demo/r300_lib.c:825: undefined reference to `SINGLE_TEXTURE_PIPELINE' /tmp/ccytyEvb.o(.text+0x3d26): In function `init_flat_primitive': /usr/src/r300_demo/r300_lib.c:530: undefined reference to `FLAT_COLOR_PIPELINE' /tmp/ccytyEvb.o(.text+0x3d3e):/usr/src/r300_demo/r300_lib.c:530: undefined reference to `FLAT_COLOR_PIPELINE' /tmp/ccytyEvb.o(.text+0x4072): In function `clear_depth_buffer': /usr/src/r300_demo/r300_lib.c:475: undefined reference to `FLAT_2D_PIPELINE' /tmp/ccytyEvb.o(.text+0x407a):/usr/src/r300_demo/r300_lib.c:475: undefined reference to `FLAT_2D_PIPELINE' /tmp/ccytyEvb.o(.text+0x44da): In function `clear_color_buffer': /usr/src/r300_demo/r300_lib.c:414: undefined reference to `FLAT_2D_PIPELINE' /tmp/ccytyEvb.o(.text+0x44e2):/usr/src/r300_demo/r300_lib.c:414: undefined reference to `FLAT_2D_PIPELINE' collect2: ld returned 1 exit status make: *** [r300_demo] Error 1 I guess you've forgot to upload some files ;) Dario. -- Laera Dario Undergraduate student at Computer Science University of Bologna ICQ# 203250303 /==/ http://laera.web.cs.unibo.it Mail to: laera_at_cs.unibo.it pennytommy_at_libero.it --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: another r300 compilation problem
Fionn Behrens wrote: Xorg and drm modules compiled fine but Mesa bails out: radeon_screen.c: In function `radeonCreateScreen': radeon_screen.c:519: error: `addr' undeclared (first use in this function) radeon_screen.c:519: error: (Each undeclared identifier is reported only once radeon_screen.c:519: error: for each function it appears in.) make[6]: *** [radeon_screen.o] Error 1 DRM_SOURCE_PATH and all symlinks appear to be set correctly. Suggestions? br, Fionn It's a little error, I've attached a patch. There is another error I can't fix: radeon_context.c: In function `radeonCreateContext': radeon_context.c:451: error: structure has no member named `tiling_enabled' make[6]: *** [radeon_context.o] Error 1 make[6]: Leaving directory `/usr/src/Mesa.up/src/mesa/drivers/dri/radeon' btw it is part of the radeon module, not needed by r300, without all compile fine :) -- Laera Dario Undergraduate student at Computer Science University of Bologna ICQ# 203250303 /==/ http://laera.web.cs.unibo.it Mail to: laera_at_cs.unibo.it pennytommy_at_libero.it --- Mesa/src/mesa/drivers/dri/radeon/server/radeon_macros.h 2005-02-12 21:37:07.0 +0100 +++ Mesa.up/src/mesa/drivers/dri/radeon/server/radeon_macros.h 2005-02-13 17:24:40.288843552 +0100 @@ -45,7 +45,7 @@ # define MMIO_IN8(base, offset) \ *(volatile unsigned char *)(((unsigned char*)(base)) + (offset)) # define MMIO_IN32(base, offset) \ - read_MMIO_LE32(base, addr) + read_MMIO_LE32(base, offset) # define MMIO_OUT8(base, offset, val) \ *(volatile unsigned char *)(((unsigned char*)(base)) + (offset)) = (val) # define MMIO_OUT32(base, offset, val) \
[Fwd: Snapshot build failed]
Weitergeleitete Nachricht Von: Felix Kuehling <[EMAIL PROTECTED]> An: [EMAIL PROTECTED] Betreff: Snapshot build failed Datum: Sun, 13 Feb 2005 07:41:54 -0800 (PST) A snapshot build failed at Sun Feb 13 07:41:54 PST 2005. Please inspect the logfiles in /home/fxkuehl/snapshots/log. Summary: Updating sources from CVS ... done. HEAD: Preparing the builds ... done. HEAD: Building ... failed. Errors occured. Skipping archive. [snip] Tail of logfile log/HEAD-mesa.build: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I/home/fxkuehl/snapshots/cvs/drm/HEAD/shared-core -I../../../../../include -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -I../dri_client -I../dri_client/imports -Wall -Os -gstabs+ -pipe -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DDRI_NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DDRI_NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 r200_lock.c -o r200_lock.o gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I/home/fxkuehl/snapshots/cvs/drm/HEAD/shared-core -I../../../../../include -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -I../dri_client -I../dri_client/imports -Wall -Os -gstabs+ -pipe -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DDRI_NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DDRI_NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 r200_screen.c -o r200_screen.o r200_screen.c: In function `r200CreateScreen': r200_screen.c:407: error: `addr' undeclared (first use in this function) r200_screen.c:407: error: (Each undeclared identifier is reported only once r200_screen.c:407: error: for each function it appears in.) make[6]: *** [r200_screen.o] Error 1 make[6]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa/src/mesa/drivers/dri/r200' make[5]: *** [subdirs] Error 1 make[5]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa/src/mesa/drivers/dri' make[4]: *** [drivers-dri] Error 2 make[4]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa/src/mesa' make[3]: *** [default] Error 2 make[3]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa/src/mesa' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa/src' make[1]: *** [default] Error 1 make[1]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa' make: *** [linux-dri-x86] Error 2 make: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa' = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: another r300 compilation problem
Am Sonntag, den 13.02.2005, 11:28 -0500 schrieb Vladimir Dergachev: > Which module is it ? You only need r300 and you can ignore compiling all > others. Sorry, here are some more lines. radeon_screen.c: In function `radeonCreateScreen': radeon_screen.c:519: error: `addr' undeclared (first use in this function) radeon_screen.c:519: error: (Each undeclared identifier is reported only once radeon_screen.c:519: error: for each function it appears in.) make[6]: *** [radeon_screen.o] Error 1 make[6]: Leaving directory `/opt/src/xorg/mesa/Mesa/src/mesa/drivers/dri/r300' make[5]: *** [subdirs] Error 1 Of course I was talking about r300. br, Fionn -- Software patents- not allowed in Europe | See whats going on: Archiving Email - patented in Europe| http://freepatents.org/ E-Shopping Baskets - patented in Europe| Become active easily: Cross-compiling - patented in Europe| http://aktiv.ffii.org/eubsa/en --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: another r300 compilation problem
Which module is it ? You only need r300 and you can ignore compiling all others. best Vladimir Dergachev On Sun, 13 Feb 2005, Fionn Behrens wrote: Xorg and drm modules compiled fine but Mesa bails out: radeon_screen.c: In function `radeonCreateScreen': radeon_screen.c:519: error: `addr' undeclared (first use in this function) radeon_screen.c:519: error: (Each undeclared identifier is reported only once radeon_screen.c:519: error: for each function it appears in.) make[6]: *** [radeon_screen.o] Error 1 DRM_SOURCE_PATH and all symlinks appear to be set correctly. Suggestions? br, Fionn -- "We view Intellectual Property theft as a threat to our national security," (http://beam.me.to/?iptheft-terrorism) *** David Israelite, Ashcroft Deputy and Chief of "US DOJ IP Task Force" --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
another r300 compilation problem
Xorg and drm modules compiled fine but Mesa bails out: radeon_screen.c: In function `radeonCreateScreen': radeon_screen.c:519: error: `addr' undeclared (first use in this function) radeon_screen.c:519: error: (Each undeclared identifier is reported only once radeon_screen.c:519: error: for each function it appears in.) make[6]: *** [radeon_screen.o] Error 1 DRM_SOURCE_PATH and all symlinks appear to be set correctly. Suggestions? br, Fionn -- "We view Intellectual Property theft as a threat to our national security," (http://beam.me.to/?iptheft-terrorism) *** David Israelite, Ashcroft Deputy and Chief of "US DOJ IP Task Force" --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage-20050205-linux snapshot - problems
Am Sonntag, den 13.02.2005, 11:03 +0100 schrieb [EMAIL PROTECTED]: > On Saturday 12 February 2005 16:33, Felix K=FChling wrote: > > Am Donnerstag, den 10.02.2005, 07:21 +0100 schrieb=20 > [EMAIL PROTECTED]: > > > On Monday 07 February 2005 15:33, Felix K=3DFChling wrote: > > > > Am Montag, den 07.02.2005, 15:12 +0100 schrieb=3D20 > > > > > > [EMAIL PROTECTED]: > [snip] > > > > > > Tested with 2.6.11-rc3. DRM functional with glxgears. > > > > > > tuxkart and tuxracer work most the time but > > > sometimes=3D20 painting occurs outside of games window. > > > Parts of the image=3D20 appear (sometime mirrored) > > > outside game window or random=3D20 patterns appear. > > > > > I can't reproduce this on my Savage/IX. Someone else > > reported problems with 2.6.11-rc3, something like it > > wouldn't even load the DRM modules. Maybe something's > > broken with current DRM on Linux 2.6.11-rc3. If this > > problem persists with the latest snapshot (tomorrow's > > should have my latest fixes) could you try if it works > > with a stock 2.6.10 kernel (you'd have to recompile the > > DRM for it)? > > > > OK, I will try with 2.6.10. > > > > Cursor and numeric display in game window=3D20 > > > appear as random patterns. > > > > I just fixed another bug in texture tiling on Savage/IX. > > Though it only affected the road-texture in Tuxkart for > > me. Most textures were looking correctly. If you still > > get broken textures with tomorrow's snapshot then it > > might be a difference between our chip revisions (sigh). > > > > > Sometimes above games mess up the screen but restart > > > Game a=3D20 few times "fixes" it. > > > > Can't reproduce this either. I took another look at your lspci-output. It's a PCI card, right? I saw vertex corruption with PCI-DMA on my Savage4 once. Maybe this isn't working reliably. Does it help to set enable_vdma to false (in driconf or the environment)? Performance will be worse though. Have you overclocked your front-side bus? In that case, does it help if you don't overclock? > > > Every time starting tuxkart or tuxracer different textures > get messed up. For example, in tuxracer sometime trees and=20 > herrings show as randomly colored rectangles/shapes only,=20 > and herring counter and speed indicator OK; restart and=20 > tress and herrings OK but indicators show (some) digits as=20 > rectangles. > > Ground in tuxracer seems to go partially wrong as well,=20 > seems that some textures do not belong there > > Seems to go wrong already during initialization as behavior > afterward seems consistent. > > By what I see about wrong texture patterns, just wondering,=20 > could pointers to some texture buffers be invalid and it=20 > then paints with crap data? Did you override the VideoRam size in xorg.conf? Maybe you made it believe that it has more memory than is actually available. > > > > > > =3D46lighgear messes up the entire screen and would never > > > work. > > > > > > BTW, the games work on i810 HW with 2.6.11-rc3. > > > > > > > Since Linux 2.4 is no longer=3D20 > > > > open for new features there is not much point > > > > back-porting it to Linux 2.4.=3D20 > > > > > > > > See=3D20 > > > > http://dri.freedesktop.org/wiki/S3Savage for more > > > > information about the savage driver status. I just > > > > added a note about Linux 2.4 to that page. > > > > > > Sorry, have not found any reference to 2.4 being > > > unsupported=3D20 on that page.=3D20 > > > > > > Are there any test programs available to systematically > > > test=3D20 DRM/GL functionality? > > > > > > Regards > > > Michael > -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage-20050205-linux snapshot - problems
On Saturday 12 February 2005 16:33, Felix K=FChling wrote: > Am Donnerstag, den 10.02.2005, 07:21 +0100 schrieb=20 [EMAIL PROTECTED]: > > On Monday 07 February 2005 15:33, Felix K=3DFChling wrote: > > > Am Montag, den 07.02.2005, 15:12 +0100 schrieb=3D20 > > > > [EMAIL PROTECTED]: [snip] > > > > Tested with 2.6.11-rc3. DRM functional with glxgears. > > > > tuxkart and tuxracer work most the time but > > sometimes=3D20 painting occurs outside of games window. > > Parts of the image=3D20 appear (sometime mirrored) > > outside game window or random=3D20 patterns appear. > > I can't reproduce this on my Savage/IX. Someone else > reported problems with 2.6.11-rc3, something like it > wouldn't even load the DRM modules. Maybe something's > broken with current DRM on Linux 2.6.11-rc3. If this > problem persists with the latest snapshot (tomorrow's > should have my latest fixes) could you try if it works > with a stock 2.6.10 kernel (you'd have to recompile the > DRM for it)? > OK, I will try with 2.6.10. > > Cursor and numeric display in game window=3D20 > > appear as random patterns. > > I just fixed another bug in texture tiling on Savage/IX. > Though it only affected the road-texture in Tuxkart for > me. Most textures were looking correctly. If you still > get broken textures with tomorrow's snapshot then it > might be a difference between our chip revisions (sigh). > > > Sometimes above games mess up the screen but restart > > Game a=3D20 few times "fixes" it. > > Can't reproduce this either. Every time starting tuxkart or tuxracer different textures get messed up. For example, in tuxracer sometime trees and=20 herrings show as randomly colored rectangles/shapes only,=20 and herring counter and speed indicator OK; restart and=20 tress and herrings OK but indicators show (some) digits as=20 rectangles. Ground in tuxracer seems to go partially wrong as well,=20 seems that some textures do not belong there Seems to go wrong already during initialization as behavior afterward seems consistent. By what I see about wrong texture patterns, just wondering,=20 could pointers to some texture buffers be invalid and it=20 then paints with crap data? > > > =3D46lighgear messes up the entire screen and would never > > work. > > > > BTW, the games work on i810 HW with 2.6.11-rc3. > > > > > Since Linux 2.4 is no longer=3D20 > > > open for new features there is not much point > > > back-porting it to Linux 2.4.=3D20 > > > > > > See=3D20 > > > http://dri.freedesktop.org/wiki/S3Savage for more > > > information about the savage driver status. I just > > > added a note about Linux 2.4 to that page. > > > > Sorry, have not found any reference to 2.4 being > > unsupported=3D20 on that page.=3D20 > > > > Are there any test programs available to systematically > > test=3D20 DRM/GL functionality? > > > > Regards > > Michael --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage-20050205-linux snapshot - problems
On Thursday 10 February 2005 14:58, Felix K=FChling wrote: > Am Donnerstag, den 10.02.2005, 07:21 +0100 schrieb=20 [EMAIL PROTECTED]: > > On Monday 07 February 2005 15:33, Felix K=3DFChling wrote: > > > Am Montag, den 07.02.2005, 15:12 +0100 schrieb=3D20 > > > > [EMAIL PROTECTED]: > > > > Hardware: > > > > > > > > Toshiba Libretto L2 Tm5600 with: > > > > > > > > :00:04.0 VGA compatible controller: S3 Inc. > > > > 86C270-294=3D3D20 Savage/IX-MV (rev 13) (prog-if 00 > > > > [VGA]) Subsystem: Toshiba America Info Systems: > > > > Unknown device 0001 Control: I/O+ Mem+ BusMaster+ > > > > SpecCycle- MemWINV- VGASnoop- ParErr-=3D3D Stepping- > > > > SERR- FastB2B- > > > > Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- > > > > DEVSEL=3D3D3Dmedium >TAbort- =3D3D > > > >SERR- > > > Latency: 248 (1000ns min, 63750ns max), > > > > cache line size 08 Interrupt: pin A routed to IRQ > > > > 11 Region 0: Memory at e000 (32-bit, > > > > non-prefetchable) [size=3D3D3D128=3D3D M] > > > > Expansion ROM at 000c [disabled] > > > > [size=3D3D3D64K] Capabilities: > > > root> > > > > > > > > Software: > > > > > > > > Gentoo current with Gentoo supplied X Window System > > > > Version 6.8.1.903 (6.8.=3D3D 2 RC 3) > > > > Release Date: 25 January 2005 > > > > X Protocol Version 11, Revision 0, Release > > > > 6.8.1.903 Build Operating System: Linux > > > > 2.4.29-rc3-mhf239 i686 [ELF]=3D3D20 Current Operating > > > > System: Linux mhfl4 2.4.29-rc3-mhf239 #2 Tue Jan 18 > > > > 17:43=3D3D > > > > > > > > :33 CET 2005 i686 > > > > > > > > Build Date: 05 February 2005 > > > > > > > > Installed snapshot from > > > > savage-20050205-linux.i386.tar.bz2. On starting X: > > > > [snip] > > > > > > So, driver in snapshot still reports 1.0. Seems to > > > > be quite old (2001). > > > > > > The new Savage DRM 2.0.0 (in fact 2.2.0 by now) is > > > only available for Linux 2.6.=3D20 > > > > Tested with 2.6.11-rc3. DRM functional with glxgears. > > > > tuxkart and tuxracer work most the time but > > sometimes=3D20 painting occurs outside of games window. > > Parts of the image=3D20 appear (sometime mirrored) > > outside game window or random=3D20 patterns appear. > > Cursor and numeric display in game window=3D20 appear as > > random patterns. > > The garbage patters could be that it's getting the > texture tiling wrong. I messed with that code recently. > Could be that I broke it on Savage/IX. Also please try if > the latest snapshot fixes this. > > > Sometimes above games mess up the screen but restart > > Game a=3D20 few times "fixes" it. > > > > =3D46lighgear messes up the entire screen and would never > > work. > > Weird. I haven't had this kind of problems in a while. > Though I haven't tested on my Savage/IX recently. Looks > like it's time to swap cards again. > Tried 0211 snapshot and it behaves similar.=20 [snip] > > > Are there any test programs available to systematically > > test=3D20 DRM/GL functionality? > > For example mesa/progs/demos and Glean > (http://glean.sourceforge.net/). For reference you can > always run with indirect software rendering. Set > LIBGL_ALWAYS_INDIRECT in the environment. > I got hold of glean and will try it later today.=20 Regards Michael --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
