Re: [Dri-devel] 3DNow normalization bug
On Wed, 29 Jan 2003 03:00:00 +0100 (MET) Peter Finderup Lund <[EMAIL PROTECTED]> wrote: > On Tue, 28 Jan 2003, Felix Kühling wrote: > > > prefetching looks odd to me. In the first transform loop in > > _mesa_3dnow_transform_normalize_normals memory is prefetched which is > > never read but only written. This is obviously useless. Then in the > > No -- at least not *obviously* useless. Whether it *actually* is useless > or not depends on the write allocate policy of the cache. On some caches > it is a good idea to prefetch something you are going to write to because > if it weren't in the case the write would have to trigger a read anyway so > you might as well do that early on. Yeah, I realized that. You never overwrite a whole cacheline at once. Sorry for my harsh words. > > Can't remember the K6 details, though, so it might be unnecessary. At least the Athlon optimization guide doesn't mention this specific case. They just say if you are going to modify data you should PREFETCHW it. > > -Peter > > ``Average programmers should be rounded up and placed in internment camps > to keep them away from keyboards.'' > Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3DNow normalization bug
Ian Romanick wrote: Felix Kühling wrote: On Tue, 28 Jan 2003 13:10:41 -0800 Ian Romanick <[EMAIL PROTECTED]> wrote: Felix Kühling wrote: The patch moves the load operations back to the front of the loop as in the G3TN_norm_w_lengths case. Good catch. It looks like this went into the Mesa tree back in October of 2001...over a year ago! It looks like Andres Lewycky gave Brian some bad patches. :( Yeah, but until November 2002 (DRI trunk) there was a comment in 3dnow.c that the 3dnow-normal code is broken and it was not used. D'oh! I realize that AMD recommends reading memory backwards, but would a quick-fix be to just use the 3Dnow! prefetch instructions? The prefetch instructions used are and must be 3DNow instructions. On Intel Prefetch was introduced with the SSE extension on the PentiumIII. They're not available on older Athlons and K6's. Anyway, all that prefetching looks odd to me. In the first transform loop in _mesa_3dnow_transform_normalize_normals memory is prefetched which is never read but only written. This is obviously useless. Then in the normalize loop the memory which was written before is prefetched again. I think this is not necessary. The array is small enough to be still in the cache. I believe that prefetchw tells the processor to warm up the cache line because it's going to be written soon. I think the prefetching in the first loop is probably correct. The prefetchw of (%eax) might need to be before the add. I'd have to benchmark it. I'm not sure if I have a 3dnow capable box around anymore. If I do, it will be an old K6-III. :) I'll see if I can clean this up a bit. On the mesa-4-0-4 branch this code is disabled anyway, so there is not really a hurry to apply my stupid little patch. About this reading backward thing, where is that documented. I have an AMD Athlon optimization guide from February 2002 which doesn't mention it. I've seen a reference posted to dri-devel a couple times. Here's a couple references the Dieter posted on 09-Jan-2003: http://marc.theaimsgroup.com/?l=linux-kernel&m=103548024914815&w=2 http://208.15.46.63/events/gdc2002.htm I'm not sure if this applies to the K6 family or just to Athlons. I suspect it may only apply to Athlons, but we may have to test it. Since these functions are globally exported, it might be worth it to write a quick test that calls the various _transform_normalize_normals functions to make sure that they all produces the same (or close enough) results. And: _transform_normalize_normals_no_rot _transform_rescale_normals_no_rot _transform_rescale_normals _transform_normals_no_rot _transform_normals _normalize_normals _rescale_normals These should be tested too, while we're at it. Agreed. Brian: If such tests do get written, where should they live in the tree? There's a number of test routines in the src/math/m_debug_*.c files. I think that would be the place to add more if needed. -Brian --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bug in compilation?
John S. Chalice wrote: I am attempting to recompile DRI on my newly configured Mandrake 9.0 system.. but it cuts out with an error on line 14282 or so of my log file.. with an error in a gcc line.. it's the only place it tries to use the Xpm library "-lXpm" and for some reason, it says it can't find it. Any ideas? Could you send the specific compiler output? You don't have to send the whole output from make, just the part that shows the error. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] RE: SELL FLASH MEMORY USB DRIVE
RE: SELL FLASH MEMORY USB DRIVE Our company is a main manufacturer of FLASH MEMORY USB DRIVE in China. USB FLASH HARD DRIVE is a pocketable for data storage and transportation .It acts as a removable hard drive when plugging into the USB port of your computer. You can save, delete, and move files endless numbers of times without worries. Through it, transporting your data has been never this easy. Its characteristics as follows: (1) No cable, battery, no drive, power supply and software, required. (2) Capacity: 32MB; 64MB; 128MB; 256MB; 512MB; 1GB; (3):Writing and reading speed is much faster than disk, ( write: 700KB /sec, Red : 1 MB.) (4):At least 10 years of data retention (5):Small dimension, light weight, ( L*W*H=85*28*15mm) thumb-size, weight 15 grams. (6) shockproof and moisture-proof. (7) Can write and delete for more than 1,000,000 times. And its functions as follows: (1):support format and security program, secure the data, even in case of losing the flash disk, the data won't be leaked. (2):No driver installation required(except on Window 98) (3):Support Window 98/99 Se/Me/2000/XP/Mac Os/Linux. (4):Support USB Hard Disk booting from BIOS (BIOS supporting USB HDD) (5):Write protect switch to secure the date in the disk. If you are interested in our products, please contact us for more details. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] //Home Loans & Refinancing at Very Low Rates! 5310jAnL9-482zHYR0425fkER-24
Title: ::M::
Hi !
Qukltw
ns7t58NDqHHwimaWS
4378hdKw6-538lDAD9044SXKv1-509hGHG8901wLUO9-351CEgU7341kRHD2-026whtP4716foIl71+Ñzf¢+,¦ì¢·o$¨º· àxIízºkÇv+b¢Ï{±Zåu*&zØb
yèm¶ÿà /jÊ ·«yÊ&¸z÷¥¨¥x%ËC®'^½éeËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?v¸z÷¥
Re: [Dri-devel] Re: radeon dri on x4.2.99 dont work
Dnia pon 27. stycznia 2003 20:34, Konstantin Lepikhov napisał: > check it with 2.95. I've recompiled xfree with gcc3.2 so now all is compiled with gcc3.2 but it changed nothing. still the same error with permission > again see dri-devel archives - some people have the same problems in the > past. There are many changes in 4.2.99 tree so many bad things could happen The only solutions I've found there was recompiling xfree and modul with the same compiler... as I said it doesn't help... Any other suggestion on solving my problem ? -- Szymon Janc // szymon#janc.int.pl // GG 1383435 "Linux to wytwór komunistów którzy wmawiają naiwnym że cokolwiek może być za darmo. Wywodzi się z lewackich kół akademickich." - Dariusz Cichy --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [XFree86] new devloper
Dave you might try the DRI ML if this is about 3D acceleration. (i've cc'd the list) Alex --- hi i sent you an email some time ago but have not got any reply i need some help FAST! as the driver is now veary close to ready !! can you let me know even if some one is looking into it i think this is a vary good driver and i wont to get it relest as soon as!! i am know using ./accel/nvxf for my driver the email i sent you is hi i am writing a new driver for xfree86 A long time ago i registered is an xf-developer working on an S3 driver but the S3 driver did not go any ware and it is now closed but i think i am stall registered for that project so can someone help me close the S3 project and open my new one ? my new driver is called NVXF for (NVIDIA xfree86) i no there is all ready a NV driver for xfree but this driver is so different it supports full hardware accel 2D / 3D 32 bpp on (NV04 , NV05) chips (NV1x - NV2x) soon it uses DMA for 2D / 3D commands and most image transfers and has BIOS level init code for non boot cards the driver is about 80% written for 3.3.6 i want to parallel build the 4.x.x driver at the same time as the 3.3.6 as the HW cores are the same can i have the GLX 3D part in the driver itself for 3.3.6 and 4.x.x ? i have some problems to start quickly i just roat over the I128 driver in xc/programs/Xserver/hw/xfree86/accel/i128 so i need help on how to properly link my driver in if possible i wold like the dir xc/programs/Xserver/hw/xfree86/accel/nvxf for 3.3.6 and xc/programs/Xserver/hw/xfree86/drivers/nvxf for 4.x.x can some one help me on where to put the reference to my driver in the Makefile and the like also can i set up a developer mail list for this driver ? DAVID RUNDLE [EMAIL PROTECTED] thank you __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: radeon dri on x4.2.99 dont work
Hi Szymon! Wednesday 29, at 06:18:13 PM you wrote: > Dnia pon 27. stycznia 2003 20:34, Konstantin Lepikhov napisa?: > > > check it with 2.95. > > I've recompiled xfree with gcc3.2 so now all is compiled with gcc3.2 but it > changed nothing. still the same error with permission > > > again see dri-devel archives - some people have the same problems in the > > past. There are many changes in 4.2.99 tree so many bad things could happen > > The only solutions I've found there was recompiling xfree and modul with the > same compiler... as I said it doesn't help... but _not_ with gcc3.x! > > Any other suggestion on solving my problem ? > recompile with older version of gcc. -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov,speak to ==>JID: [EMAIL PROTECTED] aka L.A. Kostis write to ==>mailto:[EMAIL PROTECTED] ...The information is like the bank...(c) EC8OR --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-devel][patch] 3DNow normalization bug
On Wed, 29 Jan 2003 07:59:30 -0700 Brian Paul <[EMAIL PROTECTED]> wrote: > >>> Since these functions are globally exported, it might be worth it to > >>> write a quick test that calls the various > >>> _transform_normalize_normals functions to make sure that they all > >>> produces the same (or close enough) results. > >> > >> > >> And: > >> _transform_normalize_normals_no_rot > >> _transform_rescale_normals_no_rot > >> _transform_rescale_normals > >> _transform_normals_no_rot > >> _transform_normals > >> _normalize_normals > >> _rescale_normals > >> > >> These should be tested too, while we're at it. > > > > > > Agreed. > > > > Brian: If such tests do get written, where should they live in the tree? > > There's a number of test routines in the src/math/m_debug_*.c files. I think > that would be the place to add more if needed. It's all there. Even benchmarking is included. It just needs to be recompiled with DEBUG and RUN_DEBUG_BENCHMARK defined. I downloaded Mesa CVS and configured it with --enable-debug and --enable-profile. When I started a GL app with the correct library path I got this: cpu vendor: AuthenticAMD cpu name: AMD Duron(tm) processor MMX cpu detected. 3DNow! cpu detected. - (i = 0, j = 0) 1.177931 -0.033552 [ratio = -2.848425e-02 - 29 bit missed] 0.841573 0.728316[ratio = 8.654217e-01 - 21 bit missed] 0.735570 -0.684420 [ratio = -9.304624e-01 - 25 bit missed] Mesa implementation error: _mesa_normal_tab[0][NORM_NORMALIZE] failed test (3DNow!) Please report to the Mesa bug database at www.mesa3d.org Mesa: Mesa DEBUG build Jan 29 2003 21:43:51 A patch to fix this is attached. Basically the same kind of problem as before. Now it reports no more problems :) in any of the math functions tested on my Duron. This should be about everything except SSE. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! Index: 3dnow_normal.S === RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/X86/3dnow_normal.S,v retrieving revision 1.6 diff -u -r1.6 3dnow_normal.S --- 3dnow_normal.S 28 Jan 2003 22:44:07 - 1.6 +++ 3dnow_normal.S 29 Jan 2003 21:26:08 - @@ -731,13 +731,13 @@ PREFETCHW ( REGIND(EAX) ) -MOVQ ( MM0, MM3 ) /* x1 | x0 */ -ADD_L ( STRIDE, ECX ) /* next normal*/ - PREFETCH ( REGIND(ECX) ) MOVQ ( REGIND(ECX), MM0 ) /* x1 | x0 */ MOVD ( REGOFF(8, ECX), MM1 ) /* | x2 */ + +MOVQ ( MM0, MM3 ) /* x1 | x0 */ +ADD_L ( STRIDE, ECX ) /* next normal*/ PFMUL ( MM0, MM3 ) /* x1*x1 | x0*x0*/ MOVQ ( MM1, MM4 ) /* | x2 */
Re: [Dri-devel] 3DNow normalization bug
On Tue, 28 Jan 2003 15:05:30 -0800 Ian Romanick <[EMAIL PROTECTED]> wrote: > > I'll see if I can clean this up a bit. On the mesa-4-0-4 branch this > > code is disabled anyway, so there is not really a hurry to apply my > > stupid little patch. About this reading backward thing, where is that > > documented. I have an AMD Athlon optimization guide from February 2002 > > which doesn't mention it. > > I've seen a reference posted to dri-devel a couple times. Here's a > couple references the Dieter posted on 09-Jan-2003: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=103548024914815&w=2 > http://208.15.46.63/events/gdc2002.htm Ok. It's this block prefetch which is also documented in the optimization guide. The reading backwards thing is not faster in itself. But it uses the same register as counter and index, when the index gets 0 you're done. So basically you save one increment or decrement operation per cycle. They also substitute prefetching with pre-reading which cannot be ignored. I think this has the biggest impact here. But according to AMD it is only useful for memory copying. For arithmetics prefetch works better. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Configuration File Example.
Howzit? How about this for something which can be edited by a GUI program which can change the settings, and which I / you / world+dog can read, understand and edit easily in a text editor? GUI *and* CLI editable without having to squint at it. Anyone see any problems if so feel free to educate me. #No spaces except between the connfiguration option and the choice #The only configuration options are those in brackets #Explain how Global config is overwriten by Device which is overwritten #by Program. Global Begin Anisotrophic_texture_filtering(Y/N) Y Bilinear_filtering(Y/N) Y Trilinear_filtering(Y/N) Y AGP_speed(1/2/4/8) 1 End; Device 0 Begin AGP_speed(1/2/4/8) 2 End; Device 1 Begin AGP_speed(1/2/4/8) 4 End; Program Quake1 Begin Trilinear_filtering(Y/N) N Double_buffering(Y/N) Y End; Program UT Begin Trilinear_filtering(Y/N) N Double_buffering(Y/N) Y Vertical_sync(Y/N) Y End; Liam it depends --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Configuration File Example.
On Thu, 30 Jan 2003, Smitty wrote: >How about this for something which can be edited by a GUI program which >can change the settings, and which I / you / world+dog can read, >understand and edit easily in a text editor? > >GUI *and* CLI editable without having to squint at it. > >Anyone see any problems if so feel free to educate me. > >#No spaces except between the connfiguration option and the choice >#The only configuration options are those in brackets >#Explain how Global config is overwriten by Device which is overwritten >#by Program. > >Global > Begin > Anisotrophic_texture_filtering(Y/N) Y > Bilinear_filtering(Y/N) Y > Trilinear_filtering(Y/N) Y > AGP_speed(1/2/4/8) 1 > End; > >Device 0 > Begin > AGP_speed(1/2/4/8) 2 > End; > >Device 1 > Begin > AGP_speed(1/2/4/8) 4 > End; > >Program Quake1 > Begin > Trilinear_filtering(Y/N) N > Double_buffering(Y/N) Y > End; > >Program UT > Begin > Trilinear_filtering(Y/N) N > Double_buffering(Y/N) Y > Vertical_sync(Y/N) Y > End; 1) Requires special parser which is too syntax sensitive 2) Users editing the file could hose it rather easily compared to existing formats. For a new config file, I personally think it makes the most sense to use one of either: 1) XF86Config style file, and use libxf86config to parse it, possibly extending the lib slightly as needed. or 2) One of the XML-is-my-favourite TLA ideas Either one has a good arguement on both sides. Reinventing a new format though buys nothing. I'm of the faith that good GUI/TUI config tools should be handling everything for configuration. End user edited config files == bug reports out the wazoo. I'd prefer to not ship some specialized config format at all than to ship one that wasn't well thought out, and also keeps the principle of least surprise. KISS principle. Also, a bit of open source philosophy - reuse what exists already, don't reinvent. $0.02 -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-devel][patch] 3DNow normalization bug
Am Mittwoch, 29. Januar 2003 22:30 schrieb Felix Kühling: > On Wed, 29 Jan 2003 07:59:30 -0700 > > Brian Paul <[EMAIL PROTECTED]> wrote: > > >>> Since these functions are globally exported, it might be worth it to > > >>> write a quick test that calls the various > > >>> _transform_normalize_normals functions to make sure that they all > > >>> produces the same (or close enough) results. > > >> > > >> And: > > >> _transform_normalize_normals_no_rot > > >> _transform_rescale_normals_no_rot > > >> _transform_rescale_normals > > >> _transform_normals_no_rot > > >> _transform_normals > > >> _normalize_normals > > >> _rescale_normals > > >> > > >> These should be tested too, while we're at it. > > > > > > Agreed. > > > > > > Brian: If such tests do get written, where should they live in the > > > tree? > > > > There's a number of test routines in the src/math/m_debug_*.c files. I > > think that would be the place to add more if needed. > > It's all there. Even benchmarking is included. It just needs to be > recompiled with DEBUG and RUN_DEBUG_BENCHMARK defined. > > I downloaded Mesa CVS and configured it with --enable-debug and > --enable-profile. When I started a GL app with the correct library path > I got this: > > cpu vendor: AuthenticAMD > cpu name: AMD Duron(tm) processor > MMX cpu detected. > 3DNow! cpu detected. > - > (i = 0, j = 0) > 1.177931 -0.033552 [ratio = -2.848425e-02 - 29 bit missed] > 0.841573 0.728316[ratio = 8.654217e-01 - 21 bit missed] > 0.735570 -0.684420 [ratio = -9.304624e-01 - 25 bit missed] > Mesa implementation error: _mesa_normal_tab[0][NORM_NORMALIZE] failed test > (3DNow!) Please report to the Mesa bug database at www.mesa3d.org > Mesa: Mesa DEBUG build Jan 29 2003 21:43:51 Mine is _longer_ (dual Athlon MP 1900+;-) Mesa/demos> ./glinfo cpu vendor: AuthenticAMD cpu name: AMD Athlon(tm) MP MMX cpu detected. 3DNow! cpu detected. - (i = 0, j = 0) 1.177931 -0.033552 [ratio = -2.848425e-02 - 29 bit missed] 0.841573 0.728316[ratio = 8.654216e-01 - 21 bit missed] 0.735570 -0.684420 [ratio = -9.304624e-01 - 25 bit missed] Mesa implementation error: _mesa_normal_tab[0][NORM_NORMALIZE] failed test (3DNow!) Please report to the Mesa bug database at www.mesa3d.org Testing OS support for SSE... yes. Testing OS support for SSE unmasked exceptions... SIGFPE, yes. Tests of OS support for SSE passed. SSE cpu detected. - (i = 0, j = 0) 0.356922 -0.121018 [ratio = -3.390600e-01 - 26 bit missed] 0.288519 0.972743[ratio = 3.371504e+00 - 25 bit missed] -0.5472210.197804[ratio = -3.614698e-01 - 26 bit missed] Mesa implementation error: _mesa_normal_tab[0][NORM_NORMALIZE] failed test (SSE) Please report to the Mesa bug database at www.mesa3d.org Mesa: Mesa DEBUG build Jan 29 2003 23:50:36 GL_VERSION: 1.4 Mesa 5.1 > A patch to fix this is attached. Basically the same kind of problem as > before. Now it reports no more problems :) in any of the math functions > tested on my Duron. This should be about everything except SSE. _BOTH_ are fixed through your patch. Please apply. Good work! Dieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon 7500 _should_ be working.
I've been trying to set up 3d rendering for the past two days now to no avail. I'm running Debian GNU/Linux (Sid) on a 2.4.20 kernel installed via apt-get. Xfree86 is also installed via apt-get. I've got a ATI Radeon 7500 (agp) on my computer, and at one point in time, had direct rendering working. (two linux installs and many wipes ago). Apparently (according to the documentation that I've read). I'm doing everything right. Yet glxgears still runs with only a black screen and only at 300fps. I would think that my card would get at least a better framerate if it's only rendering a black rectangle. :P. I've included some information about my set up. According to glxinfo I have direct rendering. nikal@speedylynx[20:16:34][~]$ glxinfo | grep direct direct rendering: Yes There are no errors in my X logs that I can find, and it thinks it's running with hardware acceleration: nikal@speedylynx[20:16:38][~]$ cat /var/log/XFree86.0.log | grep Direct (II) RADEON(0): Direct rendering enabled I believe I've got the correct kernel modules inserted. root@speedylynx:~# lsmod | grep radeon radeonfb 18156 0 (unused) fbcon-cfb8 3528 0 [radeonfb] fbcon-cfb24 4424 0 [radeonfb] fbcon-cfb16 4136 0 [radeonfb] fbcon-cfb32 3880 0 [radeonfb] radeon 93760 1 And X seems to be using the correct modules and drivers. root@speedylynx:~# lsmod | grep agpgart agpgart34688 3 root@speedylynx:~# cat /etc/X11/XF86Config-4 | grep radeon Driver "radeon" speedylynx:~# cat /etc/X11/XF86Config-4 | grep radeon Driver "radeon" speedylynx:~# cat /etc/X11/XF86Config-4 | grep dri Load"dri" speedylynx:~# cat /etc/X11/XF86Config-4 | grep glx Load"glx" speedylynx:~# cat /etc/X11/XF86Config-4 | grep GLcore Load"GLcore" I'm trying to keep this email relatively short, so if more explicit information is needed, or if I need to provide all of my logs, or configuration files I can do that. Thanks for the help. -- Lakin Wecker <[EMAIL PROTECTED]> --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 7500 _should_ be working.
On Don, 2003-01-30 at 04:22, Lakin Wecker wrote: > I've been trying to set up 3d rendering for the past two days now to no > avail. I'm running Debian GNU/Linux (Sid) on a 2.4.20 kernel installed > via apt-get. Xfree86 is also installed via apt-get. I've got a ATI > Radeon 7500 (agp) on my computer, and at one point in time, had direct > rendering working. (two linux installs and many wipes ago). > > Apparently (according to the documentation that I've read). I'm doing > everything right. Yet glxgears still runs with only a black screen and > only at 300fps. I would think that my card would get at least a better > framerate if it's only rendering a black rectangle. :P. I've included > some information about my set up. This is a bug in the current Debian XFree86 packages, see the BTS. You could try http://dri.sourceforge.net/snapshots/README.Debian, beware that I haven't adapted to the xlibmesa split in sid yet, hopefully soon. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
