damentz: good night
spstarr: airlied: awsome!
spstarr: now you can revel in the pain we send you ;-)
spstarr: less kittens will suffer
ossman: airlied, do you know if anyone has been looking at doing an update to the Xv protocol? or is the consensus that video should move to other mechanisms?
agd5f: ossman: there was talk at XDC about adding YUV src-only support to render
ossman: k
ossman: I'm unfamiliar with the details of render though, so I'm not sure it hasn't made the same mistakes :)
ossman: does it have some feedback for when an operation has finished?
agd5f: ossman: It's implemented via EXA
agd5f: http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt
ossman: seems to be fire-and-forget ops as far as I can tell
airlied: ossman: other than VAAPI type things.
airlied: I think direct rendered video makes more sense.
airlied: so XvMC or VAAPI.
airlied: agd5f: see the fix for peterz :)
agd5f: airlied: oh man :)
ossman: airlied, I'm afraid I haven't yet had time to fully read up on VAAPI. does it handle rendering as well, or just accelerated decoding? I would assume the former for performance, but assumptions is the mother of... and all that :)
airlied: I'm not 100% sure, also the stuff the Gallium/nouveau guys did on videdo
ossman: airlied, on an unrelated note, I don't suppose you've had any time to look at rh bug 461474? (nouveau kernel crash on nvs 140)
airlied: ossman: nope, might be worth asking upstream, we are pretty close, it might be some missing kernel bits though.
ossman: airlied, k
adamk_: Would a git-bisect of this help locate the problem? https://bugs.freedesktop.org/show_bug.cgi?id=17929
silver_hook: Hullo. I get a "out of GART" problem when I try to play e.g. PlaneShift on my PCI-e r300 card.
adamk_: silver_hook, Use the GARTSize option and set it to something like 32.
silver_hook: I've already RTFM'ed and searched the bugzilla, but all I could find were either bugs solved two years ago or solution that involve AGP.
silver_hook: But as far as I understand AGP settings have nothing to do on a PCI-E card ...or am I wrong here?
adamk_: Again, use the GARTSize option.
adamk_: GARTSize is not an AGP specific option.
silver_hook: adamk_: Thanks, will try :]
silver_hook: Btw, mind telling me if there's something else that I might change or add? http://paste.uni.cc/19518
adamk_: If you still get it at 32, try 64. I'm not sure if there is a max value.
silver_hook: I was just confused as GARTSize is not an option mentioned in either 'man radeon' or 'man xorg.conf' (anymore?)...
adamk_: Yeah, I'm not sure if all distributions include an updated man page.
adamk_: And, for all I know, that option might not be valid any more. It certainly was at one point, though.
silver_hook: Gentoo. And the man footer matches the versions ...hmm, I can file a Gentoo bug, if you say that's an error with the distribution.
adamk_: Well I don't know that for a fact. I'd have to see what the man page from the official Xorg source says, but I don't have that in front of me.
silver_hook: I'm on xorg-server 1.5.3, xf86-video-ati 6.9.0, mesa 7.2 ...if that helps.
silver_hook: I just checked the GIT and at least on 'xf86-video-ati' in the manpage GARTSize is not mentioned.
silver_hook: Would anyone know this for sure?
adamk_: Why not just try the option?
silver_hook: I will.
adamk_: If it's a valid option, but not documented, open up a bug report.
silver_hook: Should I also have 'AGPFastWrite' enabled or rather not?
adamk_: You're on a PCIe card, right? Why do you think that would do anything? :-)
silver_hook: Dunno. That's why I was wondering about all the other AGP-related PCI-e solutions O_o
silver_hook: OK, I'll try just 'GARTSize' and I'll report back in a minute.
silver_hook: Cheers
silver_hook: adamk_: Hullo. Now it works. Thanks.
adamk_: You're welcome.
silver_hook: Although I have a sneaking feeling that on PCI-e setting 'GARTSize' is not The Right Way to Do It(TM) anymore ...but as long as I don't get a better solution, it gets the job done :P
fpoibaf: silver_hook: the GARTSize option was 'fixed' this summer
silver_hook: fpoibaf: What do you mean?
fpoibaf: silver_hook: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=5b5441f8cc119db0d1e03dd35bd06015a26270dd
fpoibaf: if you are using a recent enough version of the radeon driver you should not need that
fpoibaf: else use a value of 32
fpoibaf: a higher value will cause problems on some applications
silver_hook: fpoibaf: I'm on 6.9.0 — is that recente enough?
silver_hook: s/recente/recent
fpoibaf: no, it was committed a month later 6.9.0 was released
fpoibaf: you should use a recent git version
silver_hook: fpoibaf: Crap. When's the new version going to be released?
fpoibaf: just use a value of 32 in the meantime - that value will be the default on the newer version
silver_hook: fpoibaf: Are there any other important r300 changes already present since 6.9.0?
fpoibaf: silver_hook: to my mind comes tear free Xv with bicubic filtering
fpoibaf: and many fixes
silver_hook: Cool, but I can live without that for a while :]
silver_hook: BTW, is there a RoadMap published anywhere? E.g. I'd like to know a) what's the next version's number and b) when is it planened.
Magamo: Hello, everyone. I'm having a series of odd issues with the radeon drivers, v6.9.0, which cropped up when I upgraded to Xorg 7.3.0 and xorg-video-ati 6.8.0 originally. I've got a Radeon 9250 PCI.
Magamo: A few issues are happening. On my configuration, since the upgrade to 6.8.0 and 6.9.0, 16 bit display depth is really quite messed up. Window placement wrong, only greyscale colors, and ... I can't say whether or not I've tried any 3d applications.
Magamo: On 24 bpp, if a 3d application crashes that has changed resolution, (such as a WINE app, or Terminus, or even most of the Loki releases of games) my display ends up quite garbled. It messes with the font size in GTK+2 apps, and applications can no longer change resolution (though xrandr -sX still works)
glisse: Magamo: would be good if you could test lastest Xserver with lastest ati driver
glisse: 7.3 is bit old
Magamo: I understand that. I'm not really certain that there's any good and easy upgrade paths for Slackware 12.1 as of yet... I'm not adverse to building it from source, but if I screw something up, that'd certainly be a cause of headaches. Let me go check around on linuxpackages.
mjg59: glisse: Ha. So I haven't been able to test atom reclocking on mobile r500 yet because the test machine I have to hand is an MBP booting through EFI, and Apple don't provide any atom tables in that case
glisse: mjg59: yup got that one too
glisse: i was using my own values
glisse: based on things a windows program does
glisse: can't remember the name of this windows stuff
mjg59: glisse: Anyway, just turning on the dynamic PM saves about a watt in that case
glisse: mjg59: i was able to save 5W iirc by dividing clock by 2
mjg59: glisse: Yeah, that sounds about right
glisse: memory & gpu
glisse: macosx seems to be able to only consume 11W in save everythings mode though
mjg59: glisse: I think I'm going to concentrate on the atom case, though
glisse: their might be information in efi stuff we are lacking but i think apple just hardcode everythings in the driver :(
mjg59: Yeah
mjg59: Well
mjg59: Anyone who buys Apple hardware to run Linux on deserves to lose :)
Magamo: I'll try just upgrading to the xorg packages contained in Slackware-current... It may bomb out, it may not. We'll find out soon.
glisse: yup apple hw is full of quirk hardcoded in osx
glisse: agd5f: regarding double buffering & pageflipping is
glisse: http://www.botchco.com/alex/xorg/exa_double_buffer.diff your lastest code ?
mjg59: glisse: And enabling the runtime PM stuff in RS630 knocked 8W off my test laptop
agd5f: glisse: yes
glisse: i think the best solution for this is to abstract front buffer from X, so that on anyop we subsistute dst/src differently
glisse: ie if op do compose to dst(front),src1(pixmap),src2(front)
glisse: we use the previous front buffer for src2(front) and the next front buffer for dst(front)
glisse: this way i think we shouldn't need to copy btw the 2 front buffer
glisse: one buffer will be 1 frame behind
glisse: is sratching his head
ossman: glisse, but how do you handle ops very close to the flip point?
ossman: you don't want to miss the vblank
glisse: ossman: flip are scheduled in cs
glisse: so everythings is on the same timeline
ossman: but if you're doing something that will take a long time for the card to execute, you'll miss the vblank period
glisse: what i am worried about is coherency ie that the current buffer have all the proper content
glisse: ossman: then buffer will be flipped next frame
ossman: hmm...
ossman: oh right, the hw did the flip by itself on vblank
glisse: it's in cs: dostuff, flip, dostuff, flip, .....
ossman: then nm :)
ossman: glisse, I have another issue with that approach though
ossman: or maybe not... let me think about it for abit
ossman: if you put A,flip,B,flip, etc.... then let's say that the next vblank is so far off in the future that it can be ignored, won't the card execute both A and B before it does the next flip?
glisse: ossman: yes this could happen
ossman: will any more "flips" overwrite earlier ones if the hw hasn't had time to actually update the frontbuffer regs yet?
glisse: ossman: i think so
glisse: to solve this i would be using a vblank fence
ossman: then I think we can't just go alternating between two buffers willy nilly
ossman: right
ossman: how does that work though? the hw sends an interrupt whenever it hits a fence?
glisse: thing is we have to maintain coherency btw 2 front buffer
ossman: indeed. but there are several concerns here :)
glisse: and it would be way better if we could avoid memcpy whole front buffer at each frame
ossman: was intending to play around a bit with this
glisse: ossman: my vblank fence will be done as follow: do your cs that you want to hit next frame, write scratch reg (with flush before), enable vblank,
glisse: vblank interrupt
glisse: on vblank interrupt you check that the scratch reg got the value your waiting for
glisse: if no you keep vblank interrupts enabled
glisse: and check at next interrupt
ossman: and refuse to put stuff into the cs until you're in sync?
glisse: no don't refuse anythings
glisse: it's up to X to sync with this fence
glisse: all this sounds way too complex
ossman: irc needs a sketch mode :)
glisse: might be easier to use damage area to copy current front to next front
ossman: the basic problem is that we cannot risk writing to a buffer that we've told the hw to flip to
ossman: so that's why I was thinking of having three buffers
Magamo: Well, upgrading to xorg 7.4.0 definite resolved one of my issues. I'm trying to test to see if it's helped any of the others.
ossman: glisse, and your idea of having the kernel keep track of things still holds there
ossman: and keeping things fairly transparent for X, except possibly for marking good places to flip
glisse: ossman: what we want to avoid is to do stuff on the current displayed front buffer
glisse: tripple buffer consume way too much memory
glisse: double buffer already consume quite a lot
ossman: but the buffer that is about to be flipped could get visible in the middle of an operation
glisse: no, cs(dostuff,flip)
glisse: flipreg will only be written after stuff are done
ossman: on modern hardware I wouldn't think that memory for a couple front buffers is a problem
ossman: glisse, but if you want to keep rendering?
ossman: you have buffer A that's on screen, buffer B that "dostuff" modified. if you wan't to keep on rendering, which target should it have?
glisse: ossman: think 2 screen at 2048*1024 each: 2048*1024*4*2=2^(11+10+2+1)=2^24
ossman: that's 16 MiB
ossman: not that scary
glisse: 16M for a single front buffer
glisse: that's scary
glisse: in tripple buffer you would need 48M
glisse: 32M in double buffer too
ossman: I thought cards with less than 256 MiB were extinct by now, and 512 MiB being the norm :)
chithead: some people even run vista on 512mb igp machines
ossman: glisse, do you have some alternatives to the problem I described?
glisse: ossman: this isn't a problem: cs(dostuff(front1),flip) cs(dostuff(front2),flip) ....
glisse: you never have to stop supplying cmd
glisse: just make sure you change front each time you submit a flip
ossman: but as you said earlier, it will render past the flip commands
ossman: as they do not stall the pipeline
glisse: well this is where you need fencing but all this sounds complex
glisse: and in the end the fencing might impact perf as much as exa synced op does
gentooer: i am having problems setting my refresh rate. once X is started I can set it using "xrandr -rate 75" but even with "1280x1024_75.00" or "1280x1024@75" it defaults to 60hz. is there some special option I have to pass to radeon in my xorg.conf?
ossman: glisse, what are the alternatives though?
glisse: ossman: we either have pageflipping or pipeline stalling
Nash_13: alguien me puede ayudar con un problema
Magamo: 16 bpp is still fairly hosed, even after upgrading my X server.
ossman: glisse, I don't see pipeline stalling as really a desirable long term solution
ossman: a lot of time is spent just waiting
Magamo: But, most of the rest of my issues (aside from poor WINE performance, and DOSbox performance when using OpenGL) are fairly well resolved.
spstarr_work: hmmm
ossman: airlied, how is the initial resolution configured with kms when you have two monitors?
adamk_: ossman, Both monitors adjust to what kms determines is their native resolution.
ossman: clone mode?
adamk_: Yes, clone. The console is limited to the smaller of the two resolutions.
ossman: ok, then it works as designed then
adamk_: Xorg will default to clone mode, but this can be configured via xorg.conf
ossman: can I override this using kernel params?
adamk_: I do not believe so.
adamk_: If you find a way, please let me know :-)
ossman: :)
ossman: right now I seem to have wedged something
ossman: doesn't plymouth and X play nice?
spstarr_work: is very curious to see airlied's reaction to the AGP madness
adamk_: In order to get both monitors to switch between Xorg and console flicker free, I had to start Xorg with each monitor plugged in separately, allowing KMS to use the native resolution, and then use xvidtune to grab the modeline to put into my xorg.conf file.
adamk_: Not an ideal situation, but it worked.
spstarr_work: "oh fuck!" would be priceless :)
ossman: adamk, you've managed to get X to respect xorg.conf when it comes to screen setup?
adamk_: ossman, Yes.
ossman: I tried it 6 months ago or so, and it was not functional at that point
ossman: it ignored half of the stuff
adamk_: ossman, http://pastebin.ca/1280949
adamk_: My xorg.conf file under F10.
adamk_: Without it, I just get clone mode under Xorg.
ossman: thanks
ossman: I'll give it a shot
ossman: yay!
ossman: I wonder how you specify a specific refresh rate for one of the automatic modes though
ossman: anyone?
ossman: "TargetRefresh" didn't do anything at least...
ossman: ehm... suddenly I lost Xv when I compiled git for f10
ossman: I didn't think Xv was conditional?
ossman: hmm... seems to be a drm problem
ossman: (EE) RADEON(0): [drm] Could not create vertex/indirect buffers list
ossman: help :/
ossman: pokes airlied
ossman: what have you done to f10? :)
airlied: ossman: the f10 drm shouldn't stop you doing that I do't think.
airlied: it should be backwards compatible.
ossman: airlied, there is some big modesetting patch in the f10 ati package
ossman: is that needed perhaps?
ossman: I was hoping to continue fiddling with the driver together with the new kernel stuff, but instead I've prevented any kind of development :/
airlied: ossman: if you are running modesetting its required
airlied: if you boot nomodeset the normal driver should work.
airlied: if you boot modeset you can't just run normal drivers.
ossman: I am going full out with all the bells and whistles :)
ossman: I was under the naïve impression that the current radeon driver was prepared for both modes of operation
ossman: airlied, is there a tree where I can get a current version of the kms code?
airlied: the radeon-gem-cs branch of my tree.
airlied: not surehow clean the merge is at the moment though.
ossman: what could go wrong :)
ossman: gives it a try
ossman: it didn't exactly go cleanly
airlied: yeah I didn't expect it would.
airlied: I might merge some parts of it to master under a magic config option.
spstarr_work: airlied: the cards are the right ones? :)
ossman: airlied, why not based on what the kernel reports?
airlied: spstarr_work: look like it, just need to plug em in.
airlied: ossman: because the APIs aren't stable yet.
ossman: ah
airlied: so I don't want people running shit then complaining when we break it.
airlied: explicit configure options until all the code is in the kernel.
ossman: ;)
spstarr_work: airlied: ok, I will do rapid testing on any code you have when you get time to install
ossman: but GEM is fixed now, right?
airlied: ossman: GEM on intel is fixed.
airlied: GEM isn a driver specifc API.
ossman: I see
ossman: some crude fixing, and I actually got it running with kms :)
ossman: but there is some odd screen corruption
ossman: does kms set up the display differently in some way?
airlied: corruption how?
airlied: it uses the kernel to set the display up.
airlied: so yes completely different.
ossman: but the display hardware should be set up in the same way?
ossman: I have small horisontal streaks here and there
ossman: but they disappear again very quickly
airlied: should be very similiar.
ossman: oh wait... I never got the correct frequency. might be the monitor doing something funky
ossman: how do I specify refresh rate in xorg.conf? :)
airlied: you need to define a prefered mode with a refresh rate in it I think.
agd5f: ossman: http://wiki.debian.org/XStrikeForce/HowToRandR12
ossman: airlied, what's the syntax though?
ossman: I tried x, @ and _
ossman: and with and without the fractional part
airlied: you need to define a mode by hand with the refresh.
ossman: agd5f, nothing about refresh rate with a reported mode there
adamk_: ossman, Take a look at the xorg.conf file I showed you earlier.
adamk_: ossman, It shows you exactly how to add a modeline and set it as the PreferredMode.
ossman: that's not what I want to do :)
ossman: I want to use the existing mode, but if I can't then I guess that will have to be the next best thing
adamk_: The only way to specify a refresh rate is to use a modeline.
adamk_: So, yes, that is what you want to do :-)
ossman: I hope this is on someone's todo list :)
agd5f: ossman: the modename is just a string, you can call it "bob" if you want
ossman: agd5f, right, but I find it more future proof to use the reported modes and not copy them
ossman: SPOT and all that
ossman: and xorg.conf should have the same abilities that the xrandr tool has
agd5f: ossman: ah, I see what you are saying
agd5f: ossman: I guess the thing is, you don't know what modes the edid will supply prior to starting X, so you have to explicitly specify
ossman: doesn't that hold true for resolution as well though?
agd5f: yeah
ossman: so I don't see why refresh rate is any different
agd5f: it's not
AirCanada: i swapped my old 9200se back in, and took the x1650 out. getting any kind of stable driver for ati seems to be a chore. the 9200se works rock-solid if a little slow. the x1650 is a good bit faster, and causes random badness and crashes. so what i guess i'd like to know, is when full(ish) rv535 support will be available ?
airlied: AirCanada: you using AGP cards?
AirCanada: airlied: yeah. i want another year or two out of this asus a8v mb
spstarr: airlied: when do you plan on popping in those AGP cards?
airlied: spstarr: the rv350 seems to work fine here :)
spstarr: you're..joking...
airlied: agp 4x, with DFS I get some small icon corruption
airlied: just doing some gtkperf tests on it now.
spstarr: AGP on for me shows corruption as before
spstarr: how much VRAM?
airlied: 128MB
spstarr: I have 64MB
spstarr: you dont see that kind of corruption i recorded last time?
spstarr: with small 'boxes' and other corruption?
airlied: nope nothing like that, this is in my SiS motherboard.
spstarr: different agp bridge
airlied: so you did kms + agpmode = 4, did you have DFS on or off?
airlied: (defaults to off)
spstarr: its respected in Xorg conf?
airlied: yes.
spstarr: I thought you moved that to the drm driver
spstarr: hmm DFS is...
spstarr: AccelDFS is true
spstarr: BufferSize, Ring, GARTSize are ignored as you say
spstarr: i only have DMAForXv enabled
airlied: try without acceldfs if you get a chance
airlied: also make sure you have -62
spstarr: can try now getting...
spstarr: how about composite for you?
spstarr: or you haven't gotten to that yet
spstarr: DDX updated
airlied: I haven't tried compiz yet
spstarr: ok
spstarr: AirCanada: corruption same thing
spstarr: recording...
spstarr: i cannot see waa im typing
spstarr: carbled glypths square boxes
spstarr: and scattered corruption
spstarr: its starting to improve as I type more though
spstarr: I can start to see some charactors
spstarr: Installing istanbul
spstarr: now recording you can see the corruption is the ame I think
AirCanada: spstarr : i think you mean another carrier :)
airlied: spstarr: thats with dfs off?
spstarr: recorded
spstarr: DFS is on says Xorg?
spstarr: Option "AccelDFS" "true"
AirCanada: Air Lied is a german airline that encourages in-flight singing ...
spstarr: I cut and paste to see the text from xchat to gnome-terminal
airlied: spstarr: turn it off.
spstarr: turning off now
spstarr: fail
spstarr: **) RADEON(0): Option "AccelDFS" "off"
spstarr: same corruoption
spstarr: (II) RADEON(0): [dri] Visual configs initialized
spstarr: (==) RADEON(0): Backing store disabled
spstarr: (II) RADEON(0): [DRI] installation complete
spstarr: (EE) RADEON(0): [drm] Failed to initialize GART heap manager
spstarr: adding fb map from e1144000 for 5a4000 ret 0 24229000
spstarr: f
airlied: post the whole log file
spstarr: putting up...
spstarr: airlied: http://www.sh0n.net/spstarr/Xorg.0.log
airlied: wierd.
spstarr: ah now my xchat is visible, most of the glyphs are not corrupt but there's still massive corruption
spstarr: screenshot...
spstarr: want my xorg.conf?
spstarr: airlied: http://www.sh0n.net/spstarr/kms-agp-badness.png
spstarr: the corruption is getting less and... less.. as I use this(!?!)
spstarr: interesting
spstarr: now the glyphs in firefox are less corrupt
airlied: spstarr: wow its really crazy looking.
spstarr: airlied: http://www.sh0n.net/spstarr/xorg.conf
airlied: I wonder if I make away to avoid writes to GART from the GPU will it stop
spstarr: at least now I can see what you're typing :)
spstarr: donno, if it'll lock
spstarr: ro root=UUID=6d343e06-4f14-4a85-8027-5947757d9042 rhgb quiet slub_debug=- printk.time=1 notsc radeon.agpmode=4 rhgb
spstarr: Linux segfault.sh0n.net 2.6.27.7-137.fc10.i686 #1 SMP Sun Dec 7 07:18:30 EST 2008 i686 i686 i386 GNU/Linux
spstarr: is puzzled why you dont see any of this ...
spstarr: going to non-KMS...
spstarr: airlied: hmmm
spstarr: -62 = doesnt work with KMS off..
spstarr: locks up
spstarr: im in KMS now with no agp
spstarr: no corruption
spstarr: kernel:
spstarr: Dec 9 21:01:08 segfault kernel: [ 55.268935] pci 0000:01:00.0: putting AGP V2 device into 4x mode
spstarr: Dec 9 21:01:08 segfault kernel: [ 55.828050] [drm:radeon_do_init_cp] *ERROR*
spstarr: PCI GART memory not allocated!
spstarr: *zap*
airlied: spstarr: thats with -62?
airlied: nuts.
spstarr: yeah lemme check timestamp to confirm..
spstarr: but -62 will not boot with kms off
rbrett: airlied: Does seeing the pretty solar fedora boot screen mean KMS is working, or do you get that without KMS also?
spstarr: airlied: yeah -62 with nomodeset == X lockup
spstarr: Dec 9 21:01:08 segfault kernel: [ 55.268935] agpgart-intel 0000:00:00.0: AGP 2.0 bridge
spstarr: this is an AGP 2.x bridge what is yours?
airlied: oops the kernel does bad things
airlied: rbrett: working unless you get vesafb
airlied: spstarr: try bootwinth modeset=1 agpmode=4
airlied: radeon. before both of them
airlied: modeset=0
airlied: even
spstarr: nomodeset != modeset=0 ?
airlied: nomodeset should work
airlied: I think I got the kernel bits wrong
spstarr: oops :-)
spstarr: by default its using AGP 4x
spstarr: my Xorg enforces that in anycase
rbrett: seems the kernel is forcing my AGP RV350 to pci mode
spstarr: yes
spstarr: you need to override
spstarr: rbrett: Fedora 10?
rbrett: yes
spstarr: mobile chip or desktop model?
spstarr: 64MB? or 128?
rbrett: desktop 9600 Pro
spstarr: I know it sucks,I cause so much grief for airlied :)
scsiraider: airlied: ping
airlied: scsiraider: pong
scsiraider: anything new on the kms front... is it gonna get in master this month?
airlied: nope.
terracon: hmm ksmbadness.jpg .. yes baaaaaaad
airlied: still have to get the memory manager sorted out
terracon: kms that is
airlied: intel kms will go into Linus next merge window
spstarr: terracon: you get this too?
spstarr: or just lil ole me
terracon: just lil ole you
terracon: I need to run a fairly stable system right now so I'll wait till it's yum'able
terracon: I'm staying away from koji for the time being
spstarr: bangs head on table
spstarr: wtf i wrong with this shitty stinkpad !
spstarr: either there's something different with the mobile rv350 vs the desktop non-mobile GPUs
spstarr: ?
spstarr: or there's a bug on the agp bridge that AMD worksaround?
spstarr: it would be nice if AMD would just tell us (even from their windows driver) what they workaround if that is indeed the problem
bridgman: spstarr; I know everyone hopes there is a "corrupt memory and crash randomly" bit we can tell you to turn off, but the reality is that AGP is just plain ugly and we end up having to tweak the drivers for every different chipset/card combination
spstarr: bridgman: yes
bridgman: The tolerances are too wide and there are two many possible combinations of speed and version on both sides to make it practical to test
spstarr: so, stop making them please :-)
spstarr: bridgman: if you could get erratas those might help too
bridgman: I'm sure we can eventually get your laptop model running reliably but the guy beside you will still be screwed until the driver gets tweaked for *his* hardware
spstarr: maybe some tweaks are needed for the rv350 mobile
spstarr: fun :)
airlied: spstarr: what AGP bridge was yours again? intel?
spstarr: well, i'll keep testing as the fixescome
spstarr: airlied: yes
bridgman: it's not as simple as errate; we read from the bus and sometimes we don't get the right answer, so we twiddle registers in the chipset (not in our chip) to try to make things work better
spstarr: 2.0
spstarr: airlied: specifically - 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
bridgman: if erratum is singular and errata is plural, wonder what errate is ?
airlied: spstarr: I know we have a lot of places where that chipset/card needs to be forced to AGP 1x
airlied: does radeon.agpmode=1 work?
spstarr: can try brb
spstarr: same corruption
airlied: okay so not that then :)
spstarr: airlied: http://www.sh0n.net/spstarr/badness.png
spstarr: bridgman: seen anything like this ^^^^^^^
spstarr: i cant see what im typing properly..
spstarr: :)
spstarr: bridgman: oddly as i continue to use this the text glyphs seem to get more readable..
spstarr: but there still is massive corruption
bridgman: yeah, I saw you mention that before; seemed odd
spstarr: now i can see what im typing.. amost
spstarr: agp off it works
bridgman: maybe you get more tolerant of corruption; it's amazing what the brain can adapt to ;)
spstarr: agp on with kms no go
spstarr: ahahaha
spstarr: airlied: but why would kms + agp fail but AGP 4x without kms work?
spstarr: I know that it switches to AGP 4x mode fine w/o kms
airlied: spstarr: yup thats what wierd.
airlied: spstarr: though KMS does a lot more GART useage.
spstarr: I can even prove that
airlied: spstarr: without KSM you don't get dynamic GART.
spstarr: well in Xorg i set the GARTSize manually. i dont need to though bit I did to gain some system ram to use via the aperture
spstarr: this is really puzzling
spstarr: assuming this corruption has some sort of pattern
spstarr: the root window of the solar theme is visible with black blocky lines scattered
bridgman: looks like Wraith...
spstarr: ?
spstarr: oh
spstarr: :)
bridgman: yeah
spstarr: That's fedoras theme
spstarr: Solar
spstarr: airlied: any debug i can give? is there any debug mode i can turn on besides drm's debug mode?
spstarr: does the DDX have a debug mode?
spstarr: (every command submission etc is dumped to screen)
spstarr: unless that would lockup card
spstarr: [ 58.473024] mtrr: base(0xe1144000) is not aligned on a size(0x5a4000) boundary
spstarr: [
spstarr: the drm driver is using MTRRs?
spstarr: is it absolutely critical the alignment is right or no?
spstarr: airlied: when i maximize/minimize windows text glyphs become more clear, something with offscreen memory corruption?
mjg59: airlied: Plus side of being in Boston is that I've found my code breaks RS690 completely, so I'm going to fix that up in the morning
mjg59: airlied: After that I'm shifting to the OQO and VIA lulz
airlied: mjg59: RS690 that doesn't even have emory to clock :)
airlied: spstarr: not really sure need to think of some more debugging to add.
spstarr: ok
airlied: I wonder will my 865 motherboard be as busted, though not sure about AGP voltages and that card.
mjg59: airlied: Yeah, right now mem reclocking only happens on R520+.
mjg59: airlied: It's actually oopsing on timer failure, which I swear I fixed. I think I'm managing to build code that isn't actually getting run
mjg59: But it got to the point of 8+ hours of fixing laptops, so I suspect my judgement was going towards the end
mjg59: I'll give it another go in the morning. If it works, early visit to drinking island
spstarr: airlied: is there a packet format you submit to the CS? or its just mini register programs [BEGIN] set this, that [END]
airlied: spstarr: we just submit hw indirect buffers
airlied: spstarr: same as the CP accepts in the r500 docs
spstarr: hmm ok
spstarr: so you dont think that MTRR warning is anything we really should worry about?
airlied: nope shouldn't be an issue.
spstarr: shouldn't..
spstarr: at this point, I'd point to anything alarming such as that
airlied: nope its not that
spstarr: but maybe that MTRR is being used by the intel agp bridge ?
airlied: nope not that.
spstarr: ok
spstarr: airlied: what about the BeOS driver?
airlied: spstarr: what about it?
spstarr: maybe they encountered issues with the rv350 mobile and have workarounds in their code?
spstarr: haiku even
airlied: spstarr: stop grasping at straws, I'm sure we'll figure it out.
spstarr: well, yes
spstarr: im looking at their code in anycase
spstarr: DEVICE_ID_RADEON_NP
mjg59: If the BeOS driver works better, it's probably because it doesn't actually do anything
spstarr: hehe
spstarr: im just looking for specific workarounds they noted
spstarr: airlied: it wouldn't be anything to do with timings?
spstarr: they are taking bits of code from the ddx
airlied: most of their code is just taken from radeon.
spstarr: // Set HDP_APER_CNTL only on cards that are known not to be broken,
spstarr: 889 // that is has the 2nd generation multifunction PCI interface -rv350
airlied: from radeon
spstarr: ok
airlied: no other open source driver does anything close to whatwe do
airlied: dynamic AGP seems to be the problem
spstarr: dynamic in what way?
spstarr: I thought you had to setup a fixed set of memory for a card, and that it could not be changed
spstarr: like the aperture size is fixed and not changeable, dynamically.
spstarr: airlied: the aperture by default the BIOS sets is:
spstarr: [ 0.861011] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
spstarr: is that different for your sis board?
airlied: oh you large aperture, I only get 32MB
spstarr: !
spstarr: the ibm bios set this, i cant adjust it
spstarr: maybe there's something to go on
airlied: try making it smaller
spstarr: looks to me from google all the Thinkpad BIOSes set this to 256M
spstarr: kernel option?
airlied: oh it might be changeable in the bios
airlied: but it might not
spstarr: radeon.gartsize=?
spstarr: lemme reboot into bios.. but i dont recall seeing an option
spstarr: nop3
spstarr: nope
spstarr: bios only lets me switch to PCI/AGP modes
spstarr: and pick which video out to use for display