Re: [Dri-devel] radeon 9200se
On 26 Sep 2003 22:14:59 +0200 maestro [EMAIL PROTECTED] wrote: hi all, my system configuration: P4 2,4Ghz fsb 800 HT super micro p4spa+ mainboard radeon 9200se graphics card running debian woody with kernel 2.4.21 XFree86 4.3.99-12 compiled from source recently i bought a radeon 9200se graphics card. it took me a very long time to get it work in X. its because the ati driver only knows about the 9200 but not the 9200se. the pci-chip-id is differen (9200 = 5963 / 9200se = 5964) i found a patch on the internet that makes the driver recognize that chip. (http://www.mail-archive.com/[EMAIL PROTECTED]/msg12830.html) i recompiled XFree86 and it worked perfectly. now i want dri support too. i downloaded the radeon package (radeon-20030926-linux.i386.tar.bz2) run install.sh and everything You need a r200 snapshot for this card. worked great but when i run startx i get the same message as when the card wasnt detected by the driver before. [quote /var/log/XF86log.0.log] ...snip (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (EE) No devices detected. [/quote] so my question is: does the radeon dri package support the 9200se and if not is it possible to apply the above patch to make it support it? secondly is it possible to get dri support right when building XFree86 using my existing and working driver? thanks for your help m Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI savage driver status
On Sat, 27 Sep 2003 00:30:23 -0300 Rafael Maximo [EMAIL PROTECTED] wrote: Felix, I tried this patch but it looked the same here, it only worked with DisableTile On. What's your card? i'm using a savage4 chip ID 8A22. lspci : 01:00.0 VGA compatible controller: S3 Inc. [ProSavageDDR K4M266] lspci -n: 01:00.0 Class 0300: 5333:8d04 I'm also wondering why your patch indicate line number 2601 while here it's on #1757. Are we using the same source? :) Obviously not. I made a fresh checkout of the savage-1_0_0-branch yesterday. cvs status savage_driver.c tells me: === File: savage_driver.c Status: Locally Modified Working revision:1.10.10.5 Repository revision: 1.10.10.5 /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c,v Sticky Tag: savage-1_0_0-branch (branch: 1.10.10) Sticky Date: (none) Sticky Options: (none) The local modification is only the patch I sent yesterday. Felix bye. At 02:11 PM 26/9/2003, Felix Kühling wrote: [snip] __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA G550 w/ kernel mga module version 3.1.0 hard lock
Hey, On Fri, Sep 26, 2003 at 07:37:56AM -0400, Malcolm Mallardi wrote: I resolved this issue yesterday after sending the first mail. Definitely an intentional breakage. Now using the build from yesterday 09/25/03 The OpenGL mouse issue, and console switching issues with kernel module 3.1.0 still exist. Just to let you know, I have a G400 MAX that I use in dualhead (non-merged), and I share the cursor issue with you, but switching from X to VC and back works no problem. So perhaps that issue is isolated to the G550? I use the MGA framebuffer driver though, so maybe things are different e.g. if you are using a VGA text mode on console. -- Ryan Underwood, nemesis at icequake.net, icq=10317253 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon/r200 texture engine question
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2003-09-26 at 18:16, Alex Deucher wrote: 1. looking at the mga textured video code, it disables the DRI when it is in use. is there any reason for this? is it possible to use the texture engine for Xv and DRI at the smae time. It seems like it should. I agree. When implemeting this on radeon, would I have to use the CP to program the texture registers or could I use MMIO? Using the 3D engine without the CP is hard if not impossible. how do 2D, 3D, CP, etc fit together. I take it the CP is mainly a queue for 3D commands, but can also process register writes? I understand how the to issues commands for 2D to the CP, but how does 3D work? The DRI driver seems very foreign by comparison. having looked it over it guess the various functions queue up 3D commands which are then flushed to the 3D engine at some point. where do that commands get flushed? can I just use the texture commands or do I need to recreate the commands to create a quad first and then the texture? Could some one maybe sketch out the call order do to something like this in the DRI? Like: RADEONCreateQuad() RADEONCreateTexture() RADEONBindTexture() RADEONRenderObject() or something like that. so I can get an idea of what all needs to be done. Is there a reference that explains what each file in the 3D driver does and how they fit together? like: card_tex.c - texture functions used to allocate and render textures created in card_xxx.c card_span.c - does X on objects from card_yyy.c card_screen.c - does Y card_state.c - etc. I have a general idea based on the names, but I can't see exactly how they all fit together. if someone can better fill me in on this I'll write a intro to 3D engines and DRI code page for the DRI wiki. I've been toying with the idea of converting the existing Xv code to CP anyway, however if you disabled the DRI and wanted to use the overlay or the texture engine you'd need an MMIO code path at least. The register write macros could be changed (or new ones added) to use the CP transparently when appropriate. do you mean like psuedo-MMIO using the CP? or just other macros like the 2D accel code uses (OUTRING() and such). is it possible to use the 3D engine at all when the DRI is not enabled? 3. Is there a limit on the number of textures on radeon? How many Xv ports should I allow for the texture engine? I think mga allows 32, although that might have been an arbitrary decision. Yes, I don't think there's a limitation other than the amount of video RAM. 4. Can the overlay and the texture engine Xv adapters co-exist? I don't see why they couldn't. AFAIK other drivers offer both types of adaptors simultaneously. I hope others will fill in the questions I didn't feel competent enough to answer. As a bonus, once you've solved all the issues involved, adding some RENDER extension acceleration should be trivial. :) I played with that a little but never found the time to get it very far. And maybe windows with alpha channels one day ;) Do you have any code (however broken) I could look at? Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon/r200 texture engine question
Alex Deucher wrote: I'm thinking about implementing a textured video option on radeon for mergedfb (or non-mergedfb too for that matter). It would be useful since video windows could span heads in mergedfb mode and you could also have multiple Xv windows at the same time rather than just one with the overlay unit. My questions are as follows: 1. looking at the mga textured video code, it disables the DRI when it is in use. is there any reason for this? Boy howdy is there ever! It is easy for the 2D driver and the 3D driver to work together because they don't share any state. Specifically, they don't share texture memory state, 3D hardware register state, or vertex engine state. As soon the 2D driver start using texture mapping hardware for Xv, all that state becomes shared. If you're going to go to the effort of making the server-side driver and the client-side (DRI) driver share all that state, you may as well go just a small bit further and get the client-side driver loaded server-side. :) If nothhing else, that would make maintainence easier. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 221] radeon_vtxfmt.c:925: radeonVtxfmtFlushVertices: Assertion `rmesa-dma.flush == 0 || rmesa-dma.flush == flush_prims' failed.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=221 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-26-09 18:53 --- Fixed in DRI CVS, thanks Manuel for verifying. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon/r200 texture engine question
--- Ian Romanick [EMAIL PROTECTED] wrote: Alex Deucher wrote: I'm thinking about implementing a textured video option on radeon for mergedfb (or non-mergedfb too for that matter). It would be useful since video windows could span heads in mergedfb mode and you could also have multiple Xv windows at the same time rather than just one with the overlay unit. My questions are as follows: 1. looking at the mga textured video code, it disables the DRI when it is in use. is there any reason for this? Boy howdy is there ever! It is easy for the 2D driver and the 3D driver to work together because they don't share any state. Specifically, they don't share texture memory state, 3D hardware register state, or vertex engine state. As soon the 2D driver start using texture mapping hardware for Xv, all that state becomes shared. If you're going to go to the effort of making the server-side driver and the client-side (DRI) driver share all that state, you may as well go just a small bit further and get the client-side driver loaded server-side. :) If nothhing else, that would make maintainence easier. Ummm... ok... so by this you mean, linking the radeon_dri.o into radeon_drv.o so that I can call functions from the 3D driver in the 2D driver and hence share state? Sorry if I mis-understand... Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Questions about r200 driver
Hi, I have a few questions about the r200 driver : - Will there ever be 32bit support ? - Will there ever be S3TC/DXTC support ? Well infact the big question is : will it ever be as performant as the ati driver (i mean will it produce as good looking graphics as the ati driver) one day ? (UT2003 is quite awfull and i don't think doom3 would look good with the actual version of the r200 code... Nevertheless you have done a very good job already because the open source driver is way more stable than the ati one... bye --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
