sgvadds: airlied, it seems that video=TV-1:d was just ignored. But I tried some other params and finally it works as I want with just video=1024x768. I was sure that I tried that earlier without success, may be something changed. Thanks for the hint anyway.
DanaG: [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16465
DanaG: [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser !
tesuki: Is there any plans to create optimized drivers for the FireGL cards or are there anyflags I can use to get the same 3D performance as with fglrx?
DanaG: that's when trying to run openarena on rv200.
MostAwesomeDude: There are no special optimizations specific to firegl chipsets.
tesuki: Is this on the TODO list?
MostAwesomeDude: Is what on the TODO?
MostAwesomeDude: There's nothing special to be done.
tesuki: To add ompmizations specific to fireGL chipsets
DanaG: weird... this conversation is reading like top-posting on a mailing list.
MostAwesomeDude: There are *not* any firegl-specific optimizations. Period.
DanaG: Or was, rather.
tesuki: MostAwesomeDude: May I ask why?
MostAwesomeDude: There are no special features in any firegl chipset which need to be explicitly supported.
MostAwesomeDude: tesuki: There's nothing special about the HW. It's supported just like regular Radeons are supported.
tesuki: Then how come I get much beter performance in FireGL than radeon cards?
DanaG: What app?
MostAwesomeDude: It's faster.
MostAwesomeDude: The chips are faster, but not programmed differently.
MostAwesomeDude: Think about the difference between Pentiums and Celerons.
tesuki: and fireGL with fgrlx vs radeon driver the fgrlx driver is why faster.
tesuki: DanaG: Maya and Blender
DanaG: But... the difference between FireGL X2 and Radeon 9800 Pro... was mostly just dual-dvi and driver differences, at least in Windows.
MostAwesomeDude: fglrx is faster because there's more code.
DanaG: fglrx is extra-fancy, you could say.
MostAwesomeDude: Figuring out the little bits of magic that make fglrx really speedy is not simple.
MostAwesomeDude: And some of the other bits are tough to do.
MostAwesomeDude: Finally, fglrx is about a dozen times larger than the entirety of an X stack, in terms of LOCs.
eosie: I am beginning to realize that failover has never actually been tested
tesuki: I can understand. Is there anything I can do with my computer to get info about the cards? Or how have the development of the driver gone in general, Is it reverse eginering of hardware or software?
MostAwesomeDude: eosie: Not since gallium 0.1, and not in an open-source stack.
DanaG: ATI gives specs for the cards... no reverse-engineering is really needed. Or if any, most likely it's very little.
tesuki: Even the R[1-5]00 cards
MostAwesomeDude: eosie: Have you tried raising it up to the state tracker? When shaders are created, test them for NULL, and error out if you get a NULL. Might make it easier to track down issues.
MostAwesomeDude: Ideally, that's what failover should do. It should behave like trace.
MostAwesomeDude: Wrap the driver, and only intervene when the driver returns known bad values.
eosie: MostAwesomeDude: I am trying to create failover and put r300 and softpipe inside
MostAwesomeDude: eosie: Good luck, it's definitely bitrotted.
MostAwesomeDude: eosie: You should /join #dri-devel, as it's where a lot of the devs are, and it's more topical there.
jdetring: Hi room. I have an oops on radeon.ko (modeset=1) insertion.
eosie: it basically switches to the other driver if the first one returns FALSE in draw* functions, which is the idea I was after
MostAwesomeDude: Yeah, but that's not the only point of failure.
jdetring: I am running drm-radeon-testing at 6476cbf90ee... (the 17th)
MostAwesomeDude: If any of the CSO creation hooks return NULL, then you should drop what you're doing, because you're not going to be able to get any rendering done.
MostAwesomeDude: And shaders are CSO.
eosie: the shader compilation is deferred which makes it a little bit tricky
jdetring: The kicker is that it is a sparc64 machine. Looks like failure in setting up connectors.
MostAwesomeDude: We could avoid deferring it.
MostAwesomeDude: We won't ever fail on texture compare modes, or on hpos/wpos hax.
MostAwesomeDude: We'll only fail because of flow control or NOISE or other unsupported opcodes.
MostAwesomeDude: So we could compile the first, typical version of the shader, on create.
MostAwesomeDude: And if it fails, return NULL.
MostAwesomeDude: It's not like we're seeing *that* much of a speedup; right now, mesa st creates a big handful of shaders and tries binding nearly all of them.
eosie: MostAwesomeDude: yeah but assume the instruction count gets near the hw limit and texcompare modes surpass it, then we're screwed
MostAwesomeDude: eosie: Then count out in advance.
MostAwesomeDude: GL's API provides for failed shader compilation; we should take advantage of it.
Nightwulf|work: hi all
eosie: MostAwesomeDude: I think GL API should fallback when shader compilation fails because of unmet hardware requirements, and whether the shader will run in hardware or software is written to the GLSL linker info log
MostAwesomeDude: Two reasons that's a bad idea.
MostAwesomeDude: First, you can't fallback fragment shaders.
slon_: How to enable opengl 2.0?
MostAwesomeDude: Second, the app might be able to provide an alternative shader, which would run faster than the fallback shader.
MostAwesomeDude: slon_: Which chipset?
MostAwesomeDude: I think you just have to pull from git and rebuild.
soreau: Isn't it still disabled by default?
eosie: MostAwesomeDude: 1) We must fallback fragment shaders because we must fallback NPOTs 2) in this case the app should parse the info log
MostAwesomeDude: eosie: I can't think of a case where NPOT would require us to fallback a shader, except for a couple edge cases that should get moved up into the state tracker.
airlied: also most apps are written to card specs, so its unlikely you'll get a frag shader than was written for r300 or r500 that'll allback
airlied: just refuse the shader and let the app do whatever
airlied: its probably someone running a game under Wine
slon_: I'm using this https://launchpad.net/~xorg-edgers/+archive/ppa should it have opengl 2.0 and kms by default?
eosie: wine's D3D->GL translation may raise hardware requirements (e.g. I noticed it has its own implementation of WPOS)
MostAwesomeDude: They might not use that; they may use MESAX_sm3 once it gets finalized.
MostAwesomeDude: I'll totally bug keithw over this. It's completely reasonable to fail a shader, hard, and the API should respect that.
eosie: MostAwesomeDude: in my opinion it's not possible to fallback NPOTs without fallbacking the entire pixel pipeline
MostAwesomeDude: eosie: The trick is to fall back ahead of time.
MostAwesomeDude: e.g. you have texrects and need to do wrapping. Solution: Judicious use of FRC and DIY normalized coords in the fs.
MostAwesomeDude: The driver never even knows; it thinks it's doing texrects.
airlied: I'm not 100% sure you can do fallbacks
airlied: the sampling hw can't do what you want
eosie: MostAwesomeDude: that's a simple case... what about mipmaps, 3D textures, and cubemaps? this is when it's starting to get really tricky
airlied: but lets not expose ARB_npot
MostAwesomeDude: eosie: For mipmaps, lie. For 3D textures, gripe and groan, ditto cubemaps.
airlied: and fix gallium to understand the hacks
airlied: a defacto standard is none the less a standard
MostAwesomeDude: airlied: Well, that's what I'm suggesting. We turn off NPOT advertisement in the driver, split the NPOT flag into NPOT and texrect (or just assume that all cards do texrect, srsly) and then the state tracker can just deal with it
MostAwesomeDude: And sure, some of the hax will be ickier than others, but it's gonna be a lot more pleasant if it's one level up.
airlied: MostAwesomeDude: so you think the state tracker shoudl expose GL2.0 even for texrects
eosie: I was thinking about doing it somewhere between the driver and the state tracker - e.g. using failover
MostAwesomeDude: airlied: I think that there are too many poorly-written apps that will refuse to do GLSL without 2.0 advertised, and I think that brianp will never allow advertising 2.0 without ARB_npot.
eosie: and let the driver to decide when to fallback (return 0 in draw* functions)
airlied: MostAwesomeDude: its OpenGL I seen in my fglrx glxinfo ;-)
slon_: If I install the newest kernel 2.6.33rc1 I wont have my drivers yep?
airlied: MostAwesomeDude: I think they'll do it if we just hack a patch up ;-)
MostAwesomeDude: airlied: Maybe. This is a tough question; I do not think that any answer we come up with will be a good answer.
airlied: or else we just advertise NPOT and fail to be useful beyond the basics of texrect
eosie: I don't wanna make a GL1.x driver, we already have one
MostAwesomeDude: I don't wanna make an fglrx, we already have one.
soreau: slon_: That kernel should definitely have support for your card
soreau: MostAwesomeDude: We don't already have an fglrx..
soreau: and you wouldn't be making one
eosie: I'm gonna be exploring what are our fallback options and trying to figure out how to fallback on any feature not supported by hw that's there
slon_: soreau: how to remove grub entries because I have to many kernels :D
TCW: slon_, but the kernel alone is not enough, mesa, xorg-ati-driver, dri, all part of the show
slon_: for that xorgontheedge should be enough?
TCW: slon_, and try to stick to radeon related questions here, not general GNU/Linux stuff like grub etc.
eosie: MostAwesomeDude: BTW you can advertise GL2.0 with zero extensions... they are there for GL1.x applications and are completely useless when they become a core feature
MostAwesomeDude: eosie: Not exactly.
MostAwesomeDude: fglrx simply refused to do anything that was part of ARB_npot.
MostAwesomeDude: Eventually, game writers got the hint, and just wrote around it.
MostAwesomeDude: Which is part of why this isn't quite a deal-breaker.
slon_: TCW: Is xorgOnTheEdge enough?
eosie: MostAwesomeDude: whether fglrx follows the GL spec is another story
MostAwesomeDude: eosie: Sure, I'm just pointing out that there's a precedent for it.
MostAwesomeDude: After all, if app authors stuck to the spec, then we *could* do a GL 1.5 driver.
TCW: slon_, no idea about ubuntu stuff
MostAwesomeDude: We could put in half the 3.0 spec.
MostAwesomeDude: And apps would merely look for the extensions they wanted.
MostAwesomeDude: But noooo, they want the 2.0 GLSL hooks instead of the ARB hooks.
slon_: TCW: here is what it includes https://launchpad.net/~xorg-edgers/+archive/ppa could you please check?
TCW: slon_, no
TCW: slon_, check yourself against the official xorg / freedesktop svn / git versions
slon_: where are they?
TCW: slon_, freedesktop.org x.org google.com
taiu: runs throuch piglit/quick on r600
TCW: slon_, how about looking at the topic?
taiu: not too bad: http://people.freedesktop.org/~andrem/piglit/r600-quick-21-12-2009/
eosie: taiu: remove parser tests and get piglit from git... there should be about 170 tests you should care about
TCW: xorg-ati 6.12.4 new enough for dri2 and kms? Any issues? Stability?
TCW: on r5xx that is :)
eosie: MostAwesomeDude: ok point, but float textures will be no different, their limits are even more funky and the ext spec is silent about it
zhasha: what problems present themselves if we just waste memory and do NPOT textures as POT textures?
spreeuw: TCW: does it work?
spreeuw: else just use git, its rock steady
eosie: zhasha: impossible, you can't do mipmaps, cubemaps, and 3D textures this way
MostAwesomeDude: eosie: Well, you can always either upscale to next POT or downscale.
MostAwesomeDude: Upscaling wastes memory, downscaling discards info.
zhasha: so how do we fall back efficiently (relatively)
eosie: and both breaks the behavior
MrCooper: it should be possible to do the sampling in the shader?
MrCooper: at least for 2D textures
eosie: that's the plan - to do what can be done for 2D textures and fallback everything else
zhasha: and by fallback do you mean softpipe the entire frame?
eosie: or the draw call
MostAwesomeDude: There's no pleasantries here. Doing a swrast fallback involves mapping all the buffers out.
MostAwesomeDude: So it should be avoided at all costs.
zhasha: MostAwesomeDude: by the way, I think this particular problem belongs in the driver side fix category
zhasha: there's no reason state trackers should accommodate for non-compliant hardware
MostAwesomeDude: zhasha: Non-compliant? The API provides for no NPOT support.
MostAwesomeDude: The hardware's perfectly compliant. I'm looking to make the driver more compliant, by discarding some of the PIPE_CAP lies.
zhasha: huh? I mean that we want to advertise ourselves as GL2 but we're not GL2
zhasha: ergo, we're lying about what we can. We can't comply with GL2 core
MostAwesomeDude: Technically, there's not a single GL 2.0 chipset out there. Everybody fakes something.
MostAwesomeDude: We're just faced with a larger-than-normal set of functionality we need to fake.
zhasha: yes but it still belongs on the driver side given you don't want to fix every single state tracker because 1 card is more-so retarded than usual
MostAwesomeDude: Every single state tracker? If I'm right about texrects, then most state trackers won't even care, they can get by with rects.
zhasha: just siphon as much of the fix out to a utility module as possible, then other drivers can use it if we ever hit something like this again
zhasha: the problem distinguishes itself by it being us wanting to advertise GL2 but not supporting it and there being NO fast fallback paths. If you put the fix in the ST you'll effectively be starting to require software fallbacks in the state tracker
eosie: the state tracker could tell us whether we may fallback and lie (Mesa) or whether we should expose the real feature set only (Xorg, VG)
zhasha: eosie: that's not a half-bad idea
MrCooper: MostAwesomeDude: the Xorg state tracker needs wrapping modes for NPOT textures
zhasha: A potential D3D state tracker would probably something likewise
zhasha: probably need something* even
MostAwesomeDude: Wrapping is not that hard, with the magic of FRC.
MostAwesomeDude: Gives you the fractional part of a number.
zhasha: oh it's TGSI
eosie: D3D9 has lots of caps and it never fallbacks unless you explicitly state you want the reference rasterizer
zhasha: looking at your documentation and I quite like the initiative, but I think it would be more efficient to use doxygen, and also prettier
MostAwesomeDude: Already discussed on the ML.
zhasha: MostAwesomeDude: the doc thing has been discussed? I can't find it
taiu: hmm, on r600 we can't address constant file using negative register index
taiu: wonder what r300 does ?
taiu: hmm, fprintf(stderr, "negative offsets for indirect addressing do not work.\n"); -- seems same?
moobie: Hi folks
moobie: Zajec, is powermanagement in master? :)
moobie: or do you know when it will get commited to master
Zajec: moobie: no
Zajec: moobie: so far no objections for my patch from developers
Zajec: moobie: we have some reports about fences problem... but not sure if that is really pm patch related... that report is somehoe weird
Zajec: moobie: agd5f is working on reading PowerPlayInfo table from AtomBIOS (that's what radeonhd does)
Zajec: moobie: he should have that soon (day?) so I don't try to do that faster :)
airlied: Zajec: regressions need t obe hunted down
airlied: those are GPU hangs
eosie: FWIW I managed to get software fallback working (switching between two drivers anytime during rendering) with the apps that doesn't use textures, the next step is to fix textures in failover but I won't continue working on this, as it's the least important thing now
Zajec: airlied: i'm not sure if that is real regression fromy my patch
Zajec: airlied: one of reporters said it also happens with dynpm=0
Zajec: airlied: could you maybe see if https://bugs.freedesktop.org/show_bug.cgi?id=25718 makes any sense to you?
Zajec: airlied: any idea about what may happen?
slon_: Is there a way to quicly switch between fglrx and open drivers?
slon_: so like no 3d games playing for now?
soreau: Do you not have 3D working using the open driver?
glisse: Zajec: this just looks like gpu hang
slon_: I cant play through wine
TCW: spreeuw, as noone replied I did not try it yet, not sooo important
soreau: slon_: What does 'glxinfo|grep renderer' say?
soreau: TCW: I agree with spreeuw. You might as well use git
slon_: OpenGL renderer string: Software Rasterizer
slon_: that is bad
soreau: So you don't have 3D working
soreau: Yes it is bad
slon_: interesting I did radeon.modeset=1
TCW: soreau, YOU should know, I am not that comfortable with source, but debien experimantal has some upgraded packges (latest stable releases as I see it)
slon_: and now I dont have 3d but I had it before :D
slon_: any ideas how to fix?
soreau: TCW: Actually, I don't use 'releases' typically so I don't know if 6.12 or w/e has kms support. Also, it has to be built against libdrm with kms support, and no telling how the package maintainer did it
soreau: slon_: Pastebin your X log
TCW: soreau, let's guess the maintainers did it the right way ;)
TCW: I will test it this afternoon or evening
soreau: Good idea
slon_: soreau: http://pastebin.com/m1ed17b33
soreau: TCW: Note the packages of interest to upgrade would be libdrm, mesa, ddx (xf86-vide-=ati) and the kernel. You want to use at least 2.6.31
TCW: ddx == the xorg-ati-driver? What does "ddx" mean?
Ghworg: Latest libdrm release hasn't made it into debian yet. It was packaged but got rejected for some reason
soreau: TCW: See the link in the topic. It tells you what ddx means
TCW: apart from "xf86-video-ati (ddx)" no explanation what ddx means :)
soreau: Well it's the device dependent X driver iirc
TCW: ok... another acronym that nobody needs ;)
slon_: soreau: maybe I should try the older 2.6.32 kernel?
Ghworg: TLAs FTW
TCW: Ghworg, \o/
TCW: anyhow, need to get going, bbl
soreau: slon_: Did you build that kernel yourself?
slon_: It is from the ubuntu ppa
soreau: slon_: Did you update libdrm, mesa and dx along with it?
slon_: yes the xorgontheedge has that
soreau: Well I guess they got something wrong
soreau: You could try your old kernel then and see if it works
slon_: this is really weird
slon_: when I remove radeon.modeset=1 I get OpenGL renderer string: Mesa DRI R600 (RV635 9598) 20090101 TCL
twnqx: anyone tested suspend/resume with 126.96.36.199 (and no further patches)?
twnqx: (on RV635)
twnqx: 188.8.131.52+drm-radeon-testing didn't wake up for me :X
Zajec: glisse: yeah it does
twnqx: well, + PM patch
Zajec: glisse: but can that be related to my patches?
Zajec: twnqx: i've same issue with RV620 for even
Zajec: twnqx: have no idea how to debug this :/
twnqx: neither here. so i'm stuck on 184.108.40.206 + a month old drm-next + bfs
Ghworg: twnqx: Suspend works for me on rv630 on 220.127.116.11 + drm-radeon-testing from a few days ago. Fails on latest drm-radeon-testing
glisse: Zajec: your patch likely make the hang more likely to happen
twnqx: 2009-12-17 17:20 linux-18.104.22.168-kms <- fails
slon_: soreau: What is the problem that radeom.modeset=1 doesnt work?
Ghworg: twnqx: Bug report I filed -> https://bugs.freedesktop.org/show_bug.cgi?id=25733
soreau: slon_: You probably don't have modesetting enabled in mesa or ddx
slon_: and to do that i have to?
soreau: Build libdrm with kms support then mesa, ddx and X against that libdrm
Zajec: glisse: any idea how/why?
Zajec: glisse: any suspiction about real source of problem?
slon_: soreau: Can I get a link?
Zajec: glisse: would backtrace be useful?
soreau: slon_: It's in the topic here
glisse: gpu hang are painfull to trace i spend last week working on them
glisse: backtrace is useless
glisse: it's the gpu which is faulty
soreau: glisse: So don't test with bad hardware? :)
glisse: soreau: issue is that we send cmd that leads to lockup
glisse: we are likely guilty
soreau: j/k it just sounded funny
Ghworg: glisse: Can you think of anything in your "drm/ttm: Rework validation & memory
Ghworg: space allocation (V3)"
Ghworg: Grr, stupid copy paste. I'll try that again
Nezmer: I'm holding upgrades atm. Will I need to build X from a development branch? Or just libdrm/mesa/xf86-video-ati ?
soreau: Nezmer: Likely just the trio, unless your X is ancient
Nezmer: soreau: that's what I thought. not ancient "22.214.171.1241"
soreau: Nezmer: That should be plenty good enough
Ghworg: glisse: Can you think of anything in your "drm/ttm: Rework validation & memory space allocation (V3)" that would cause suspend to hang? My git bisect indicates that is the cause of my problem
twnqx: not suspend! resume! :P
glisse: Ghworg: should work with lastest head
twnqx: doesn't with 4 days old
glisse: and don't trust git bisect in this area
Ghworg: twnqx: Different problem then. Mine is a problem when suspending
twnqx: wait, latest head of drm-next or drm-radeon-testing?
Ghworg: glisse: Okay, I'll try updating again
twnqx: so i just do git pull; git pull origin to move to that, right?
twnqx: i think i'm on 126.96.36.199 + head from 4 days back :P
twnqx: gah, loads of conflicts
soreau: twnqx: Does git branch -a show drm-radeon-testing?
twnqx: * radeon_kms
twnqx: but i'm p sure i used that
soreau: twnqx: To clone fresh, do this: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git; cd drm-2.6; git checkout --track -b drm-radeon-testing origin/drm-radeon-testing
twnqx: i should track them all separately
twnqx: now updateing the vanilla part produces conflicts
Ghworg: git pull for drm-radeon-testing says "Already up-to-date.". So latest head is definitely broken for me
Ghworg: Hmm, I suppose I should try a pure drm-radeon-testing build to make certain it's not some weird interaction with stable
Zajec: glisse: ok, thanks...
uyf: hello, i have a problem with latest drm-radeon-testing kernel. when i boot in agp mode it sets the card to 4x mode, it works with agpmode"-1" but then the fps gets very low instead
uyf: i have a R635 chip, also i would try the .31 and .32 kernels but the radeon-testing remote branch won't merge correctly
twnqx: is happy with his patched 188.8.131.52 & RV635
uyf: twnqx: are u using modesetting?
twnqx: kms? yes
twnqx: but it's about one month old
uyf: twnqx: so which patches did u use only for irqs?
uyf: i would like to use an earlier kernel too because after i reinstalled my system the performance dropped for me
twnqx: no irqs
twnqx: doesn't care about 3d
uyf: ok, off to experiment some more with getting a stable system. stable+fast doesn't compute very well for me :P as usual
adamk: Anyone know if quake live should be playable with the open source drivers on r6xx/r7xx?
spreeuw: dunno never tried
spreeuw: lookup in the programs page
spreeuw: PLATINUM (7.7-dev)
spreeuw: so yeah
darkbasic_: adamk: since the merge of glsl/opengl2 no
darkbasic: when will the conflict between 184.108.40.206/2 and drm-radeon-testing be solved?
Zajec: glisse: AFAIK drm.debug=15 will print all commands sent to CP
Zajec: glisse: can this be way to track gpu lock up?
moobie: Hi folks
moobie: Zajec, is powermanagement in master? :)
Zajec: moobie: check irc log, i replied
moobie: Sry dude. But I had to rush to the town
moobie: I have been disconnected since
Zajec: no problem, just check log :)
moobie: Where is the log located? Sry for the stupid question.
gsedej: Hi! How is OpenGL 2.x support going? :)
Zajec: yeah, it's somehow hidden :) http://radeonhd.org/ links to: http://radeonhd.org/?page=archive_display&c=radeon&m=12&y=2009&d=2009-12-21
Zajec: airlied: that is not regression, just makes bug being triggered more often
Zajec: airlied: and it's only when you set dynpm=1
Zajec: airlied: unfortunately I can not debug GPU hang :|
niasha: what is the difference between radeon driver and radeonhd driver ?
hifi: short answer: use radeon
niasha: hifi, but i have a radeon HD 4670 , should i still use radeon driver ?
darkbasic: how to get 2.6.32-git + drm-radeon-testing? "Automatic merge failed; fix conflicts and then commit the result."
niasha: hifi, does radeon support 3d acceleration ?
hifi: the difference between radeon and radeonhd was something about "how things should be done" and in the end radeonhd became much like radeon
soreau: darkbasic: To clone fresh, do this: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git; cd drm-2.6; git checkout --track -b drm-radeon-testing origin/drm-radeon-testing
hifi: niasha: if you have current enough code, yes
niasha: hifi, do you mean lastest driver ?
hifi: yes, I don't know which versions of which components are required for 3D acceleration on R7xx
hifi: http://yangman.ca/blog/2009/10/15/linux-graphics-driver-stack-explained/ read that if you are interested and have the time
darkbasic: soreau: does drm-2.6.git use latest stable kernel (2.6.32)?
hifi: about how linux graphics work
soreau: niasha: Yes, radeon supports acceleration for that card. like hifi said you will want the latest components, namely kernel, libdrm, mesa and ddx
spreeuw: niasha: it has
soreau: darkbasic: I dont know
hifi: niasha: what distribution are you running?
niasha: can any one give me a tutorial about that
hifi: and which version/release
darkbasic: soreau: I follow this guide (http://xorg.freedesktop.org/wiki/radeonBuildHowTo#head-a6271d23a9199673cea21478e0198d772a55fad3) but 220.127.116.11/2 +drm-next/drm-radeon-testing is broken
niasha: hifi, debian testing
hifi: it probably has all the pieces except firmware
hifi: which you need from the nonfree repo
niasha: hifi, what firmware?
soreau: darkbasic: That is out of date and broken
hifi: was "sid" the codename for debian testing or unstable?
soreau: darkbasic: Using drm-radeon-testing is recommended for latest radeon kernel code
Nezmer: darkbasic: I fetch drm-radeon-testing. It's 2.6.32-based but with all the latest drm code
Nezmer: darkbasic: It's a whole kernel
hifi: niasha: testing doesn't have recent enough components for R7xx acceleration at the moment, my conclusion
hifi: wasn't 2.6.31 required for R600/R700 acceleration?
darkbasic: Nezmer: I know, but someone told me it's based on 2.6.33
hifi: or did 2.6.30 already have the code
Nezmer: darkbasic: that someone is wrong I think
soreau: hifi: For r6-7xx you need at least 2.6.32-rc*
Nezmer: darkbasic: "2.6.32-bfs311-NZ1"
Nezmer: darkbasic: my uname
hifi: soreau: oh, good to know
darkbasic: Nezmer: ok, thank you
niasha: hifi, sorry my friend i mixed up , can you tell me what should i exactly do for installing radeon driver with 3d acceleration on my HD 4670 ?
Nezmer: darkbasic: the drm code is for 2.6.33 though
hifi: niasha: either upgrade to unstable or install newer components from somewhere else or completely use a different distribution
Nezmer: darkbasic: remember to install ucode firmware http://people.freedesktop.org/~agd5f/radeon_ucode/
gsedej: Hi! I have R350 (mobile), Ubuntu 9.10. When I use Compiz, computer "randomly" fully freezes (dring switching viewport). I haven't got crash in 3D app (games, blender,...). Is it possible to report bug with decent info for developers? (when it freezes is becomes unresponsive to anything)
hifi: gsedej: have you tried to force the card to PCI mode?
soreau: gsedej: Try booting with radeon.modeset=1
hifi: I'll bet on buggy AGP
niasha: hifi , i choose to install newer components . can you tell give me a link ?
darkbasic: Nezmer: I already have 2.6.32+drm-radeon-testing with ucode, but I pulled drm-radeon-testing from drm-2.6.git over 2.6.32.y.git
hifi: niasha: it's going to be a real pain, and I don't know how to get newer components for debian testing
hifi: it basically means you'll have new kernel, new xorg and new mesa
hifi: gsedej: I had similar issue with non-mobility 9600 Pro, I forced it into PCI mode and has been working since
niasha: hifi, i'm cool with kernel and mesa but i never changed my xorg before
Nezmer: darkbasic: hmm. I only need this: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing
gsedej: hifi, soreau: I think I won't be comailing drivers, sice it looks to complex. I am using default binary built of ubuntu. PCI mode in BIOS? Where to set radeon.modset=1?
hifi: gsedej: kernel boot options
soreau: gsedej: radeon.modeset=1 should be added to your kernel parameters. To test it, use E at the grub prompt to add it for that boot
hifi: my money is all on PCI mode, but testing modesetting before is a good start
hifi: I do run modesetting and PCI mode currently with that particular setup
gsedej: soreau: Is working in grub2? so just add line in boot proces?
soreau: gsedej: Yes, try it temporarily first and if you have no problems then you can add it to the grub2 config in /etc
gsedej: I hate configuratin of grub2... it is so more complex vs grub1, wher ju just added lines :S
gsedej: lets try
hifi: gsedej: can you reproduce the freeze in a small time or is it completely random?
niasha: hifi, do you now any article on the web to help me through this ?
hifi: niasha: sorry, no
gsedej: hifi: I do not know. It happens mostly when I use "scale" compiz for many windows, especialy when chosen windows is on the other viewport
gsedej: hifi, maybe it the "CPU frequence" have problems, when it turns turns high when compiz effects
gsedej: radeon.setmod=1 makes it PCI?
hifi: gsedej: no, radeon.modeset=1 makes it to use newer kernel modesetting code
gsedej: how to set it to PCI?
adamk_: gsedej, When using KMS you would also pass radeon.agpmode=-1
adamk_: gsedej, When not using KMS, you would use the AGPMode option in the Device sectioin of xorg.conf.
gsedej: how to check if I use KMS now?
soreau: X log or dmesg
soreau: If you didnt boot with radeon.modeset=1 and using ubuntus stock kernel, kms is not enabled
soreau: [ 1.513577] [drm] radeon default to kernel modesetting DISABLED.
darkbasic: radeon.modeset in grub has no effect unless you compiled radeon statically
gsedej: with KMS on, I will get less FPS in 3D, right?
darkbasic: you need to set the modeset=1 parameter in modprobe.d
soreau: darkbasic: This is ubuntu, radeon.modeset will tell the radeon module to use kms
soreau: gsedej: Yes, slightly
soreau: as of right now anyway
darkbasic: soreau: how can radeon.modeset in grub tell radeon to use kms if radeon is not static (*)?
BioTube: darkbasic: presumeably it parses the cmdline when loaded
soreau: darkbasic: I dont know what you mean, but radeon in ubuntu is compiled as module and this option will work when passed as kernel param
darkbasic: BioTube: in gentoo it doesn't for sure
gsedej: btw... Is possible tu use multimedia keys (volumen + and -) in fullscreen games?
glisse: Zajec: it's not that easy
soreau: gsedej: That has nothing to do with radeon driver
glisse: more over we use ib with kms
gsedej: soreau, yes :) I said btw :P
glisse: if gpu lockup were easy to fix, we would have done so long time ago :(
soreau: gsedej: btw, ask in your distros support channel
darkbasic: soreau: with radeon compiled as module (in gentoo of course) I had to add 'options radeon modeset=1' in /etc/modprobe.d/radeon.conf because radeon.modeset=1 in grub didn't worked. now I compiled radeon statically and the grub parameter works fine
soreau: darkbasic: I dont know what you mean by statically. Its either a module or compiled into the kernel
soreau: If its compiled in, you can use nomodeset to turn it off
darkbasic: soreau: i men compiled into the kernel
IRCMonkey: anyone working on xvmc for Radeon X1200 ?
soreau: IRCMonkey: xvmc?
adamk_: darkbasic, As soreau keeps saying radeon.modeset=1 works in Ubuntu, regardless of what you had to do in Gentoo :-)
soreau: darkbasic: In staging drivers section of kernel config, you can tell it to have kms on or off by default
IRCMonkey: http://www.x.org/wiki/RadeonFeature <- says TODO
darkbasic: soreau: I know it and I already set it, what I cannot understand is why in ubuntu the grub parameter works for radeon compiled as module too
gsedej: I started nexuiz but it crashes when it should go in level: nexuiz: radeon_dma.c:210: radeonRefillCurrentDmaRegion: Assertion `dma_bo->bo->cref == 1' failed.
soreau: IRCMonkey: Well if its not WIP, then Id have to make the educated guess and say no, no one is working on it atm ;)
soreau: darkbasic: No idea, but its mostly irrelevant in this case
IRCMonkey: funny. What do people use when they try to play HD Video Material eg. 1080p or similar ? Use CPU Power ?
soreau: gsedej: With kms or..?
[Enrico]: darkbasic: iirc on my gentoo it works
soreau: Works fine for my gentoo too
BioTube: IRCMonkey: CPU-decoding works fine for me for a 1280x768 MKV video
IRCMonkey: 1920x1080p ?
[Enrico]: now i use it compiled builtin to get the modesetting on startup but it worked when i tested it the first time
[Enrico]: as a module
gsedej: soreau, still no kms, i will restart later
soreau: gsedej: I would suggest you try kms and toggling agpmode with the information already given to you
darkbasic: [Enrico]: really? so am I the only one who had to add an option line in modprobe.d with radeon compiled as module?
IRCMonkey: Biotube: What kind of CPU do you use ? I need to play 1920x1080p MKV video. Any solution ?
gsedej: OK OK :)
soreau: darkbasic: Its probably a mere pebkac issue, I would worry about it much ;)
BioTube: IRCMonkey: E2180 Pentium 2GHz
darkbasic: soreau: it may be, but the only difference between the working config and the non working config is an * instead of a M in the kernel config :)
soreau: darkbasic: WorksForMe(TM)
niasha: i install radeon driver , but it composite does not worked
soreau: niasha: Pastebin X log
niasha: soreau: http://pastebin.com/m54afba35
soreau: oh my
soreau: That kernel is way too old
adamk: And isn't the radeon driver too old?
Zajec: glisse: then there is not universal way for debugging that? :|
soreau: Usually the build kernel version is older than the running ond lol
niasha: soreau: i'll be back in a second
glisse: Zajec: there is no way at all except making wild guess and testing
niasha: soreau: hello , again i make mistake , let me pastbin x log again
Zajec: blah :(
niasha: soreau: http://pastebin.com/m1a8b0604
soreau: niasha: You are still using 2.6.26 according to that.. what does uname -r report?
niasha: soreau: why should use new kernel ?
soreau: Because the bits to make 3D happen for your chip there are only in the latest kernels?
soreau: You need at least 2.6.32-rc
niasha: soreau: aha , so is there any option in config time of kernel that i should enable for that ?
soreau: Radeon DRM at the very least..
soreau: You probably want FRAMEBUFFER_CONSOLE too..
niasha: soreau: is that all i need ?
soreau: TBH, I dont know
soreau: of course you want modules enabled for the rest of your hw too...
niasha: soreau: i mean is there something else except kernel ?
soreau: niasha: You want latest kernel, then latest user space components, libdrm, mesa and ddx (xf86-video-ati)
niasha: soreau: hmmmmmmmmm , what about xorg sould i change that
soreau: Sorry, I didnt quite understand that question..
BioTube: xorg shouldn't need rebuilding
niasha: soreau: i mean , should i compile new xorg too ? or my current xorg is enough?
soreau: Ah, yes you shoudnt necessarily need to build X
niasha: soreau: thanks alot
adamk_: rnoland, Should I open up a bug report on freedesktop about that sl_pp_context_create undefined symbol and see if any of the developers working on that code have any ideas?
gsedej: soreau, Hi! I am now in KMS enabled. what is benefit? I find out I got less fps on GLX gears (yes, no benchmark at all) :D
gsedej: I think the boot time is longer now
agd5f: gsedej: unified memory manager, more gl extenstions, dri2, etc.
gsedej: agd5f, opengl2?
evil_core: Zajec: what new_pll is for?
agd5f: gsedej: framebuffer objects, pbuffers
agd5f: evil_core: new pixel clock selection algo for r5xx+
gsedej: what is grub kernel parameter force pci mode?
agd5f: gsedej: agpmode=-1
evil_core: agd5f: how to set it?
evil_core: I got r500 exactly
agd5f: evil_core: it's on by default
agd5f: you can turn it off by setting it to 0
evil_core: Zajec: I dont get any info in dmesg about clocks
evil_core: agd5f: but I understand that I shouldnt care about that one, right?
agd5f: evil_core: it's for pixel clocks, not eng/mem
gsedej: agd5f, thx:)
evil_core: agd5f: event know whats that, anyway thanx
evil_core: but Zajec gaved me some pm patches I am using, dunno where check current clocks
soreau: gsedej: The original purpose was to try and curb the compiz crashes
soreau: Did it solve that issue?
lordheavy: evil_core: you can see clocks in debugfs
MichaelLong: puhh I'm not alone http://lkml.org/lkml/2009/12/20/44
evil_core: debugfs(8): ext2/ext3 file system debugger - Linux man page ?
Zajec: evil_core: not that one :)
Zajec: evil_core: i was confused as well by that ;)
evil_core: Zajec: I need to change something in mine kernel?
Zajec: mkdir /debugfs/
Zajec: mount -t debugfs debugfs /debugfs/
Zajec: cat /debugfs/dri/0/radeon_pm_info
lordheavy: mount -t debugfs none /sys/kernel/debug/
Zajec: evil_core: it should be compiled with debugfs
Zajec: yeah, use lordheavy's solution
Zajec: i was told it's baaaad to mount in /debugfs/ for some reason :)
Zajec: but it works and I'm lazy :)
evil_core: # cat /mnt/debugfs/dri/0/radeon_pm_info
evil_core: state: PM_STATE_ACTIVE
evil_core: default engine clock: 400000 kHz
evil_core: current engine clock: 344250 kHz
evil_core: default memory clock: 330000 kHz
evil_core: current memory clock: 324000 kHz
lordheavy: cat /sys/kernel/debug/dri/0/radeon_pm_info
evil_core: so it works
lordheavy: without patches:
lordheavy: default memory clock: 667000 kHz
lordheavy: current memory clock: 42949672870 kHz
lordheavy: funny :-)
evil_core: lordheavy: its empty dir for me, should I add it to /etc/fstab?
Zajec: evil_core: because you mounted in other place :)
evil_core: Zajec: so before mount it was mounted there?
Zajec: lordheavy: no, it wasn't mounted anywhere by default
Zajec: evil_core: no, it wasn't mounted anywhere by default
lordheavy: umount /debugfs && mount -t debugfs none /sys/kernel/debug/
Zajec: evil_core: for some reason ppl advise to mount it in /sys/kernel/debug :)
Zajec: believe them rather than me :)
evil_core: Zajec: I got T60p, so want more agressive power saving
evil_core: changing 50 to 3000 is good idea?
evil_core: 30 0000
evil_core: or maybe 30000
Zajec: evil_core: may be tricky, but you can try
evil_core: we give in MHz?
Zajec: evil_core: no
Zajec: evil_core: 10kHz (yeah, little crazy :) )
evil_core: its damny stupid
evil_core: 40 0000 - 500 != 344250
Zajec: evil_core: it's how AtomBIOS is programmed and that is realted to hardware specific things (clocks?)
Zajec: evil_core: ah, this one
Zajec: evil_core: that's normal and OK
Zajec: evil_core: you can no program to exactly value
Zajec: evil_core: and you use decimal system, not like hardware does
evil_core: its 10* more
Zajec: evil_core: rdev->pm.min_gpu_engine_clock = rdev->clock.default_sclk - 5000;
Zajec: it's - 5'000
evil_core: $ echo $(( 400000 - 500 ))
evil_core: hmm.. I wasnt looking in patch, somebody told about '50' hardcoded ;)
Zajec: 50MHz :)
Zajec: 50MHz == 5000 10kHz
evil_core: but what about memory?
Zajec: evil_core: we don't reclock memory yet
evil_core: yeah, maybe, I hate math
evil_core: so 300Mhz should be reasonable?
Zajec: evil_core: i'm not working on PM for now, waiting for my patch to be commited
Zajec: then I'll be back working on it
Zajec: evil_core: if your default engine is 400000 i think you can even try 200'000
Zajec: 200'000 should be really safe
Zajec: personally I'd even try 100'000 or 150'000 :)
evil_core: but its less power save'y
evil_core: I bought T60p with 9cell to use less battery
Zajec: rdev->pm.min_gpu_engine_clock = 20000; // for 200MHz
mjg59: If you have clock gating enabled, then engine downclocking isn't a terribly big PM win
mjg59: Memory, however, is a huge one
evil_core: I enabled it in xorg.conf
evil_core: dunno even what gating mean
Zajec: well, decreasing my engine from 680MHz to 110MHz have quite nice results already :)
evil_core: but I was enabling all that sounded usable to me
Zajec: evil_core: xorg.conf is not used for KMS
evil_core: how to check gpu temp?
gsedej_: Hi! I was asking before. I have R350, ubuntu 9.10, have problems with compiz (scale), it compleatly freazes (randomly). Now I do radeon.modeset=1 and agpmode=-1, but it STILL FREEZES! What can I do now?
Zajec: clock gating is disabling unused hardware blocks
Zajec: evil_core: not released code yet
Zajec: evil_core: Alex has it working AFAIR
mjg59: Right, it means the core automatically turns off the clock to areas of the chip that aren't currently used
evil_core: so gimme patch!
Zajec: agd5f: may I ask about your PowerPlayInfo parser?
soreau: gsedej_: Did you test without the agpmode=-1?
Zajec: evil_core: so write it!
evil_core: mjg59: can I use it on KMS?
mjg59: evil_core: I can't remember whether the code enables it or not
Zajec: putting radeon_set_memory_clock(mclk); should be fine, but mjg59 discovered it's too slow on some GPUs
Zajec: evil_core: gate clocking? sure
evil_core: I got r500
evil_core: Zajec: how?
Zajec: evil_core: dynclk=1
evil_core: i got it already
Zajec: don't know why it's disabled by default
Zajec: evil_core: then that's it
gsedej_: soreau, yes (nexuiz made total freze, without KMS it only crashes sometimes)
mjg59: Zajec: One possibility would be to do it during initial mode set
evil_core: but mine friendstold me that his T43p uses 4W when iddling :/
mjg59: Zajec: Time how long it takes to reclock the memory
mjg59: evil_core: That's basically implausible
Zajec: mjg59: emm, what for? :)
agd5f: Zajec: there's isn't the same sort of clock gating on r6xx+
agd5f: as on previous chips
Zajec: agd5f: i know
evil_core: but w/o xorg
evil_core: with xorg 7W
gsedej: soreau, I can now "force" freeze with opening caa 15 folders in nautius...
Zajec: agd5f: but do we enable it on pre-r6xx?
Zajec: agd5f: dynclk is 0 by default
evil_core: I went to 14-17W
agd5f: dynclks option
mjg59: Zajec: If it's fast enough to do it during vblank, you could just do it
Zajec: ah, so dynclks is for r6xx+ only?
Zajec: mjg59: ah, good idea
mjg59: evil_core: Your friend is wrong. 4W is basically impossible on a T43.
Zajec: mjg59: we may want it
evil_core: Zajec: you told that somebody written code for checking gpu temp yet
agd5f: Zajec: the dynclks option enabled clock gating
Zajec: agd5f: did you wrote reading temperature?
agd5f: which is only on r1xx-r5xx/rs6xx
agd5f: Zajec: it's just i2c. you need a driver for the actual chip
dileX: hi all
evil_core: agd5f: I got r500 so its not problem
dileX: hi Zajec
Zajec: agd5f: do you have such driver? :)
Zajec: dileX: hi
evil_core: Zajec: lmsensors
agd5f: Zajec: the kernel has drivers for most of them
mjg59: The kernel has drivers for the majority of common i2c chips
Zajec: agd5f: oh... didn't find such for my GPU, but maybe will have to check
mjg59: agd5f: Is there a table that tells us what kind of chip to use, or should we just scan addresses?
dileX: (great, libdrm-2.4.17)
mjg59: agd5f: I have code to do this for nouveau now, so hooking up hwmon is pretty trivial
agd5f: mjg59: it's in the power tables. tells you the i2c bus it's on and the addr
mjg59: agd5f: These power tables are distinct from powerplay tables?
Zajec: agd5f: ok, let's sum it up... clock gating can be used on pre-r6xx and it gives some power saving... so we should enable it by default... it's enabled when dynclks=1... then why this parameter is 0 by default?
agd5f: mjg59: I wanted to hack up a bit-bang algo for radeon i2c since we need to mask the pins before we touch them
mjg59: agd5f: Yeah, that's pretty easy
agd5f: Zajec: it's not always stable or caused problems in some cases
mjg59: agd5f: I actually wrote an algorithm for the hardware block at one point, but never got it working
Zajec: ah, ok
Zajec: agd5f: maybe we could make black list?
mjg59: agd5f: Think it was timer issues. But it's pretty easy to add support to the kernel that way.
agd5f: mjg59: I've got a patch that adds hw i2c for r1xx-r5xx, but never got around to adding r6xx+
evil_core: agd5f: so share it
agd5f: been there for a while, not much use for it yet as it's not wired up
mjg59: agd5f: So on desktop cards without powerplay tables, is there a way of autoprobing the chip?
agd5f: need a i2c algo code to hook it uyp
agd5f: mjg59: if they don't have power play tables, they don't have a chip AFAIK
agd5f: since powerplay tables handle overdrive as well, at least for atom
mjg59: agd5f: Doesn't match my experience
agd5f: on pre-atom, there are separate overdrive tables
mjg59: I've got an r500 without any obvious powerplay tables and with a sensor and fan control chip
agd5f: mjg59: what card?
Zajec: agd5f: any progress about reading PowerPlayInfo?
agd5f: Zajec: in progress
mjg59: But possibly it was just a version of powerplay we didn't parse at that point
mjg59: For an old version of the driver, and it never worked
mjg59: But combined with agd5f's code, that ought to get a working i2c implementation using the hardware engine
agd5f: mjg59: http://www.botchco.com/alex/xorg/0001-drm-radeon-kms-add-hw-i2c-support-for-r1xx-r5xx-GPU.patch
agd5f: worked fine
mjg59: agd5f: Yeah, so it should just need combining with the algo code in my patch
agd5f: but I never hooked it up to a i2c algo. just manual testing
agd5f: mjg59: I wanted to create a radeon i2c algo that would transparently handle sw/hw i2c
agd5f: either bit banging or hw i2c since not all lines are hw capable
mjg59: agd5f: Right
evil_core: hi all, ekg2 hanged
evil_core: I got still black screen when running quake3 :/
evil_core: I see light trough walls in ut2k4
evil_core: and gfx is laggy in UXGA :(
evil_core: Can I get good performance in UXGA on this card?
gsedej: Hi! R350 ubuntu9.10. When I enable kms (radeon.modeset=1) i have problems with chars 5,-,p,... only some pixels of those chars are displayed. Known bug?
dileX: Zajec: is v8 last one of your radeon-pm patch?
adamk: rnoland_: Do you want me to open up a bug report on freedesktop for the sl_pp_context_create undefined symbol? Maybe one of the developers that worked on that code have some idea of what's going wrong.
Zajec: dileX: it is
agd5f: adamk: it's from the merge. it's not specific to r600 IIRC. there's a bug about it on fdo
adamk: Any thoughts on why it happens on FreeBSD but not Slackware?
agd5f: adamk: no
agd5f: adamk: http://bugs.freedesktop.org/show_bug.cgi?id=25735
adamk: agd5f: I see one bug on freedesktop that refers to sl_pp_context_create, but that bug is a build issue.
adamk: Mesa builds here, but libGL just fails to load the dri driver.
adamk: Think it's the same problem?
agd5f: due to an unresolved symbol
adamk: Well that's sucky :-)
adamk: Time to roll back my local repo.
bridgman: adamk; this smells like some nuance in the build environment that's different between bsd and linux
bridgman: AFAICS the changes are local to mesa, ie not spread around mesa/libdrm/drm which is where the usual fun comes from
bridgman: did you get a chance to confirm that the sl_pp_whatever routine was defined in your source ? wondering if adding "void" to the def'n might help...
rnoland_: bridgman: i'm suspecting a missing linker
adamk: bridgman: Yes, I checked and the routine ws defined.
adamk: Don't remember the file, but it was the first definition.
rnoland_: i haven't tried to test/fix it yet....
adamk: bridgman: And OT to this channel, xrandr *did* work properly on fglrx, btw.
rnoland_: it does build the needed static libs...
bridgman: adamk; oh good ;)
soreau: Do user space components such as libdrm reference kernel headers?
Zajec: bridgman: hey, do you know details of audio block IRQs?
Zajec: bridgman: i wonder if it reports just single IRQ that something has changed, or many detailed IRQs, like BPS changed or playing changed, and more
bridgman: right now I stare at the audio stuff and my eyes glaze over, will be looking at it again tomorrow ;)
bridgman: or maybe later today if lucky...
Zajec: agd5f, airlied: could you share some thoughts about my PM patch?
Zajec: agd5f, airlied: can that be commited, or is sth wrong in it?
bridgman: I think there was a list of IRQs in the interrupt code agd5f pushed, hold on...
edgecase: Zajec, any of your PM stuff relevant to rv200 M7 ?
edgecase: also, is any of that stuff in the released docs?
Zajec: bridgman: do you mean pushed to public?
Zajec: bridgman: huh, would be great if you could point me to that
bridgman: I keep forgetting to bookmark the kernel trees ;(
Zajec: edgecase: didn't you yest my patch? i remember you tested something
bridgman: if you can point me to the kernel trees I'll try to point you to the irq stuff ;)
Zajec: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary ?
bridgman: wanders off to get more coffee
agd5f: Zajec: the hdmi irq stuff isn't public yet
edgecase: Zajec, i only tested KMS on rv200 using drm-radeon-testing. if you have some bits relevant to my chip i'd love to test since i'm on laptop and PM matters
edgecase: are the laptop/Mobility chips PM different than desktop versions?
Zajec: agd5f: yeah, i thought like that
Zajec: agd5f: bridgman had other opinion ;)
bridgman: I knew the audio details weren't public, just didn't remember if there was anything interesting in the irq stuff
Zajec: edgecase: i don't think mobility vs. non-mobility matters
agd5f: Zajec: some of the irqs are listed in r600.c, but not all. there are over 200 IIRC
bridgman: given that my STINKIN' COFFEE MAKER is short-changing me on coffee again
Zajec: agd5f: r600.c? are you sure?
agd5f: Zajec: yes in the drm
Zajec: agd5f: r600d.h maybe?
agd5f: no r600.c
Zajec: agd5f: there are only dhp and vblank
Zajec: HPD :p
agd5f: Zajec: see the comment right before r600_irq_process()
bridgman: wonders if he should answer all questions with "I dunno, ask agd5f" ;)
Zajec: agd5f: hm, ok, so there is source and data, ok...
Zajec: agd5f: still i don't know register to enable receiving audio IRQ :)
Zajec: and AFAIK that's not documented
agd5f: Zajec: because we haven't released that yet
Zajec: yup :)
bridgman: sorry Zajec; I couldn't remember off the top of my head what was in the list
Zajec: sure, np :)
agd5f: in addition to the ring entries, you need to know the registers with the enable and ack bits
agd5f: which we also haven't released yet
bridgman: adamk / rolands; stillunknown just mentioned a similar-sounding glsl build problem on #dri-devel, no idea if it's related
Zajec: i've just noticed sth like:
Zajec: [ 13.960179] [drm:r600_irq_process] *ERROR* Unhandled interrupt: 21 5
Zajec: [ 2266.848208] [drm:r600_irq_process] *ERROR* Unhandled interrupt: 21 4
bridgman: thought we were almost finished audio ;(
Zajec: can you share the secret, what is source 21?
spstarr: agd5f: that may be right, but, that doesn't explain why even with glxgears moving the mouse over the title bar (when maximized) shows the stalls and w/o KMS it does not
bridgman: Zajec; probably not yet
spstarr: agd5f: I don't see how there's any IRQ issues with my system that are known
agd5f: spstarr: it does perfectly. without kms there is no irq support, so the driver doesn't use them as such the gui isn't influenced by busted irqs
agd5f: spstarr: but with the latest kms, the driver uses irqs so the gui depends on them and if they are not working right it impacts the gui
agd5f: so you notice
spstarr: agd5f: so were do we go then on trying to find out why this is happening?
agd5f: spstarr: need to figure out what's wrong with irqs on your laptop
spstarr: so you think an ACPI issue then
edgecase: how does it work at all, does it poll things to catch missed irqs ?
agd5f: spstarr: hard to say. could be acpi, could be a chipset bug
agd5f: spstarr: no
edgecase: otherwise i'd think a missed irq would just sit forever
agd5f: if irqs aren't working properly, the driver doesn't get them
spstarr: well, I posted to LKML but not a single response or confirmation a week ago or so
edgecase: if you cat /proc/interrupts on a working KMS system, you see vid card ones increasing ?
agd5f: spstarr: it's probably stalling because irqs aren't working properly so the driver never gets them so it has to wait for fences to time out
spstarr: agd5f: the only thing that looks odd is 'rescheduled interrupts'
edgecase: maybe put in a debug printf() every time a fence times out?
spstarr: RES: 212213 211401 Rescheduling interrupts
spstarr: is this supposed to rise so quickly?
agd5f: spstarr: yes, but you were gettign them with or without kms
edgecase: lookup what RES: means even
agd5f: spstarr: so they don't seem to be working in general. you just notice it more with kms since the gui uses them
spstarr: so i will report to LKML that im seeing high rescheduled interrupts and here is my hardware info etc
spstarr: same for local timer interrupts (LOC)
spstarr: but i think thats ok
spstarr: my quad core shows nothing like this
edgecase: agd5f, is there an interrupt test at dri or xserver init time? like the CP test?
edgecase: spstarr, what else shares irq line with your vid card?
spstarr: edgecase: i will have to reboot into KMS to tell you in a moment
agd5f: edgecase: no
spstarr: i also want to test again with the intel wifi card disabled
edgecase: i'm seeing it without kms enabled, check /proc/interrupts
spstarr: edgecase: what GPU?
spstarr: brb rebooting
spstarr: my assumption is rescheduling interrupts always happen
spstarr: the quad core has some but its dependent on CPU
spstarr: having being just turned on
spstarr: RES: 269 1834 234 2118 Rescheduling interrupts
edgecase: what's sharing irq line?
spstarr: RES: 250022 251748 Rescheduling interrupts
spstarr: on the quad core?
edgecase: on problem gpu
spstarr: it has a desktop HD 3650
spstarr: oh interesting
spstarr: 0: 283040 294766 IO-APIC-edge timer <-- laptop
spstarr: 0: 41 0 1 0 IO-APIC-edge timer <-- quad
edgecase: cat /proc/interrupts, paste line for gpu
spstarr: brb lemme log out of X to compare
evil_core: Zajec: is your code decreasing clock down to lower limit, or it does it only one time?
spreeuw: present git is failing
edgecase: recompile all as topic says?
spreeuw: did a make realclean / autogen
spreeuw: I compiled yday too
uyf: is it ok to use preemtible kernel for KMS?
spreeuw: those checkouts worked
evil_core: uyf: I am using BFS and it works
uyf: i had to go trough my kernel config, because i forgot to check x86 PAT support and that made the performance drop big
uyf: evil_core: BFS?
spstarr: agd5f: timer
spstarr: agd5f: turn off all devices the timer is flooding the bus
spstarr: on quad core, the timer is not even moving
evil_core: uyf: scheduler designed for desktop
agd5f: spstarr: sounds like that might be the issue
spstarr: 0: 18611 19445 IO-APIC-edge timer
edgecase: spstarr, quad core probably used HPET instead of PIT
spstarr: agd5f: but what timer?
spstarr: egbert: both are HPET this is a dual core
spstarr: thats a quad core
agd5f: spstarr: the timer on the motherboard
spstarr: [ 0.000000] hpet clockevent registered
spstarr: [ 0.240016] Switching to clocksource tsc
agd5f: onteh chipset
spstarr: agd5f: the rtc ?
spstarr: I thought I tried disabling tsc, hpet,
edgecase: spstarr, you realize that linux *needs* a timer?
evil_core: is spread spectrum working for r500 w/o problems?
spstarr: edgecase: yeah to keep a pulse on all devices
spstarr: edgecase: even poll() if you cant use any timer
edgecase: spstarr, grep redeon /proc/interrupts
spstarr: i need to reboot into kms sec
edgecase: see if any devices are sharing the interrupt
edgecase: try it now!
agd5f: edgecase: it's there
edgecase: sorry which is there?
agd5f: edgecase: spread spectrum
edgecase: i wasn't asking about that...
evil_core: agd5f: I was
evil_core: agd5f: Is it working on r500?
agd5f: edgecase: evil_core: whoops
agd5f: edgecase: for most chips. there are some where it it takes a while for the screen to come up
agd5f: when ss is enabled
evil_core: ut then I will get rid of bzzzz... when running glxgears?
spstarr: radeon is not sharing any IRQ
spstarr: 33: 1678 1721 PCI-MSI-edge radeon
spstarr: so the system timer is going haywire
edgecase: spstarr, i see radeon has interrupt even when not using KMS
spstarr: im gonna disable tsc, hpet
edgecase: spstarr, i think system timer can mind it's own business and not affect radeon
spstarr: fallback to the old PIT
edgecase: tsc isn't a timer
agd5f: edgecase: pre-r6xx has interrupts support without kms
edgecase: it's a cpu register
spstarr: its just a sync register?
edgecase: agd5f, oh, and does software use it?
edgecase: spstarr, it doesn't cause interrupts, the TSC
agd5f: edgecase: yes
spstarr: then disable hpet which will fallback to acpi_pm timer
edgecase: so when I enable KMS and things are slow in 2d, it's probably not an interrupt issue?
agd5f: edgecase: no. kms is knwn to be slower at the moment due to unoptimized memory manager
edgecase: if it's not fixed in 5 minutes, i'll just wait longer!
spstarr: [ 4.960114] Switching to clocksource acpi_pm
spstarr: no difference
evil_core: is there patch to change memory clock on r500?
spstarr: the system timer is flooding bus
spstarr: emails LKML
edgecase: spstarr, you should be aware that timer is required, why do you say it's flooding the bus?
edgecase: spstarr, you could try using INTx mode instead of MSI, maybe msi is buggy on your card/driver
spstarr: edgecase: because it is continuing to count up so rapidly and im supposed to be on a tickless kernel
spstarr: tick on-demand
spstarr: i will try to disable MSI then
edgecase: well process switching uses ticks regardless
spstarr: that made no difference though last time i tried
edgecase: tickless just eliminates other sources of ticks
edgecase: not the process switch timer
spstarr: edgecase: but the quad core is not showing the timer tick rising at all
spstarr: CPU0 CPU1 CPU2 CPU3
spstarr: 0: 42 2 0 1 IO-APIC-edge timer
spstarr: local timer interrupts is rising as normal
spstarr: LOC: 223891 201255 209921 220369 Local timer interrupts
edgecase: well rather that focusing on the fact that the timer *is* increasing, maybe you could look at why the Radeon interrupts are *not* increasing
edgecase: that's what's important
spstarr: it's not increasing cause im not using any 3D ?
spstarr: or it should be rising even now you're telling me?
edgecase: i thought you were getting stalls?
spstarr: I get stalls, but i can't tell if I would see them using the 3D engine as 2D mode
edgecase: well i would exercise things, and monitor radeon interrupts rising
edgecase: if it's not rising, maybe you're missing interrupts
spstarr: oh they do rise, but now the radeon is sharing USB and PCMCIA Yenta socket
spstarr: i assume its due to the USB mouse though
edgecase: i think the most helpful would be adding a printf() every time fence times out
spstarr: edgecase: I note this also happens with no KMS
spstarr: so there is a timer issue affecting my laptop/chipset
edgecase: why do you say timer?
edgecase: does radeon driver even use a timer?
spstarr: cause the timer is not supposed to spew so many interrupts so fast
spstarr: worse, tickless is only suppose to fire on demand
edgecase: which is 30 times a second
edgecase: or more
edgecase: without tickless, it's even higher
spstarr: this is doing much more
edgecase: use powertop to find out why
spstarr: and powertop says:
bridgman: quivers in anticipation
spstarr: 63.5% (398.7)
spstarr: 10.1% ( 63.3)
spstarr: 7.5% ( 47.3)
edgecase: rescheduling int seems to be passing irqs between cpus
spstarr: removing the USB mouse:
edgecase: remove the pcmcia/yenta stuff unless you're using a slot
Zajec: agd5f: should this be easy possible to find audio IRQ register?
spstarr: not using it
spstarr: removing those now
Zajec: agd5f: i thought about typing 0xFFFFFFFF to most 73.. registers andwatch for unknown IRQ come
spstarr: PCMCIA removed
spreeuw: hmm whats going on with git
spreeuw: is it me alone?
spstarr: 61.9% (247.6)
spstarr: 12.1% ( 48.6)
spstarr: 8.3% ( 33.4)
spstarr: 8.3% ( 33.4) USB device 6-1 : Microsoft Basic Optical Mouse v2.0 (Microsoft )
spstarr: 5.2% ( 20.8)
spstarr: the wireless i can understand being up there, and that's ok
spreeuw: and now compile errors
spstarr: edgecase: this just does not look right at all
spreeuw: radeon_dri.c: In function 'RADEONDRIScreenInit':
spreeuw: radeon_dri.c:1600: warning: cast to pointer from integer of different size
spstarr: at idle the top 3 are:
spstarr: extra time interrupt, rescheduling interrupts and iwlagn
spstarr: 40.0% ( 62.1)
spstarr: 22.9% ( 35.6)
spstarr: 17.0% ( 26.4)
wsnelr: is it ok that ttm seems to be gone from the latest airlied release? I'm not even sure what it stands for.
spstarr: time to email LKML and ask for help
edgecase: spstarr, what do you hope to find out about timers interrupts?
spstarr: edgecase: what is causing the the flood of the timer
edgecase: why do you think it's flooding?
spstarr: I don't know?
edgecase: how many per second you get?
spstarr: like I said, the quad core shows the main timer (irq 0) not incrementing at all
spstarr: LOC: 37104 38600 Local timer interrupts <-- laptop
spstarr: LOC: 387099 352404 368097 386906 Local timer interrupts
spstarr: thats ok
spstarr: 0: 42 4 1 1 IO-APIC-edge timer
dmb_: bridgman, any news on evergreen stuff yet?
spstarr: 0: 66775 70429 IO-APIC-edge timer
spstarr: you can't tell me this is right
spstarr: installs powertop on quad core
spstarr: edgecase: even on the quad core scheduling interrupts is not even rising
spreeuw: false alarm, my xf86-ati tree got corrupted somehow
edgecase: spstarr, how many wakeups per second in powertop? 30 or less then i don't think timer is going crazy
spstarr: edgecase: way more than 30
methods: anyone tested the gallium code on an rs690 ?
spstarr: 43.1% ( 78.7)
spstarr: 21.0% ( 38.3)
spstarr: 14.7% ( 26.9)
edgecase: spstarr, on my laptop with no optimizations i got 110/s
spstarr: edgecase: but you don't reschedule interrupts for no reason?
spstarr: i thought this is only done when the CPU is unable to process an interrupt in time
edgecase: i don't have SMP so nothing to resched between CPUs
edgecase: IPI = interprocessor interrupt
spstarr: so then this must be a bug in kernel
edgecase: i would assume it's all just normal operation
edgecase: i would focus on radeon interrupts, leave the timer alone
edgecase: how many wakeups/s you get total?
spstarr: for radeon:
edgecase: no system total
spstarr: 16: 12402 11144 IO-APIC-fasteoi uhci_hcd:usb6, radeon@pci:0000:01:00.0
spstarr: runs glxgears
edgecase: in powertop, how many Wakeups-from-idle per second : 116.6
spstarr: *NO* IRQs are being used in radeon
spstarr: with glxgears running?
edgecase: is it stalling?
spstarr: if i move the mouse and click yes
edgecase: you have msi disabled yes?
spstarr: if i move the mouse over the titlebar of glxgears, it stalls a bit
spstarr: no MSI is enabled
spstarr: but radeon is not using it(?)
edgecase: seems not
spstarr: 16: 12716 11453 IO-APIC-fasteoi uhci_hcd:usb6, radeon@pci:0000:01:00.0
spstarr: the rising number is due to USB mouse sharing same IRQ
edgecase: i don't have any msi (bugfree) capable systems to compare with here
wsnelr: spstarr did you mention if your system has tickless interrupts enabled? CONFIG_NO_HZ which is the Tickless System (Dynamic Ticks) config option. I haven't been following your entire conversation, I'm just curious.
spstarr: wsnelr: yeah i have CONFIG_NO_HZ set
spstarr: but the system timer is rising and rescheduling interrupts is also rising for no reasons
edgecase: is DRI doing work in timer bottom half maybe?
edgecase: spstarr, timer is rising *for a reason*
spstarr: edgecase: I booted laptop in single user mode and it was rising also
spstarr: no wifi, no usb
spstarr: just rising out of control
edgecase: the timer?
edgecase: you don't understand, that the linux kernel uses timers constantly
spstarr: timer + RES
edgecase: you can't disable them, even with tickless kernel
spstarr: but TICKLESS
edgecase: doesn't matter
spstarr: its supposed to fire when needed
spstarr: not fire always
edgecase: and it IS NEEDED
spstarr: so then why is my quad core not firing interrupts so much?
edgecase: it's needed constantly by kernel process scheduler
edgecase: how many per second?
edgecase: compare with powertop?
spstarr: hell even my old AMD machine:
edgecase: powertop shows idle constantly?
spstarr: 0: 131 IO-APIC-edge timer
spstarr: 0: 131 IO-APIC-edge timer
mjg59: Why is this conversation happening here?
spstarr: RES: 0 Rescheduling interrupts
edgecase: what about this timer: LOC: 2918230 Local timer interrupts
spstarr: mjg59: im having issues with the timer firing too much and i dont know why causing radeon to stall
soreau: mjg59: I am wondering the same thing
edgecase: i'm trying to convince spstarr that timer interrupts are normal
mjg59: spstarr: Well, I'd recommend getting the first thing fixed before worrying about radeon
spstarr: mjg59: ive emailed LKML about the issue
spstarr: mjg59: i know it has nothing to do with radeon, now.
edgecase: spstarr, in powertop your system is idle 100%?
mjg59: spstarr: Excellent. Then we don't need to talk about it here.
edgecase: heh sorry for the noise then
edgecase: spstarr, i would find someone/somewhere to say what is normal for your timer
spstarr: mjg59: should I turn off PAT?
spstarr: or unlikely to be cause
mjg59: You can, but it won't make any difference
spstarr: might as well try
edgecase: T is for timer
spstarr: ya, no difference
spstarr: I just removed all devices except usb and iwlagn, still happening, so we can conclude it is not any devices doing it
soreau: unloaded all related device modules?
spstarr: just removed usb also both 1.x/2.x
spstarr: and sound
gimzo: Somebody was talking about patches to fix screen flickering on high resolutions on dvi on r700 a few weeks back. Where can those be found ?
wsnelr: spstarr: I wonder if there is any application that will visualize the /proc/timer_list file. Maybe these are the LOC: entries that edgecase was explaining, that the kernel always uses. The system I'm on has a pair of nvidia boards and has been running all day with a LOC: line of 16694957 86779735 Local timer interrupts, which is huge but seems normal.
edgecase: need to write "irqtop" app
edgecase: powertop has some info, but not all
spstarr: wsnelr: oh very nice /proc/timer_list
spstarr: wsnelr: its not local timer thats the problem, it's the system timer (irq 0)
adamk: gimzo: It's in drm-radeon-next.
gimzo: ok, thanks
adamk: gimzo: Or, at least, it was a week ago.
gimzo: I'm just doing a git fetch of drm-something I haven't updated for about a month, so I hope it's there :)
gimzo: is this ok or it has to be radeon-next ?
adamk: gimzo: I do not know if it's in drm-next.
gimzo: ok, I'll check, if it isn't I'll switch to radeon.next
lordheavy: methods: Did you succeed in testing gallium with rs690 ?
spstarr: tries nolapic knowing i cant turn off the APIC cause this is SMP machine
spstarr: ok,so we're now in simple UP mode
spstarr: old PIT timer, nothing else
spstarr: now let's try radeon i want to actually see no stalls now, and I should not see nay
spstarr: I still am seeing stalls
spstarr: oh geez
taiu: spstarr: can you continue somewhere else
spstarr: whois taiu
spstarr: you do understand why im talking about this
taiu: yes, put it in you bug report
spstarr: because im having problems with KMS and the new interrupt code
bridgman: spstarr, I think the prevailing view is that you have a generic interrupt problem, and once that is fixed your KMS-specific issues will go away automagically
wsnelr: spstarr did you try to set a different priority on the Xorg task or the application that you are running? perhaps something else strange scheduling wise is going on, outside the scope of the radeon driver
spstarr: bridgman: indeed, that's what it has come down to now, i mean, using the old PIT timer exclusively is showing same problem, wsnelr doesnt matter with X or without
spstarr: im logging a bug on bugzilla.kernel.org now
spstarr: but rebooting.
wsnelr: I think I was just missing libXinerama and that was messing up my build for xf86-video-ati to get Xorg running. I reverted back to the airlied kernel but was surprised it was all the way back to 2.6.29-rc2. I think I should be able to move ahead again to 2.6.33-rc1 again from the Linus tree
yahoo: hello, can someone give me a hint why my modeline 768x576@50i works with xorg-server 1.6 and with 1.7 is not working?
yahoo: my xorg.conf: http://pastebin.com/m494b988
evil_core: spread s[ectrum patches doesnt aplly :/
evil_core: it says reversed or previously apllied
agd5f: evil_core: they are already in kms
agd5f: evil_core: and they only apply to LVDS
evil_core: but glxgears in non-gallium make noise
evil_core: i got T60p, so its LVDS?
agd5f: evil_core: LVDS is the laptop screen
evil_core: its digital connector?
agd5f: evil_core: yes
evil_core: anyway, where is memory clock patch?
Zajec: agd5f: should this be easy possible to find audio IRQ register?
Zajec: agd5f: i thought about typing 0xFFFFFFFF to most 73.. registers andwatch for unknown IRQ come
AndrewR: wow. after few 'fence timeout's i got my animated radeon bug
AndrewR: (sorry screen mostly unreadable, so just for record. reboot)
agd5f: Zajec: just wait until we review the patches.
agd5f: we'll get the info out eventually
Zajec: agd5f: that's boring ;)
Zajec: (waiting) :)
airlied: Zajec: if it doesn't happen with dynpm off and it does with dynpm on then its a regression
airlied: I suspect reclocking while CP is active or soemthing like that
lordheavy: doo ! cannot boot with kernel 18.104.22.168 => blank screen , out of sync
agd5f: lordheavy: there's patch to fix it on dri-devel
lordheavy: ok will forward it to the distro maintainers
lordheavy: agd5f: where is it ? cannot find it.
lordheavy: agd5f: found it
lordheavy: sorry for the noise
lordheavy: here http://article.gmane.org/gmane.comp.video.dri.devel/41412
spreeuw: are there any recommended kernel settings for radeon concerning irq?
jinzo: hm, I'm having an interesting issue
jinzo: when I upgraded to latest git drivers, my videos started running really fast
jinzo: too fast, any ideas why is this happening ?
spreeuw: jinzo: what player?
spreeuw: sounds more like something kernel related
jinzo: mplayer ( with smplayer frontend )
jinzo: ah, sorry for misfiring then
spreeuw: mplayer uses the rtc kernel variables
spreeuw: for av sync
AndrewR: drm from 2.6.33-rc1 works in AGP 1x mode on my system, right now ... may be i just broke my rv280 over time, or whole system was damaged by bad PSU .... (random hangs/black screens may indicate hw failure, too ...not sure how to differentiate)
spreeuw: echo 1024 > /proc/sys/dev/rtc/max-user-freq
soreau: jinzo: Does it matter which -vo method you use?
jinzo: the two I tried, no
jinzo: spreeuw, no souch file or directory
spreeuw: you should use xv
jinzo: let me search the distros forums
spreeuw: its least problematic and fastest
soreau: spreeuw: I think he needs it to slow down ;)
spreeuw: or has the best ratio between the two
jinzo: I'm on xv now
Zajec: airlied: it does happen with dynpm=0-
soreau: jinzo: Are you sure you dont have it in fast forward somehow? Does it happen when calling mplayer without the front end?
airlied: so just with your patch applied?
Zajec: airlied: i don't believe applying patch can affect anything (without setting dynpm to 1)
Zajec: airlied: it's probably general issue
Zajec: airlied: and my patch maybe make it trigger more often
Zajec: (my patch + dynpm=1)
jinzo: soreau, I played with that ( set it on default ) and it didn't help
soreau: jinzo: Do you have config file in .mplayer in $HOME?
jinzo: hmz, mplayer from command line works good.
soreau: So its probably just smplayer setting
agd5f: Zajec: likely changing the clocks often causes a hang. that's one of the hardest parts to power management
jinzo: soreau, and spreeuw thanks
ernstp: when I build a kernel from drm-radeon-testing, my computer hangs at boot unless I add the R700_rlc.bin file to my firmware
Zajec: agd5f: what do you mean by often? should we pause PM for (for example) 1 second after last change?
Zajec: well, we probably already do
Zajec: more seconds?
agd5f: Zajec: frequently changing the clocks is one of the trickiest parts
Zajec: ouch :|
Zajec: that's weird... i changed engine on my RV620 every 500ms and it didn't cause any problem :/
soreau: ernstp: If you have an r7xx, then what is the problem?
Zajec: agd5f: trickiest... ok, but what about solution?
Zajec: any idea?
agd5f: Zajec: trial and error
ernstp: soreau, well shouldn't there be proper fallback? the code seems broken in this case
Zajec: yeah, sounds horribly without access to machine :/
soreau: ernstp: File a bug then
ernstp: soreau, yeah, I should... :-)
evil_core: Zajec: are you still?
Zajec: evil_core: for a moment yes
evil_core: Zajec: can you rewrite your patch?
evil_core: Zajec: to allow setting clock from userspace
evil_core: it works still on 10000
evil_core: but all looks horrible
evil_core: when glxgers is not running
evil_core: then we would find correct min values for different chips
evil_core: it looked like bad refresh rate
Zajec: evil_core: no reason for that
Zajec: evil_core: we will read that from PowerPlayInfo table in AtomBIOS
Zajec: evil_core: it's what radeonhd does and agd5f is working on this for KMS
DanaG: Does PowerPlay table exist on older cards (especially desktop ones)?
evil_core: Zajec: why for radeonhd, not radeon. Isnt radeonhd driver deprecated?
bridgman: the radeonhd devs partially reverse engineered it
bridgman: they did the work, so it went into radeonhd, seems fair ;)
evil_core: you dont have patch for radeon yet?
evil_core: for r500 its better to use radeon, right?
bridgman: depends on which set of developers you ask ;)
bridgman: radeon focus is on enabling the transition to kms
agd5f: DanaG: pre-atom cards have power tables as well
evil_core: Zajec: can I check this value for mine V5200?
wsnelr: interesting. I passed in a modeset=0 to radeon.ko and bypassed that version 2.0.0 / 1.7.x version requirement message. I was using libdrm from git but maybe not drm-next. In any case my next error now is DGAInit as an undefined symbol from radeon_drv.so. I'm inching closer.
evil_core: laptop is getting very got
evil_core: never was that much hot
bridgman: what are you doing differently from before ?
evil_core: bridgman: I?
dileX_: someone posted on #grub while talking about my gfxterm problems
evil_core: 10MHz GPU clock, some patches for spread spectrum
DanaG: I say that's bollocks. what the hell are you supposed to buy, then?
DanaG: Intel? Suckage.
evil_core: CPU is used by glxgears
bridgman: we probably shouldn't have called the police, I guess
evil_core: lol, glxgears uses 124% CPU
evil_core: by htop
bridgman: "my cpu goes up to 11"
dileX_: bridgman: really, did you?
bridgman: I don't think it was us actually - IIRC the event was at some auditorium and building security called 'em
bridgman: I think we were on the side of letting him stay but nobody is quite sure
Zajec: evil_core: start radeonhd for a moment, it will print all modes from your card
Zajec: evil_core: from AtomBIOS on your card
bridgman: geez, 4pm and the sun is almost down
Zajec: evil_core: you can also try to parse GPU rom with some tool... don't remember name right now
bridgman: you'd think it was the shortest day of the year or something
agd5f: avivotool or radeontool
spreeuw: hmm interesting seems rtc is now kept in dev.hpet.max-user-freq
spreeuw: which is 64 default
evil_core: spreeuw: bot what there should be?
AndrewR: I guess for drm bugs i must use http://bugzilla.kernel.org/ ? (drm ops with benchmark=1 still here)
bridgman: my guess would be to still use the fdo bug tracker
AndrewR: bridgman, under DRI ?
bridgman: just looking now, hold on...
airlied: file them against the DDX or DRI, otherwise we probably won't see them
bridgman: looks like DRI has a DRM/radeon component, which seems like a good candidate
AndrewR: bridgman, #25747
evil_core: anybody can run q3a on drm-next?
evil_core: I got everytime hang with black screen
evil_core: with galkium only galxgears run and xmoto
evil_core: ut2k4 breaks kernel driver in gallium
evil_core: restart is needed
evil_core: restarting xorg causes hardcrash(sysrq not working)
bridgman: it's probably hanging the gpu rather than breaking the kernel driver, isn't it ?
evil_core: rmmod and modprobing causes blackscreen
spstarr: we found the cause
spstarr: it is dynticks
spstarr: nohz=off it stops the timer firing and such, now to test radeon with irq finally
adamk: rnoland_, agd5f: Brian updated Mesa with a fix for the OSMesa build problem relating to sl_pp_context_create. I haven't tried to build libOSMesa yet, but his updates don't fix the sl_pp_context_create error coming from r600_dri.so and swrast_dri.so
adamk: I updated that bug report to let him know.
evil_core: whats the resolution except nohz=off?
spstarr: so if anyone is having IRQ stalls with KMS, try to disable dynticks from grub with nohz=off
rnoland_: adamk: hrm, ok thanks
spstarr: I am still seeing glxgears stalling though
rnoland_: just testing my mmap rework patch on intel....
evil_core: its r500, dunno id if its IRQ
spstarr: agd5f: when im typing with mouse, the gears 'get jerky'
evil_core: rnoland_: fix for mine problem?
spstarr: er typing with keyboard
rnoland_: it seems that getting write-combining set properly doubled or more the framerate of glxgears
rnoland_: evil_core: which issue is that?
evil_core: blackscreen in quake3
rnoland_: evil_core: did you have crap in the ring buffer?
rnoland_: evil_core: no, what was happening was the ring buffer was getting mismapped into the framebuffer on some i386 hardware on freebsd
dileX_: fezie: dm woukd be logo of drogerie-markt trade-chain :-)
rnoland_: so i totally reworked the way that map handles are done
dileX_: wrong channel
spstarr: radeon: 33: 13283 13231 PCI-MSI-edge radeon
evil_core: spstarr: so you say i dont need to recompile kernel, are yoi usure?
spstarr: evil_core: nope, just turn off dynticks at boot time
evil_core: it will fix both non galkium q3 black screen and gallium ut2k4 gpu hang?
spstarr: my timer is now: 0: 48 0 IO-APIC-edge timer
spstarr: so it is clear something is fscked with the kernel and timers on x86_64
spstarr: i will disable MSI now and try radeon again
spstarr: i should not be seeing any stalls
bridgman: evil_core, AFAIK spstarr is talking about a different problem
dileX_: http://marc.info/?t=126138767400002&r=1&w=2 "libdrm_radeon API change". fine, tomorrow seems to be the day to update libdrm, mesa and ddx.
bridgman: he's talking about IRQ issues, you're talking about 3D issues
airlied: adamk: how are you building mesa?
airlied: with autoconf or old static configs?
rnoland_: airlied: we use autoconf
evil_core: anyway I will try nohz
rnoland_: and gmake
evil_core: and will back there
spstarr: still stalls :(
spstarr: so it's not MSI related
spstarr: 68.3% (451.0)
spstarr: 18.9% (125.0) events/0 : worker_thread (delayed_work_timer_fn)
spstarr: 6.2% ( 40.7)
spstarr: 2.6% ( 17.0)
spstarr: this is better
agd5f: spstarr: so it still sound like there is some problem general irq problem on your system
spstarr: but still glxgears stalls on drawing each time i type a character in here when it is maximized
spstarr: agd5f: yeah, they are looking into it (the timers guy @ IBM)
spstarr: agd5f: looks like dynticks is magnifying the problem :)
adamk: airlied: autoconf
spstarr: builds mesa git master
adamk: Have you run out for a bit. be back in a few.
adamk: Oh, at least with Brian's fix, libOSMesa does build here. Unfortunately, I don't know if that was the case before his fix, and can't test it now.
spstarr: agd5f: assuming it is general irq problem, you don't think radeon IRQ code is firing too much?
agd5f: spstarr: why do you say that?
agd5f: it fires when it needs to
airlied: it only fires when we are waiting for it
evil_core: now it sits in C0 all the time :/
evil_core: quake3 still blackscreen
spstarr: what is interesting is this though: 9.6% ( 10.0)
spstarr: the HDMI sound stuff on the radeon
spstarr: powertop shows it as #3 offender in wakeups
agd5f: spstarr: that timer can be removed when we add irq support for hdmi
spstarr: ah ok
spstarr: I don't suspect thats playing into any of my stalls
agd5f: spstarr: not likely
spstarr: agd5f: is there a option to turn off hdmi?
spstarr: just to test
agd5f: spstarr: audio=0
airlied: could we make it dpeendant on having hdmi active?
agd5f: spstarr: but you've been complaining about this long before hdmi support was added
agd5f: airlied: yeah
spstarr: yeah so it's unlikely
spstarr: so i wont bother
evil_core: nohz didnt helped for nothing
gimzo: I'm trying to build drm-radeon-next but when I try to boot it radeon module crashes
mkoco: are there errors?
bridgman: evil_core, spstarr is working on a totally different issue from you
bridgman: IRQs vs 3D
evil_core: but what I can do?
lordheavy: evil_core: try to run q3 inwindow mode, from a terminal to see errors messages (window mode will avoid you lock due to sdl fullscreen)
mkoco: when I startx, there is (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r300_dri.so failed (/usr/lib/xorg/modules/dri/r300_dri.so: No such file or directory)
mkoco: but that modules exists in /usr/local/lib
mkoco: how can I tell X to look there?
evil_core: lordheavy: I pasted ut2kt gallium problem
bridgman: first thing I would do is ask what apps the devs believe to work on gallium3d and try those first
evil_core: thatbreaks driver
jcristau: mkoco: you don't afaik
evil_core: or liek spstarr told hangs gpu not driver
mkoco: lordheavy: thanks
evil_core: quake3 is killable with -4 w/o gallium
jcristau: lordheavy: X isn't libGL
lordheavy: ldconfig so ?
dileX: airlied: remember our discussion pr_* vs printk(KERN_*)?
lordheavy: ModulePath "/usr/local/...." inxorg.conf perhaps
lordheavy: in section "Files"
rnoland_: agd5f: what is the status of display port stuff?
airlied: rnoland_: should be all merged
rnoland_: in the ddx?
airlied: UMS has no support for replug/hotplug
rnoland_: but should work with randr right?
agd5f: rnoland_: works in ddx and kms
agd5f: rnoland_: yeah
rnoland_: ok, thanks...
rnoland_: you know what ddx is needed?
airlied: rnoland_: git
rnoland_: ok, thanks.
xmikos: Hello, is there anyone using Arch Linux with PKGBUILD for stable kernel + drm-radeon-testing? Or should I make new one?
bridgman: aw nuts, I missed FUDcon
bridgman: reading adamw's blog looks like lots of people were up in Toronto
bridgman: and Seneca is about a mile south of our office
xmikos: Anyone? I guess I will have to make a new PKGBUILD :-)
xmikos: Btw. what is the difference between drm-radeon-testing and drm-radeon-next?
airlied: xmikos: one has testing patches and one has slightly more tested patches
xmikos: And which one is pulled by Linus, drm-next or drm-linus?
dileX: xmikos: drm-linus
agd5f: pushed the newer power table defs
rolling1: buona sera a tutti
xmikos: dileX: Ok, so what is the difference between drm-next and drm-linus? Sorry for stupid questions, there is really a lot of branches :-)
rolling1: se ci fosse qualcuno che parla italiano in grado di darmi una mano ve ne sarei grato
jcristau: dave explained that recently on dri-devel..
Zajec: agd5f: :)
Zajec: agd5f: what is USHORT usVoltageTime; // in microseconds ?
agd5f: Zajec: likely the time you need to wait after changin voltage before changing sclk
lordheavy: xmikos: http://article.gmane.org/gmane.comp.video.dri.devel/40626
glisse: /win 1
bridgman: presumably you reduce the clock *then* reduce the voltage, so I guess VoltageTime would be the time between *raising* voltage and raising clock ?
Zajec: agd5f: some info about ATOM_PPLIB_R600_FLAGS_* please? _PCIEGEN2? _BACKBIASENABLE? _MEMORY_ODT_OFF? _MEMORY_DLL_OFF?
agd5f: Zajec: ignore them for now
agd5f: don't really need them at the moment
Zajec: bridgman: http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/tree/src/rhd_pm.c?id=ffc141e2 "If Voltage is to be rised, then do that first, then change frequencies. \n If Voltage is to be lowered, do it the other way round. */"
Zajec: agd5f: do you release drm parser as well?
agd5f: Zajec: workign on the kms patches. almost there
Zajec: PM, HDMI and we are feature-complete I guess :)
xmikos: lordheavy: Thanks, that's great explanation. But there isn't explained relation between e.g. drm-next and drm-linus, can anyone shed some light on it please?
airlied: drm-next is for the linux-next kernel
airlied: it gets recreated from my tree + intel + radeon + nouveau trees
spreeuw: evil_core: 1024 for some a/v apps
evil_core: spreeuw: but wil it drain battery quicker?
spreeuw: dont know but its not the HZ thing
spreeuw: of the kernel ticker
yangman: ooo, temperature sensor stuff in there as well
evil_core: yangman: where?
yangman: evil_core: part of the power table update
evil_core: code fir pm is ready?
evil_core: quake3 doesnt work in window
spreeuw: ut2k4 remains rock stable and eyecandy on r600
spreeuw: a little fps doubling would come in handy
bridgman: spreeuw; LIBGL_TWICE_AS_FAST=1
evil_core: spreeuw: with gallium?
mkoco: join #nvidia
spreeuw: bridgman: thanks for the tip, it's actually working!
spreeuw: evil_core: no KMS / dri2 r600
xmikos: Does anybody know why Plasma panel in KDE 4 isn't transparent with kernel 2.6.32 + latest (today from GIT) libdrm, mesa and xf86-video-ati (even if OpenGL composite works and alpha transparency in other apps also works)?
[Enrico]: bridgman: you know i just told a friend about LIBGL_TWICE_AS_FAST=1 , he believed me so he tried nexuiz with that and he said: "well 2.7 fps more than without, better then nothing" rofl
bridgman: Enrico; tell him to take two placebos and call me in the morning
[Enrico]: bridgman: sure doctor :D
xmikos: It did work with stable libdrm 2.4.16 + mesa 7.6 (but I had hard X server crashes with it, now it seems that crashes are gone but alpha transparency in Plasma is broken)
xmikos: Btw. I have RS690
xmikos: (mobile version)
xmikos: Anyone please? Or I am too late here and everyone slready sleeps? ;-)
bridgman: xmikos, don't think anyone knows
bridgman: there have been a couple of detection-related issues with kde recently, not sure if this is another one of those
wsnelr: Well I'm recompiling xorg-server with --enable-dga explicitly set, instead of on auto. I'm not really understanding where DGAInit exists but when I ran Xorg last time there was a complaint about radeon_drv.so not being able to find it.
TBBle: Using last night's head build of libdrm, radeon and drm-radeon-testing, X is kicking me back to xdm randomly. Didn't notice it happening yesterday with the same kernel, but older libdrm and radeon builds. Is this a known problem, or should I go bisect it?
edgecase: can you get a backtrace?
agd5f: TBBle: might make sure mesa is built properly. some people were having issues with the latest libdrm api changes
TBBle: I'm not even seeing a crash in any of the logs.
TBBle: Oh, I didn't rebuild mesa. >_< I'll go update that now.
Zajec: [Enrico]: can you ask him to try LIBGL_FOUR_TIME_FASTER=yes ? :)
[Enrico]: Zajec: rofl someone else asked for LIBGL_THREE_TIME_FASTER he said it is worste than DOUBLE
[Enrico]: you got a lot of laught :D
[Enrico]: Zajec: i see the powersave patch is improving ( i occasionally follow the ml) congrats
[Enrico]: Zajec: i began to be impatient and see it in master :D (i love to see a good job at work)
Zajec: [Enrico]: we should get something nice as agd5f release his parser for AtomBIOS PowerPlayInfo :)
Zajec: yeah, me too :)
Zajec: ok, that's too late for me... night :)
[Enrico]: very good, i hope it will be soon, so i will switch to kms full time :D
mkoco: adamk: Thanks for all the help :D
hbock: just bought a thinkpad advanced mini dock
hbock: radeon detects the DVI-D output correctly, but the display is garbage
hbock: VGA and LVDS outputs are fine
hbock: http://spanning-tree.org/~hbock/Xorg.0.org logs look fine, anything I can do to help track this down?
Ghworg: There is a bug in mesa src/mesa/drivers/osmesa/Makefile "$(TOP)/src/glsl/cl/libglslpp.a" should be "$(TOP)/src/glsl/pp/libglslpp.a"
TBBle: Pull again.
TBBle: It's been fixed
TBBle: Right, here's hoping the mesa update fixes X dying.
Ghworg: is crossing the libdrm api change barrier
TBBle: "(EE) AIGLX error: Calling driver entry point failed" is there any way to get more information about what failed?
TBBle: On a side-note, I'm amused to see that DRI swrast reports "direct rendering: yes" in glxinfo. I didn't expect that...
TBBle: And it turns out it wasn't a too-old mesa issue...
TBBle: So, any suggestions on diagnosing these sudden X kick-outs? I'm hoping I don't have to bisect the driver, since I'm coming from pre-2.4.17 to post-2.4.17 libdrm, which means bisecting around the API changes to libdrm-radeon1.