Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-12-10

Search This Log:


airlied: AndrewR: try it again in a minute :-)
airlied: if you got the dmesg and it says Divide by 0
AndrewR: EIP at rfixed_div+0x2d/0x4d [radeon] was in one line (sorry dmesg is actually on other machine)
airlied: AndrewR: sounds like it alright
airlied: boot with radeon.new_pll=0 to see if it goes away
AndrewR: airlied, one moment
AndrewR: airlied, yes, new_pll=0 avoids segfault running it now
dileX: well, drm-linus GIT branch
airlied: whew all sent to Linus
eosie: soreau: cool, enemy territory appears to work here without any visual errors
eosie: or artefacts
dileX: airlied: cool. start compiling, now.
airlied: dileX: /me has 5 machines compiling at the moment
airlied: I'll probably find 10 regressions before I go home now that I've pushed it
soreau: eosie: Damn it :/
soreau: eosie: Here it has visual problems even when going from server screen to download mode
dileX: airlied: did you ever try that make-target thingie?
soreau: eosie: And in-game, it is not playable - very slow with major visual problems
dileX: or are you compiling "generic" kernels?
eosie: it's not playable here either
airlied: dileX: generic
soreau: eosie: But.. I am still waiting for the system to update at he end of which will update libdrm and ddx
soreau: eosie: So et works without visual errors but too slow to play?
soreau: there on rv530
dileX: airlied: so the fastest way to re-new drm-stuff was for me (assumed you have already compiled a kernel): cd $builddir ; make M=drivers/gpu/drm clean && make M=drivers/gpu/drm
airlied: dileX: you can probably avoid the clean, kernel normally gets depends all right
dileX: yeah, the linus-kernel an "intelligent" build-system, shows you which k-modules "really" changed
dileX: +has
AndrewR: airlied, segfault fixed, thx!
eosie: soreau: yes exactly
soreau: eosie: Thanks for testing
dileX_: arghh, freeze while building kernel.
JohnDoe_71Rus: next try enable kms and dri
JohnDoe_71Rus: http://pastebin.com/m5f3464a5 dmesg
JohnDoe_71Rus: http://pastebin.com/m6f9004e0 xorg.log
JohnDoe_71Rus: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
soreau: JohnDoe_71Rus: Did you build latest libdrm then mesa and ddx against that libdrm?
JohnDoe_71Rus: soreau: just update from
JohnDoe_71Rus: http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu and
JohnDoe_71Rus: http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu
JohnDoe_71Rus: http://ppa.launchpad.net/tormodvolden/ppa/ubuntu
soreau: Can you verify the fbcon module was loaded before radeon module?
MostAwesomeDude: xf86-video-ati is too old.
JohnDoe_71Rus: soreau: how to know it?
soreau: JohnDoe_71Rus: Is fbcon even loaded per lsmod?
soreau: But I'm inclined to agree with what MAD said
eosie: does r300c use tiling?
eosie: most probably not
JohnDoe_71Rus: soreau: lsmod in kms mode http://pastebin.com/m50351412
dileX_: BTW, are there any plans to push a 6.13.0 DDX?
soreau: JohnDoe_71Rus: But did you build latest mesa and ddx against latest libdrm?
soreau: or you're using xorg-edgers repo..
MostAwesomeDude: eosie: IIRC yes.
soreau: If so, you need to complain to xorg-edgers maintainer
soreau: JohnDoe_71Rus: but you also need to make sure fbcon loads before radeon
DanaG: are you on Karmic, or on Lucid?
DanaG: On Lucid, vga16fb is blocking stuff from loading, as I found out when trying to use nouveau.
JohnDoe_71Rus: use xorg-edgers repo. just update. karmik
dmb: don't use fb's there ill maintained
dmb: KMS replaces them
JohnDoe_71Rus: dmb: how to disable?
dmb: don't load vga16fb
JohnDoe_71Rus: where to disable the download мпф16аи,
JohnDoe_71Rus: vga16fb
virtuald: johndoe_71rus: /etc/modprobe.d/blacklist-framebuffer.conf
JohnDoe_71Rus: virtuald: is blacklisted vga16fb
bjaglin: JohnDoe_71Rus: i had a similar race condition. Taking the 2.6.32 kernel from the lucid repositories fixed it. There is also a workaround in gdm.conf that you can try: https://wiki.ubuntu.com/X/RadeonKMS#Module_loading_issues
JohnDoe_71Rus: thanks work.
airlied: eosie: tiling where?
airlied: eosie: we do color buffer tiling if the DDX enables it
airlied: which we should do on r300->r500 by default but I keep forgetting
spreeuw: hey maybe the r600 dev could run spring rts and fix some oddities
eosie: airlied: tiling in 3D (colorbuffers, zbuffers, textures)
airlied: color + Z is done, under non-kms we did have texture tiling until I rewrote the driver
airlied: and screwed it up
airlied: I've been meaning to redo texture tiling under bufmgr when I figure out how
airlied: eosie: tiling is transparent apart from sw access really
spreeuw: http://yfrog.com/iyscreen003yp
airlied: if the DDX enables it, the 3d driver doesn't see it unless it has to do sw access
spreeuw: this smoke as always worked
airlied: for color/Z that is
MostAwesomeDude: eosie: You can add it to the todo list; basically we have to have de-tiling in either the kernel or in our pipe_transfer code for it.
airlied: MostAwesomeDude: where does the CPU access color buffers with r300g?
eosie: somewhere in r300_screen.c
airlied: wondesrs why
MostAwesomeDude: airlied: Any BO can be mapped for read/write.
airlied: I didn't think gallium did sw fallbacks
MostAwesomeDude: It doesn't.
airlied: MostAwesomeDude: so why would it map the color bo?
eosie: we have to still read correct values on glReadPixels
MostAwesomeDude: But e.g. glReadPixels() is going to incur a map and read.
eosie: *read=return
airlied: glRP should be done via a blit really
airlied: copy the block to untiled using GPU
DanaG: holy shiznit: http://gizmodo.com/5051490/sony-brings-their-114000-4k-projector-out-from-hiding
MostAwesomeDude: Right, but a blit where? It has to get blitted into a colorbuf, even if that buf's in main memory.
airlied: doing direct RP on VRAM is shit
DanaG: wonders what ATI card could power that.
airlied: MostAwesomeDude: an untiled BO in GTT
spreeuw: I love it how these new cards almost dont care about your resolution
MostAwesomeDude: airlied: Sure, so we should probably not request tiling for those BOs. That's a simple flag in winsys
spreeuw: it just churns through 1920x1200 3d like butter
DanaG: oh, back to vga16fb:
DanaG: It's built-in ... does blacklist apply to compiled-in stuff?
DanaG: I just did it a hackish way:
MostAwesomeDude: I expect that we could do as we do for VBO emits, and just stuff that area full of assertions along the lines of assert(better_not_be_mapping_that_tiled_bo_boy())
DanaG: added "vga16fb.DONOTWANT=1" into boot params.
DanaG: It makes vga16fb abort with "invalid parameter".
DanaG: "DONOTWANT" could also be "GODIEINAFIRE", if you're feeling really angry.
DanaG: s/GO//
MostAwesomeDude: And then, if for some reason people *are* mapping BOs that they said they wouldn't, then we can either bug keithw, or just refuse to map them.
airlied: MostAwesomeDude: if you map a tiled BO you need accessor methods
airlied: like radeon_span.c
MostAwesomeDude: airlied: I know. Accessors are unpleasantness.
MostAwesomeDude: I would be perfectly happy with simply refusing to ever map tiled BOs.
airlied: for gallium I don't see the point, just do ReadPixels properly
MostAwesomeDude: Well, that's a level above us.
airlied: for the X.org DDX we would need to map tiled BOS
airlied: but we have surfaces for that for the front BO
airlied: so its probably a good idea to block maps of unsurfaced BOs or a least warn on it
MostAwesomeDude: Obstensibly, when st requests BO creation, it should give us some flags specifying exactly what it will use it for.
airlied: like you have the problem now with depthb uffer
airlied: since its always tiled
MostAwesomeDude: And those flags are binding WRT API, although nobody respects them.
airlied: MostAwesomeDude: front/back/depth come from DRI2
airlied: the DDX picks the tiling
MostAwesomeDude: airlied: Good point, although, again, any st wanting to map the frontbuf should STFU if it can't get it.
MostAwesomeDude: And IIUC xorg st behaves properly in those cases. Dunno about others.
eosie: soon enough we will be able to blit anything we want anywhere in the driver
airlied: with texture tiling it gets fun again, though Gallium has transfer functiosn
airlied: so we use those to blit back/forward
MostAwesomeDude: Right, pipe_transfer can be used to do accessors, like nouveau does.
airlied: eosie: yup once we can do that, we should do RP etc using blit
MostAwesomeDude: I'll check, but I think ReadPixels is just done by directly mapping the BO in question.
MostAwesomeDude: Which is actually a series of calls involving a pipe_transfer and such.
MostAwesomeDude: At any rate, Gallium doesn't explicitly ask for BO migration; it just uses the proper flags when requesting things from libdrm. It's up to libdrm to decide how to handle radeon_bo_map.
MostAwesomeDude: :T
MostAwesomeDude: I think I'm getting a bit incoherent; maybe sleep should be done soon.
eosie: we can't rely on flags since gallium can't know what a GL app is about to do, we can get GetTexImage or RP anytime...
MostAwesomeDude: If they didn't include the "I'm gonna map this later on" flag, then we can refuse to map it for them.
airlied: MostAwesomeDude: libdrm doesn't do that
airlied: I know Gallium can do accel readpixels paths
airlied: since that was one of Brian P's goals never to write another accelerated RP path
MostAwesomeDude: airlied: I know that as well. I've read through the relevant code in u_blit.
DanaG: "The biggest missing feature from the Radeon KMS driver before we can probably mark it not-staging is some sort of power management support, this is being worked on, but is a hairy problem, but lots of people have cards that run hot or with full fan and it would be nice to do something about it. However we will probably remove the staging bit before 2.6.33 goes live." -- cool.
eosie: MostAwesomeDude: We can't refuse to map anything... how else would those piglit tests check for results? they can read any resources they want and GL has a well-defined behavior when the mapping should succeed
airlied: MostAwesomeDude: so gallium does read pixels using tex transers
airlied: which you use to do the blits I assume
samitheberber: I have Ati Radeon 9550 se (RV350) and latest builds from git, however my opengl version is 1.5, but Wikipedia says that 2.0 is supported.
samitheberber: Is the version 2.0 supported in that card yet?
samitheberber: Software rendering gives 2.1
glisse: samitheberber: the opensource driver doesn't support yet the 2.0 on this hw
samitheberber: ok
samitheberber: glisse: can you tell me, when is that support planned to release?
glisse: no ETA
samitheberber: ok
glisse: in one year likely
samitheberber: shame, that I'm not so good in C and not so famillar with hardware :/
scarabeus: 0: /usr/bin/X (xorg_backtrace+0x38) [0x80d3b58]
scarabeus: Segmentation fault at address (nil)
scarabeus: is there any way how to beat up that thing to do more sane backtraces?
scarabeus: i know it crashes when i have enabled xcomposite and dri2 but this is too vague to find the root of all issues :]
eosie: sleep time
glisse: scarabeus: through ssh attach gdb to Xorg : gdb Xorg `pidof Xorg` just before triggering the crash
scarabeus: glisse: the problem is that i cant trigger it myself
scarabeus: it just "sometimes" crashes
glisse: scarabeus: then attach gdb to Xorg through ssh and wait for it crashing :)
glisse: scarabeus: you might want to use nostop on bunch of signal
glisse: so gdb only stop if it gets segfault
scarabeus: yeah that i tried now with nice help from cornair, but problem is that at the moment i attached to the pid it froze the box :D
glisse: type c
glisse: to continue
glisse: when you attach gdb it stops the process
scarabeus: looks like this time it didnt hang
scarabeus: and i did exactly what i did before :P
scarabeus: we can suspect something else tho :D
scarabeus: anyway it mostly happens with heavy cpu load and too much compositing
scarabeus: i guess it hits software fallback somewhere and nicely passes out ;]
rah: I'm getting continuous errors from the kernel:
rah: radeon 0000:01:00.0: object_init failed for (7274496, 0x00060004)
rah: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7274496, 4, 4096)
rah: radeon 0000:01:00.0: object_init failed for (7274496, 0x00060004)
rah: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7274496, 4, 4096)
rah: coupled with major display corruption
glisse: rah: do you have lastest kernel ?
glisse: patch want in a couple hours ago for that
rah: ok
rah: which tree?
glisse: rah: also AGP ? aperture size ?
rah: I'm using drm-radeon-testing
rah: this is PCI-E
glisse: drm-radeon-next & drm-radeon-testing
glisse: with the lastest commit ? 4hours ago ?
dileX: drm-linus should have all latest fixes
rah: glisse: this is from yesterday
rah: I'll update
rah: CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/r600.c
rah: ARGH
rah: ffs
rah: I JUST WANT IT TO WORK
rah: kicks things
rah: calms down
rah: I have an ethics committee application to write for my masters thesis
rah: I shouldn't be dealing with git right now :/
glisse: well you shouldn't test bleeding edge on a working station :)
rah: pfft
rah: the last release doesn't work for me
rah: it has bad TV output
rah: the bleeding edge has the same problem but it's at least likely to be fixed
MrCooper: airlied, glisse: FYI mesa/progs/tests/texleak aborts with a CS ioctl failure after a while here with today's drm-linus
tobydeh: hello
tobydeh: Im having trouble with my screen resolution on fedora 12 with a RV710 card connected by DVI to a 32" sony bravia
tobydeh: its currently using 1280 x 720 which is perfect but its overscanning
tobydeh: ive added a few new modelines to xorg.conf but i can get them to have any effect?
tobydeh: cant*
tobydeh: the screens pixel resolution is apparently 2360 x 768, but it says it accepts 720p
glisse: MrCooper: what is in linus ? :)
glisse: tobydeh: there is likely an option in you tv menu to disable overscaning
MrCooper: glisse: your TTM changes, e.g.
tobydeh: glisse: unfortunately not
rah: apparently, CONFIG_EXTRA_FIRMWARE doesn't work :/
glisse: MrCooper: do you have a kernel message associated with the failure ?
adamk: rah, It worked fine for me yesterday.
MrCooper: glisse: if you haven't tried the texleak test yet, give it a try; if you let it run until it uses more texture memory than there is GTT + VRAM, it's a good BO eviction test
rah: adamk: what did you set it to?
glisse: MrCooper: yeah will try it
glisse: fixing eviction to always succeed is on my today plate
adamk: rah 'radeon/R700_rlc.bin'
MrCooper: glisse: just [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
rah: urg
adamk: rah, There's another option in .config that lets you specify the firmware path, which I had to set to '/lib/firmware/' because the full path is '/lib/firmware/radeon/R700_rlc.bin'
rah: adamk: yes, I get that
rah: I set CONFIG_EXTRA_FIRMWARE=R700_rlc.bin and CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware/radeon
rah: silly me
adamk: rah, You might need an extra / at the end of _DIR... Otherwise the full path becomes /lib/firmware/radeonR700_rlc.bin, right?
rah: adamk: if the code is constructing a fully qualified file name from a directory and a filename, it should put a directory separator in between the two
rah: the name of the directory isn't /lib/firmware/radeon/ but /lib/firmware/radeon
rah: s_/radeon__g
adamk: All I know is that it worked for me with _DIR as /lib/firmware/ and _FIRMWARE as radeon/R700_rlc.bin
rah: I'll add it anyway
rah: what with not trusting this at all
rah: I don't know why it doesn't fail if the file isn't found
rah: the build
rah: this is all not good
adamk: The build did fail for me yesterday till I got the path right.
adamk: Sounds like something is quite screwed up on your end.
rah: mmm
rah: tries again
dileX: why not copy the files from < to /lib/firmware/radeon?
rah: I'm in shock
rah: it worked
rah: I'm still getting corruption :(
rah: radeon 0000:01:00.0: object_init failed for (15974400, 0x00060004)
rah: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (15974400, 4, 4096)
rah: and dmesg errors
rah: woe be me
glisse: rah: open a bug and attach full dmesg
glisse: double check you are loading the right version
rah: I don't really have the time
rah: but I'll do it anyway
rah: glisse: right version of what?
glisse: well the lastest drm-radeon-testing
glisse: it shouldn't happen with it
glisse: i did have same error before my fixes went in
rah: rah@myrtle:/usr/src/drm-radeon-testing$ git log | head -n 3
rah: commit fb53f8621a3fab88776ae2450a1f3afc7920231b
rah: Author: Jerome Glisse
rah: Date: Wed Dec 9 21:55:10 2009 +0100
rah: rah@myrtle:/usr/src/drm-radeon-testing$
glisse: and you shouldn't use bleeding edge on working station
orly_owl: got a bit of a pickle
orly_owl: http://gnewsense.pastebin.com/m513b59ca
orly_owl: trying to use a tv as the monitor (s-video output)
rah: https://bugs.freedesktop.org/show_bug.cgi?id=25559
orly_owl: i can get the picture on the tv ok, but if i boot with only the TV plugged in, xorg doesnt like it
orly_owl: rah: Is that for me?
rah: orly_owl: no
orly_owl: oh
rah: glisse: is there any point in opening bugs?
rah: I've opened a few bugs against radeon
rah: not one of them has ever been closed
orly_owl: http://gnewsense.pastebin.com/m3a5cff65 gdm and xorg logs
adamk: I've had quite a few bugs resolved.
adamk: orly_owl, Exactly what do you mean by "xorg doesn't like it' ?
orly_owl: adamk: well i dont see xorg loading on the tv
adamk: orly_owl, If you boot up with both the TV and a monitor, can you use 'xrandr' to enable the TV at a specified resolution?
orly_owl: adamk: yep, i have a script that does this at boot. works fine with both the TV and a monitor plugged in
adamk: orly_owl, I don't know if this will work, but you could try giving the monitor section of your xorg.conf the same identifier that xrandr shows for the output, and forcing it to use a specified resolution.
orly_owl: but if i unplug the monitor, xorg wont show on the tv
adamk: So the TV only shows a clone of the monitor?
glisse: rah: you do nothing else than launching X ?
orly_owl: adamk: yes. and that's how i have it set up
orly_owl: im not even going to try doing dual displays
orly_owl: im not that insane
glisse: rah: it's very strange you get this issue you got plenty of vram & gtt
orly_owl: the tv is fed 800x600
marvin24: rah: I'm getting the same errors as you - something is broken on drm-radeon-testing, will "revert" to drm-linus
orly_owl: unless there's a way to feed it 720x576 (PAL)
rah: glisse: this is using X
rah: (as opposed to just launching it)
adamk: orly_owl, Can you start up X with both connected, run 'xrandr' and pastebin the output?
orly_owl: ok
orly_owl_: http://gnewsense.pastebin.com/m5c0b31d2
orly_owl: adamk:
spreeuw: orly_owl: hey btw whats gnewsense stance on the radeon drivers these days?
spreeuw: with all this firmware in the kernel
orly_owl: ah
adamk: orly_owl, So change the identifier in the Monitor section of your xorg.con file to "S-video" and use the PreferredMode option to specify "800x600". Hopefully that will work, but I'm certainly not positive.
orly_owl: spreeuw: (non-free) firmware in the kernel is removed
orly_owl: spreeuw: the radeon driver is probably ok, radeonhd probably not as it loads firmware onto the card
adamk: orly_owl, Actually, does "800x600" show up in xrandr for S-video before you run xrandr with addmode?
orly_owl: it probably wont
orly_owl: adamk: ill turn off the script and reboot to see what happens
orly_owl: i get a picture on both tv and monitor on boot
adamk: And what's the output of 'xrandr' before using addmode?
orly_owl: k
tobydeh: Hello, Im using a radeon rv710 card on redora 12 and mythtv playback is very juddery
tobydeh: how can i fix it?
orly_owl_: http://gnewsense.pastebin.com/m439b4a74
orly_owl: adamk: it says S-video disconnected but i havent unplugged the tv
orly_owl: i set the default resolution to 800x600 btw, using gnome
tobydeh: the card is a radeon 4550
[Enrico]: can i ask if there is an official tarball for radeon irq firmware somewhere ?
rah: glisse: just out of curiosity, are you looking at the bug I raised right now?
kmays: tobydeh: You may want to upgrade to the latest kernel update (first).
kmays: tobydeh: Otherwise, you'd have to tweak the app (based on what it is doing with your video output).
rah: I guess not
rah: I wonder what the point was of raising that bug?
TBBle: What bug?
scarabeus: ok crash seems not to be happening anymore :/
scarabeus: anyway i have another problem :]
scarabeus: mplayer -vo xv Warriors_of_the_net_CZ-MPEG1_Web_PAL.mpg
scarabeus: when i try this
scarabeus: i got
scarabeus: -vo unable to initialize selected video output
scarabeus: althrought xvinfo reports its as working
rah: TBBle: https://bugs.freedesktop.org/show_bug.cgi?id=25559
rah: glisse: what was the point of raising that bug?
dileX: rah: would be helpful to add some more infos to that BR, like lspci-output, in addition version of libdrm, mesa and ddx.
rah: dileX: why?
rah: dileX: to whom would it be helpful?
dileX: rah: for the reader. dunno how much gfxcards belong to RV770 family. and noone knows when this error-messages arose. on boot-up? starting a 3D-game. IIRC this is with KMS, did you try nomodeset parameter as grub-cmdline?
TBBle: Huh, I've got an rv770 I think. Mobility HD4850.
rah: dileX: what's the point of filing a bug report if the only thing people do is read them?
rah: dileX: an email would be sufficient for that
TBBle: You want to email everyone who might want to look at the bug directly? That's daft. Email is the temporally wrong way to deal with bugs.
rah: the idea of a bug reporting system is to help fix bugs, not just disseminate information on the prevalence of error messages in the hope that some developer somewhere might take an interest
adamk: rah, Except that they are stored in a nice database that is searchable, and ou can keep track of everyone's feedback in one location.
dileX: rah: BRs also document a bug with a history. sometimes patches are added for testing. BR-no are also referenced in software-development.
tobydeh: kmays i thought that fedora 12 was pretty recent?
tobydeh: kmays, its not just myth, its also vlc etc
rah: TBBle: no, I want to file a bug so that someone will look at the bug directly
tobydeh: all vidoe is choppy
TBBle: rah: Oh, you want a paid support service then.
rah: adamk: http://lists.x.org/archives/xorg-driver-ati/
adamk: rah, And hopefully someone will eventually. There's only a limited amount of developers and a limited amount of time they have.
rah: TBBle: no, just support service
kmays: tobydeh: Did it work fine before?
adamk: rah, That's not even remotely the same thing.
adamk: rah, Sounds more like you have an issue with open source development.
tobydeh: kmays, on ubuntu yes - it was never perfect but the video wasnt choppy like this
rah: adamk: "hopefully someone will eventually"
rah: hah
tobydeh: kmays, it has a wierd interlaced effect and its almost like its vibrating
rah: adamk: no, just radeon development
TBBle: This _is_ a volunteer effort, to some extent, right? I guess Red Hat customers have a certain amount of leverage, but they have their own bug-tracking system to apply said leverage.
dileX: rah: a "sexy" BR attracts ppl to read and deal with them :-). dont be surprised if your older BRs are still open.
rah: adamk: I've filed bugs with other areas of X and they've actually been dealt with
adamk: rah, You can always pay someone to deal with your bug.
adamk: And I've filed bugs against radeon that have been dealt with. What's your point?
dileX: rah: dont forget your master-thesis :-)
rah: adamk: can you give me an example of a bug being dealt with?
adamk: And I've also had bugs with probably dozens of other projects that have gone ignored.
rah: adamk: I'm just curious
adamk: Sure... Give me a second.
TBBle: Surely a search on Bugzilla for RESOLVED FIXED would tell you that?
rah: TBBle: no, that would show you which bugs had been created and subsequently closed with a resolution of RESOLVED FIXED
rah: TBBle: which doesn't necessarily mean they've been dealt with
rah: s/bugs/bug reports/
TBBle: Well, yeah, technically. I'd rather assume people aren't bizarrely abusing the bug tracker though, it's a useful simplifying assumption.
tobydeh: can someone please help me wsort out this choppy video before i give up and buy an nvidia card?
rah: tobydeh: no
adamk: rah, This bug of mine was resolved this week: http://bugs.freedesktop.org/show_bug.cgi?id=24263
tobydeh: rah, wow that was helpful!
TBBle: Maybe you'd be happier if the bugzilla system automatically emailed your bugs to the main ATI/Radeon driver developers?
adamk: tobydeh, Do you have direct rendering working? Do other applications other than mythtv work fine?
tobydeh: adamk, no all videois chopy, myth, vlc, movie player
tobydeh: is direct rendering == open gl overlay?
TBBle: tobydeh: Have you tried -vo gl with mplayer, see if it has the same effect (or even works, I have no idea what state you're in)
adamk: Is direct rendering enabled in the X server? If you aren't sure, pastebin your /var/log/Xorg.0.log file.
rah: TBBle: the bugzilla system does automatically email my bugs to the main ATI/Radeon driver developers
tobydeh: TBBle, ill try that now, adamk xorg log commint up...
TBBle: rah: Excellent. So you get your wish of directly filling people's inboxes, and I get my wish of being able to see the bug even if I don't happen to read that email.
rah: adamk: cf. http://bugs.freedesktop.org/show_bug.cgi?id=25520
adamk: rah, The developers deal with bugs that come in as quickly as they can. As I said, their numbers are limited, as is their time. The more information provide, the more likely it is to get fixed. So, for example, if this was something working previously, locating the commit where it broke is good.
tobydeh: adamk, Xorg.0.log http://pastie.org/737194
tobydeh: TBBle, its really slow with -vo gl and still jittery
adamk: rah, Alright, so you opened the bug yesterday... You're expecting something in less than 24 hours? :-)
rah: adamk: no, just expecting something
rah: adamk: cf. http://bugs.freedesktop.org/show_bug.cgi?id=23851
tobydeh: adamk, looks like direct rednering is enabled
dileX: rah: why do you use "pci=nommconf" in your kernel-cmd-line?
rah: adamk: nobody even responded to that bug
kmays: tobydeh: Yes..but your software renderer kicks in for GL.
rah: adamk: and I commented that it seemed to have disappeared after a month
rah: adamk: a month
tobydeh: kmays, that does that mean?
tobydeh: it aht on line 405 / 406?
rah: adamk: I wonder why it is that agd5f responded to your bug after 1 day, but nobody at all responded to my bug
adamk: rah, Wait... As for that second bug, you larter said it was an issue with gnome's utility, not even the driver.
kmays: Something is mucking things up.
adamk: rah, What do you expect the developers to do about it, then?
rah: adamk: I said that after a month
rah: adamk: that is, after a month of no developers responding
tobydeh: kmays, is that error shown on line 405 / 406?
rah: adamk: like I say, I'm just wondering why it is that someone responded to your bug after 1 day, but nobody at all responded to my bug
kmays: tobydeh: Technically, you should have both 2D/3D direct rendering (hw-accelerated). Anything else means an feature option is messing things up...like KMS or an overlay enabled.
tobydeh: ok, what option is messing my card up? here is my Xorg.0.log http://pastie.org/737194
adamk: rah, That's not unusual... Nor is it necessarily a bad thing. It's not like all the developers can drop what they are doing to work on a single bug that pops up, especially if they can't reproduce it.
rah: adamk: I think it is a bad thing
TBBle: On brief examination, adamk's bug was quite easy, both to fix and to reproduce.
adamk: rah, It's just the way open source has always worked.
rah: adamk: I think why it could possibly be a good thing, either
glisse: rah: i updated the bug with a patch to gather more debug info
adamk: rah, Open source driver developers either work on what interests them or what they get paid to work on.
TBBle: rah: If you were to do a git regression, for example, to find the actual commit which caused the problem, then it'd probably become much easier to look into. As it is, they'd have to reproduce it to have a very clear idea of what's going wrong.
dileX: rah: as a hint: "I am using GIT master" is meaningless, better you add commit-id and commit-subject. radeon OSS driver-development is Work-In-Progress, changes (and sometimes breakage is) are possible.
adamk: rah, Which, frankly, is no different from any development :-)
rah: eek
rah: glisse: umm.. thanks
rah: I'll test it now
rah: adamk: I guess the problem I have, then, is that no radeon developers seem to be interested in fixing my bugs :)
tobydeh: kmays, what option could be messing up my video?
rah: except for this one that glisse has taken an interest in
dileX: rah: or they havent the hardware to test on :-)
adamk: Or the time :-)
dileX: or lust
glisse: rah: we are interested in fixing all bugs
adamk: And glisse has shown that the developers are certainly interested.
dileX: just kidding
glisse: we are focusing on bugs which affects s/r and basic video mode setup for time being
adamk: It really is just a matter of having the resources.
glisse: also we are focusing on finishing up the kernel part to have solid base for userspace
rah: mmm
TBBle: s/r?
glisse: and fixing regression like one that my rework seems to induce is a top priority
dileX: jupp, and its kernel merge-window for 2.6.33 right now. till next week.
dileX: suspend/resume
kmays: tobydeh: Try running a simply playback of video on your system.. something like this: http://www.youtube.com/watch?v=QtGlHPFCH8A
TBBle: Thanks
tobydeh: ok kmays trying now
glisse: rah: also in the bug document anythings special you do to trigger the bug, like 10firefox tab open bunch of video playing, opengl games running ...
tobydeh: kmays, its not very good quality but it plays without jumping
rah: glisse: I'll bear that in mind
tobydeh: i get the occasional horizontal line for a slip second but im putting that down to flash
kmays: hmm
rah: ok, bbiab
adamk: rah, Oh, and as for why for one of the developers commented on my bug the next day... It's because I had been actively discussing that bug with one or more of the developers prior to opening it up.
rah: adamk: mmm
rah: bb
adamk: rah, Which is probably also part of the reason why glisse responded to your bug :-) Polite poking on here is often a good thing.
tobydeh: any ideas kmays ? want to see some log files?
kmays: your video playback...coming from HD?
tobydeh: kmays, noimjust playin a vob from a dvd that i ripped
tobydeh: out fromdviinto hmi
tobydeh: fom dvi to hdmi*
kmays: if you have mplayer or vlc..just do a simple playback or use mplayer -benchmark to see what is gives you.
tobydeh: ok
kmays: mplayer -benchmark -nosound ...
tobydeh: kmays, just the last line?
kmays: yes
tobydeh: A: 19.9 V: 19.9 A-V: 0.001 ct: 0.031 496/993 10% 0% 0.9% 0 0
tobydeh: hold on, with -nosound i get:
tobydeh: V: 88.2 2204/4409 10% 1% 0.0% 0 0
kmays: better.. but needs a little firepower.
kmays: ;)
tobydeh: so the problem is with my soundcard drivers? slowing it down?
tobydeh: got some firepower for me!?
kmays: let me check you logs for a sec.
tobydeh: ok which ones
rah: glisse: I've been very gentle about starting up my desktop
rah: glisse: nothing in particular has started the error messages
rah: something has though
rah: glisse: http://bugs.freedesktop.org/attachment.cgi?id=31934
kmays: tobydeh: Try mplayer -dr -nosound -vo xv yourmoviefile
tobydeh: kmays, ok
hifi: btw. does anyone know if HL2 works better on R700 than R500, or at all?
kmays: hifi: better... spped or rendering? ;)
kmays: speed
hifi: speed
kmays: speed/rendering - RV770 wins.
hifi: how big of a margin?
hifi: thinking of switching my X1950 Pro to HD 4650 (64bit crap)
hifi: I was once again fooled to buy 64 bit...
kmays: relative...really... I'd go for a 4850 overall if you make the leap.
tobydeh: kmays, it plays without juddering but it still has lots of horizontal lines and is a bit flickery
kmays: maybe even a 4830 (hmm).
tobydeh: the lines appear at regular intervals and dissapear about once every 0.5 seconds
hifi: kmays: I have the card in another machine
kmays: You can play games like HL2 with that card..just that you'll get system slowdowns if you try to push it a bit with some of the higher visuals.
kmays: not to digress here.
kdekorte: What is the best way to us git to get the latest code. I keep having merge issues when I pull drm-radeon-testing and so I have to delete and recheckout the branch
glisse: rah: are you using kde ?
rah: glisse: no, gnome
rah: glisse: starting gnome up didn't cause any errors, either
glisse: rah: bug happen when you open firefox ?
rah: glisse: in fact, I think the thing that error only occurred after I'd started up everything I normally use; gnome, iceweasel, evolution, xchat, openoffice and finally, hmm.. okular, which is a kde application
rah: the bug didn't happen until I after I'd started okular
rah: I normally use evince but for some reason it seems to have disappeared from my system
marvin24: glisse, rah: it crashes here when using openoffice under kde
glisse: hates kde
rah: righty
rah: scrolling in evince causes it
rah: yep, definitely scrolling in evince
rah: woah
rah: and scrolling in okular
rah: okular seems to cause a lot more errors
glisse: yeah anything which does dl/up to screen will cause that
glisse: kde is more problematic because it allocate tons of small buffer
glisse: qt people tried to be clever but in the end the are a pain to us
rah: yes, dl/up by dragging a selection in iceweasel also causes it
rah: btw, I do have Option "EXANoDownloadFromScreen" "on" in my xorg.conf
lordheavy: glisse: it must be the the reason i've got lot of slow down (with X cpu ressource growing) during several seconds, i'm under kde :-p
rah: glisse: do you want 19M of dmesg output?
rah: gzips it
glisse: rah: no it's fine
rah: ok
lordheavy: here i've got lot of slowdowns/stalling but nothing in logs
rah: glisse: in case you change your mind, http://pkl.net/~node/misc/lots-of-dmesg-output.gz
rah: agd5f: heh, thanks :)
glisse: rah: attached a new patch which should work around the issue
rah: compiles
rah: glisse: this is a work-around and not a fix?
glisse: well it's bit both
rah: ok
rah: bbiab
rah: don't have any errors yet
dileX: O.O. thought drm-linus is in 2.6.32-git5, but drivers/gpu/drm/* commits mostly are typos
lordheavy: got font corruption while running opengl app http://imagik.fr/view-rl/175804
lordheavy: damn cannot reproduce it
da1l6: hi
da1l6: Just installed kernel 2.6.32 to get r600 3D working, but it seems i have bad luck. Even glxgears refuses to work :(
da1l6: "deonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info."
da1l6: *drmRadeonCmdBuffer
da1l6: Details here: http://pastebin.com/m5ea3955e
agd5f: da1l6: you need a newer mesa
da1l6: git branch?
hifi: where I can get the IRQ patch for 2.6.32?
elm: what if I cann not install the http://cgit.freedesktop.org/xorg/util/macros/ on path due to missing permissions?
elm: http://bugs.freedesktop.org/show_bug.cgi?id=24505
elm: how to circumvent the problems
hifi: found it
elm: ?
hifi: uh, not related
elm: :(
hifi: hmm, I need a 2.6.32 rebased version...
glisse: Zajec: i will try to review your patch tomorrow
glisse: haven't had time today
Zajec: glisse: sure :) i just hope we will manage to do that before merge end
glisse: Zajec: don't worry i think we will be allowed to add that
Zajec: glisse: maybe i'll check HDMI patch tomorrow if it still applied
glisse: even after merge window
Zajec: you think? would me nice
Zajec: don't know Linux enough :)
Zajec: *Linus
kdekorte: hifi, the patch is in the drm-radeon-testing branch
glisse: we can sneak it in with the help of Santa ;)
Zajec: glisse: Christmas sounds like a good argument :P
Unggnu: hi all
fscan: hmm .. i just updated to drm-radeon-testing and got massive screen corruption when running x
Unggnu: What is the status of the Powerplay implementation?
Unggnu: for HD4xxx cards
fscan: the last working configuration for me was drm-radeon-testing before the git tree reorganization
fscan: i had to do a fresh checkout, so i guess a bisect is not possible
fscan: hardware is hd4850, mesa,libdrm and radeon driver from git (they work with my last kernel build)
fscan: the only errors i get in dmesg are some edit mode valiation errors
Zajec: glisse: what is state of your function calculatining minimum clocks for current mode(s)?
Zajec: is that sht working?
hifi: whats the difference between drm-linux, drm-radeon-next and drm-radeon testing?
hifi: they all seem to be quite synced together
kdekorte: hifi, just different releases of the same code more or less. airlied recommended using drm-radeon-testing for most users
fscan: to clarify, the corruptions are mostly font corruptions (gdm renders ok, except for the font)
leifer: agd5f: looking at bug #19960, your comment #29
leifer: agd5f: have a question about trying your different PLL settnigs
leifer: agd5f: do i just do something like " pll_flags |= RADEON_PLL_PREFER_HIGH_REF_DIV;" above RADEONComputePLL_AVIVO() ?
agd5f: leifer: no, the new code doesn't use the flags
leifer: agd5f: ah ok
leifer: agd5f: is there anything i can try to help with this bug?
leifer: agd5f: btw, i'm Leif Gruenwoldt from the comments on that bug
glisse: Zajec: need to go through bandwidth computation again to finish it
agd5f: leifer: might try turnig off coherent mode
agd5f: leifer: xrandr --output DVI-0 --set coherent_mode 0
adamk: Yay for coherent mode!
Zajec: glisse: ok
agd5f: for non-KMS
agd5f: leifer: xrandr --output DVI-0 --set coherent 0
Zajec: glisse: right now I see some corruptions when reclocking... weird, i didn't have that earlier
Zajec: glisse: it may be because I hacked it to downclock by about 80%
agd5f: for KMS, but for KMS, you need the latest drm bits from airlied's drm-radeon branches
Zajec: but it happens only while reclocking....
Zajec: so this does not seem like corruption because of too low clock
agd5f: Zajec: if you rebase you patch against drm-radeon_testing or next, you can use the work queue added by the hpd code
Zajec: glisse: if you will review that, you will notice i didn't take any modesetting mutex
Zajec: agd5f: ok, thanks
Zajec: agd5f: i think we will also use that for HDMI
agd5f: yeah
agd5f: you only need one
Zajec: glisse: that's because I disable PM from modesetting function
Zajec: glisse: so I don't additionaly try to lock it from PM
tball: How is powermanagement for kms evolving? :)
kdekorte: Zajec are you hoping to get KMS PM into .33?
hifi: is building Ubuntu lucid 2.6.32 kernel with radeon-drm-testing patches
Zajec: tball: i try to get it mainline :)
Zajec: basic infrastructure
kdekorte: just upgraded to latest drm-radeon-testing from yesterdays and now I'm getting a little corruption in compiz titlebars (rv635, git everything)
spreeuw: kdekorte: what kind of corruption?
kdekorte: looks like the wrong buffer when transparency is used in the titlebar of the window
spreeuw: does it look like this:
spreeuw: http://yfrog.com/iyscreen003yp
spreeuw: see the menu and smoke corruption
spreeuw: ni idea what functions are used for that smoke
kdekorte: no...
kdekorte: let me try and screen cap it
kdekorte: spreeuw, looks like this: http://imagebin.ca/view/gKgORJU.html
spreeuw: hmkay
kdekorte: I am using mesa in opengl 2.0 mode, but only think I did was get the newer kernel from last night to today
fscan: for me too, in addition all the text is garbage (even in non composited mode)
kdekorte: I only see it in compiz, metacity is fine
kdekorte: Ah I do have font corruption in gnome-terminal now
kdekorte: crap...
fscan: the font corruption happens to me as soon as i start gdm
kdekorte: when I resized gnome-terminal corruption went away...
honk: I had corruptions like that before I upgraded mesa 'n stuff yesterday
fscan: running an older kernel (pre git restructure) works fine
kdekorte: I have a 2.6.32-rc9 kernel... I might try going to that one
kdekorte: cause that is after the restructure
kdekorte: like I said it was fine with yesterdays kernel
fscan: hmm .. i have 2.6.32.y + drm-radeon-testing
kdekorte: I can make the gnome-terminal corruption come back by running glxgears
kdekorte: remember seeing this problem before.. it was a buffer issue
fscan: had to clone from new after git restructure
honk: kdekorte: I'm running the latest drm-radeon-testing kernel :]
kdekorte: honk, what card?
honk: like I said: make sure your mesa, libdrm and ddx are up to date, too
kdekorte: I'm on a rv635
honk: r700
kdekorte: yeah everything is up to date
fscan: they are, git master from a few hours ago
honk: *shrug*
fscan: my hardware is rv770
honk: guess I'm just lucky ;MD
kdekorte: BRB.. gonna try with older kernel
kdekorte: yup using a kernel from a couple of days ago seems to make the corruption go away
Zajec: kdekorte: of course I want this for .33 :)
Zajec: kdekorte: tomorrow glisse maybe will review my patch
hifi: mysterious corruption?
honk: kdekorte: bisect it ;P
hifi: I had it yesterday
hifi: tried to revert ddx and everything, nothing worked
Zajec: kdekorte: it's hard code because of many threads
tball: Zajec, Cool :-) Is it working okay now, or is it very experimental??
Zajec: PM works itself in a loop, it can be disabled from modesetting and there is also IRQ which queue it's work...
Zajec: tball: working stable for me
Zajec: tball: i didn't experience problems with it
Zajec: there is some weird thing when I try to force low engine clock
Zajec: have to understand that
tball: :)
tball: sounds good
tball: So I could in theory use kms now with working pm?
mjg59: Zajec: You're just changing the engine clock right now?
tball: If only it can keep my laptop cool,i would use it fulltime
spreeuw: is http://wiki.x.org/wiki/radeonBuildHowTo still up to date for latest kernel drm?
Zajec: mjg59: yup
Zajec: tball: for now it just downclocks engine by some dumb 50kHz
Zajec: 50MHz
Zajec: tball: it's about introducing infrastructure
mjg59: Zajec: Ok. I guess we're still not sure how to calculate the memory clock required
Zajec: tball: getting real values will come later (should be soon)
mjg59: Zajec: My measurements suggested that memory reclocking was what gave the biggest win
Zajec: mjg59: yup, Jerome has some code for that but he has to fix it
Zajec: mjg59: asked him minuts ago
mjg59: Ok, cool
Zajec: mjg59: do we need to somhow enable memory reclocking before reclocking it? i think i saw sth like that in your patch
Zajec: mjg59: not sure how to call it...
Zajec: mjg59: preparing for reclocking or sth
Zajec: void radeon_atom_initialize_memory_controller(struct drm_device *dev)
mjg59: Zajec: The Atom code for memory reclocking takes too long
Zajec: that is what I meant
Zajec: what does it do?
chomwitt: whats the difference between radeon driver and xf86-video-ati ?
mjg59: Zajec: So what I did was implement the register programming by hand, which requires per-core code
mjg59: chomwitt: -ati is a metadriver that loads the appropriate driver
mjg59: Zajec: And then use atom for the bit that works fast enough
Zajec: chomwitt: same thing
Zajec: mjg59: ah, so void radeon_atom_initialize_memory_controller(struct drm_device *dev) is some part of standard memory reclocking?
Zajec: yeah, i see it is
Zajec: ok, understand now
mjg59: Zajec: But it means reading the docs per core to work out what needs doing
Zajec: mjg59: yeah, i know
mjg59: Which kind of sucks
Zajec: mjg59: i guess i'll just read AtomBIOS command
Zajec: mjg59: guess it'll be faster :)
mjg59: Heh
mjg59: Yeah, if you can work it out then that works
maligor: it'd suck even more if you didn't have the docs
Zajec: maligor: right now I'm going to ignore docs :P
maligor: (since I've done that with a embedded system cpu)
mjg59: It's worth re-testing on newer cards to find out if it's fast enough there
maligor: was trying to rewrite the bootloader
Zajec: mjg59: ok, i'll check it
Zajec: mjg59: anyway even parsing AtomBIOS will take some time...
Zajec: mjg59: i think i'll rewrite it anyway
mjg59: Zajec: Sure, but computers are fast
mjg59: The only reason the memory reclocking code isn't fast enough is that it sleeps for several ms
Zajec: mjg59: may be important if we will want dual head configurations power managened some time
chomwitt: mjg59 , Zajec thanks
mjg59: Zajec: Oh, ugh. I guess so, but that's always going to be a nightmare
Zajec: mjg59: so you skipped sleeping part?
mjg59: Zajec: Yeah, that's the bit I did by hand
Zajec: mjg59: i guess it will :)
Zajec: mjg59: however may be possible... actually basic version in my head doesn't sound so scary :)
Zajec: blah, wait, stop, let's get single-head mainline first :P
yangman: you could also hack the atom parser so you can selectively disable sleep
Zajec: yangman: thought of that
Zajec: yangman: quite hackish... but could work
mjg59: I don't think it's fine-grained enough
mjg59: There's a few cases where you do want to sleep
chomwitt: mjg59: sorry, but i read sth that implies tha xf86-video-ati contains many drivers: radeon , mach, r128 etc. is that right?
yangman: yeah
yangman: I haven't looked at any of it in a long time
mjg59: chomwitt: Yes. It loads the correct driver.
chomwitt: mjg59: ok. thanks.
Zajec: err, weren't that drivers excluded from -ati?
Zajec: mjg59: we could hack AtomBIOS parser to give it some maximum amount of sleep time...
Zajec: but as I said - quite hackish :)
agd5f: mach64 and r128 were split into separate repos
agd5f: Zajec: but the sleeps are important. they are there for a reason
agd5f: generally to wait for the plls to lock and such
Zajec: agd5f: that talk seriously with mjg59 who ignored them :P
mjg59: No, I ignored one of them
Zajec: mjg59: still.... :)
Zajec: mjg59: but i believe you may be right, maybe we can reduce some sleeps
tulcod: which driver has better 3d performance for an HD3650: radeon or radeonhd?
hifi: they share the same code
tulcod: so no serious difference?
hifi: (ditch radeonhd)
tulcod: oh - why's that?
tulcod: i'm already using radeon atm btw
hifi: it's kind of.. dead?
yangman: tulcod: 3D is handled by mesa
tulcod: hifi: hm, ok
hifi: someone could explain it better
tulcod: yangman: it is? man - i find it hard to catch up on the internal technology structure
yangman: tulcod: http://yangman.ca/blog/2009/10/15/linux-graphics-driver-stack-explained/
tulcod: for example, phoronix is talking about gallium3d all the time. wth does it do?
hifi: was just trying to find that :)
hifi: very good reading
ajax: gallium doesn't _do_ anything. it's just a name for some code.
yangman: ugh, phoronix
tulcod: yangman: i'm not getting a CSS, btw
yangman: tulcod: there isn't any ;)
ajax: in particular, for one of the two major designs of mesa-based 3d drivers.
tulcod: ajax: in the same sense as aiglx isn't really anything more than a standard, too?
MostAwesomeDude: I'm still waiting for a good chance to use Pylladium for Python-based Gallium loader. :3
ajax: aiglx is more like a name of a feature than a standard, but, yeah, sure.
tulcod: yangman: well, it looks like your site is broken... not that I disrespect broken sites, or am bothered by it...
tulcod: anyway, thanks guys, i'll try and read up on it
yangman: tulcod: I like to think of it as a filter to weed out people that care more about style than content
tulcod: (and i'll deinstall my radeonhd driver)
yangman: but, in all honestly, it's just me being lazy
tulcod: yangman: hehe, got it ;)
eosie: gallium3d is a set of APIs, drivers, and utility modules
tulcod: yangman: care for some improvement hints?
tulcod: s/hints/ideas/
yangman: sure. always open to ideas
eosie: s/utility/auxiliary/
tulcod: yangman: "XAA, EXA, and UXA all fall under the DDX’s domain, in addition to Xv.". maybe add a small note here that these technologies are related only to 2D stuff?
yangman: well, the assumption is the reader is aware of what they are
tulcod: oh, ok... well, i happen to know that, but i imagine some people might not
kdekorte: tulcod, XV can be a little weird in how it is implemented and of course all this changes with gallium
tulcod: yangman: okay, thanks for that article... suddenly a couple of things make complete sense :)
yangman: good :)
tulcod: so what's gallium?
tulcod: :)
yangman: heh
kdekorte: gallium kinda turns the model upside down
yangman: well, what gallium is is a way of writing graphics drivers
yangman: it's a specific formalization of the abstractions that inevitably end up being used
tulcod: hm...
tulcod: so it kind of defines the way your DDX needs to be written?
yangman: it's not as specific as that
kdekorte: I believe it will be X talks to gallium which then decides what subsystem handles the request and eventually goes to KMS in the kernel for display... but I could be all wrong
yangman: http://www.lunarg.com/wordpress/technologies/gallium-3d/gallium3d-online-developers-workshop/ "Overview and Motivation for the Architecture" will hopefully give a better explanation
tulcod: yangman: thanks :)
fscan: i bisected the corruptin i had earlier ...
fscan: the offending commit is 779720a3209849be202ac36a811e934865c50971
fscan: drm/radeon/kms/r600/r700: fallback gracefully on ucode failure
fscan: i have an rv770, so i guess its in the rv770.c
fscan: ucode gets loaded ...
fscan: the only errors i get are about some invalid EDID
fscan: brb
fscan: ok, i can confirm that reverting the commit "779720a : drm/radeon/kms/r600/r700: fallback gracefully on ucode failure" fixes my screen corruptions
eruditehermit: hey
Janhouse: please help me make xorg.conf file for my ATI Technologies Inc RS690M [Radeon X1200 Series] card
Janhouse: without that file my card works in some kind of power saving mode and I get really low fps if cpu usage is low
Janhouse: I am using Ubuntu Karmic
Wizzup: man radeon has all options
Wizzup: Do you use the proprietary driver?
Janhouse: I use radeon drivers
Janhouse: opensource radeon
Janhouse: that is why I came to this channel
AstralStorm: hello there
AstralStorm: why is drm-next behind drm-radeon-next now?
tormod: Janhouse, you get higher fps if cpu is busy?
Janhouse: yes
Janhouse: I am using laptop
Janhouse: it is funny
Janhouse: ok, it is sad actually...
tormod: Janhouse, how are you measuring fps?
Janhouse: with compiz benchmark
Janhouse: I need compiz
Janhouse: don't tell me not to use it
Janhouse: :D
soreau: eosie: I just finished updating everything (radeon-drm-testing kernel, libdrm, mesa, ddx) and everything is still the same. fisheye works, et still is a total visual mess, I get "neverball: radeon_cs_gem.c:121: cs_gem_write_reloc: Assertion `bo->space_accounted' failed. \n Aborted" and mipmap still shows visual problems in expo where the wallpaper should be
soreau: Janhouse: First, don't rely on compiz benchmark for fps. Second, are you having any real problems?
Janhouse: yes
Janhouse: I get low fps!
soreau: Well i can see we're not gonna get too far like this
Janhouse: compiz animations are laggy
Janhouse: moving windows too
soreau: Pastebin /var/log/Xorg.0.log
AstralStorm: soreau: cache failure :)
soreau: eosie: and fwiw, neverball was working before this update
soreau: AstralStorm: Excuse me
soreau: ?
AstralStorm: soreau: well, someone gets to trace that
spreeuw: Janhouse: dont use compiz
Janhouse: :D
AstralStorm: others had shader cache fail completely on them
soreau: AstralStorm: This is only with r300g. r300 works fine
Janhouse: soreau, http://pastebin.com/f436e074d
soreau: Well except for the fisheye mode :P
Janhouse: I have nvidia 8800gts on my desktop pc
Janhouse: with ubuntu karmic
Janhouse: omg, so sweet.
Janhouse: I wish radeon drivers will once be as good :)
AstralStorm: soreau: hmm :)
Janhouse: dear santa, give us completed opensource radeon drivers!
Janhouse: :D
soreau: Janhouse: Well everything looks fine afaict except you may have a lower end card..
soreau: Janhouse: You can try enabling KMS to see if it changes anything for you
Janhouse: do I do it in xorg.conf?
Janhouse: I am reading man radeon
Janhouse: to make that config file
Janhouse: ...
soreau: Add radeon.modeset=1 to kernel parameters
Janhouse: to gernel parameters?
Janhouse: where?
soreau: afaik, I think you can do it with both grub1 and 2 by using 'E' at the grub loader screen
soreau: to make it 'permanent', it is different for grub1 or 2
Janhouse: I'l try it now.
soreau: Also, creating an x conf file will not help you
Janhouse: took some time to get to grub2 menu :D
Janhouse: how can I check if I successfully set that radeon.modeset=1
tormod: Janhouse, check dmesg
Janhouse: [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.31-16-generic root=UUID=31325816-79e3-420d-814a-09733472a1d1 ro quiet splash radeon.modeset=1
Janhouse: [ 0.000000] Unknown boot option `radeon.modeset=1': ignoring
Janhouse: [ 1.933680] [drm] radeon kernel modesetting enabled.
Janhouse: [ 1.935583] [drm] radeon: Initializing kernel modesetting.
Janhouse: [ 2.050769] [drm] radeon: kernel modesetting successfully initialized.
Janhouse: unknown option
Janhouse: ...
tormod: Janhouse, never mind, the module read the option when it loaded
Janhouse: well
Janhouse: I logged in, started compiz benchmark
tormod: (actually, modprobe parsed the cmd line)
Janhouse: while something was loading in background I had 30 fps
Janhouse: now I have ~17 :D
Janhouse: soreau, any other ideas>
Janhouse: ?
soreau: Janhouse: Try reset to defaults in ccsm>Prefs
Janhouse: where?
soreau: Some compiz effects are more resource intensive than others
soreau: ccsm>Preferences
Janhouse: oh
Janhouse: I have defaults
Janhouse: it is not compiz fault
soreau: Well I guess your card sucks then
soreau: Those RS series have had nothing but problems
Janhouse: plays HD videos fine
Janhouse: on dekstop pc with same card fps was fine.
Janhouse: and
Janhouse: if I have high cpu usage I have good FPS
Janhouse: do you understand it?
Janhouse: there must be some stupid power saving feature
Janhouse: or something
soreau: Sounds like your 2D works better than your 2D :P
soreau: Err.. than your 3D
Janhouse: y
Janhouse: isn't there anything I can do by configuring xorg.conf?
Janhouse: or something...
agd5f: Janhouse: turn off KMS
Janhouse: I don't know how can I edit some preferences
Janhouse: is kms on by default?
agd5f: Janhouse: depends on your system
Janhouse: OS?
Janhouse: Ubuntu Karmic
soreau: Janhouse: KMS is off by default. The radeon.modeset=1 turned it on
Janhouse: ok
soreau: KMS is currently slower
Janhouse: doesn't matter if I use kms or not.
Janhouse: I get low fps :)
shadowmaster: Janhouse: that's for 3D?
soreau: You know last time I tried gnome here on gentoo, it really sucked, making compiz a choppy mess
soreau: Janhouse: Is this a clean install or upgrade from karmic?
Janhouse: soreau, I thought that clean install would help so I have clean install now
Janhouse: it didn't help
Janhouse: and
Janhouse: I still have to enter xvattr -a XV_BICUBIC -v 0 in terminal
Janhouse: to make .avi problems go away
soreau: Janhouse: Well, can you try creating a different user and logging in with it to see if there's any difference?
Janhouse: http://bugs.freedesktop.org/show_bug.cgi?id=23322
Janhouse: I did
Janhouse: the same
Janhouse: I haven't configured much. It is almost like clean installation
Janhouse: soreau, are you suggesting kde?
soreau: No no no
Janhouse: :D
eosie: soreau: I don't think any of my changes have any impact on the "bo->space_accounting" assertion failing, but if you like, you can bisect that issue and report
soreau: I would never make such an outlandish suggestion. I said different user, not slower DE :D
soreau: eosie: Well the problem is, I wouldn't know which component to bisect
eosie: if you undo my latest mesa patches, does it work?
soreau: eosie: All's I know is it was working before, so i guess I could try to see if an older mesa commit is good..
scarabeus: agd5f: hi, can i have bit evil packager question? Users are requesting some snapshot of 6.13 series (or what ever you plan to call it), would it be possible to release some beta/rc version already? The code has mostly fixes comming in lately, so it might get more testing audience if we (distros) include such package :] (or is there some roadmap i missed?)
Janhouse: well
Janhouse: I turned off compiz
Janhouse: and enabled metacity compositing feature
Janhouse: at least I get shadows...
Janhouse: but there is no fun. no animations, no nice plugins, nothing. :(
Janhouse: oh
Janhouse: great
Janhouse: guess what
Janhouse: without compiz enabled I can't watch movies without lags
Janhouse: I set it to use XV
Janhouse: no I was wrong
Janhouse: it is because compositing is enabled
Janhouse: I didn't have this problem on jaunty
Janhouse: f**k. This driver gets worse. :(
Janhouse: at least for my card
soreau: eosie: Yea, I checked out the commit before your most recent patches and it did not fix it
soreau: How can I figure out which component is responsible for neverball: radeon_cs_gem.c:121: cs_gem_write_reloc: Assertion `bo->space_accounted' failed.?
soreau: tried to locate radeon_cs_gem.c
eosie: it's in libdrm
soreau: eosie: You think the problem may be in libdrm or is libdrm just pointing out there is a problem elsewhere (perhaps in the kernel)
otaylor: soreau: that's either in libdrm or mesa, not in the kernel
otaylor: soreau: would tend to guess mesa, since there's a lot more complexity there than in libdrm, but it's hard to say without debugging the details - that message basically means "stuff got done in the wrong order"
soreau: otaylor: The file or the problem?
otaylor: soreau: radeon_cs_gem.c is in libdrm, but the problem likely lies elsewhere
soreau: That's what I was assuming
soreau: otaylor: Thanks, I might try finding a good mesa commit then
eosie: soreau: there is problem either in libdrm or in mesa
soreau: eosie: Ok, I will assume it's in mesa then since that's easier for me to bisect :)
eosie: good guess
soreau: I am building a 10 day old commit now
eosie: soreau: I should have asked you about this before... could you pastebin a backtrace from gdb?
soreau: eosie: Sure, hang on
flyback: http://www.urbandictionary.com/products.php?defid=238319 <--- MOTHERCANUCKING AWESOME!
soreau: eosie: Ugh.. I am not good with gdb though. How should I attach it? I run neverball, it goes full screen and plays about half a second of sound then dies
soreau: but I never see any visual in the fullscreen window it creates in that short time
soreau: eosie: I am used to attaching gdb to a running process, then making that process crash
soreau: but this one crashes right away
eosie: huh, now I have the same issue as you do
soreau: :)
eosie: there is something fishy going on here
soreau: eosie: The strange thing is, it doesn't output that message the first time I run it (1st time in an X session?) it just dies. But the secong time, it dies and gives that message
Janhouse: any ideas why video has lags?
Janhouse: low fps
Janhouse: or something
Janhouse: on jaunty at least that worked fine
soreau: Janhouse: If it's that bad, you can go back to jaunty and try again with lucid. Or, you can use latest mesa from xorg-edgers repo
soreau: I don't know what else to tell you
Janhouse: I just installed latest from xorg-edgers repo
Janhouse: and kernel .32
Janhouse: didn't fix it
Janhouse: weird...
soreau: eosie: Well i found a good commit
soreau: eosie: So I'm gonna bisect now.. please stop me if you happen to figure out what the problem is ;)
agd5f: Janhouse: you likely have you CPU powersaving set too aggressively
soreau: He left.. I'll tell him if he comes back
soreau: agd5f: How would you adjust the cpu power saving anyway?
agd5f: soreau: cpu governors in the kernel
soreau: agd5f: Does this mean you have to recompile the kernel? oO
agd5f: soreau: no most kernels have them enabled by default
agd5f: there are different profiles for how agressively they get downclocked
soreau: agd5f: So.. how do you change it without recompiling?
agd5f: soreau: there's an interface
hagabaka: does flash run smoothly for anyone with radeon 9800 Pro?
soreau: agd5f: How do you use that iface?
agd5f: soreau: http://www.thinkwiki.org/wiki/How_to_make_use_of_Dynamic_Frequency_Scaling
agd5f: for example
soreau: eosie: Does it matter if you compile with --disable-egl or not?
eosie: no, it doesn't
agd5f: soreau: http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html
soreau: ok thanks
soreau: agd5f: Ok, thanks. I will pass the info along
soreau: (if he comes back and you're not here)
airlied: Zajec: okay I rebased HDMI audio patch
airlied: its on drm-radeon-testing in a few mins
Zajec: airlied: huh
Zajec: airlied: you were faster
Zajec: airlied: i wanted to do it... :|
Zajec: :)
airlied: well I built it ;-) I can't test it here
Zajec: airlied: me neither :p
Zajec: airlied: will have access to HDMI received tomorrow
Zajec: airlied: will test
Zajec: airlied: i can see it :)
spreeuw: flash crashes browser here when going fullscreen
spreeuw: I've had it working sometime in the past
Zajec: wow, that will be really happy release that .33 :)
spreeuw: with hardware accelration on it almost has no cpu load
spreeuw: linux 2.6.33?
Zajec: airlied: any idea how can I debug lock up on resuming?
soreau: spreeuw: You know, adobe's proprietary flash pluign actually detects if compiz is running and disables gl if so?
Zajec: airlied: i'm afraid i won't able to use netconsole :|
soreau: Janhouse: you likely have you CPU powersaving set too aggressively
Zajec: spreeuw: yup
Janhouse: what cpu powersaving?
Janhouse: I haven't set anything
spreeuw: soreau: don't know, you can see the status when rightclicking a flash video
Janhouse: I don't have any options in bios (this is laptop)
spreeuw: and check the hardware acceleration option
Janhouse: and have default Ubuntu Karmic settings
soreau: Janhouse: He pointed to these links http://www.thinkwiki.org/wiki/How_to_make_use_of_Dynamic_Frequency_Scaling http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html
spreeuw: and there are some mms.cfg settings too
spreeuw: google it
soreau: spreeuw: Anyway, if you have compiz running it disables gl for fullscreen
agd5f: Janhouse: if you make the CPU scaling less agressive you sould see better performance
soreau: spreeuw: Open the plugin in a hex editor and see for yourself. Changing 'compiz' to compix' for example works around it
spreeuw: I dont mind, since I do not use it
Janhouse: ok
spreeuw: with hw accell its still broken, so nothing lost there
Janhouse: I manually set cpu to 2.10 ghz
spreeuw: fullscreen crashes ;p
Janhouse: now I get 37 fps
Janhouse: but this is laptop!
Janhouse: there are 5 steps
soreau: I don't use it either.. usually just let the vid d/l into /tmp and play it with mplayer
Janhouse: 2.10, 2, 1.8, 1.6 ghz, 800mhz
Janhouse: it is usually on 800 mhz
spreeuw: Janhouse: the CPU?
Janhouse: 1.6ghz, 41fps
Janhouse: cpu
Zajec: airlied: coding style? "if(changes)"
spreeuw: Janhouse: you know you can change it righht?
Janhouse: change what?
airlied: Zajec: oops I'll checkpatch it and repush ;-)
spreeuw: its a linux kernel setting, it can be chanmged on the fly in proc
Janhouse: cpu frequency?
Janhouse: I do it using CPU Frequency Scaling Monitor 2.28.0 applet
spreeuw: the autoscaling yes
spreeuw: echo performance | tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Zajec: airlied: "+#define AUDIO_TIMER_INTERVALL 100 /* 1/10 sekund should be enough */" sekund :)
spreeuw: puts it in full throttle
spreeuw: you need it for all low latency stuff
Janhouse: my question is. Shouldn't video processor be separated from cpu?
spreeuw: like video and probbaly your 2d video accel too
spreeuw: Janhouse: no some stuff is still softrendered
Janhouse: :|
Janhouse: everything? :D
spreeuw: see if disable low impact fallback makes a difference in driconf
Janhouse: what, where?
chithead: in driconf
spreeuw: if your video driver doesnt support acceleration or critical parts then everything yes
Janhouse: and what is driconf?
soreau: Janhouse: apt-get install driconf, should appear a gui app in your menu
spreeuw: its the 3d driver config panel for all mesa drivers
Janhouse: oh
spreeuw: it writes a little xml to .drirc
spreeuw: if you doubt something you can delete that file
spreeuw: to get the defualts
Janhouse: installed
Janhouse: opened it
Janhouse: what am I looking for?
Janhouse: tcl mode : use software tcl pipeline ?
spreeuw: no
spreeuw: disable low-impact fallback
Janhouse: methid to limit rendering latency: let graphics hardware emit a software interrupt and s;eep
spreeuw: what is it set to?
Janhouse: it is set to yes
Janhouse: by default
spreeuw: no dont touch the other settings
spreeuw: ok then its already good
spreeuw: as good as it gets
Janhouse: no it is not!
Janhouse: :D
spreeuw: oh
Janhouse: method to limit rendering latency sounds interesting
soreau: It's like you just gave a kid a screwdriver xD
Janhouse: lol :D
Janhouse: there aren't many options
Janhouse: I am in beginner mode...
soreau: The defaults should be sane and you shouldn't mess around in there
spreeuw: you dont have to change anything
spreeuw: forget I mentioned the program and rm ~/.drirc
Janhouse: fine...
flyback: is bleeding out his leg in 3 places
spreeuw: shootingrange?
spreeuw: or cat?
spreeuw: or screwdriver..
soreau: spreeuw: idiot.
spreeuw: dont know the expression
Janhouse: but it is weird that if I have no cpu usage at all and cpu frequency is <1.6ghz I get bad fps
Janhouse: and this is dual core processor
Janhouse: it should be enough
soreau: Janhouse: It should be painfully obvious to you then, that <1.6Ghz is too slow for what you want
spreeuw: maybe it slows down the memory bus too
spreeuw: and with that maybe your video memory
Janhouse: maybe
eosie: Core2 Duo 1.6GHz is faaaaar from slow
Janhouse: soreau, I don't understand why it is not making cpu usage.
Janhouse: It only needs frequency
spreeuw: you dont see cpu load?
Janhouse: it doesn't affect anything else and if I will have 100% cpu load from other programs, video will run fine
spreeuw: try looking at top
spreeuw: instead of a gui app
Janhouse: ok
Janhouse: so
Janhouse: now I have cpu frequency set to 800mhz
Janhouse: top shows
spreeuw: soreau: give this a try with flash http://blogs.adobe.com/penguin.swf/2008/08/secrets_of_the_mmscfg_file_1.html
flyback: just shattered a clock with a glass face on his leg when it came off the wall
Janhouse: Xorg uses 2% cpu and 2.6% mem
Janhouse: 2% cpu from 200% total (2 cores)
Janhouse: and 2gb ram
Janhouse: and ofcourse fps is bad
spreeuw: you only have to look at the cpu totals
spreeuw: 3th line
spreeuw: press 1
spreeuw: to merge them
Janhouse: Cpu(s): 1.0%us, 1.3%sy, 0.0%ni, 97.4%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st
Janhouse: this is @ 800mhz
soreau: spreeuw: 1) That page does not load 2) I don't use flash, perhaps you missed my comment WRT that
spreeuw: ok
mydrmeix: hi im just wondering what kind of performance id get from a radeon 9250 in linux
mydrmeix: would it be better than a intel extreme graphics?
Janhouse: this is @ 800mhz with maximised video in totem
Janhouse: echo performance | tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Janhouse: Cpu(s): 30.2%us, 5.9%sy, 0.0%ni, 63.6%id, 0.2%wa, 0.2%hi, 0.0%si
mydrmeix: im trying to add a card to a slim profile old dell
mydrmeix: and i dont want to pay $50 for a card that wont work
Janhouse: and
Janhouse: you see
Janhouse: cpu usage is only 30%
Janhouse: and video has bad fps
Janhouse: it lags
Janhouse: so
spreeuw: mydrmeix: it will work but not nearly as fast or stable as in windows
Janhouse: why?!
Janhouse: I set frequency to 2.10 GHz
Janhouse: Cpu(s): 11.7%us, 3.2%sy, 0.0%ni, 85.0%id, 0.0%wa, 0.2%hi, 0.0%si,
Janhouse: cpu load now 11%
Janhouse: video has no lags
Janhouse: good fps
spreeuw: Janhouse: you need the power I guess
Janhouse: the power?
Janhouse: what power?
spreeuw: processing power
Janhouse: I need better drivers :(
agd5f: Janhouse: the CPU is still used for video decoding and other tasks
Janhouse: on jaunty I didn't have such problems with video playback
mydrmeix: justin only quakelive im happy on this old dell
Janhouse: I had no problems playing hd videos
Janhouse: now I get lags with dvdrip quality .avi
Janhouse: I am not going to install jaunty again, sorry....
fscan: hmm .. afaik if one thread uses 100% cpu it shows as 50% in top on a dual core cpu
agd5f: Janhouse: it's possible jaunty didn't enable as agressive power saving
fscan: so, your numbers might be misleading
Janhouse: maybe...
Janhouse: agd5f, wrong
Janhouse: with processor that has 2 cores you get 200% max
Janhouse: with 8 cores - 800%
Janhouse: simple as that
agd5f: Janhouse: you have no idea what you are talking about
Janhouse: agd5f, I have server with 2x quad core cpu's
Janhouse: sometimes I get 500-600%
agd5f: Janhouse: CPU frequency!!!!
agd5f: doesn't matter how many cores you have if they are all too slow to do what you need
Janhouse: oh, you are talking about frequency
Janhouse: sorry :D
Janhouse: it is late, I think I must get some sleep.
Janhouse: agd5f, they are not slow.
Janhouse: The problem is in particular drivers
agd5f: Janhouse: you just said, it works fine if you cahnge the frequency
Janhouse: that is the problem
agd5f: jaunty may have used a differently less aggressive frequency adjustment algorithm
Janhouse: it needs 2.10ghz to use 10% cpu for fullscreen video
Janhouse: on 800mhz it uses 30% cpu and has lags
Janhouse: wtf!
Janhouse: then use 100% and don't do lags...
spreeuw: 30% is a huge load
Janhouse: simple
Janhouse: :D
agd5f: Janhouse: at 800 Mhz it can't get what it needs done in the time required
spreeuw: dont expect realtime applications to perform well up to 99%
Janhouse: so where can I change power saving options?
Janhouse: any ideas?
spreeuw: the scaling governor is one
spreeuw: echo performance | tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
spreeuw: is full power always on
Janhouse: that is not good...
spreeuw: there are 2 more below
spreeuw: they others both suck
fscan: have a look at cpufreq ...
spreeuw: especially on an underpowered 1.6ghz c2d
Janhouse: then I have a question
spreeuw: you can barely watch 720 HD on that
spreeuw: if at all
Janhouse: why doesn't video player request higher frequency?
Janhouse: because load is not high enough?
Janhouse: 2.10 ghz
spreeuw: good question
Janhouse: and I think it is AMD
spreeuw: do you have any idea of what to expect of your hardware?
fscan: i had this problem once ... if one core was maxed and the other idle, the governor would not switch to a higher freq.
spreeuw: like an XP driver or something
soreau: eosie: Here you are sir :) http://pastebin.com/m26608661
Janhouse: I am telling you. On jaunty I had no problems at all watching 720p
yangman: Janhouse: have you tried using a different governor?
Janhouse: I tested windows 7 on this laptop too
fscan: but as far as i can tell it's working now ... using the ondemand governor
Janhouse: played warcraft3
Janhouse: swat 4
Janhouse: some other games
Janhouse: governor?
yangman: Janhouse: a different scaling governor than whatever the default is
spreeuw: its a template for freq scaling behaviour
Janhouse: switching to performance mode makes it better
MostAwesomeDude: Janhouse: You need to set your governor to conservative, or maybe ondemand if you're on a desktop.
Janhouse: but I wonder why do I have to do this on karmic
Janhouse: on jaunty it didn't had to use so high frequancy
Janhouse: and had no problems with videos
Janhouse: I guess I should try other os
yangman: Janhouse: try both ondemand and conservative. and make sure it's applied to both cores
AstralStorm: MostAwesomeDude: ondemand works badly on AMD machines
Janhouse: maybe plain debian or something
AstralStorm: they have too slow switching for it
AstralStorm: (and it's dumb anyway, uses 2 states - max and 0)
Janhouse: anyway, thank you for your help. I must get some sleep :)
fscan: AstralStorm: i dont know, it's working ok for me
AstralStorm: fscan: it does, but doesn't power-save well
AstralStorm: conservative with a bit improved thresholds (defaults are too slow) works fine
MostAwesomeDude: AstralStorm: I hear this all the time. Is there a CPU that ondemand *does* work well for?
soreau: MostAwesomeDude: This causes neverball: radeon_cs_gem.c:121: cs_gem_write_reloc: Assertion `bo->space_accounted' failed. \n Aborted http://pastebin.com/m26608661
AstralStorm: MostAwesomeDude: intels
AstralStorm: they have fast switching power states
MostAwesomeDude: AstralStorm: Except, apparently, for Atoms.
AstralStorm: also, armel cpus, but there I'd use conservative anyway for extra power saving
MostAwesomeDude: And Prescotts.
AstralStorm: yes, atoms have slow :)
AstralStorm: also yes
MostAwesomeDude: And Willamettes.
AstralStorm: all core series have fast
AstralStorm: the problem with ondemand is that when it makes a mistake, it's grave
AstralStorm: while with conservative, it's only one step down
AstralStorm: conservative slows down app startup a tiny bit though
MostAwesomeDude: soreau: Hm, if you revert only the change in r300_emit in that commit, does it work again?
AstralStorm: it tends to not ramp up fast enough
AstralStorm: that needs a fix
soreau: MostAwesomeDude: I just reverted to the 'fix warnings' commit and compiling that now
AstralStorm: so it becomes less of a dreaded PI controller and more of a predictor
AstralStorm: needs that D step
soreau: MostAwesomeDude: Afterward if it works, I will try reverting only the r300_emit stuff
AstralStorm: a bit ringier, but better user experience
soreau: MostAwesomeDude: Ok, this is definitely what breaks it. Is there an easier way to revert those changes other than by hand?
eosie: if you revert it, you will break xmoto and other apps
soreau: oh well, it's only like three lines
soreau: eosie: Well we need to test at least
MostAwesomeDude: eosie: The problem is that we can't flush a potentially invalidated CS.
MostAwesomeDude: We need to have atom-based emit. :T
soreau: MostAwesomeDude: Reverted r300_emit.c changes, compiling now
fscan: AstralStorm: will try conservative for a while :)
soreau: MostAwesomeDude: Yup, commenting that if statement out of r300_emit.c fixes it
MostAwesomeDude: soreau: I was afraid of that. :3
eosie: yesterday I was playing neverball and everything was ok... until today
eosie: the question is why it worked and now it doesn't
soreau: libdrm changes?
soreau: wonders how often libdrm changes. :P
AstralStorm: not too often
soreau: I wouldn't imagine so
soreau: Well something changed
soreau: eosie: Ball's in your court now :-)
soreau: eosie: FWIW, xmoto works fine after commenting that if statement
soreau: Will try with master now
eosie: soreau: but not all levels
soreau: eosie: Ah ok
eosie: soreau: challenge cup - #9
soreau: eosie: Yea, that locks it up pretty good
edt: has mesa/ddx/libdrm/drm-next tip been working ok for r600 the last couple of days? Just asking before rebuilding?
eosie: MostAwesomeDude: I didn't know CS can be invalidated, how is that possible?
MostAwesomeDude: eosie: Validate it, then add a reloc for a non-validated buffer.
eosie: oh that one
EruditeHermit: soreau, what sort of shape is r3g in now?
EruditeHermit: soreau, you testing with xmoto?
AstralStorm: edt: I'm using it
soreau: EruditeHermit: It's doing pretty well I must say. I do not use xmoto to test but so far it runs compiz without flaw including mags fisheye mode but of course not alpha blur yet
AstralStorm: edt: works fine so far, one bug with console blanking
AstralStorm: (doesn't disable backlight for some reason now, it did before)
soreau: AstralStorm: What console blanking?
AstralStorm: VT blanking
AstralStorm: you know, dpms
AstralStorm: instead of black I get white ;)
AstralStorm: meaning backlight is not disabled
soreau: EruditeHermit: Anyway, fisheye mode works much faster with r300g than it ever did with classic mesa but as of right now, games are considerably slower
soreau: EruditeHermit: I'm testing mostly with compiz, OA, et, neverball and (just checked) glxgears still has the resize issue (though it runs really smoothly)
Dr_Jakob: soreau: the glxgears resize bug is a known issue, st/dri doesn't call DRI2GetBuffers when the window resizes.
soreau: Dr_Jakob: So what's the fix?
Dr_Jakob: A code fix to make st/mesa notify st/dri on a glViewport call. To check the buffers.
Dr_Jakob: Looking at the intel/radeon driver should tell the basics behind it.
Dr_Jakob: That is the mesa drivers.
tstellar: I have an xpress 200m video card, I am trying to get kms working I have this message: [KMS] drm report modesetting isn't supported. in my xorg.log. Is my card not supported, or is it possible I have misconfigured something?
BioTube: tstellar: the radeon and fbcon modules need to be loaded before x is started
soreau: tstellar: Which distro?
tstellar: Gentoo
soreau: Then you probably just misconfigured something
soreau: tstellar: You will want to make sure KMS isn't disabled by default in staging drivers, then compile latest libdrm, mesa, X and ddx
soreau: Which kernel version are you using btw?
tstellar: I am using 2.6.32. I think my kernel is configure correctly because I have this: [drm] radeon kernel modesetting enabled in dmesg.
tstellar: BioTube: Does the fbcon module have another name? What is the config option for it in the kernel?
BioTube: tstellar: FRAMBUFFER_CONSOLE
BioTube: that's the kconfig option
tstellar: I have fbcon built in, does that matter?
soreau: Nope, shouldn't
soreau: You need to build libdrm-9999 then mesa and xf86-video-ati and X against that libdrm
soreau: X being configured with VIDEO_CARDS="radeon"
tstellar: I'll try rebuilding X, I just upgraded to 1.7.3, and I built libdrm-9999 mesa-9999 and xf86-video-ati-9999 afterwards.
edgecase: hey anyone up on power wells, suspend, clock scaling and such?
tstellar: What is ddx, btw?
soreau: tstellar: You need to build other components after libdrm, not the other way around
BioTube: edgecase: Zajec is working on PM, which works but is a little hamfisted
chithead: device dependent x, eg. xf86-video-ati
soreau: tstellar: ddx = xf86-video-ati
edgecase: i'm wondering if it would be possible with a custom card to preserve ram contents, over reset
edgecase: BioTube, PM for KMS?
BioTube: yes
BioTube: but to keep the RAM contents, you'd have to bypass initialization routines at the very least
edgecase: sure, just erase the bios
edgecase: well reset domains is the thing too, pci-e reset can't be allowed to initialize the dram controller part
edgecase: but maybe in suspend reset doesn't hit everything, but rather does a wake-up?
tstellar: I just rebuilt xorg, but still no luck with KMS, I also noticed this message: RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM in my xorg.log, is this possibly related?
EruditeHermit: soreau, is OA playable?
EruditeHermit: soreau, how much slower is it than classic at this point?
EruditeHermit: soreau, are you using it to run your daily desktop at this point?
soreau: EruditeHermit: 1) Define playable 2) I would have to actually test that, but it is playable with some slowness 3) Yes.
EruditeHermit: 3) is very interesting
EruditeHermit: since I couldn't really do 1 and 2 on classic mesa that well anyway
soreau: Recent changes made compiz usable and OA 'splash' work now
soreau: For 1), I can play OA on classic mesa without problems last I checked
EruditeHermit: soreau, I could play it too. However, most other games were too slow FPS wise or just didn't run
EruditeHermit: therefore I never used it for games
soreau: Yea, if you really want to play, DRI1 is probably best
soreau: for now anyway
rxt0: Hi guys, how's R500 TV-out going?
airlied: it was sorta going but mine is very green now
hifi: where can I find R700_rlc.bin?
airlied: http://people.freedesktop.org/~agd5f/radeon_ucode/
DanaG: http://www.engadget.com/2009/12/10/onkyos-dx-dual-screen-laptop-is-a-far-better-deal-than-kohjinsh/
DanaG: hmm, I wonder what that thing has in it... displayport? dual lvds?
hifi: thanks
DanaG: interesting: radeon 5570.
DanaG: http://www.engadget.com/2009/12/09/hp-leaks-forthcoming-radeon-gpus-core-i3-cpus-hulu-and-netflix/
hifi: hm, with the IRQ patch glxgears still isn't limited to vsync even when I set it to force from driconf
hifi: but it does not show the warnings anymore
airlied: DRI2 doesn't do vsync on clients
hifi: could you explain, please?
airlied: vblank support isn't complete in DRI2
hifi: ah
airlied: we just avoid tearing which can end up syncing to vbl
airlied: its on the plans to fix, I've seen patches from Intel
DanaG: I see... it makes sure it won't redraw in the middle, but doesn't actually limit framerate?
airlied: pretty much
DanaG: Interesting.
hifi: I think theres some fundamedally wrong with this app that it doesn't do well without vsync
DanaG: Now, if an app were running at, say, 55 FPS on a 60 FPS display, would it be all stuttery, like a non-deinterlaced video?
DanaG: s/non-/badly-/
hifi: I have the problem that if my app runs over 60 fps it comes stuttery, under 60 works just fine
hifi: with high enough graphics settings it runs just at 50-55fps and works just fine
hifi: and it has no frame limiter, just vsync
hifi: which isn't of course working right now