AstralStorm: I bet this is a bug in the command stream parser ;) it has worked before
DanaG: How can I get my GPU into low-power mode on the open-source driver, with KMS?
taiu: AstralStorm: the packet3_check error is due to kernel cs parser updates
taiu: it requires reloc for this register, which older mesa does't send
AstralStorm: which is the first version that supports this?
taiu: I guess kernel change is http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=a39533b4ddad388b64a20bcabd17ac125fd4ba65
MostAwesomeDude: Which reg is needing the reloc?
AstralStorm: no idea
MostAwesomeDude: Oh, those.
AstralStorm: want the fragment program?
MostAwesomeDude: Yeah, that's a Good Thing.
taiu: and mesa http://cgit.freedesktop.org/mesa/mesa/commit/?id=74ef3207d8bd97a529e7b0ab8d99e44c805f3af0
AstralStorm: ok, so I'll start with that as the reference
taiu: not sure i followed it all :) what fp?
AstralStorm: the one from mplayer gl:yuv=4
AstralStorm: really basic
MostAwesomeDude: Er, those changes affect all shaders, not justsome.
AstralStorm: exactly, like I thought
DanaG: sorry, was feeling random.
EruditeHermit: is it possible to update video bios?
AstralStorm: nothing uses it
AstralStorm: so, why would you want to
cxo: well i did
cxo: I reflashed it with a different fan profile and clock speeds
EruditeHermit: drivers sometimes use information from it
cxo: there is also a tool for flashing cards on linux
EruditeHermit: just wondering if mine is corrupted
AstralStorm: taiu: your picked commit still fails with reloc
cxo: forgot its name, phoronix did an article on it
AstralStorm: or maybe not, wait
AstralStorm: my bisect tree is futzed
MostAwesomeDude: cxo: Please don't ask for help with the free drivers if you've flashed your card.
MostAwesomeDude: We can't help you.
MostAwesomeDude: At all.
cxo: Huh? How come?
AstralStorm: 90692486aa79452c6421041b4b7e7f34857e3278 - fails
MostAwesomeDude: cxo: Consider that the driver needs to read the VBIOS to know how to program the card.
AstralStorm: taiu: so, your idea of CS parser changes is incorrect :/
MostAwesomeDude: If the VBIOS changes, then all bets are off.
AstralStorm: MostAwesomeDude: for what? EDID info?
AstralStorm: uhm CRTC I meant
MostAwesomeDude: AstralStorm: For nearly everything. Modesetting info, like EDID reading, PLLs, CRTC setup, etc.
cxo: MostAwesomeDude, yeah, so? Its not like I changed the bios. Its still the same ati bios
MostAwesomeDude: But also safe memory controller setup, memory speeds, PCI lanes, fan speeds, etc.
taiu: AstralStorm: no, it's just you have to have both kernel and mesa earlier than respective commits or both later than these
MostAwesomeDude: cxo: No, ATI doesn't make the BIOS.
AstralStorm: taiu: ... both later, fails.
AstralStorm: cxo: the card manufacturer does
MostAwesomeDude: The board assembly people made the VBIOS. Sapphire or HIS or whoever put the chip on the board.
AstralStorm: it depends on output wiring, for instance
taiu: AstralStorm: hmm, i'll try later today ...
AstralStorm: and the clocks used
AstralStorm: (for output mostly, PLLs can be adjusted)
cxo: is confused
AstralStorm: cxo: that info depends on hardware on the card
AstralStorm: not just the GPU
AstralStorm: so if you flash a VBIOS from another card, it might not fit
AstralStorm: now, the company might've used the reference design
AstralStorm: but that's definitely not certain
cxo: So how would it work at all if it didnt "fit"?
AstralStorm: maybe, maybe not
AstralStorm: it depends on how much stuff "fits"
cxo: I'm just trying to understand what "unfitting" (obviously non-critical) elements, would cause the free drivers to not work properly?
AstralStorm: and not work properly in various ways
AstralStorm: bad CRTC info will cripple modesetting and screen selection
AstralStorm: (or make it not work at all)
cxo: but CRTC is not hard coded in the bios?
AstralStorm: bad memory setup = explosions
AstralStorm: cxo: define hard-coded
MostAwesomeDude: Example: The memory controller has a set of clock speeds. You flash on a VBIOS with a different set of clock speeds. You try changing the power-saving mode; card locks up or maybe dies.
AstralStorm: cxo: it's as hard-coded as flash is
MostAwesomeDude: *Nothing* is hard-coded. The VBIOS is technically firmware flash; you can unlock and flash it with the right tool.
cxo: but wont the power saving mode, change the clock accordingly and override the default clock?
MostAwesomeDude: No, the HW has no protection against these things.
AstralStorm: no, it changes PLL setting
MostAwesomeDude: Because it was not designed to be flashed.
cxo: No not protection
AstralStorm: not the clock directly
cxo: How would that lock up the card?
AstralStorm: see, it changes the PLL divider and multiplier
AstralStorm: to change the clock
cxo: the driver?
AstralStorm: if the clock is different, the card will start with wrong divider/multiplier
EruditeHermit: airlied, hey you about?
AstralStorm: and magic smoke might come out ;p
EruditeHermit: quick question about merging drm-next into the kernel
cxo: but doesnt the driver read the clock from the card, before it starts dividing it/messing with it
AstralStorm: EruditeHermit: drm-linus branch. that's all.
AstralStorm: cxo: read from where?!
AstralStorm: cxo: the VBIOS.
EruditeHermit: AstralStorm, what do you mean?
AstralStorm: which you've just flashed with wrong info.
cxo: How is it wrong?
AstralStorm: EruditeHermit: take drm-2.6 git repository, drm-linus branch
cxo: The card is running at the clock, it was flashed to run at
AstralStorm: EruditeHermit: that tracks drm-next... usually, and is based on 2.6.32-rc
MostAwesomeDude: cxo: The driver reads a bunch of instructions from the VBIOS and programs the card according to those instructions.
MostAwesomeDude: When you flash the card, you change those instructions.
EruditeHermit: AstralStorm, do you know the git clone command for that?
cxo: I still dont get how this should affect anything
MostAwesomeDude: And if those instructions don't match up with the actual HW on the card, then the card does undefined things.
MostAwesomeDude: Like lockup. Or go melty.
cxo: Ok i get that
AstralStorm: EruditeHermit: git clone
AstralStorm: then git checkout -b origin/drm-linus
cxo: So whats an example of an instruction that would cause that scenario?
AstralStorm: git checkout -b drm-linus origin/drm-linus
MostAwesomeDude: The memory clock, which is changed when changing power-saving modes.
AstralStorm: cxo: wrong "clock" value
cxo: That doesnt make any sense
cxo: The memory clock taken from the bios, is the memory clock
AstralStorm: I mean the GPU could actually... measure the clock ;p
AstralStorm: and set PLL properly, but that's overkill
MostAwesomeDude: AstralStorm: That's the RHD classic technique.
MostAwesomeDude: And it works, if you care to create code to bring up *every single board*.
MostAwesomeDude: Oh, it also depends on VBIOS to identify the card. :3
cxo: This is sounding worse than corporate FUD
AstralStorm: the GPU version, yes
AstralStorm: although that is possible to implement in the driver with educated guessing ;p
AstralStorm: (like before AtomBIOS days)
AstralStorm: or just force the right setting
AstralStorm: the most variable info is the CRTC
AstralStorm: and memory controller setting (since different manufacturers use different memory chips)
cxo: Well then the card wouldn't work at all
EruditeHermit: AstralStorm, there are drm-2.6 repos for different people on there
EruditeHermit: which one is it?
AstralStorm: EruditeHermit: airlied's
EruditeHermit: many thanks
AstralStorm: well, I'm out of ideas and am about to suspect the kernel to have broken my -vo gl:yuv=4 ;)
AstralStorm: (which means drm-linus latest)
EruditeHermit: AstralStorm, you said that tracks drm-next. Does it actually have all of drm-next?
EruditeHermit: AstralStorm, or should I merge that in?
AstralStorm: yes, it has all of it right now
AstralStorm: why the heck is it checking for NOP there
AstralStorm: I mean, it's !PACKET_TYPE3 || !PACKET3_NOP
AstralStorm: so, suppose it's PACKET_TYPE3 but not NOP
AstralStorm: then the check explodes
AstralStorm: say, the first relocation failed
AstralStorm: which debug should I enable to see what really happens there, since it's definitely now a drm bug
AstralStorm: something doesn't like the ring base, somehow
AstralStorm: http://cgit.freedesktop.org/mesa/mesa/commit/?id=a176b1c5d8b14601ec7e6ca9599c55fcc4797a7d - this might be the smell
AstralStorm: it's the recent commit touching CS
cxo: god its late...
AstralStorm: or early ;)
cxo: didnt even notice the time, 2:04am
airlied: EruditeHermit: hey? the link in the wiki page should explain how to get drm-next or drm-linus
honk: and the differences between those ;P
airlied: at the moment drm-next contains some non-radeon patches for 2.6.33
airlied: drm-linus is for 2.6.32
EruditeHermit: airlied, I tried the wiki, but it had merge conflicts
EruditeHermit: ah that was with 2.6.31 though
EruditeHermit: I didn't try the drm-next instructions
EruditeHermit: ah well
EruditeHermit: its already built
airlied: as long as the patch applies
EruditeHermit: yeah it did
airlied: and it was broken before it, it should be fine ;-)
EruditeHermit: it complained about whitespace issues
airlied: I've no idea if it'll fix it, its just a first guess
EruditeHermit: the wiki explains drm-next
EruditeHermit: but not drm-linus
EruditeHermit: just fyi
EruditeHermit: but I'll use the instructions for drm-next on my next build
EruditeHermit: i'll test the patch in a few mins =)
EruditeHermit: I am excited
ahox: Hi, 3D acceleration with the radeon drivers is awfully slow, any idea what could cause this/how to fix it?
zhasha: ahox: what does `glxinfo | grep renderer` say?
ahox: OpenGL renderer string: Software Rasterizer
zhasha: there's your problem
ahox: thanks for the hint, doesn't sound to good - so how do I change it?
zhasha: can you paste your /var/log/Xorg.0.log for me?
hifi: HD 3600 XT, how new is your system?
zhasha: that's a new one :/
zhasha: (the error)
ahox: its about 6mth old, a HP workstation
zhasha: I wonder if you need a newer DRM
hifi: I meant your linux distribution :)
ahox: my drm is 2.4.14 on a kubuntu 9.10 - so the dist is pretty new
zhasha: if I had an r600, I'd be using catalyst
ahox: (and suboptimal for kde, I know...)
chithead: for drm on r600 cards, you need kernel 2.6.31 and recent enough libdrm. for 3d you need kernel 2.6.32_rc1 and mesa from git
ahox: I tried the catalyst, but it crashes hard on me
chithead: mesa r600 works very well with kde desktop effects
ahox: my kernel is the 2.6.31, so how stable is the rc1?
ahox: I am not too inclined to experiment here because it's my office pc
chithead: using rc kernels in production environments is not recommended
MostAwesomeDude: agd5f: I'm due for sleep, but here's MRTs in r300compiler. Still WIP, but a step in the right direction. http://cgit.freedesktop.org/~csimpson/mesa/log/?h=r300g-draw-buffers
zhasha: mrt = multi render targets?
osiris_: airlied: where should I put the bo_is_referenced function? in radeon_bo_funcs or radeon_cs_funcs?
ahox: sry, I was just afk. So is 2.4.14 new enough?
cire: Is it possible to determine whether a "git pull" updated some files, or repo was up-to-date? And second: Do I have to "make clean" when something changed to get all changes compiled, or is this recognized automagically?
cire: To my first question: I tried it via returncode, but when an update was successful, or it was up-to-date, in both times I get "0" as return code...
Ghworg: cire: Changes to the code get recompiled automatically when you rerun make. If the build files themselve change you might need a clean
cire: Ghworg: thanks. In that case I won't need any return code for git. May I check whether build files changed somehow?
Ghworg: cire: Generally just running make is fine. If the build fails then try a clean then rebuild
cire: Ghworg: okay, since make will throw an exit stats != 0 when build failed, I can work with that. Thanks for your help.
Nightwulf|work: hi all
dileX: hi Nightwulf|work
Nightwulf|work: hi dileX
osiris_: fpoibaf: do you know some games that are very slow when you enable some graphical effects?
hifi: I know half-life is overall very slow
osiris_: hifi what gpu do you have?
hifi: still RV570
fpoibaf: osiris_: with sauerbraten on a certain maps fps go very low and I also get texture corruption, see https://bugs.freedesktop.org/show_bug.cgi?id=23545
osiris_: fpoibaf: anything else than sauerbraten?
osiris_: hifi: try it with my patches from r300-blit branch
fpoibaf: the game panzers II under wine, is very slow, this is a closed source game and the demo does not run under wine
hifi: osiris_: what do I currently need for that branch?
hifi: I'm running ubuntu lucid toolchain
hifi: osiris_: also does it work with KMS?
osiris_: hifi: I'm developing it on KMS, so actually I don't know if it works on UMS
osiris_: hifi: you just need one patch for libdrm
hifi: and your work is in mesa?
osiris_: hifi: here's the patch for libdrm http://pastebin.ca/1666444
osiris_: hifi: yes, the r300-blit branch is mesa
hifi: and I love you so much if your patch finally gets me out of windows xp
hifi: it's been horrible and sad to look at the windows desktop :(
hifi: I need to look at it later today, currently at work, thanks anyway for the hope :)
fpoibaf: osiris_: $ git clone git://anongit.freedesktop.org/~osiris/mesa mesa-osiris
fpoibaf: Resolving deltas: 100% (231448/231448), done.
fpoibaf: warning: remote HEAD refers to nonexistent ref, unable to checkout.
osiris_: fpoibaf: run "git checkout -t origin/r300-blit -b r300-blit" now
hifi: osiris_: thats a highly probable fix for half-life rendering slow?
osiris_: hifi: yes
hifi: nice, can't wait to test it out
hifi: hm, I *do* have a quad core radeon at work...
osiris_: hifi: it makes half life 2 work (at least the menu so far)
osiris_: hifi: it is r500 only for now
fpoibaf: ok, thanks, the libdrm patch is needed when testing your branch without KMS?
hifi: osiris_: so it applies for me then
osiris_: fpoibaf: yes (unless you don't have libdrm_radeon in your system)
hifi: the board at work is also R5xx
fpoibaf: I have libdrm_radeon, and compile with it but I use a UMS kernel, so I shouldn't need it?
fpoibaf: it->the libdrm patch
osiris_: fpoibaf: no, the patch is not needed when you don't have libdrm_radeon (doesn't matter whether you're using UMS or KMS)
osiris_: fpoibaf: so you have to patch the libdrm
fpoibaf: ah, ok I will do that
osiris_: fpoibaf: also there may be bugs in UMS mode, I haven't tested it yet on UMS
fpoibaf: ok, I will let you know of them if I'll find some...
hifi: osiris_: btw. would it also speed up the slow netgraph with quake 2?
hifi: or was it a separate issue
osiris_: fpoibaf: also be aware that there are a few regressions after texformat-rework branch got merged
osiris_: hifi: what does it use to render the netgraph?
fpoibaf: osiris_: I am aware I just filed a bug yesterday: http://bugs.freedesktop.org/show_bug.cgi?id=25016
hifi: osiris_: I can't remember anymore, but it did change between textured and non-textured(?) mode between every draw or something like that
hifi: for a single line
hifi: and with a screen width of 600 pixels it did that 600 times per frame
osiris_: hifi: it's worth trying
hifi: I so want to get back home to test it out
osiris_: hifi: other games like portal, tomb raider legend, prince of persia are starting to work
osiris_: well not fully, but it's a progress
hifi: appreciate your work
osiris_: appreciate your testing
hifi: if it's even close to finally speed up hl, I'll test every commit you do :)
fpoibaf: osiris: applied libdrm patch and recompiled, compile your r300-blit mesa and run panzers II: crashes with http://pastebin.ca/1666502
fpoibaf: it works fine (albeit corrupted) with mesa master
osiris: fpoibaf: try with kms
fpoibaf: I'll try...
[Enrico]: mhm on my r200 (agp 4) if i start the system without kms i get some screen corruptions.... i'm using the xf86-video-ati shipped with archlinux so 20091014 git. is this a known bug?
fpoibaf: osiris: with KMS it works fine (I am still getting the corruption that I have with mesa master)
fpoibaf: it's also a lot faster now, even if it was already faster with KMS vs UMS with mesa master
Kaapa: hey there, simple question (I think). when I try to put dual-head in left of I get xrandr: screen cannot be larger than 1280x1280 (desired size 2560x1024)
Kaapa: But I have a virtual line on my xorg.conf
Kaapa: any ideas?
fpoibaf: tested with kernel 2.6.31 from ubuntu with radeon.modeset=1
fpoibaf: btw 2D with KMS is very slow (especially scrolling)
agd5f: MostAwesomeDude: looks good
riri: hi, is it possible to specifiy driver options without xorg.conf ?
Kaapa: found it
osiris: fpoibaf: good :)
osiris: fpoibaf: yeah 2d is slower
agd5f: fpoibaf: try commenting out line 308 of radeon_dri2.c in the ddx: info->accel_state->vsync = TRUE;
agd5f: that might improve performance at the expense of tearing
fpoibaf: agd5f: I'll try
osiris: fpoibaf: KMS is slower is 3d too, so when I'll make it work in UMS the game will run even faster
fpoibaf: osiris: ok, thanks for all these improvements!
riri: Kaapa, what was the problem ?
riri: if one day I've the same one :)
fpoibaf: agd5f: I tried it but it's still slow, maybe moving the text cursor is a little faster (it lagged before)
Kaapa: riri: the Virtual line on xorg.conf was.... commented :p
fpoibaf: osiris: since I noticed the commit "radeon: workaround for #22742"
fpoibaf: i tried prey (with KMS) but it stuks, I killed -9 it and I got this:
fpoibaf: osiris_: ^
agd5f: taiu, MostAwesomeDude, ossman: richard posted his glsl branch: http://cgit.freedesktop.org/~richardradeon/mesa/log/?h=glsl
ossman: I'll have to have a look at that when I have some time
ossman: agd5f, any updates on interrupts?
agd5f: so far just loops and if/else/endif
agd5f: ossman: still waiting for approval
hifi: osiris_: if I have libdrm-radeon version 2.4.15+git20091107, is it enough for your mesa branch?
fpoibaf: hifi: no, you should compile with patch at http://pastebin.ca/1666444 which it isn't yet on git drm git master
hifi: osiris_: with your patches my xorg halts and my monitor shuts down
hifi: I can reboot over ssh, I see no errors in dmesg or Xorg.log
hifi: that happens when I try to start a game
hifi: glxgears runs fine
hifi: and just btw. it did it without the libdrm patch and with it
hifi: oh, libdrm didn't build/install correctly
hifi: osiris_: it did speed up netgraph drawing and KMS 3D overall with quake 2
hifi: no help with half-life though
hifi: and yeah, hl2 seems to work a lot better
osiris_: fpoibaf: looks like it's stuck on another assertion
hifi: osiris_: are the from/src/dst debugs from your patch?
hifi: damn, I don't get any of those with hl1
hifi: and I can't get d3d renderer to work with hl, only opengl
osiris_: hifi: so what's broken in hl1?
osiris_: crash or rendering errors?
osiris_: hifi: cany you profile it?
hifi: didn't you have hl1?
osiris_: hifi: I do, but it crashes for me
hifi: really? it has worked for me all the time
hifi: which renderer did you use?
hifi: hl1 defaults do d3d which doesn't work too well
osiris_: hifi: looks like it was wine problem. I've installed newest wine and it works now
hifi: try both renderers, opengl and d3d
osiris_: hifi: both work
osiris_: hifi: but d3d is slower
hifi: and opengl isn't fast enough for sure
osiris_: hifi: works fine here
hifi: if you have counter-strike, run around de_aztec
hifi: fps drops down to 30-40
hifi: resolution or settings won't speed up
hifi: small hallways like most of half-life itself isn't really stressing the graphics stack
osiris_: hifi: cs crashing during level load
spreeuw: hifi: bad map?
spreeuw: many amateur maps are not balanced out well
spreeuw: to play properly the lowest reached fps must be higher than the screen refresh
spreeuw: so thtas timedemos of 200fps +
kdekorte: osiris_, just as an FYI I rebuilt mesa today and neverwinter run fine on r6xx now.. I think it was a local build issue
osiris_: hifi: is the quake2 playable now with the netgraph?
glisse: agd5f: in r600 vtx resources dword1 size is unused ? does it need some activation in other reg ?
glisse: or setting 0 implicitly disable the feature
hifi: osiris_: I think so
hifi: spreeuw: de_aztec is a stock map
hifi: and anyway, it shouldn't be a problem with this good graphics card how many extra polygons a map from 10 years a go had :)
glisse: agd5f: also what is mem_request_size
glisse: dword3 of vtx resource
agd5f: mem_request_size is fetch optimization
agd5f: size is uses
agd5f: it's the size of the vertex in bytes-1 IIRC
glisse: i saw size of 0 in some stream
hifi: osiris_: crashes with both renderers?
hifi: I only had crashing/hanging with d3d
osiris_: hifi: yes, both are crashing
glisse: agd5f: my brain p4 parser hanged ;d
glisse: according to doc size should be the size of the vertexbuffer
glisse: so it should help a lot for cmd checking
spreeuw: hifi: moa only with my r600 now quake3 is a little playable
agd5f: glisse: yes. size of the vb. see r700SetupVTXConstants() in mesa driver
spreeuw: looks quite ace on 1280x960 with hq textures
agd5f: glisse: if you see 9, probably a bug
agd5f: sorry 0
spreeuw: noticed ioquake has some nice new weapons
spreeuw: mines and nailguns
glisse: no it was mean ill parsing the stream
spreeuw: hadnt noticed them before
glisse: my brain did miss a dword
Ghworg: When I set wine to use fbo for OffscreenRenderingMode I hit the "radeon_cs_gem.c:121: cs_gem_write_reloc: Assertion `bo->space_accounted' failed.".
Ghworg: With it set to backbuffer it works fine though.
Ghworg: Is this something worth opening a bug about?
glisse: Ghworg: should be fixed now
Ghworg: Okay, cool. Will go grab the latest git. Thanks
Kaapa: airlied: the new kernel with drm-next is not available yet, right?
Kaapa: anyoen knows of a way to configure hal to automatically connect the external monitor on connection?
kdekorte: Kaapa - gnome-display-properties should do it
Kaapa: I don't use gnome
Kaapa: was hoping for a more system-level answer
Kaapa: after all this is a xrandr call
Bigshot_: i want to enable desktop effects i am using open source ati driver xf86-video-ati for Radeon HD 3200 card, when i start to enable desktop effect i get logged out
Bigshot_: do i need to use xf86-video-ati-git for it?
adamk: Bigshot_: You either need to install development drivers (which no distribution currently ships with, so you will have to compile them yourselves) or you will have to install the fglrx driver.
Bigshot_: i am using 2.6.31 kernel
Bigshot_: fglrx won't do
adamk: Then you will have to start compiling code.
adamk: Check the wiki in the topic.
Bigshot_: how much time will doing all this take?
adamk: Depends on how much experience you have and how smoothly it goes.
adamk: It can be a matter of minutes, but I've also seen people on here for hours (even days) trying to get things working.
MostAwesomeDude: The more experienced you get, the quicker it goes, as you learn what works and what doesn't.
MostAwesomeDude: And then eventually you get lazy like me and just use F12. :3
adamk: Does F12 ship with the r6xx driver?
taiu: I'v heard it's available by installing some experimental package
Bigshot_: cool where taiu
adamk: Bigshot_: They were talking about for F12, but you are using opensuse, right?
muep_: adamk: by default there's a driver for r600 stuff, but the DRI driver isn't installed as default
muep_: adamk: so you don't get opengl acceleration before you install mesa-dri-drivers-experimental
Bigshot_: adamk: yes any dice?
adamk: Bigshot_: I see no option other than fglrx or compiling the driver from git.
Bigshot_: does 2.6.31 kernel support fglrx?
kdekorte: MostAwesomeDude, Fedora 12 does ship with r6xx, you just have to enable it by installing mesa-dri-drivers-experimental
kdekorte: to get 3d, 2d + KMS is out of the box
stikonas: I think that mesa-dri-drivers-experimental contains relatively old r6xx driver
muep_: what do you mean by relatively old?
muep_: at least it seems to work here quite fine
kdekorte: stikonas, there is a package in koji that is only a week or two old now...
stikonas: ah, maybe ot was updated
stikonas: I thought that they still ship mesa 7.6 in that experimental
kdekorte: not sure it has been put in any update yet, but I expect it soon after the F12 release
Bigshot_: does 2.6.31 kernel support fglrx? adamk
kdekorte: Bigshot_, might ask in #ati
adamk: Bigshot_: No idea. I don't use fglrx any more.
kdekorte: fglrx is banned from my systems
Ghworg: glisse: Nope not fixed, still getting the assertion with latest code
DanaG: weird... Xorg is getting stuck in a loop.
DanaG: But only when KMS is enabled.
airlied: osiris_: not sure where the is reference makes more sesne
airlied: its probably bo
Ingmar: Where should I send a patch to xf86-video-ati?
osiris_: airlied: why do radeonTexObj and radeon_texture_image have bo field? isn't the miptree enough?
airlied: osiris_: not for TFP
airlied: since pixmaps don't really have a miptree
airlied: and I didn't feel like wrapping them with one
kdekorte: DanaG, that sounds like one of the problems that was fixed in Fedora. how recent is your kernel, libdrm and ddx?
osiris_: airlied: hmm, so additional bo in radeonTexObj should be enough, right?
airlied: osiris_: yeah seems so, not sure why texture_image has one, there might e another reason
DanaG: It's whatever's in xorg-edgers on Lucid. I'll check.
kdekorte: DanaG also might need to upgrade your xserver
DanaG: ddx is 6.12.99+git20091111.2af2744c-0ubuntu0tormod
DanaG: libdrm-radeon is also 2009-11-11
DanaG: Kernel is based on 2.6.32-rc6.
DanaG: I may stick with non-KMS for now... it should be more stable with suspend/resume than fglrx, and it has at least SOME power savings.
DanaG: KMS does not do power savings. :(
DanaG: I'd love to at least have forcelowpowermode for KMS.
Zajec: DanaG: it's simple if you compile kernel yourself :)
Zajec: DanaG: open radeon_pm.c and put
Zajec: radeon_set_engine_clock(rdev, 30000); /* 300'000 kHz */
Zajec: works for engine clock only...
Zajec: but gives effect already ;)
Zajec: DanaG: working on getting really implemented, not hacked, but experience lock up everytime I try to downclock in timer
kdekorte: Zajec, I know agd5f had worked with those values in the dri1 driver. Did you start with those values?
DanaG: Hmm, don't gpuclk+memclk+voltage changes have to be atomic, or something?
DanaG: Or at least, done in a specific order.
Zajec: kdekorte: values of clocks are not a problem
adamk: Is it possible yet to select a resolution for KMS at boot (or when the module is loaded)? I recall patches getting sent to various mailing lists, but don't know what happened afterwards.
Zajec: kdekorte: it's about setting engine clock that causes lock up when executed in timer
Zajec: kdekorte: will post request for help with example patch on dri-devel today
DanaG: Oh, and for safety, you'd use the powerplay states.
Zajec: DanaG: that's right
Zajec: DanaG: that's why i named it hackish :)
airlied: adamk: video=
kdekorte: Zajec, could the timer submit the clock change commands to the cp rather than change them directly?
adamk: airlied, What about with multiple monitors?
Zajec: kdekorte: ASAIK not
Zajec: kdekorte: we change clock using AtomBIOS command, not something simple like register change
Zajec: rebooting to confirm lock up before posting
airlied: adamk: video=DVI-1:
adamk: Ahhh.. That makes sense.
kdekorte: Just wondering if changing the AtomBIOS while the cp is in the middle of something is the problem.. so if that is the case you have to wait under the cp is idle or force the cp to be idle while the AB change is made
airlied: you shuoldn't be reclocking while the CP is doing stuff
airlied: the poing of dynamic reclocking is you do it when idle
airlied: also using atom is possibly too slow to not glitch the users screen
airlied: the easiest to implement first pass is when dpms off, idle CP and ramp everything down
DanaG: heh, though that's not extremely useful for me... I want to be saving power while using the thing. =þ
DanaG: Even if it's statically in low-speed mode from the moment the module loads.
airlied: it doesn't make sense you use more power in the long run
airlied: if you do things slower the gpu is on for longer
DanaG: As it is right now, radeon without KMS uses 4 or 8 more watts when idle, compared to fglrx... and with KMS, it's more like 10 watts difference.
adamk: airlied, Is drm-next necessary, or will the stable tree work? I'm on 188.8.131.52 compiled from the stable tree on Monday...
kdekorte: the problem is that the driver keeps the gpu running full steam even if nothing is being done on the screen so it uses more power
airlied: adamk: for kms I don't recommend stable trees
kdekorte: so there needs to be a way to slow down the gpu while on battery and the gpu is idle a lot
adamk: Gotcha. I was just happy that KMS finally worked with my x850 when I tried it on Monday. I'll see about updating to drm-next.
airlied: kdekorte: if nothign is done on screen we sholdn't be doing anything
DanaG: I'd also like to have it slow down when on AC, too... then it's solely about fan noise.
airlied: we just don't have a way to dynamically reclock the gpu
airlied: so it always runs at full speed doing nothing
kdekorte: I thought that is was Zajec was working on.. a way to dynamically clock the gpu
airlied: yup, it is
Zajec: poor results
airlied: we can probably add static points in debugfs for testing but we need to think about how users are expected to use them
DanaG: Hmm, perhaps for now, just let them choose from the existing PowerPlay states?
airlied: DanaG: how?
airlied: we don't have a UI
airlied: we need to think about it from the UI down not just some files in sysfs.
MostAwesomeDude: e.g. an ioctl that sets the clocking policy might be better than letting people directly touch powerplay states.
kdekorte: I was thinking of something in the /proc system kinda like laptop mode
DanaG: That depends on dynamic clocking, though, doesn't it?
DanaG: /proc is bad style, isn't it?
agd5f: plus some power states aren't meant to be user selectable
Zajec: ok guys, posted request for help on dri-devel
Ghworg: "echo bazillion > /proc/gpu/clock", bwahahaha
Zajec: i really hope someone explain me that stupid timer issue :) promise to implement basic PM then :P
kdekorte: if the is a way to calc the cp depth then if the depth is over say 25 then kick it into full power... when the depth is 0 or < 5 drop it down.. (numbers for example only)
airlied: Zajec: did you use that code from mjg59?
MostAwesomeDude: I think something similar to the CPU dynamic clocking interface, with governors, might be useful.
airlied: since it actually did work already
Zajec: airlied: i'd need to rewrite it partially... no i didn't try it
agd5f: it relied on irqs IIRC which are available yet on r6xx+
Zajec: airlied: i really prefer to understand that over just rewriting
airlied: ah it did use vbl irqs
airlied: you can't really dynamically reclock outside vbl
Zajec: airlied: it's about memory reclocking, right?
kdekorte: time for the mandatory "We want r6xx irq support" call... agd5f I know it is waiting for approval
Zajec: airlied: AFAIU engine reclocking should not be related to VBL...
airlied: Zajec: how else do you propose it works?
airlied: its kind of fundamental
airlied: so I guess you've just missed that there isn't another way to do it
Zajec: airlied: i try to get engine reclocking working for now
Zajec: i ignore memory so far
agd5f: Zajec: the whole thing was tied into vbls
airlied: if engine reclock doesn't flicker the sceren it would be okay
airlied: but this being hw I woudln't be surprised
DanaG: Oh yeah, using governors might allow code reuse... spiffy.
Zajec: airlied: if can even flicker... i won't leave it that way... just want to udnerstand locking issue
airlied: the big problem with GPUs is latency between states
airlied: its a lot larger than CPUs
agd5f: you have to wait for the plls to settle
Zajec: airlied: what statues do you mean?
agd5f: also, the engine should be idle when manually reclocking since the block clocks are derived from the engine clock
Zajec: agd5f: i downclock by calling "cat radeon_pm_info" so plls are not issue
Zajec: (i know, hackish way)
Zajec: agd5f: engine idle... do you mean CP?
Zajec: agd5f: i guess you do... but prefer to ask
airlied: Zajec: changed mem/eng clock
agd5f: Zajec: the CP is part of the engine
airlied: cpus have been optimised to change power states a lot faster than gpus
agd5f: engine being the CP, shader cores, texture blocks, etc.
Zajec: agd5f: radeon_do_wait_for_idle should do it?
agd5f: Zajec: and the engine/memory clocks are plls just like the pixel plls
agd5f: so you have to wait for them to settle as well
MostAwesomeDude: airlied: So we can't use the CPU governors without tweaking them to not change states 10 times a second? :3
airlied: MostAwesomeDude: something like that
DanaG: cat radeon_pm_info... where is that?
Zajec: DanaG: nothing interesting, just dumps clocks
Zajec: mount -t debugfs debugfs /debugfs
Zajec: ; /debugfs/dri/0/
airlied: /sys/kernel/debug is the mount point you should use ;-)
DanaG: It's already mounted, but doesn't have radeon_pm_info.
DanaG: bufs clients name queues vm vma
Zajec: DanaG: drm-next?
airlied: DanaG: he's writing it, and its kms only
Zajec: agd5f: how can I make sure engine is idle? what about:
Zajec: mutex_lock(&rdev->cs_mutex); radeon_do_wait_for_idle; reclock();
agd5f: Zajec: I don't think we have a function for that in kms yet
Zajec: agd5f: radeon_do_wait_for_idle is from radeon_cp.c
airlied: thats not kms
Zajec: ah, ok, i see Makefile explaining it nice
Zajec: will try mdelay(100) for wait :P
tokstolle: hello x-developer, I have a problem. I play neverwinter nights and I use the OS radeon-driver.
tokstolle: but the textures in that game are very ugly.
tokstolle: Can I do anything do help you to fix that problem?
tokstolle: a message on the mailling-list?
kdekorte: tokstolle, might need to get todays mesa, I tried it this morning and it looks good
kdekorte: tokstolle, also what video card are you using?
tokstolle: a X1300. not the fastest one ;(
tokstolle: kdekorte: do you know that problem?
kdekorte: I saw the bad textures yesterday on my r6xx, I upgraded mesa this morning and rebuilt and the textures looked much better
tokstolle: kdekorte, in which app you saw this bad textures? this problem with nwn is an older one
kdekorte: tokstolle, NWN 1.69 on linux and I get about 40fps when running
DanaG: hmm, still hangs with KMS.
kdekorte: DanaG, does booting with pcie_aspm=off help any?
kdekorte: with KMS enabled
tokstolle: kdekorte, there are nwn-gamers here O:) and they'r about to fix the problem. Okay thats all I need to know
DanaG: [ 0.331278] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
DanaG: shouldn't that be "disablING" it? =þ
kdekorte: tokstolle, I'm not a developer, but I happen to have NWN and I check it periodically
kdekorte: DanaG, should be, but can you try it
DanaG: What's weird is where it hangs:
kdekorte: DanaG, do you happen to have an ICH8, 9 or 10 chipset?
kdekorte: yeah, I have one of those and early Fedora 12 kernels < -112 or something would hang without that option... could open a gnome-terminal type dmesg and scroll the window up and down and get a constant hang everytime
DanaG: Weird... did yours say it was disabling already, but not actually disable it?
kdekorte: DanaG, I don't recall, I don;t think it said anything
DanaG: Still hangs.
DanaG: so yeah, non-KMS for now.
DanaG: Is there any way I can save more power with radeon? The fan noise is getting to me.
dileX: drm-linus commits now in linus-tree
Luzipher: cheers for linus tree
tsamolotoff: Hi guys!
tsamolotoff: I take drm:r100_cs_track_texture_check] *ERROR* Texture of unit 1 needs 1310720 bytes but is 327680 is a well-known bug?
tsamolotoff: In other words - is there fix now or not yet?
DanaG: so, I'm not sure where my hang is, then.
Kaapa: guys, I've seen here and there reports of problems with suspension/hibernation when an external monitor is connected
Kaapa: any known issue or just rumors?
octoploid: I've updated to the latest Linus git tree and get this new kernel error whenever I run 3d apps:
octoploid: [drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 47.
octoploid: [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014
octoploid: [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
octoploid: This happens on a RS780 running KMS.
agd5f: octoploid: update mesa
octoploid: agd5f: OK
octoploid: agd5f: It's working again. Many thanks.
octoploid: had to git clone mesa three times, thanks to arch's intelligent aur packages...
phercek: octoploid: merge arch packages mesa, libgl, atidri to one package mesa-git then you will not need to clone mesa 3 times
octoploid: phercek: Yes, will do next time. I had to edit libgl-git to make it work anyway.
phercek: octoploid: here is an example how I do it: http://www.hck.sk/users/peter/pub/paste/PKGBUILD
phercek: octoploid: I did not update for about a month so not sure it still works that well, but it was pleasure to update that way
octoploid: phercek: Cool. Saved for the next time.
Bigshot_: adamk_: you there?
Bigshot_: is this the newer driver? http://download.opensuse.org/repositories/home:/jobermayr/openSUSE_Factory/x86_64/xorg-x11-driver-video-ati-6.99_20091109-2.2.x86_64.rpm
c64zottel: thanks very much
EruditeHermit: airlied, no luck with the patch
EruditeHermit: airlied, I will get the register dump in a sec
airlied: christ bisecting atom operation deubg printks to find a bug is no fun
EruditeHermit: airlied, I did the dump of the registers and attached the files to the bug
airlied: EruditeHermit: I have another plan, I just fixed a resume bug on a T60 laptop (taken 8 hrs of fighting)
airlied: I'm wondering if something similiar might be broken
airlied: the T60 bug was in atom stuff but maybe the legacy stuff is similiar broken
EruditeHermit: let me know when you have something for me to try
EruditeHermit: the last patch didn't fix teh problem
EruditeHermit: it just created corruption all the time as described in the report