Re: r300 Status Report - Gentoo amd64, Saphire 9600
Hamie wrote: Hi. A quick status report/feedback on how the r300 effort fares on my workstation. Hardware is an AMD64 3200 (Socket 939, on an Asus A8V Deluxe Motherboard). 1GB RAM dual channeled (2x 512MB sticks) and a Saphire Radeon 9600 card (Mobility Radeon 9600 M10 - PCI ID 1002,4e51). Todays CVS works, yesterdays didn't... I belive it's the 64bit/32boit IOCTL's that were posted today or late yesterday that did the trick there. Up till now I'd either get a complete hang, or (Last night) X would start show a black screen with the movable cursor nothing more. No keyboard access at all no displaying anything else). Today it goes a lot better. X actually starts correctly, and I can bring up an xterm, glxinfo runs (But still says no direct rendering, Xorg.0.log says different) and glxgears now gives a result of 739fps (Default size) vs 270fps using the default non dri setup. (Which still looks a bit slow to me... My 1.6GHz Pentium-M laptop with a FireGL-T2-128 can get ~300fps, I expected more from an Athlon 64 AGP8... Anyway). Things now work... Although I did expect better frame rates. Especially since other have reported much much higher ones... My config log are appended below if anyone else is interested in duplicating/criticising what I've got. One other funny I noticed that I've never noticed before without the r300 drivers is that X would 'reload' itself whenever the client closed.. (I was only runnning one at a time, no window manager). Is that normal? Ahem... Brain fade... Damned thing wasn't picking up the new GL libs r300_dri.so... I found a couple of problems... 1. Gentoo seems to install the libs dri modules for X in /usr/lib/modules/dri instead of under /usr/X11R6 2. The Mesa cvs I have doesn't seem to copy r300_dri.so from $BASE/lib64... In fact the install script just does a cp $BASE/lib*/lib to the destination lib directory. WHich misses r300_dri.so because it's in $BASE/lib64, and NOT in a sub-directory... Maybe I did somethign wrong when I set it up... I'd better check the readme's again. Anway... Now I get ~1080fps in glxgears and tuxracer is actually playable... But the ice is as others have reported black with strange swirly bits on it now again... --- 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=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 Status Report - Gentoo amd64, Saphire 9600
Philipp Klaus Krause wrote: Hamie schrieb: One other funny I noticed that I've never noticed before without the r300 drivers is that X would 'reload' itself whenever the client closed.. (I was only runnning one at a time, no window manager). Is that normal? It is. Right. Ta... I've never actually tried running it like that, so wasn't sure... Anyway... Results were much better once I'd got the r300_dri.so actually copied the libs loaded from the correct place... --- 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=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Unknown PCI-ID...
Hi a.. I just got a Saphire radeon 9600 with 256MB of memory on it. lspci reports is as two device though, one of which has a pci-id of 4e71, which I can't find anywhere... Anyone know the details? And which chipset it is? :01:00.0 VGA compatible controller: ATI Technologies Inc M10 NQ [Radeon Mobility 9600] (prog-if 00 [VGA]) Subsystem: PC Partner Limited: Unknown device 0200 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 169 Region 0: Memory at d000 (32-bit, prefetchable) [size=fbd0] Region 1: I/O ports at e000 [size=256] Region 2: Memory at fbe0 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 0002 [disabled] Capabilities: [58] AGP version 3.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=none Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :01:00.1 Display controller: ATI Technologies Inc: Unknown device 4e71 Subsystem: PC Partner Limited: Unknown device 0201 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (2000ns min), cache line size 08 Region 0: Memory at e000 (32-bit, prefetchable) Region 1: Memory at fbf0 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- --- 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=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 on Thinkpad r50p
Hamie wrote: It's working... Mostly... I get pretty good rates on glxgears... But get a funny error about not enought verticies... [EMAIL PROTECTED]:~$ glxgears r300NewProgram, target=34336, id=0 vertex prog r300NewProgram, target=34820, id=0 fragment prog r300NewProgram, target=35104, id=0 ati fragment prog Using 8 maximum texture units.. r300_render.c:r300_get_primitive_type Not enough vertices to draw primitive 08 - help me ! 8143 frames in 5.0 seconds = 1628.600 FPS 8310 frames in 5.0 seconds = 1662.000 FPS 8241 frames in 5.0 seconds = 1648.200 FPS 8326 frames in 5.0 seconds = 1665.200 FPS 8304 frames in 5.0 seconds = 1660.800 FPS 8317 frames in 5.0 seconds = 1663.400 FPS Oh yeah... Forgot to say... It flickers as well... --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Mesa linux-dri fails to build
This mornings cvs snapshot of Mesa using linux-dri config fails to build. A missing drm.h file... It builds fine using linux-x86, but I want it for the r300 stuff, so assuming I acytually need the linux-dri build... is there a date tag I can use that will build? TIA Hamish Marson --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mesa linux-dri fails to build
Adam Jackson wrote: On Saturday 29 January 2005 17:21, Hamie wrote: This mornings cvs snapshot of Mesa using linux-dri config fails to build. A missing drm.h file... It builds fine using linux-x86, but I want it for the r300 stuff, so assuming I acytually need the linux-dri build... is there a date tag I can use that will build? You also need to check out drm CVS: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/dri co drm Do this from the directory above your Mesa dir, so that the Mesa and drm directories are in the same directory. - ajax Ah bugger. Thanks. I knew it was something simple. I had a drm cvs, but it wasn't there... H --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 on Thinkpad r50p
It's working... Mostly... I get pretty good rates on glxgears... But get a funny error about not enought verticies... [EMAIL PROTECTED]:~$ glxgears r300NewProgram, target=34336, id=0 vertex prog r300NewProgram, target=34820, id=0 fragment prog r300NewProgram, target=35104, id=0 ati fragment prog Using 8 maximum texture units.. r300_render.c:r300_get_primitive_type Not enough vertices to draw primitive 08 - help me ! 8143 frames in 5.0 seconds = 1628.600 FPS 8310 frames in 5.0 seconds = 1662.000 FPS 8241 frames in 5.0 seconds = 1648.200 FPS 8326 frames in 5.0 seconds = 1665.200 FPS 8304 frames in 5.0 seconds = 1660.800 FPS 8317 frames in 5.0 seconds = 1663.400 FPS Not sure if anyone else gets it... I have to take a look see if I undertsand why I get it. Hamish. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
Philipp Klaus Krause wrote: Does anyone have figures for the MOST time consuming parts of software 3D in the Mesa libs? Those would be the logical bits to push into hardware first. But I'm not sure I've ever seen a profile output from X to say which parts are actually most would benefit more from acceleration than others... Even without any such data you can easily find out the most important stuff: Since It's a 3D graphics _pipeline_ you should always start by accelerating the back end: implement hardware z- and stencil buffer first. Then work your way from the backof the graphics pipeline. Yes, but where the tree branches, you still need to know which branches (Usually) consume the most time/CPU... Admittedly you should be aqble to get this from profiling the X server, but I just wondered if someone had the figures already... --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
Rogelio Serrano wrote: On 2004-10-25 04:10:30 +0800 Vladimir Dergachev [EMAIL PROTECTED] wrote: If there weren't all those patents out there we might just try to develop a free graphics chip. I have thought about this (repeatedly - the idea gets very tempting after asking for the docs for the Nth time) and I don't think it is feasible to make an actual chip. By the time we are finished the world will move on. What could work, however, is to make a *board* that is capable of decent 3d. Put lots of memory, lots of bandwidth and several DSP to approximate the same level of raw floating-point power as 3d GPUs. Leave everything else to the software. The problem is getting such a beast under $1000 range. Last time I looked TI DSPs that were up to the task were rather expensive. best Vladimir Dergachev [snipped...] This was discussed in lkml a few days ago. A hardware company is considering building an open fpga based video card. Although the target is mainly 2d accel its a good start. There was a lot of discussion about off screen rendering and support for the new compositing model in xorg. You can see that thread posted on kerneltrap. I was watching that... Does anyone have figures for the MOST time consuming parts of software 3D in the Mesa libs? Those would be the logical bits to push into hardware first. But I'm not sure I've ever seen a profile output from X to say which parts are actually most would benefit more from acceleration than others... H --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
Alan Cox wrote: What about if you want to use fb when in text mode (Because you get 200x75 on a 1600x1200 screen) AND run DRI because the rest of the time you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7 back forth between X fb... (i.e. how I currently use it but with unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely). Thats actually the easy case. We don't care if it takes another 30th of a second to flip console. The hard one Jon was trying to point out is a dual head card. Head 0 has someone running bzflag, head 1 has someone editing an open office document. You have one accelerator set for both heads. At that point you do care about the switch over, but the drivers can co-operate for it. So it would always work, but it would work better with friendly drivers when there is a need to do so. I see you point of view. And agree with the sentiment about another 1/30th of a scond to switch modes... Heck, I'd put up with 500ms... (1000ms looks like too much of a lag makes me impatient when I want to switch. Especially if there's no feedback). But this relies on drivers co-operating with each other. Which is a real pain, and we'd still be stuck with finger pointing whenever two drivers didn't manage to co-operate successfully... And you'd need co-operation understanding to solve the problem... If one of the sides is proprietary closed source drivers then the co-operation may not be there. At the end of the day, if it works works well, it doesn't appear to matter too much whether it's a single driver, or multiple drivers accessing the same hardware. I have no axe to grind either way, and hope I'm keeping an open mind. But from a supportability point of view I think Jon's single driver wins. Even if it's a closed source driver, as long as the entry points callbacks are documented well can be tested, it's easier to find where the problem lies (i.e. inside or outside the one driver). Having competing ones may well prove to be near impossible to get to work together (Risking the wrath and going back to an example like the ide cd disk one, it would be like having a proprietary driver talking to your SCSI DVD drive, manipulating the chipset on your SCSI card another one doing the same thing for you HD... It just doesn't happen that way now... We have a SCSI card driver that looks after the card separate drivers that use the low-level one to just push SCSI commands to each. - Bad analogy? Currently this fails to work... Presumably because the fb DRI code (fglrx here BTW) don't talk to each other so the display gets garbled if you're lucky... Lockup if you're not. fglrx stomps blindly on everything including your AGP. Not much we can do about it. Yeah. Would fglrx be more stable if you used the external AGP rather than fglrx's built in AGP driver? although Alan's probably works for DRI fb on separate heads, how does it guarantee that the chipset is all setup the same way for each process on different heads... (When they have to share some of the hardware). Or is that necessary? You assume someone else crapped on the hardware. That is how DRI works for example. You have multiple rendering clients each of which when it takes the lock finds out if it was the last user (thats one thing Linus sketch lacked but is easy to add). My code ends up looking like lock if(someone_else_used_it) restore_my_state() blah unlock Ah... Now I understand what you've been talking about as well... The only caveat is whether you can always restore your own state from the state the other person put it into. Do any cards exist where you could perhaps still lock the card up because you didn't know the current state of the card? Would it be better to do the state_changed flag as a callback to each registered driver? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
Alan Cox wrote: On Sad, 2004-09-11 at 17:46, Jon Smirl wrote: User 1's game queues up 20ms of 3D drawing commands. Process swap to user 2. -quiesce() is going to take 20ms. User 2's timeslice expires and we go back to user 1. User 1 queues up another 20ms. User 2's editor is never going to function. If you implement it wrongly sure. If you implemented it right then this occurs. User 1 queues 20 ms of 3D commands User 1 is pre-empted User 2 wants the 2D engine User 2 beings wait for 2D User 2 sleeps User 1 wakes User 1 beings wait for 3D but discovers a claim is in progress User 1 sleeps User 2 wakes, runs commands If you have DRI loaded then as you rightly say the obvious desired outcome is that the fb engine either turns acceleration off or switches to using the DRI layer. But this is a pretty obscure case, and one we can't even begin to support yet anyway. What about if you want to use fb when in text mode (Because you get 200x75 on a 1600x1200 screen) AND run DRI because the rest of the time you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7 back forth between X fb... (i.e. how I currently use it but with unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely). Currently this fails to work... Presumably because the fb DRI code (fglrx here BTW) don't talk to each other so the display gets garbled if you're lucky... Lockup if you're not. Although I didn't like (Understand?) Jon's suggestion at first, I have to admit, that his scheme would let this work... because the low level driver would know what mode was in place, and you'd call the low-level driver to change between 3D fb mode... Although Linus' suggestion works for memory allocation... I don't believe it addresses two competing drivers wanting to play with the same screen... Even when it's serialised like that. And unfortunately although Alan's probably works for DRI fb on separate heads, how does it guarantee that the chipset is all setup the same way for each process on different heads... (When they have to share some of the hardware). Or is that necessary? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
Patrick McFarland wrote: On Mon, 06 Sep 2004 21:15:07 +0100, Alan Cox [EMAIL PROTECTED] wrote: In some cases yes. The DRM is happy with the idea of the kernel being a DRM client too. Thats actually a pretty cool idea. For us that need to use the vesa fbcon driver because there is no native driver, it would probably be faster and saner, and no more problems with dri drivers that don't play nice with fbcon drivers (is that even an issue anymore?) Yeah it is... Especially with (Dare I say it) closed source drivers such as ATI's firegl. H --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
Alan Cox wrote: On Sul, 2004-09-05 at 23:11, Jon Smirl wrote: What is the advantage to continuing a development model where two groups of programmers work independently, with little coordination on two separate code bases trying to simultaneously control the same piece of hardware? This is a continuous source of problems. Why can't we fix the development model to stop this? I don't see that as much of a problem. The mess arises from some simple lacks in the objects in kernel and the methods required to co-ordinate. Lots of drivers are written by a lot of people in the kernel and they work just fine. The ext3 authors don't spend their lives co-ordinating with SCSI driver authors, they just get the API right. Sorry, but I think that's (Possibly?) a really really bad misleading example... Apples Apples vs Chocolate Milkshakes... The dual screen problem with DRM fb is two drivers accessing (Sometimes) the same hardware. The ext3 vs SCSI is a filesystem, that sits on-top of a disk device that may just be SCSI.. Or IDE.. The fs - SCSI interface is a logical one. Unless you can have fb sitting on top of DRM of course... (I discount DRM on-top of fb, because of the D == Direct... No other reason :)... Does it make sens to have fb ontop of DRM at all? Anyone? regards Hamish. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
