Borgvall: arbvptorus from mesa-tests seems to show nothing on r500
Borgvall: a driver bug?
Borgvall: the other arbvp* seems to work correctly
bridgman: Borgvall; not sure, but there may be a problem in the arbvptorus program :
Borgvall: yes maybe
bridgman: Looks like there was a change in arbvptorus but not sure if it ever got pushed back
bridgman: see also https://bugs.freedesktop.org/show_bug.cgi?id=5366
Borgvall: hmm changing the line mentioned (it seems to be line 132 now) in the bugreport seems to change nothing with dri
Borgvall: both variant sare working with sowtware mesa though
logari81: does anyone knows this card 1002:4336? I suppose it is a r100 but I didn't find it here http://wiki.x.org/wiki/Radeon%20ASICs
bridgman: guess there might be a driver bug in there as well. There's still some experimentation going on re: figuring out the best way to push vertex parms from mesa into the GPU
bridgman: logari81; I think it's an integrated graphics chip with an RV100-like GPU but running off system memory
adamk: logari81, I'm pretty sure that was the GPU on my old HP laptop.
bridgman: this puppy : http://ati.amd.com/products/radeonigp/rigp320m.html
bridgman: Note that the web page was written a long time ago and the part is probably no longer giving "industry leading performance" ;)
logari81: aha, does it support 3D, composite etc. ?
adamk: logari81, Yes.
adamk: logari81, If it is the same GPU as what I had... lspci identified it as a Mobility U1, so I'm pretty sure it's the same.
bridgman: AFAIK U1 was the internal code name for an IGP320M, so seems like the same chip
adamk: If I set it to use 64 megs of the system RAM, compiz worked pretty well.
logari81: adamk: this is the GARTsize parameter?
adamk: Even at 24 bit depth... It worked even better at 16 bit depth.
adamk: logari81, No, a bios option.
logari81: ah ok
bridgman: logari81; IGP chips don't normally have separate video memory, so you allocate a chunk of system memory for the video chip to use. You still need a separate memory area (GART) used for communication between the driver and the GPU
bridgman: adamk is talking about changing the amount of system ram given to the video chip for its own use (frame buffer etc..)
Fuss187: what do I do in xorg.conf to enable direct rendering for my Radeon 9800?
adamk: Fuss187, Not much. Just make sure that you are using the 'ati' or 'radeon' driver and direct rendering should be enabled.
adamk: If it's not, then there is something wrong with your drivers or installation.
Fuss187: adamk I am using the "radeon" driver, but glxinfo says NO
Fuss187: adamk how can I troubleshoot it?
adamk: Fuss187, Go to http://pastebin.ca/ and paste in your /var/log/Xorg.0.log file... As well as the complete output from 'LIBGL_DEBUG=verbose glxinfo'
Fuss187: the verbose thing doesn't add much information o.o
Fuss187: in fact it gives exactly the same output
adamk: Pastebin it anyway.
Fuss187: yeah yeah
Fuss187: working on it
adamk: And do not redirect the output to a file or pipe it through less or more.
adamk: Fuss187, "client glx vendor string: NVIDIA Corporation"
Fuss187: does that paste work for you?
adamk: Fuss187, You have the nvidia drivers installed.
adamk: Specifically, at least, the nvidia glx module.
Fuss187: adamk remove them and it should work?
Fuss187: yum remove akmod-nvidia xorg-x11-drv-nvidia <-- restarting X
Fuss187: direct rendering: Yes.
Fuss187: adamk thanks
ossman: why is RS690 listed as "R300 3D" and why is bicubic Xv filtering conditioned on "R500 3D"?
adamk: ossman, Xv overlay is not supported on r500 GPUs. Xv is supported via textured video, which requires direct rendering in the X server.
adamk: As for the RS690....
ossman: bicubic filtering is part of the textured video code path :)
adamk: I'm guessing that it's actually using some r300 GPU.
ossman: fiddling with it and I'd like to test the bicubic code path so I don't break anything
ossman: what does that mean in terms of missing functionality though?
ossman: it seems to have both pixel and vertex shaders
ossman: (it also seems to work if I remove the check)
adamk: I didn't think any of the Xpress GPUs have vertex shaders...
adamk: But that's just my non-developers recollection of things :-)
ossman: adamk, to be honest, "work" here means "doesn't crash"
ossman: what kind of pattern would be useful to see the difference?
ossman: a simple checkered pattern seems to expose the problems, and it does indeed look like simple linear interpolation
bridgman: ossman; the RS690 (and RS600) have a 3D core derived from the R4xx family; it's just the display and video blocks which are from the R5xx/6xx families
bridgman: actually I guess everything except the 3D core is from 5xx/6xx families...
bridgman: rs600/690 have no vertex shaders, btw (ie no TCL)
ossman: I see
bridgman: the RS780 is our first IGP with vertex shaders
ossman: but the rs690 has pixel shaders?
bridgman: yes, pixel shaders are just like the 4xx family but maybe fewer pipes (4)
bridgman: ie works on 4 pixels at a time
bridgman: R420, 423 work on 16 pixels at a time IIRC
ossman: isn't the bicubic filtering be a pixel shader thing?
bridgman: I think so... AFAIK the original concern was that running bicubic on older chips would be too slow, so it was restricted to 5xx and above. The fact that MostAwesomeDude only had a 5xx at the time (so could only test on that) might have been a factor as well, not sure ;)
ossman: heh, ok
ossman: but as it did not work when I forced it on, something must be missing
ossman: unfortunately that code is far from easy to understand for someone who isn't familiar with the 3d arch :/
bridgman: the code is not easy to understand for someone who *is* familiar with the 3d arch, ask any dev ;)
bridgman: best guess is that the problem is related to the SW TCL code paths not passing something through properly, but that is only a guess
bridgman: if you wanted to take the easy route, get it running on an R4xx first and then try to move to an RS690; that would tell you for sure whether the vertex or pixel paths were the problem
bridgman: the sw tcl paths are relatively recent, Dave and others only got them working for Compiz this year
ossman: bridgman, unfortunately the only hardware I have is a RS690 and a HD 3600
ossman: is MostAwesomeDude the only one who has been hacking on the bicubic code?
bridgman: there were some other folks involved; Corbin is the only one I remember for sure though...
bridgman: let's try something...
bridgman: turns on the MostAwesomeDude signal
bridgman: it works for me, don't know why it shouldn't work for him ;)
ossman: bridgman, hmm.. thinking more about it... are there any software TCL paths involved here?
ossman: the code is just putting a triangle on screen. there is no transformation or lighting
bridgman: yes and no... there probably isn't any actual TCL-ing going on, but something has to turn the vertex information into something that the pixel shader can use, and on a 690 that has to be done by SW TCL rather than by VAP
bridgman: checks the bulb in the MostAwesomeDude signal
ossman: bridgman, ah
ossman: I assume that the docs don't have a step-by-step instruction for doing this on R300? :)
bridgman: step by step, no... but there are hints scattered throughout the documentation if you can find them and put them all together ;)
bridgman: I don't think this is an r300 vs r500 thing as much as sw tcl vs hw tcl -- that's what I was talking about re: hints.
ossman: any pointers to what kind of information that needs to be fed into the card?
bridgman: just looking it up now... although best bet is to hund down airled and mostawesomedude (airlied for swtcl and mostawesomedude for the rest)
spstarr: hullo bridgman
bridgman: if we can get someone to test this on a 5xx with the hw tcl turned off (there's an option for that) that would give you a real good clue where the problem was
bridgman: not at work, I hope
bridgman: ossman; I guess a good first step would be to look at the bicubic code and see if it passes any unusual vertex parameters along... if so there's a good chance that sw tcl is not passing them through
ossman: bridgman, any obvious clues as to what constitutes a vertex parameter?
bridgman: the normal ones are colour, textore coordinates etc...
bridgman: guess I should check whether you're talking about the bicubic Compiz effect or bicubic in textured video; I think they are different implementations
ossman: this might be a naïve question, but why isn't it grabbing this from the vertex data?
ossman: oh, bicubic textured video. I have a very strict focus of having a well working video implementation :)
bridgman: I'm only guessing that is the problem, but quick answer is that with HW tcl there has been a lot more testing and AFAIK it's relatively straightforward to set up VAP to pick up all the parameters... with sw tcl you have to write code to do all the processing which VAP and the vertex shaders normally do, so there's a better chance something is missing
bridgman: ok, hold on, let me dig up the source code
ossman: there is an interesting part of the code, where it checks "has_tcl" and "bicubic_enabled"
ossman: so there seems to have been some ambition of getting it working under those circumstances :)
bridgman: or maybe there was just an intention to make sure it *didn't* work on a 690 ;)
bridgman: what decision does it make after looking at has_tcl ?
ossman: it's just some code determining how many ops it is going to put in the ring
bridgman: interesting... cause AFAIK there are no chips which have a 5xx 3d engine but no tcl
bridgman: checks to make sure the MostAwesomeDude signal is plugged in...
ossman: it is saturday, perhaps he's not up yet?
ossman: what tz is he in?
ossman: ah... here we go... the code that activates the bicubic pixel shader is condition on !IS_R300_3D
ossman: so it wasn't even running during my test
ossman: is the actual pixel shader compatible between r300 and r500?
ossman: or is that arch different enough that it might need tweaking
spstarr: hullo MAD
bridgman: definitely would need tweaking, IIRC the instruction format is "similar but completely different"
bridgman: ie you need totally different shader code but if you understand one chip it's not hard to write code for the other chip
bridgman: unlike the 6xx/7xx where everything is totally, completely, massively different ;(
spstarr: so will the 8xx :)
bridgman: MAD is west coast US, so it's still early there
bridgman: once we make the transition to 6xx-style programming model we can change the underlying hardware a lot and the virtualization hides many changes from the driver... so I expect that the programming diff from 7xx to 8xx will be more less than 4xx to 5xx even though the hardware change is much bigger
bridgman: s/more less than/about the same as/
bridgman: you'd think English was my fifth language or something
spstarr: I guess sooner or later the programming model will each a pinnacle of design?
ossman: bridgman, the fact that that more or less every define starts with R500_ gets me thinking that maybe I should reconsider this project...
bridgman: spstarr; yes, every new architecture is the pinnacle until we have to live with it for a couple of years ;)
bridgman: when we talk about "PM4 packets" that's the fourth generation programming model - there was a PM1, PM2 and PM3 before that
bridgman: and I think we have had at least 4 generations of 3d architecture built over PM4
bridgman: ossman; don't give up yet, but I would strongly suggest talking to MAD and airled first
oga: agd5f been around?
gmaxwell: Greetings. I have freshly installed Fedora 10 on a system with dual X850XT (PCIE). My video worked in Fedora 9, but F10's kernel mode setting just produces panics and hardlocks. With mode setting disabled it does not attempt user mode setting. If anyone here would like to help me trouble shoot this, I'd be greatly appreciative and I'm willing to try patches etc. Also, if someone can tell me how to make it use the old userspace mode setting,
gmaxwell: I'd greatly appreciate that. The particular computer has been useless to me for several days now...
bridgman: gmaxwell; would it be possible to test with one of the cards removed ? I doubt KMS has had much testing with dual cards plugged in...
adamk: gmaxwell, Disabling kernel modesetting should not make your computer useless :-)
gmaxwell: bridgman: Yes, I can try that. It's a minor pain, so I was waiting for someone to suggest it.
gmaxwell: adamk: I agree, but alas. Radeon driver just complains that there is no fb0 and refuses to start without modesetting... on a system who's whole purpose is to run an xserver this is not too useful.
adamk: Have you created an xorg.conf file?
gmaxwell: I did, just a stubby one that specifies the radeon driver. I had not tried creating a full one.
gmaxwell: adamk, I am not clear one what triggers the use of kernel mode setting, nor did I find it via google...
ninjaslim: anything on r600 drivers?
adamk: gmaxwell, There's really nothing in your xorg.conf file that triggers kernel mode setting. That's handled by the drm, assuming you don't specify nomodeset on the kernel boot line.
adamk: gmaxwell, However, disabling kernel modesetting should not prevent the use of Xorg. I disable it here, but am able to use Xorg, so I'm not sure what's going on with your system.
gmaxwell: Well without an xorg.conf I get:
gmaxwell: (EE) Unable to locate/open config file
gmaxwell: Primary device is not PCI
gmaxwell: New driver is "vesa"
gmaxwell: (==) Using default built-in configuration (30 lines)
gmaxwell: (EE) open /dev/fb0: No such file or directory
gmaxwell: (EE) No devices detected.
gmaxwell: (==) Using config file: "/etc/X11/xorg.conf"
gmaxwell: (EE) No devices detected.
gmaxwell: with the conf:
gmaxwell: Section "Device"
gmaxwell: Identifier "Videocard0"
gmaxwell: Driver "radeon"
gmaxwell: So get this: I needed to specify a BusID
Sylvia7: Someone can help me setuping a hd 3650 dual display ? I'm completly mixed up with all xorg.conf sample found on the web
ossman: is there any better guide to learning R300 fragment shaders than digging through the mesa code?
airlied: oga: ?
airlied: gmaxwell: I've got a fix for modesetting with two cards, in that it doesn't oops.
airlied: however you need to configure an xorg.conf with two device sections and specify busids
airlied: no matter what way modesetting works.
airlied: ossman: getting the bicubic on the rs690 shouldn't be that hard in theory :)
airlied: in fact i thoguht the code already dealt with it.
airlied: ah the R300 codepath doesn't
airlied: so you would need to port the shader to r300 alright.
airlied: I thought someone started on that before
airlied: so MostAwesomeDude is probably the best person to annoy
ossman: airlied, if you have anything helpful in learning the stuff, please point me to it :)
rx__: MostAwesomeDude's bicubic branch if he still has it
ossman: is his tree on fdo?
airlied: yeah that has code for the r300
airlied: , it must not be fully working
airlied: as it never got merged into master.
ossman: I'll see if I can fiddle with it, now that I have something to base it on
ossman: getting this up an running from scratch was a bit daunting. at least without any docs on how the fragment shader of the chip works :)
ossman: airlied, since you're here, I have another question for you :)
ossman: the scissor coordinates needs some strange offset
ossman: why is that? and is it constant on all cards?
ossman: (bug 18542 btw)
gmaxwell: airlied, Fantastic. Where is the fix? I'd be glad to try it out.
gmaxwell: (I'm also just happy in general now that I have something *working*)
airlied: gmaxwell: I need to push it into an updatest-testing kernel
gmaxwell: airlied, Okay. Well I'll be around and will gladly test anything you'd like me to test.
airlied: ossman: its an r300 thing, and all r300/400s need it,
ossman: airlied, and for r500?
airlied: ossman: it has full scissors.
ossman: meaning? :)
airlied: ossman: I think the r5xx docs explain it.
ossman: takes a look
airlied: ossman: it can scissor up to 4kx4k
ossman: and no offsets?
airlied: the r300 can only do 2560 or somewhere around that
airlied: ossman: nope full range.
ossman: so the code would need to be changed to check for IS_R500_3D?
airlied: oh its clip regs not scissor
airlied: the r200 has cliprects
airlied: just different regs
ossman: ok, so that should solve the r200 case
ossman: but what about r500?
airlied: the r500 doesn't need the offsets
airlied: otherwise it shoudl be the same
airlied: wierd I don't remember the scissor needing that offset, maybe the docs have smoe more info in them.
ossman: no, nothing
ossman: at least not in the section about the relevant regs
ossman: and I have only the single card to test with, so I have not verified it properly
airlied: the 1088 is definitely the r300 offset value
ossman: any pretty define for it?
airlied: its mentioned really obliquely... search for 1088 in the r5xx docs
ossman: the r5xx docs?!
airlied: not that I know off.
airlied: the r5xx docs have info for all the cards
airlied: the r300 docs just have regs
airlied: radeon_commonfuncs.c also uses 1088
ossman: oh... I didn't know that, so I didn't really think of digging through anything other than the r3xx docs
gmaxwell: airlied, FWIW, without kernel mode setting if I create a server layout that uses both video cards I get a black screen and hard lockup. (I'll try using totally seperate xservers next)
airlied: gmaxwell: I think the second card posting code isn't working.
airlied: I'll just do a build wit that patch
ossman: airlied, I just tested the cubic on r300 stuff, and a white texture results in blue output
ossman: so yeah, I understand why this was not merged :)
bridgman: kicks the MostAwesomeDude signal a couple of times and leaves...
airlied: gmaxwell: http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-ati/6.9.0/60.fc10/
airlied: you might want to ty that with nomodeset
airlied: see if it posts the cards
airlied: I'll try and get the modeset code fixed better this week, I plugged two cards in this week to play.
gmaxwell: airlied, I tried xorg-x11-drv-ati-6.9.0-60.fc10.x86_64.rpm with nomodeset, doesn't work with both cards (just goes black)
gmaxwell: (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI.
gmaxwell: giving up.
gmaxwell: xinit: Connection refused (errno 111): unable to connect to X server
airlied: can you post the logfile?
gmaxwell: I just tried again and this time it's black with video card bios message "R480 DVI DVI VIVO â€¦"
airlied: so it might have posted it at least
gmaxwell: This is the first run: http://pastebin.ca/1270598
spstarr: airlied: do you expect the EXA code in the DDX to be modified significantly now that the MM is more or less settled on?
gmaxwell: airlied, This is the second run: http://pastebin.ca/1270600
airlied: gmaxwell: not sure it should exit where it did in the first run
airlied: you won't get DRI with xinerama but no idea why it exited.
airlied: spstarr: the EXA code in the DDX hasn't changed much moving to the mm.
spstarr: airlied: but will it with the various issues you raised in your blog?
airlied: but I suspect there might be some changes in EXA when I get time.
spstarr: you mean the sever side EXA code?
airlied: it might not need much changes in the driver
airlied: spstarr: yes
gmaxwell: Oh X is also pegging the CPU now.
gmaxwell: (gdb) bt
gmaxwell: #0 0x0000000002d1394f in add_byte () from /usr/lib64/xorg/modules//libint10.so
gmaxwell: #1 0x0000000002d13b59 in ?? () from /usr/lib64/xorg/modules//libint10.so
gmaxwell: #2 0x0000000002d1d6d3 in X86EMU_exec ()
gmaxwell: from /usr/lib64/xorg/modules//libint10.so
gmaxwell: #3 0x0000000002d0b555 in xf86ExecX86int10 ()
gmaxwell: from /usr/lib64/xorg/modules//libint10.so
airlied: not sure why its using int10 to post
airlied: try option "int10" "false"
gmaxwell: Okay. Did that screens still black, now it's like the first time:
gmaxwell: (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI.
gmaxwell: giving up.
gmaxwell: Option "DRI" "false" ?
airlied: yeah it might help, but it shouldn't exit like that
airlied: thats just a warning
gmaxwell: FWIW, it's not restoring the screen when it fails.. screen is stuck black now (I'm logged in remotely)
airlied: X is dying completely by the sounds of it
gmaxwell: woo.. with DRI false it doesn't die now
gmaxwell: but it's coming up with video only on the second card, and the output is something like a cross between Mondrian and Warhol.
airlied: post a log from that, I wonder what we screwed up that stuff should work the same no matter what.
gmaxwell: http://pastebin.ca/1270612 < there you go.
airlied: try Option "AccelMethod" "XAA"
airlied: for both devices
gmaxwell: Closer! So both cards are up now. (I guess I need to use xrandr to get screen 0 out of clone mode) .. but the second card has a screwed up background and windows are leaving 'droppings'
airlied: ponders some more, I'll need to set it up locally during the week.
gmaxwell: So ... after some more testing I found that Screen 1 suffers all kinds of interesting corruption for windows moved past a some point in the virtual space.
gmaxwell: I also see that xrandr extension is disabled (I presume due to xinerama), so I'm not quite sure how I can get the second display port working on each of the cards, but I guess that is a different issue.
gmaxwell: airlied, Well now that I have one card working I can keep this machine on fedora 10 and continue to twiddle around. The third and fourth displays are nice to have not needs to have, I can move them to another system and control them via X2X for the time being.
airlied: gmaxwell: hopefully I cna resolve it this week.
gmaxwell: airlied, I'd be glad to give you access to this system, though without an ability to see the screens it might be hard to tell if it's working or not. :)
DanaG: Hmm, no accel for R600 yet.. even if I force "dri" on? No wonder my /dev/dri dir is empty. Bummer.
DanaG: Well, at least I have software 2D. Note to self and others: manual fglrx installer moves around the opengl libraries. Bad.
DanaG: And radeonhd still seems to depend on radeon kernel driver.
rx__: not obvious?
spstarr: airlied: theres badness
spstarr: airlied: suspend /resume, X is using 99% CPU
ssieb: airlied: did you see my comments about the results of my testing the resume problem?
spstarr: ssieb: same thing?
ssieb: not really any CPU usage though
ssieb: it's just stuck trying to read from the dri device
spstarr: in an ioctl?
airlied: ssieb: oh I think I missed that
airlied: I fixed some resume issues in later -ati driver
airlied: spstarr: what chip is that on? I'm having no luck reproducing sus/resume issues
spstarr: rv350 agp mode, no kms
ssieb: I had problem all the way back to the first 6.8.0-3. I couldn't go back to 6.7.x because it needs an older X server
ssieb: would an F10 ati driver work with F9 X server?
airlied: well maybe.
spstarr: airlied: im using latest DDX -57... pulled
airlied: shopping &
cockroach: hey, i keep getting corrupted mouse pointers on dual-head setups (X1950) - i think this is a known issue, right? any known fixes?
adamk: cockroach, It is known. To my knowledge, the only workaround is to use software cursor instead of hardware cursor.
adamk: cockroach, Of course, this has some downsides to it.
cockroach: adamk: such as?
adamk: flickering in Xv windows... It doesn't always interact nicely with 3D apps, from what I've been tolde.
cockroach: i see. well, i guess i'll just live with the weird mouse cursor for the time being, then. thanks!
mo3sizlak: guys i have BIG problems w/ fedora 10
mo3sizlak: radeon 9600 mobility, r300 driver
spstarr: we know :)
mo3sizlak: any ideas?
soreau: we do?
mo3sizlak: lol, k whats the verdict
spstarr: soreau: we do with AGP
mo3sizlak: yup i habve agp
soreau: Yes, but I've been seeing many fc10 folks using the radeon driver having problems lately
spstarr: dont use KMS with composite effects on rv350 if its an agp
soreau: Ah yes, now I recall
spstarr: Kernel mode setting
spstarr: the default thats enabled
soreau: mo3sizlak: Try turning of kernal mode setting stuff
mo3sizlak: i have my own kernel
spstarr: you can turn it off with 'nomodeset' in your grub config
mo3sizlak: er, 220.127.116.11 actually
soreau: Yes, that you should do
mo3sizlak: i tried w/o nomodeset
spstarr: until airlied has some time to bash the AGP gunk
mo3sizlak: same probs
spstarr: what problems
mo3sizlak: compiz will load...but be very unstable
mo3sizlak: opening anything may result in a hard lock
mo3sizlak: running fusion-icon or compiz-manager == hard lock
spstarr: your mileage may vary with compiz
mo3sizlak: but i have my own custom kernel...and i tried nomodeset
mo3sizlak: whats goin on here
spstarr: custom kernel.. in what way
mo3sizlak: i compiled my own...
spstarr: kernel.org or compiled kernel from Fedora RPM?
mo3sizlak: using same setting that were rock solid for me in f9
spstarr: well.. you're mixing an older DRM driver
mo3sizlak: so fedora uses a patched kernel?
spstarr: the radeon driver in kernel is VERY FLUID right now...
mo3sizlak: by fluid, you mean?
spstarr: it works, but theres changes going on
mo3sizlak: what did fedora patch exactly?
spstarr: the main plumbing is coming into shape in the driver, airlied would be able to tell you whats missing
spstarr: mo3sizlak: see cvs.fedoraproject.org look for kernel in view cvs
mo3sizlak: prlly same airlied wo maintains the xorg-x11-drv-ati package i assume?
spstarr: see the drm patch files and radeon-modesetting.patch
mo3sizlak: well, when i use the fedora kernel, i boot to a black screen
mo3sizlak: cant switch terminals, or ctrl-alt-bksp
mo3sizlak: only thing that works is power button (shuts down)
spstarr: hmm, just know the rv350 agp card (I have this too) is buggy right now, i remain right now in nomodeset with EXA only no composite effect (compiz/kwin)
spstarr: and NO vt switching as that wedges
spstarr: but with composite off vt switching works
mo3sizlak: so the impression im getting is that im an idiot for upgrading to f10 so quickly, and i just have to wait for stuff to settle?
spstarr: no, you can use it but composite is not stableish
spstarr: i wont use it.. it will lock up
spstarr: if you had a non-AGP card you'd be fine
mo3sizlak: could that be related to this;
mattst88|laptop: PCI and PCIe work but AGP doesn't work, spstarr?
spstarr: AGP has issues, airlied and others haven't had much time to look at why yet
mo3sizlak: k, thx for your help...ill wait for sunnier days
spstarr: but there are issues scattered though different things will cause either corrupt video, wedged video card, or X crashing
airlied: nomodeset should be fine for AGP cards.
mo3sizlak: not for me :(
mo3sizlak: i still boot to a black screen
airlied: that's wierd then, did you ever have to use an agpmode beofre?
spstarr: airlied: i donno when you plan to kick off the AGP 'fun' stuff yet
mo3sizlak: in f9 everthing was rock solid
airlied: Option "AccelMethod" "XAA" might help then.
mo3sizlak: tried that
airlied: spstarr: when my rv350 agp card arrvies
spstarr: airlied: oh you ordered one? great!
airlied: spstarr: AMD are sending me one.
mo3sizlak: woot, im sporting a rv350 i think....9600 mobility
spstarr: couldn't be better then
spstarr: mo3sizlak: is yours a 64MB ?
spstarr: IBM Thinkpad T42p?
mo3sizlak: no p
spstarr: they made a 128MB for the non p?
spstarr: didnt see that option
spstarr: <- T42
mo3sizlak: yup, the very rare 17" screen on a T42
spstarr: ahh 17" mines the 15"
mo3sizlak: it was impossible to find this when i bought it
airlied: I think 32MB cards are causing issues as well.
spstarr: mo3sizlak: rare, i didnt know they made it with 17"
airlied: I didn't think they made 32MB r300s but life sucks.
spstarr: airlied: i will have time to test your fixes as done in F10
airlied: knowing my luck it'll work fine out of the box :)
airlied: I've two AGP motherboards to play with
airlied: so hopefully one of them sucks, I wonder if doing what I did for IGPs would ehlp on AGP
spstarr: unless the mobility rv350 is so much different then the non-mobility
spstarr: this would mean when i try the r300 i have your changes should also fix that
mo3sizlak: well, you guys seem to know your stuff...im sure ill be back later
spstarr: mo3sizlak: airlied does, not me :)
mo3sizlak: btw, any chance the xorg-x11-drv-ati-
spstarr: im just a KDE developer
spstarr: -59 eh..
airlied: mo3sizlak: I haven't fixed anything good yet.
airlied: for AGP
mo3sizlak: its in updates-testing now...i couldnt find a copy of it yet
mo3sizlak: k, thx
spstarr: is on -57
airlied: if fixes the IGPs...
airlied: I wonder if a similiar hack to EXA would help AGP.
spstarr: if you got patch i'll try it now
spstarr: non-kms agp mode is ok with EXA
spstarr: i have not seen it lockup yet in 1 week now
airlied: spstarr: can you rebuild -ati with http://people.freedesktop.org/~airlied/agp-hack.patch
airlied: in the spec?
spstarr: getting -59 SRPM
spstarr: airlied: force radeon.agpmode on bootup?
spstarr: since this is for kms
airlied: or leave it alone I just want to see if it helps stability at all in kms case.
spstarr: ok, upgraded kernel
spstarr: Im in kms + no agp
spstarr: seems faster redrawing xchat
spstarr: there is lag dragging a little
spstarr: ok there is serious lag
spstarr: dragging a window in front is sluggish redrawing the damaged area
spstarr: but, no corruption
spstarr: the icons in kde menu don't look corrupt or inverted
airlied: so they were getting corruption before
spstarr: airlied: want me to try AGP on? i tried with -117 and i saw corruption with that
spstarr: yes there was some corruption before
spstarr: i had some inverted icons i think i have a video from that
spstarr: found video
spstarr: i do not see ANY corruption now
airlied: try agp on for lolz.
spstarr: ro root=/dev/VolGroup00/LogVol00 slub_debug=- printk.time=1 quiet rhgb radeon.modeset=4
spstarr: [ 1.857341] [drm] Forcing AGP to PCI mode
airlied: radeon.agpmode=4 :)
airlied: not radeon.modeset
spstarr: airlied: agpmode=4 X locks but can reboot with sysmagic
spstarr: so your changes for non-AGP fix corruption
spstarr: airlied: interestingly, there seems to be an interaction with e1000 and radeon, but not ipw2200 and radeon..
spstarr: for irq issues are not happening
scsiraider: airlied, ping