EruditeHermit: looks like modesetting_drv.so was added to nouveau
airlied: hmm my rs480 nearly s/rs okay,
Nightwulf|work: hi all
EruditeHermit: Nightwulf|work, hi
Nightwulf|work: hi EruditeHermit
Milo-: well, the power-saving features in radeon-driver are absolutely horrible, therefore I cannot use radeon
Milo-: not yet anyways
Milo-: see you again in few months
Milo-: then again, this could be a sign that I should write my own powersaving features, but no..
EruditeHermit: airlied, phoronix was fast
legume: airlied: agd5f_: That rv670 uses dce3 patch still causes wrong firmware to load for me. I recloned over the weekend & retested and have just tested again now it's in. http://bugs.freedesktop.org/show_bug.cgi?id=24025
airlied: legume: thats wierd
airlied: ah crap I know what this is
airlied: glisse: we really need to share the defines used in the pciids
legume: airlied: Oh good as long as it isn't me :-)
airlied: legume: another case of duplication that claims helps us, shafting us
airlied: agd5f_: we need to consolidate the CHIP and family falgs and fixup the DCE3 check
airlied: or separate the pciids somehow
airlied: I'll get to it tomorrow if no-one else does
taiu: airlied: for kms blit is this correct? http://pastebin.ca/1573752
fpoibaf: Hi, I wanted to try the patch for bug http://bugs.freedesktop.org/show_bug.cgi?id=22741 but I noticed that the map "singleplayer -> Start Private Stan Sauer -> Run and Gun Part II " of sauerbraten is completely visually broken today, as of commit c67bb22fe7b4a7176efd9177d8de413d7c1a9192
fpoibaf: also I get many errors like:
fpoibaf: bo(0x135ec820, 65536) is mapped (-1) can't valide it.
fpoibaf: validated 0x135ec820 [0x81034000, 0x85034000]
taiu: actually for non_kms also
fpoibaf: and also:
fpoibaf: *********************************WARN_ONCE*********************************
fpoibaf: File radeon_dma.c function radeonReleaseDmaRegions line 348
fpoibaf: Leaking dma buffer object!
fpoibaf: ***************************************************************************
fpoibaf: it worked fine some time ago
taiu: at least something got better inbetween, I can now reload radeon and start X without hanging
fpoibaf: osiris_: ^^
Lutz_Ifer: same for me: bo(0x8381b50, 65536) is mapped (-1) can't valide it.
Lutz_Ifer: sauer_client: radeon_dma.c:210: radeonRefillCurrentDmaRegion: Assertion `dma_bo->bo->cref == 1' failed.
dileX_: airlied: build-errors with drm-linus
dileX_: stolen from
nha: fpoibaf: is it due to suokko's commit 284a7af274bc148f112bd0ebb40583923ee26b49 ?
nha: fpoibaf: maybe you could try reverting that?
fpoibaf: nha: without that the game segfaults
nha: okay
nha: Lutz_Ifer: are you sure it's the same for you? after all, that assertion you cite is *removed* by Pauli's commit
Lutz_Ifer: maybe, git version from yesterday
Lutz_Ifer: ← updates
Lutz_Ifer: glxhash.c:129: warning: incompatible implicit declaration of built-in function 'memset'
Lutz_Ifer: still get bo(0x7f6e4896c900, 65536) is mapped (-2372) can't valide it. etc
Lutz_Ifer: doesn't crash anymore, but i get HUGE texturefailure
nha: Lutz_Ifer: I'm afraid I just can't reproduce the problem... are you using KMS?
nha: oh, I've only loaded this Run and Gun.. do you have to play longer to see the problem?
Lutz_Ifer: no - i'm using 2.6.30 without kms since i got more problems with 2.6.31+kms than before
Lutz_Ifer: what i did was a botmatch, ffa, map "douze"
nha: oh okay, then the bug is no-kms-specific
fpoibaf: nha: the segfault started with http://cgit.freedesktop.org/mesa/mesa/commit/?id=6f9dbe773953b024075910b3bec11ebc96c2e8e0
nha: interesting
fpoibaf: nha: however reverting that change from latest git still give the corruption and the bo is mapped errors
fpoibaf: nha: reverting 6f9dbe773953b024075910b3bec11ebc96c2e8e0 and 284a7af274bc148f112bd0ebb40583923ee26b49 still give the corruption
fpoibaf: if can be of help I could bisect the corruption problem without 6f9dbe773953b024075910b3bec11ebc96c2e8e0
fpoibaf: oops, ignore my last 3, when reverting 6f9dbe773953b024075910b3bec11ebc96c2e8e0 mesa doesn't compile properly...
agd5f_: taiu: add you signed-off-by for the kernel
suokko: http://nopaste.org/p/ajDkNg50L <- Even this and 2D/3D caches disabled fails to updated memory from blit to dma before dma reads the data.
agd5f_: suokko: the host_path_stuff only affects accesses via the pci bar
agd5f_: ie cpu
suokko: ok. I just tested it in case itwould affect anything
agd5f_: suokko: do you have the same issues with src/dst both in vram?
suokko: agd5f_: yes
suokko: Or I have failures if blit happens in vram->vram and next dma is vram->gtt
suokko: and for blit gtt->vram and dma vram->vram
suokko: But I haven't put in pure vram test case
suokko: Now I compile one that has 4 bos in vram
agd5f_: suokko: so is the problematic on the vram->vram or the vram<->gart?
suokko: So it can show if there is failures
suokko: agd5f_: It looks like somehow dma engine is reading outdated data from vram
suokko: Or blit doesn't write data early enough to vram so dma engine already has done copy before blit hits vram
suokko: but if dma operates first and then only blits there is no errors
agd5f_: suokko: are you scheduling the dma via the ring or programming it via mmio?
suokko: ring
agd5f_: try setting the CP_SYNC bit in the dma setup
suokko: Which bit is that?
agd5f_: looks like that bit is only available when you use dma tables
agd5f_: bit 0 of 0x780
agd5f_: suokko: see section 4.14 of the r5xx accel guide
suokko: But when I have the dma in ring it should be synchronized if there is wait_untill before and after?
agd5f_: should be
agd5f_: er rather section 4.7
agd5f_: suokko: same problems if you only use the blitter or only use dma?
suokko: agd5f_: Blitter has sometimes problem if there is no synchronixation that last 8 bytes haven't arrived from GTT to VRAM before next blit
suokko: But DMA engine haven't failed ever
suokko: And DMA->BLIT transition haven't failed ever either
suokko: It is only BLIT->DMA that fails always
agd5f_: if it's blit to/from gart I suspect chipset cache issues
suokko: But blit->dma transition fails also if it appens after sequence where data is first copied from GTT->VRAM with DMA and then BLIT VRAM->VRAM and now DMA reads old data from 2nd VRAM object when coping data to GTT
suokko_: I don't know if blit is different to others 2D engine operations but if it is not then immidiat copy with DMA after 2D drawing would be problematic in my system at least
agd5f_: maybe we should just use the dma engine for bo moves on r2xx chips
juergbi: i have an issue with two 30" displays connected via dual-link dvi to a r600 (HD 3650)
suokko_: Or should not :) Like we aren't now
juergbi: it only detects the full resolution (2560x1600) for the monitor connected to the first output (DVI-0)
suokko_: Blit is reliable if only waits for 2D_IDLE after (at least if there is not other engines operating same time)
suokko_: I guess there might be coming problems for blit if I had some 3D oeprations going same time
juergbi: for the second output (same monitor, output name HDMI-0) it only detects 1280x800 (i.e. no dual link dvi)
juergbi: the same worked with a r700 and the same driver (master as of 2009-09-03)
juergbi: no kms
juergbi: known issue, any hints?
suokko_: agd5f_: There is failures also blit->dma transition when copies are running only in vram for both
suokko_: And I have run million+ copies where I quarenteed that blit->dma transition didn't happen and there was no failures for dma->blit transition there
suokko_: It looks somehow weird problem
agd5f_: suokko_: have you tried messing with RB2D_DSTCACHE_MODE (0x3428)?
agd5f_: or 0x3258. 0x3428 is just a mirror of 0x3258
suokko_: agd5f_: no. I did only disable chaches using RADEON_RB3D_DSTCACHE_MODE
agd5f_: suokko_: that's 0x3258
agd5f_: bit 0 is 2D dst cache and bit 1 is 3d dst cache
agd5f_: setting them disables the caches
suokko_: yes. I did write 3 to there
agd5f_: suokko_: also bit 8 is auto_flush_enable for 2d and bit 9 is auto_flush_enable for 3d
agd5f_: bit 10 is auto_free_enable for 2d and bit 11 is auto_free_enable for 3d
agd5f_: the default should be to set those bits. you might want to check and see if they are set for you
suokko_: ok
suokko_: f00
suokko_: so bits from 9 up are set
suokko_: I suppose fglrx might he some code to handle dma transfers correctlyafter 2D operation but that would be old code and none would remember it
suokko_: Which comes done to spying what glrx does with dma engine or blits
agd5f_: suokko_: might not even use the dma engine. AFAIK, it wasn't used much
stikonas: merging drm-linus and mainline kernel results in merge conflict, though quite trivial
suokko_: At least fglrx would use blit most likely so see what it does to synchronice them might be give solution to font corruption
agd5f_: suokko_: also, are you setting both the flush and free bits in DSTCACHE_CTLSTAT?
dileX: stikonas: culprit seems to be firmware/Makefile
agd5f_: you have to set both for the the data to hit memory
suokko_: FLUSH all is 0xf
suokko_: so yes
agd5f_: ok
stikonas: dileX: yes, it is trivially resolved, but linus will have to do it himself
dileX: stikonas: I read his replies when he cant merge
dileX: stikonas: how did you resolve btw?
stikonas: I added both entries
stikonas: seems to work
stikonas: git mergetool helps a lot in resolving conflicts
dileX: which entries do you mean?
stikonas: radeon firmware and some other firmware was added to firmware/Makefile IIRC
stikonas: and git mergetool launched kdiff3 for me
dileX: merge tool candidates? opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse ecmerge emerge vimdiff?
stikonas: pick your favourite
dileX: stikonas:
stikonas: really strange, maybe you have merged already
stikonas: dileX: ^^
dileX: stikonas: whats your master? linus-tree or drm-linus?
stikonas: drm-linus
stikonas: and I pulled git pull ../linux-2.6 master
dileX: then it says merge conflicts
stikonas: the other way around there are no conflicts?
dileX: same ass ***
taiu1: agd5f: ok, could you (let) review http://pastebin.ca/1573922 also:)
dileX: 'git mergetool --tool=/usr/bin/kdiff3 --prompt firmware/Makefile' is correct
agd5f: taiu1: yes
dileX: stikonas:
nha: osiris_, nanonyme, etc.: I've added a quick.tests profile to piglit which should run much faster than doing all tests, while still covering a reasonable number of tests
nha: actually, "quick" might still not be quite the right word for it - basically, it cuts down on the number of visuals tested by the Glean tests
nha: in any case, it should be much better than running the full test suite
dileX: stikonas: lol, 'git mergetool --tool=kdiff3 --prompt firmware/Makefile'
suokko_: nha: thanks :)
stikonas: dileX: http://filebin.ca/errqmt/Makefile
stikonas: this is my merged firmware/Makefile
dileX: stikonas: takes this long?
dileX: seems to hang
stikonas: dileX: then just use my Makefile
nha: osiris_: I can confirm that glxgears on master r300g is broken
nha: osiris_: doesn't lock up for me, just seems to take tons of CPU and causes broken display
suokko_: It is also broken with r100 and r200 but it only cuses wrong colors with r200
suokko_: And I couldn't find wroking versoin of mesa fter I first saw it
nha: oh, I get a lot of 500+ms timeout messages in dmesg
suokko_: That means gpu hang
nha: yeah
dileX: stikonas: overseen 3 lines according to your Makefile
BCMM: anyone using KDE desktop effects on an r600? is it stable?
kajik: hi, i installed karmic and ran into serious problems with ati x1400 on my thinkpad t60, it is constantly overheating, i have to run the fan manually on full to keep the gpu temperature at around 61 (celsius) , i installed all the new packages from the xorg-edgers ppa but the problem remains...
kajik: karmic is up to date, everything seems to work (glx etc..) just the temperature is way too high
dileX: dileX: after mergetool session? git pull ..?
kajik: i would like to report a bug to launchpad, but i dont even have a clue where to search for the problem? any hints?
jcristau: kajik: sounds like you want #ubuntu.
kajik: they send me here
suokko_: ping-pong ;)
suokko_: kajik: maybe yo uwant to start explaining what is problem that you see
suokko_: but if it is graphics related usually good start is to look at dmesg and xorg.log for errors
kajik: no errors there
kajik: sadly
kajik: just the temperature for the gpu is rising fast
suokko_: kajik: man radeon. There is forcelowpowermode
suokko_: Unless it is raising very highthen you have hradware cooling problem and should check for physical problems
kajik: i'll check that out
nha: kajik: you ran a different linux distribution before, right?
kajik: yes
kajik: jaunty
nha: good; this means that it's definitely a software problem
nha: you're probably not running KMS, right? I believe karmic has it disabled by default
kajik: yes
kajik: it s not working
nha: okay
nha: I don't know anything about those power management things, but those are the important corner data, anyway
nha: and yeah, what suokko said
dileX: stikonas: I solved firmware/Makefile (its same as yours). so whats next? git pull ... results in next conflicts with 'drivers/gpu/drm/drm_sysfs.c'
kajik: should i enalbe kms?
stikonas: dileX: I had no other conflicts
kajik: i'll try the forcelowpowermode for now... c u after reboot and thank u
dileX: stikonas: but what did you do after your kdiff3 session?
stikonas: I compiled the kernel
stikonas: dileX: anyway, a few more hours, and it should be in linus' tree
dileX: stikonas: tig says there are no new commits on top of drm-linus (after solving firmware/Makefile) from linus-tree
jcristau: dileX: after solving the merge conflict, just commit.
jcristau: that'll commit the merged tree
dileX: jcristau: how do I just commit?
suokko_: git commit
dileX: OK
suokko_: and before than yo uhave to do git add for files you fixed after conflict
stikonas: I haven't even commited, just compiled after resolving conflict
dileX: OK, I did 'git add firmware/Makefile'
kajik: the x.org0.log gives me (II) RADEON(0): Force Low Power Mode Enabled, but there is no recognizable difference
suokko_: working tree is in right state but git tree should be updated too so you can use it later on
dileX: 'git commit' opens my $EDITOR. leaving it does nothing
kajik: does anybody thing, enabling KMS will resolve the problem?
suokko_: no
nanonyme: dileX: Did you write in a commit message?
nanonyme: git commit requires one.
suokko_: kajik: Do you have some way to read the temperatures or just fan isspinning at max?
kajik: i read the temperature through thinkpad_acpi
suokko_: How hot it claims that card is?
suokko_: 60 C or 90 C?
kajik: the fan is software controlled , at the moment around 65
kajik: with fullspeed fan
kajik: glxgears will bring it to 80 in about 1 minute
suokko_: Did you check that the cooling system is clean from dust and not loosly connected?
dileX: nanonyme: OK, I see I have to type the commit-msg in when $EDITOR pops up
kajik: no, maybe i should do that...i thought of software problems, because with jaunty everything was slightly better and i saw this http://www.phoronix.com/forums/showthread.php?t=17438
stikonas: suokko_: is this caused by bad flushes? http://stikonas.homelinux.org/files/picture1.png
stikonas: I'm trying to view a pdf file
dileX: jcristau: can I change the commit-msg (subject) afterwards?
jcristau: dileX: commit --amend
suokko: stikonas: I can't connect to the server
stikonas: soukko: suokko: http://imagebin.org/64672
stikonas: forgot to install ddclient after clean install
suokko: That looks like tail data or wrong format for image
stikonas: soukko: it sometimes happens with web-browsers
stikonas: image is perfectly correct
stikonas: some pages load ok, and after reboot all pages may render correctly for some time
suokko: stikonas: It might be DFS/UTS problem, Do you have AGP card?
stikonas: so this is most likely driver issue
stikonas: suokko: no, thsi is PCIE RV730
suokko: What if you disable UTS/DFS and kernel bo move blit copy?
stikonas: where exactly should I disable it? what file is that?
stikonas: xorg.conf?
suokko: xorg.conf yes. man exa gives the correct options
suokko_: stikonas: Do you use KMS?
stikonas: suokko_: Yes, I do
nha: r300: Set texture state (512x32, pitch 0, -1212372576 levels)
nha: somehow, that looks suspicious :P
suokko_: stikonas: http://nopaste.com/p/a0OIxhUd6 might help too
adamk_: Has anyone here seen this particular problem with KMS? http://adam.npark.com/snapshot23.png This is with 2.6.31, X server 1.6.3, ddx 6.12.99, Mesa 7.7-devel from this morning.
nanonyme: suokko_: If it's KMS, then it's a known problem, me thinks.
nanonyme: DFS/UTS have been somehow broken there.
agd5f: might also try the taiu's patch I just posted to dri-devel
adamk_: Hmmm. A 32 bit GL apps don't work.
agd5f: adamk_: need newer libdrm
adamk_: s/A/And/
adamk_: Yeah, google is turning up some hits that lead me to believe that issue is fixed.
adamk_: Just a newer 64 bit libdrm or a newer 32 bit libdrm as well?
agd5f: adamk_: http://cgit.freedesktop.org/mesa/drm/commit/?id=cdd325b59a17a614b90fc2f8b388175e6d79e3cf
adamk_: Nevermind, stupid question.
agd5f: you also need latest kernel bits
adamk_: Ahhhh.
zhasha_: nha: that particular bug caused a hardlock on my machine yesterday
zhasha: oh wait, it's just a bad printf... damn
stikonas: suokko_, agd5f: neither of the pathes helped me, but AccelDFS=off seems to help
suokko: So ddx blit needs updates too
nanonyme: suokko_: The KMS and non-KMS have separate blitting code in ddx?
agd5f: nanonyme: separate dfs/uts paths
nanonyme: Ah.
nha: *sigh*
nanonyme: nha: Sup?
nha: bisect keeps citing suokko's printf-changing commit as the cause for the gallium corruption
suokko: nha: Did you bisect with full source tree?
nha: does it get confused by merges or what's wrong there?
nha: can you bisect without full source tree?
nha: and yes, I also did make clean, and all those things
suokko: yes. Yo ucan give path which you want to bisect
AStorm: heh
AStorm: likely that printk change messed up some timing
AStorm: and the bug surfaced
suokko: Did I then change some logic there?
nha: AStorm: it's all userspace
nha: no
AStorm: hmmh
AStorm: nha: what commit is that?
nha: it's literally just appending some helpful text to the format string
suokko: Does valgrind report any memory errors?
nha: I suppose that's one of the next things to try
nha: suokko: does r300g work for you?
nha: suokko: and no, it's completely obvious that this commit has nothing to do with the bug
suokko: I have only r200
MrCooper: nha: git bisect handles merges properly IME
nha: as I said, git just reports a commit that clearly has nothing to do with the bug
suokko: bisect should work well with merges
nha: I do
nha: git checkout
nha: make clean && all that
nha: --> things are wrong
nha: git checkout HEAD^
nha: make clean && all that
nha: --> things are still wrong
nha: so *clearly* git bisect didn't report the correct commit as being the cause
suokko: yes
nha: besides the fact that it's totally obvious that the commit could not be the cause
suokko: You need to do manual bisect then :/
nha: for fuck's sake, the diff even doesn't touch the gallium codebase at all
MrCooper: sounds like git bisect got confused somewhere, you did do git bisect reset before starting, right? :}
nha: it gets more fun due to the fact that the precise nature of the corruption is different
nha: yes, I did
nha: I even bisected the whole damn thing twice using different end-points for the bisect
MrCooper: or could there have been an invalid partial build for one of the tested commits?
nha: suokko: how can I do a manual bisect?
nha: no
MrCooper: nha: if you start with git bisect good
MrCooper: err, bad obviously
nha: hmm
MrCooper: otherwise there would seem to be a git bisect bug
nha: I have not tried that
suokko: nha: You could just have commit log open in gitk and then checkout commits using binary search from there
nha: suokko: but then I get confused by merges :/
suokko: Then you have to jsut start new bisect with bfirst bad commit just before my merge of printf stuff
nanonyme: wonders what DCE3 is and whether the fix related to it and his card should immensively concern him
ajax: display control engine, version 3
ajax: r600 and up
ajax: (more or less)
nanonyme: drm/radeon/r600/kms: rv670 is not DCE3
MrCooper: nha: start with merges to master, only go elsewhere once you've isolated it to between two consecutive merges
MrCooper: nha: actually that could have been the problem, if git bisect had you try commits on older branches where not all the infrastructure for building r300g was there yet
nanonyme: wonders why simply reordering radeon_family struct should solve such issues
nanonyme: Erm, enum apparently.
nanonyme: Right, figures.
MrCooper: nanonyme: a couple of places use greater / smaller than tests on the family to determine certain hardware characteristics
agd5f: nanonyme: dce 3.0/3.1 was rv620/rv635/rs780/rv770 and DCE 3.2 is rv710 and up
agd5f: r600/rv610/rv630/rv670 used the older display engine from r5xx
simplexe: what is it dce?
nanonyme: 18:44 < ajax> display control engine, version 3
simplexe: thought so )
nanonyme: Is it just me or does dragging a window around fast in KMS take immensively much CPU time for rv6xx?
nanonyme: Probably better to profile.
nanonyme: Right, it seriously does...
nanonyme: For some reason or another EXA atm gives me a slower experience than Compiz. O.o
MrCooper: nanonyme: that sentence doesn't make sense, EXA is active regardless of compiz
kcodyjr: that's logical; exa relies on copying window contents around and then redrawing what was behind it, compositing wouldn't have to deal with the redraw
nanonyme: Well, the old one used to be fast.
MrCooper: sounds like you mean 'no compositing' when you say 'EXA'
MrCooper: but those aren't synonyms at all
nanonyme: Doesn't Gnome use EXA by default?
kcodyjr: whether or not exa is in effect depends on whether the ddx and xserver agree to activate it, the desktop environment has neither control nor visibility of it
stikonas: linus tree now has R600 3d/kms support
nanonyme: stikonas: Linus tree also (what a shocker) doesn't compile.
stikonas: due to drm?
nanonyme: No, due to something else that got merged in.
kcodyjr: due to god only knows what, it's the maintainer's between-versions tree.
stikonas: hopes that he has it disabled in his .config
nanonyme: Hmm, I seem to be missing debugging symbols for X...
nanonyme: Well, considering airlied recommended not to even for 2.6.31 rc1 due to the likely breakages in other parts of the kernel...
nanonyme: Not to go even.
nanonyme: goes to attempt to get debugging symbols for X
nanonyme: MrCooper: But yeah, apparently I do. It's just as if there'd been a performance regression without compositing.
legume: Mesa LIT fix mends gloss and engine for me :-)
spreeuw: big mesa commit today
jnoah1984_1: How can I force a resolution to be used? My monitor is able to do 1280x1024, however, I am only able to set the resolution as high as 1024x768.
chithead: jnoah1984_1: if "xrandr" does not list the resolution you can use cvt, xrandr --newmode and xrandr --addmode
franjva: today's mesa updates make darwinia intro and menu run almost glitch-free :)
franjva: but starting a game still gives this:
franjva: radeon_mipmap_tree.c:117: compute_tex_image_offset: Assertion `lvl->size > 0' failed.
franjva: is this a known bug?
osiris_: franjva: yes
osiris_: what gpu do you have?
franjva: rv670
franjva: (HD 3850)
osiris_: try this patch http://pastebin.com/m5e85e97f
franjva: ok, compiling :)
jnoah1984_1: chithead: cvt?
chithead: jnoah1984_1: "cvt 1280 1024 60" will compute a modeline which you can pass to xrandr --newmode
spreeuw: hey darwinia bundle is cool
franjva: hum, the patch may have solved the assertion, but darwinia still crashes
franjva: maybe too much for the current driver
osiris_: franjva: can you pastebin the backtrace?
franjva: how do I do it? gdb? darwinia just outputs "segfault [...] error 4 in libc-2.10.1.so[f7b45000+13e000]" in dmesg
spreeuw: type bt enter
jnoah1984_1: chithead: oh cool! thanks, I was just googling how to do that and was about to ask.
spreeuw: do you folks play http://springrts.com/media.php ?
spreeuw: it's really brutal 3d
spreeuw: its a tiny bit like darwinia
chithead: it is a remake of total annihilation (which did not require hardware 3d acceleration, one might note)
spreeuw: it seems to run without crashing now on r600, just waiting for texturing to get in shape
jnoah1984_1: chithead: is that permanent?
Ampheus: warzone2100 runs fine on r600
chithead: jnoah1984_1: no, for permanent setting you need screen and monitor section in xorg.conf
jnoah1984_1: ah, ok
spreeuw: you can also use 2 lines of xrandr in your xinit
spreeuw: rc
Ampheus: spreeuw: do you run kms?
spreeuw: no dri1
benvdh: hey, I was just trying to get my tv-out to work, but I'm having some problems. I first tried to use the radeonhd driver which does seem to detect the tv-out but that fails with the following error : RADEONHD(0): Query for AtomBIOS Get Panel EDID: failed
benvdh: Then I tried to use the radeon driver but that driver did not detect the tv-out output (according to xrandr and xorg.0.log
spreeuw: all thats lacking atm is working s3tc
spreeuw: or s3tc handling
benvdh: any thoughts on how to solve this ?
spreeuw: and maybe shaders
agd5f: benvdh: you need to add Option "ATOMTvOut" "TRUE"
agd5f: to the device section of your config
benvdh: I already did, but it didn't work, also I'm trying this on an X1400 (which according to the xorg wiki doesn't need that option)
agd5f: spreeuw: compressed textures aren't currently supported
benvdh: (Using OpenSuse 11.1 btw.)
agd5f: benvdh: it does
agd5f: only relevant for radeon. radeonhd doesn't support tv-out yet
spreeuw: agd5f: pitty, does it differ that much from r300?
benvdh: agd5f: okay, I will try to clean up my xorg.conf a bit and see if it works
agd5f: benvdh: make sure you are using 6.12.4 or git master
spreeuw: agd5f: is there perhaps a way to decompress textures on the fly then? before using them in videomemory?
spreeuw: I have memory enough
agd5f: spreeuw: disable the s3tc extension
legume: spreeuw: game may have an option, et does.
spreeuw: but doesnt the disabling require a game with uncompressed textures in the gamefiles?
spreeuw: some games dont have uncompressed textures
spreeuw: on disk
spreeuw: those are the problem cases atm
agd5f: spreeuw: game should test for the extension and if it's not there, use non-compressed
airlied: dileX: I didn't tell you to use drm-linus did i?
nanonyme: What is drm-linux anyway?
agd5f: airlied: what's the issue with the pci ids and family flags?
dileX: airlied: I have now built latest linus-tree (has drm-linus and other patches, e.g. for staging crap)
dileX: (will be 2.6.31-git11)
franjva: osiris_: this is the backtrace with mesa --enable-debug
franjva: http://pastebin.com/d73d4094c
franjva: probably not too helpful. something else I need to enable-debug?
osiris_: franjva: yes, you would have to disable compiler optimization. set CFLAGS="-O0 -g2" when running configure
suokko: franjva: Looks like you didn't recompile everything
suokko: or what osiris_ sayes is probably more correct :)
franjva: suokko: yeah, gentoo removes and recompiles everything in each emerge ;)
nanonyme: likes FEATURES="splitdebug"
octoploid: Just switched to KMS with my RS780 and everything works fine. The only problem is IRQ related:
octoploid: % glxgears
octoploid: IRQ's not enabled, falling back to busy waits: 2 1
octoploid: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
octoploid: Any hints?
airlied: agd5f: ordering of the family is different in kms/non-kms
airlied: agd5f: the CHIP_ enum is in two places bt pciids only gets it from one
airlied: so you moved RV670 in kms, but non-kms and pciids have it the old way
airlied: so ppl get wrong firmware
agd5f: ah
nanonyme: octoploid: That's normal.
nanonyme: Interrupts aren't implemented yet.
octoploid: Ah, thats good to know. I'm quite happy with the current state.
octoploid: The only other thing I noticed is a "Unpin not necessary for ffff88011de61a00 !" message in my dmesg.
Neo_The_User: is all the r6xx/r7xx kms code in radeon_kms.c?
airlied: Neo_The_User: no
Neo_The_User: rather.. all the r6xx/r7xx suport in r600_exa.c r600_state.c r600_textured_videofuncs.c r6xx_accel.c radeon.h radeon_dri2.c and radeon-exa.c?
airlied: Neo_The_User: kms isn't chip specific
airlied: the kms code is for r100->r700
Neo_The_User: stops trying to port kms to radeonhd
Neo_The_User: ok this is too complicated
nanonyme: airlied: You just won, I think. :)
airlied: drmmode_display.c is most of it
airlied: but really you'd have to re-port all the accel code first
Neo_The_User: which isn't all in r6xx_accel.c is it?
airlied: that + r600_exa.c
nanonyme: Neo_The_User: Why would you possibly want KMS for radeonhd, btw? :)
airlied: you'd also need to port over r500 accel code since rhd supports that
Neo_The_User: nanonyme: because i dont want radeonhd to drop over dead because somebody didn't port the code over but now i think its out of my control
suokko: 16bpp depth in xserver looks funny with KMS
suokko: That means I get 2x2 grid of dekstop from my 2 virtual desktops
Neo_The_User: what reason would radeonhd have to live, if -ati had everything?
yangman: suokko: bad colours?
suokko: of course :)
nanonyme: Neo_The_User: So you just want them to be identical instead?
suokko: my monitor is showing 32bit desktop
Neo_The_User: no. i just dont want one to be depreciated
suokko: But data in vram is in 16bit
nanonyme: Neo_The_User: You probably know that radeonhd loses its main benefits like HDMI audio with KMS, right?
Neo_The_User: nope
Neo_The_User: now i do
suokko: btw, Also reading text that renders to hafl pixel sizes from normal is quite hard
nanonyme: HDMI audio needs to be implemented on top of KMS in KMS-scenario anyway so radeonhd has nothing at all at that point that justifies putting extra effort into it. :3
Neo_The_User: thank you
Neo_The_User: for the info :)
suokko: yangman: I guess it is some KMS bug not to change depth when xserver starts
suokko: hmm. My VTs got also green shading but ont is right sizesed there
yangman: suokko: https://bugs.freedesktop.org/show_bug.cgi?id=21489
yangman: and try this: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg42227.html
Neo_The_User: so the text is still messed up if you dont set agpmode to -?
Neo_The_User: *-1?
suokko: It is funny that console was also affected by the green shading
suokko: But when Irestarted X in 24bpp it turned back to correct colors in console too
suokko: yangman: So it would be fixed in drm-next
yangman: sounds like a LUT loading bug
yangman: I'm not sure if that's made it into drm-next
franjva: Hm, adding -g to CFLAGS didn't add anything to the backtrace (http://pastebin.com/d73d4094c)
cbmuser: airlied: I am having trouble with kms on RV-350 with linux 2.6.31 and xf86-video-ati from git
cbmuser: syslog says:
cbmuser: [ 17.340397] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
franjva: and changing -O2 to -O0 just removed everything from it
agd5f: airlied: probably need to pull http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg42227.html
cbmuser: my problem is that once X starts and I switch to a virtual console, the display turns black and thats it
franjva: -ggdb didn't help either
cbmuser: can't even switch back to X
cbmuser: the machine doesn't lock-up however
cbmuser: IIRC it worked properly on a RV-370
suokko: But that looked quite funny how X caused the problem in 16bpp format
cbmuser: I have several radeon at hand to test
franjva: someone with more experience with gdb will have to debug darwinia
franjva: (well, not darwinia, but the mesa segfault produced by it)
suokko: franjva: gento odefautls to strip debug symbols so you need to give special build option for ebuild to handle symbols
cbmuser: airlied: this seems to be related: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/434190
Clatch: anyone have experience with radeon xpress series and ubuntu?
cbmuser: what chip would that be?
Clatch: M400 I believe
cbmuser: hmm
suokko: Clatch: You most likely need xorg-edgers packages
cbmuser: is that an old chip?
Clatch: About two years old
cbmuser: I don't see it here: http://www.stefanweiske.de/gati.htm
airlied: cbmuser: missing fbcon?
cbmuser: YES
cbmuser: thanks
cbmuser: it works immediately now
cbmuser: hmm, guess radeon should depend on fbcon then, shouldn't it?
airlied: no, its a distro thing
franjva: suokko: oh yeah, i assumed that when adding "debug" to the use flag portage would be smart enough. It isn't.
airlied: it selects fbcon but it can't make you load it
cbmuser: ok, I guess I will report that on Ubuntu then !
cbmuser: thanks alot
airlied: wonders how vesafb works for hem
airlied: if they don't have fbcon built in
Neo_The_User: well...
cbmuser: it is in
cbmuser: but not loaded
Neo_The_User: /etc/rc.conf and add it into erm.. what??? HHAHAHHA!!
airlied: cbmuser: but vesafb doesn't load it either
cbmuser: by the way, syslog still says:
cbmuser: [ 1577.023797] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
airlied: does booting with vga= work at all?
cbmuser: everytime I switch to virtual console
cbmuser: airlied: haven't tested
airlied: cbmuser: since we don't see that allow me to blame someone else
cbmuser: the error-message in syslog?
cbmuser: what do you mean?
franjva: suokko: meh, after disabling strip I get a single line backtrace. The same I got with -O0
franjva: #0 0xf7be0dc6 in memcpy () from /lib32/libc.so.6
franjva: that's it
airlied: cbmuser: it doesn't happen on any of my systems, so it sounds like an bug specific to ubuntu
suokko: I don't understand why gentoo doesn't use splitdebug by default
cbmuser: airlied: sorry, to ask again, with "it" you mean the framebuffer-error, right?
cbmuser: I'm on Ubuntu unstable, so some things might be broken :)
airlied: cbmuser: yes
suokko: cbmuser: WFM ;)
franjva: suokko: shit, I WAS compiling with -O0. Ok, this is the full backtrace (at last): http://pastebin.com/m3dad541e
cbmuser: suokko: :)
cbmuser: I guess I will switch back to Debian soon
cbmuser: having more and more trouble with Ubuntu :(
suokko: franjva: dstAddr=0x0
franjva: hmmm... mesa_memcpy dest=0?
franjva: suokko: yeah, i was looking at that
suokko: yes. null pointer reference
nanonyme: cbmuser: Good luck with that path. ;)
cbmuser: nanonyme: why?
cbmuser: need to reboot, brb
franjva: ok, I'll file a bug tomorrow then
Neo_The_User: i have a 4650 pci e 2.0. is the performance going to matter if i use ati or radeonhd if im not looking for kms?
Neo_The_User: i rather run something in full pci e mode while being able to read text ;)
Neo_The_User: cmbuser: you should try my distro ;)
MrCooper: nanonyme: probably >= R600 is slower without compositing because there's only a 3D engine, which can't handle overlapping blits directly, so those require intermediate copies
nanonyme: MrCooper: My point is that it feels slower than it was before. But yeah, you're probably right though, it seems utterly incapable of handling some overlapping situations properly.
agd5f: nanonyme: what do you mean? it should handle them fine
MrCooper: 'before' meaning pre-KMS?
agd5f: albeit with a extra copy
nanonyme: MrCooper: No, it's as if it had slowed with KMS from what it was before in KMS.
nanonyme: agd5f: I meant the "video blacks out for a second or so when overlapped in Xv" issue.
nanonyme: Which only exists without compositing.
agd5f: nanonyme: haven't seen or heard of that one. did you file a bug?
nanonyme: Err, no. I thought it was normal, been having it ever since r600 got EXA/Xv.
nanonyme: You lose the video for a second or so if moving a window over it or if you move the window beyond a screen boundary.
nanonyme: Doesn't happen with OpenGL output which is somewhat interesting.
agd5f: nanonyme: I can't reproduce it here
nanonyme: Hmm, odd. Know of any program I could record my screen?
agd5f: nanonyme: probably better to use a digital camera
nanonyme: Well, it'll have to wait until tomorrow then. I'll be off to sleep. Honestly surprised if I'm the only one who's getting it, I was already convinced it's more of a feature than a bug.
nanonyme: (since there's no errors anywhere)
agd5f: nanonyme: recordMyDesktop maybe
nanonyme: Hmm.
nanonyme: recordMyDesktop showed even worse corruption than there actually was.
nanonyme: http://koti.kapsi.fi/~nanonyme/public/out.ogv not exactly what it shows like but since it flickers a lot, might give an impression...
nanonyme: There's black sections in the video window momentarily.
nanonyme: Anyway, any kind of compositing fixes it, whether EXA-based or OpenGL. Just borks without.
nanonyme: (even xcompmgr helps)
nanonyme: I'm not sure I care that much anymore anyway since 3D works so I get Compiz which removes the issue. :3
DnaX: currently, radeon (rv280) driver what type of accelerarion is preferred? exa, uxa etc.
MostAwesomeDude: EXA. There's no UXA for non-intel.
DnaX: ok, but exa use TTM memory management?
MostAwesomeDude: When available and using KMS, yes.
DnaX: ok
DnaX: another question, when I run glxinfo get this "warning": DRM version 1.0 too old to support HyperZ, disabling.
agd5f: DnaX: not supported with kms at the moment
DnaX: ah, ok
DnaX: but this message isn't right!
agd5f: nanonyme: weird
Terman: airlied, agd5f: is there a way to follow the current drm/ttm/radeon development (rv515 on 2.6.31) without needing to check out a complete kernel tree? I really miss the days when drm git repo contained the current linux kernel stuff as well ;)
agd5f: Terman: pull from drm-next and track that branch
agd5f: as long as you are tracking that branch you only have to rebuild the whole kernel once
agd5f: then you can just pull updates and rebuild the drm modules
Terman: agd5f: so I can't continue my current kernel and just play with the new drm stuff :-/
agd5f: Terman: you can merge drm-next into your tree
agd5f: should only be drm changes
Terman: agd5f: I have a normal source rpm without git stuff - thanks for the help. Now I need to decide between lazyness (and disk space saving) or curiosity
agd5f: Terman: rawhide has bleeding edge kernels you can try
suokko: Terman: git doesn't take much disk space if you run git gc --aggressive once in a while
suokko: 307M kernel git repository but open source tree+object files are taking over 3G
airlied: the nouveau guys were running some sort of compat tree but I think they gave up
airlied: maybe when the kernel stuff stabilises something like drm.git could be done again
airlied: but at the moment its not workable
Terman: so just copying over the gpu tree from drm-next to 2.6.31 is guaranteed/very likely to not work?
airlied: I'm not testing or supporting anything outside of Linus tree + drm-next
airlied: after that you are on your own
airlied: if the drm was completely self contained it would be fine, but since other parts of the kernel have fixes that drm requires it gets too messy
dileX: $ dmesg | grep vgaarb
dileX: vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
dileX: vgaarb: loaded
PaulH: airlied: excuse, you mean you allready have glsl for i915?
edt: what git tree has the vgaarb.c code? I am trying to get the drm pull that adds r600 3d to work on 2.6.31.1
AMD_Fanboy1993: is there a way to watch DVDs and flash videos on youtube while using radeon kms so the CPU can still go off and compile while the GPU is processing all the graphics or...
AMD_Fanboy1993: ^ in command line
edt: airlied are there just three patches to implement vgaarb? the two originals plus a cleanup posted to lkml? I am trying to get the latest drm code sent to linux working in .31.1
AMD_Fanboy1993: one last thing, can you read stuff with kms or is that still broken?
airlied: edt: you can just remove the vgaarb patch from drm (note drm-next doesn't have it)
Luzipher: hm, are there still known mesa corruption issues with r600 (on a rv770) or should I better check the wine folks ?
edt: airlied I've got it building with the vgaarb stuff (two original + cleanup) you posted to lkml along with the new drm for-linus building now. I'll see how it works before trying to drop the patch from drm
AMD_Fanboy1993: Luzipher: what kind of corruption?
AMD_Fanboy1993: im using everything straight from git from xserver to mesa to DDX everything is fine
Guest44945: did something in the latest mesa/xserver git break?
Luzipher: hm, textures look like ... skewed ... each line seems to be shifted right by one or two pixels
AMD_Fanboy1993: oh something within the last 90 mins
Guest44945: i cant turn on desktop effects anymore kde instantly freezes
AMD_Fanboy1993: i dont run git pull that often every 90 mins.... usually twice a day
Guest44945: im gettting
Guest44945: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug!
AMD_Fanboy1993: stays away from git for awhile
Guest44945: it'l work fine if u didnt attempt to turn on desktop effects =x
AMD_Fanboy1993: ohh
AMD_Fanboy1993: goes back to git
MostAwesomeDude: odz: This is not a bug.
MostAwesomeDude: Or rather, it's a compiz bug that nobody noticed before. :3
MostAwesomeDude: Don't worry about it, but if you get compiz crashes, be sure to mention them in bug reports.
odz: compiz? but im running kde 4.3.1 using their composting engine
AMD_Fanboy1993: i never use compiz so i wouldn't know. complete waste of processing power, and decreases the speed of everything
odz: it was all running fine yesterday
MostAwesomeDude: odz: Same deal.
odz: :/
AMD_Fanboy1993: maybe this did it... http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_5_branch&id=e8573033058a13bd39a0b85f48b6db64b04c65e0
MostAwesomeDude: odz: This is *not* a new bug. We just never printed "OH NOES YOUR DESKTOP EFFECTS ARE BUGGY" before.
odz: ya but i get an instant freeze now
odz: it was working fine yesterday o.O
MostAwesomeDude: Hm.
MostAwesomeDude: Sounds unrelated.
odz: hmm
edt: build worked - now to see what X does...
Luzipher: ah, and as Linux pulled the drm-linus branch: should i rather still use drm-next or linus treee ?
AMD_Fanboy1993: i'd use linus tree pulled with drm-next code then apply my patch to make it work then type in git add . and then git commit -m merge with master
AMD_Fanboy1993: didn't upload his patch though to make the merge work on his website yet :S
AMD_Fanboy1993: just use linus tree
AMD_Fanboy1993: its safer and airlied doesnt want people using his stuff right now ;)
odz: http://pastebin.ca/1574664 <--- anyone got any ideas what could be wrong?
dileX: AMD_Fanboy1993: AFAIK drm-linus has all was drm-next has, drm-linus has vgaarb in addition
AMD_Fanboy1993: correct
AMD_Fanboy1993: and linus's tree has latest drm-next code
dileX: drm-linus*
AMD_Fanboy1993: you said drm-linus the right way the first time :)
airlied: I only said not to use drm-linus tree.
airlied: drm-nex tis fine
Luzipher: hm, drm-next doesn't compile for me anymore :) I'll try make clean ...
airlied: if the tree has your name no it or -next you can use it
Luzipher: is drm-next still rc9 based ?
AMD_Fanboy1993: i think its erm... 2.6.30-rc3 or something
Luzipher: I'm quite sure it was 31-rc9 a few days ago
AMD_Fanboy1993: you're right
AMD_Fanboy1993: my memory is terrible
airlied: don't we have a build howto?
airlied: in the topic?
AMD_Fanboy1993: yeah and one my website
AMD_Fanboy1993: :)
Luzipher: and your website would be, AMD_Fanboy1993 ? :)
airlied: I'm not advising people to use webswites like that
airlied: since we can't conrtol them
AMD_Fanboy1993: im not saying you should
airlied: shit ends up being used years after its necessayr
dileX: airlied: how do I see vgaarb support in Xorg? (atm only one gfxcard)
airlied: dileX: it does nothing with one gfxcard
airlied: so you are using it
dileX: then I see nothing is OK :-)
AMD_Fanboy1993: Luzipher, http://neo-technical.wikispaces.com i got one for ermm radeonhd-3d, old radeon cards kms, and erm.... how to compile the DDX alone
AMD_Fanboy1993: its really dumbed down
AMD_Fanboy1993: ;)
Luzipher: thanks, AMD_Fanboy1993 ... will check it out :)
AMD_Fanboy1993: .. :)
Luzipher: and that's why i hate websites without a date on them ... you just can't tell if they are horribly outdated or not
AMD_Fanboy1993: which one?
edt: when building mesa for the new in kernel drm with r600 3d are the instruction for building mesa in the experimental 3d page still correct (./autogen.sh --with-dri-drivers=swrast,r600 --libdir=$(pkg-config --variable=libdir dri) --includedir=$(pkg-config --variable=includedir dri) --disable-gallium --enable-debug)
AMD_Fanboy1993: go to history and look at the dates
airlied: edt: should be
AMD_Fanboy1993: the xf86-git guide is never out of date ;)
Luzipher: i didn't talk about your site, AMD_Fanboy1993 ... just in general :) there are so many technical pages that miss dates, it's awful
AMD_Fanboy1993: oh
edt: thanks - I'll let you know. btw 31.1-rc1 + 3 vgaarb patches + drm for-linus builds, boots and starts X. mesa comes next
AMD_Fanboy1993: sorry my mistake
odz: anyone know what this means?
odz: X: radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy->is_pending <= bo->cref' failed.
odz: http://pastebin.ca/1574680 <-- :(
MostAwesomeDude: Quick question: r200-r500 can do full NPOT w/repeat and mirror, right?
MostAwesomeDude: Or only rectangle?
edt: this ring any bells? "IRQ's not enabled, falling back to busy waits" from glxinfo
Luzipher: edt: if you are on r600 or above this is normal afaik
edt: well glxgears now gets 500fps vs 300fps with software alone
Luzipher: well, you should only get that message when you're accelerated ;)
MostAwesomeDude: Curses, found it. No ARB_npot. Oh well.
edt: googleearth starts but flickers so much that its unusable
edt: which is a BIG improvement over the old experimental 3D - that killed X when googleearth started
AMD_Fanboy1993: when agd5f gets itturepts going, it should be better
AMD_Fanboy1993: my guess
kcodyjr: interrupts should indeed be a very big deal
AMD_Fanboy1993: my spelling is terrible sorry guys
kcodyjr: anyone that can read source code should be able to interpret typo
edt: will that be mesa only or will kernel drm need updating (my spell+grammer sucks too)
kcodyjr: interrupts is a kernel thing
kcodyjr: actually, i infer that's part of the challenge, is having the kernel call out to userspace
AMD_Fanboy1993: but can be introduced into the drm linux-core, bsd-core whatever the bsd version is called
MostAwesomeDude: kcodyjr: Just like before, libdrm has a call for it.
kcodyjr: i haven't read that part recently. how exactly does that happen? usually it's userspace calling into the kernel
MostAwesomeDude: Polling for IRQ, usually. :T
kcodyjr: suppose the most obvious would be a userspace wait thread
kcodyjr: doesn't polling kinda defeat the purpose of using interrupts?
kcodyjr: otoh, i can see an efficient implementation that starts a background thread, which in turn sleeps on an ioctl, until the interrupt wakes it
MostAwesomeDude: Most apps are GPU-bound anyway. If they really want to do other things, they'll thread or fork.
AMD_Fanboy1993: i think it'd be faster though if the interrupts were always ready to go
AMD_Fanboy1993: not sleeping
kcodyjr: AMD_Fanboy1993, it's a question of how does the message -get- from the kernel, into userspace - there is no direct callout mechanism
AMD_Fanboy1993: mmm
MostAwesomeDude: AMD_Fanboy1993: The entire point of an interrupt is to sit and wait until you get it.
AMD_Fanboy1993: im thinking of IRQs then i think
kcodyjr: well now. actually the point of an interrupt is so you -don't- have to sit and wait until something happens
kcodyjr: but that all goes to hell once you have to go the wrong way down a one way street
AMD_Fanboy1993: doesn't even know the difference between the two. hahah
AMD_Fanboy1993: is uber noob
kcodyjr: an IRQ is an interrupt request line; a wire (legacy) or memory vector (MSI) that lets the device tell the cpu that it requires attention. the cpu will then stop what it's doing to handle the device.
MostAwesomeDude: AMD_Fanboy1993: IRQ == interrupt more or less.
kcodyjr: an "interrupt" is what you call it when the cpu stops what it's doing to run such a routine
AMD_Fanboy1993: oh ok
AMD_Fanboy1993: thank you you two!
AMD_Fanboy1993: ^comma
kcodyjr: what MostAwesomeDude said is correct, from the point of view of an X driver. the only way to get the interrupt is to wait around for it; at best it'll be a thread using a smart ioctl, at worst it'll be outright polling and there's little benefit in even using interrupts.
kcodyjr: either way it's going to play hell with latency
edt: r600 3d is __much__ more stable than it was a month ago. So far only googleearth is a problem
airlied: MostAwesomeDude: only r600 has full NPOT
airlied: MostAwesomeDude: fglrx advertises GL2.0 without the extension which is defacto for we don't support mipmapping
AMD_Fanboy1993: fgl-aaaarrggghhhh no my eyes
airlied: the X drvier doesn't use irqs
airlied: under non-kms it doesn't at least
airlied: under KMS we can use irqs to sleep wait instead of busy wait
AMD_Fanboy1993: airlied: is text screwed up in kms still?
airlied: never has been for me
AMD_Fanboy1993: without having to set it to fallback to standard pci?
AMD_Fanboy1993: in other terms.. without radeon.agpmode=-1
edt: airlied from your commit it looks like 3d is only for non kms with r600 correct?
soreau: I picked up an X1600 at a thrift shop today for cheap, but when I boot with it, there's back and white all over my screen then colored lines for grub. Does this mean the gpu on it is fried? (and it looks like it's in really good shape sadly)
edt: s/commit/pull request comment/
airlied: edt: no for everything
airlied: soreau: VRAM is toast
soreau: airlied: Damn. That sucks :)
soreau: and it had 512mb of good vram once upon a time
edt: given that I have a fairly up to date user space is there anything special I have to do if I rebuild with kms enabled?
soreau: Guess I'll stick to the r300 for now
soreau: edt: See the link in the topic
edt: airlied think you want to submit a comment to say that kms works for r600 too (if it does now)
soreau: airlied: It's an agp card and it has a four prong connector on the side opposite the standard vga/svideo connectors.. what's that for? http://www.thg.ru/graphic/vga_test_2006_i/images/sapphire-x1600-pro-agp.jpg Does it need more power maybe? :P
airlied: soreau: possibly normally they give out when they lack power but maybe that might be all it needs
airlied: edt: I did
airlied: if you read the pull req it says kms + accel for r600
soreau: airlied: How would I get a connector for that from the PSU?
airlied: soreau: thats the floppy power
soreau: Is that connector definitely for power?
soreau: oh yea.. the 'A:\
soreau: ' drive ;0
soreau: ;)
airlied: if it releases the magic smoke don't blame me.
soreau: That's probably the last time I used that thing when I used to use that one os
soreau: airlied: lol
soreau: hmm.. I wonder how I can know for sure if it's for power
airlied: I blew up my tvtuner a few weeks back
soreau: Well it's already pretty much useless in the state it is now.. and I still have the receipt regardless if I damage it further..
Luzipher: soreau: try it amd hope the whole box doesn't boot if it shouldn't be for power :)
soreau: the other matter would be polarity..
soreau: Luzipher: heh
Luzipher: soreau: afaik the connectors fit only one way unless you use force ...
soreau: Oh neat.. A jumper for ntsc/pal
soreau: Luzipher: Alright. I'm going in for further investigation
kcodyjr: a jumper... wow... keep looking, there might be a pair of bell bottoms in there
soreau: kcodyjr: lol
soreau: I just wish someone could confirm that connector's actually for power or if someone has theirs setup like this..
kcodyjr: in my experience, if the card has an extra power connector, it needs the extra power
soreau: kcodyjr: ok
soreau: powers down the machine
kcodyjr: had an asus sound card that seemed to work, but wouldn't deliver any sound without it
kcodyjr: that sure looks like a floppy power connector to me. you'll be able to tell when it either does, or does not, slide on cleanly
airlied: my tv-tuner had a connector that looked like power ;-)
kcodyjr: yeah, the other thing it could be is analog sound, but i don't see why on a display card
kcodyjr: i wouldn't be surprised to see that on an AIW though
kcodyjr: i think i found my test board for the dma engine thing, by the way. if i'm able to get it, i should know in a couple of weeks if i'm getting it. twin xeon 3.0 HT on an E7520 chipset. looks like one of the earlier pcie boards.
Luzipher: lernt something new: don't replace the modules your current kernel uses and do a modprobe then ...
soreau: airlied: Well now it 'works' but it still has weirdness. Bios splash when first turning on the machine has corruption with colors and such, then when booting the text is sort of 'mirrored' on the right side of the screen in pink with corruption and X fails to start and machine hard locks
soreau: I guess it still is a bad card
kcodyjr: if that's the only graphics card in the system, sounds like the vram is toast to me
edt: well r600 kms almost works here. dmesg shows it activating just fine. Then there is an opps. X does start and work and glxinfo reports dri:yes but glxgear speeds are back to non accell speeds (300 instead of 500fps)
edt: goes mesa have to be build with galium enabled if kms is used?
airlied: gears isn't a benchmark
soreau: yea, it's toasted :P
soreau: Oh well, it was worth a shot
edt: agreed but I get 300fps without 3d support....
soreau: has the taste of a new gfx card in his mouth now
edt: and 500 with it on without kms
airlied: edt: which bit of not a benchmark you failing on?
airlied: edt: does glxinfo report hw or sw?
edt: airlied I think its saying hw (nothing in the first couple of says software except the compression stuff)
airlied: does it say DRI2?
soreau: So sad too, X log looks pretty good http://sprunge.us/fEjh
edt: no not in either dmesg or glxinfo.
airlied: then keep following the build guide
edt: does mesa need to be built with gallium enabled for dri2 (or any other flags)
airlied: no
airlied: gallium has nothing to do with dri1/2
edt: I though it was part of ttm but I guess not
airlied: edt: ttm is in the kernel
airlied: gallium is in mesa
edt: ok with the kernel drm and up to date mesa from git there looks to be a third piece of code I need to update to get kms working here
airlied: edt: you aren't following the build instructions?
edt: glxinfo | grep OpenGL
edt: are not the build instructions a little dated with the new drm code in the kernel (the .32-rc0 stuff)?
airlied: no
soreau: I guess since it dies at 'setting up textured video' is a further sign that the vram is fubar
soreau: oh well, butter luck next time I guess
edt: It instucts me to build a 7.5 mesa not the 7.6 that r600 needs....
airlied: edt: you might want totry reading
soreau: indeed
soreau: airlied: Send me an agp card >rv350 you hate! :D
soreau: and this card is so nice and shiny with the chick on the fan cover. what a waste ;)
edt: airlied I have read. What I am tring to do is a bit different. I am attempting to see what happens with the code you have asked to be placed in .32
edt: I know this is not exactly what is/was in drm-next
edt: but it is close to what people are going to try to test very soon
soreau: edt: What are you trying to do exactly then?
edt: I first build a kernel with (31.1-rc1, the three vgaarb patches from Dave posted to lkml, the drm pull request sent to linus for .32, Ingos build fix for VGA_ARB)
edt: this boots fine
edt: then I build mesa from git and installed
edt: this also works fine
edt: and gives me 3D at about 500fps vs 300fps with .31
edt: so now I am trying to get kms working
soreau: and?
edt: looks like I need to rebuild xf86-video-ati as I am getting "radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed"
edt: which implies I will have to alter the ebuild for libdrm to include --enable-radeon-experimental-api
soreau: edt: Why not use the x11 overlay?
edt: the 9999 ebuild?
soreau: ebuilds
edt: that probably will make things easier
edt: is the 9999 mesa ebuild a current git image too?
soreau: The x11 overlay has everything you need except the kernel
edt: soreau thanks
edt: soreau is there a file with what to unmask to enable the overlay?
soreau: You will have to unmask the -9999 components most likely but you add the overlay with layman just like you would any other
edt: I already have the layman setup done. I know that some overlay have a file with stuff to unmask to make things easier. I'll do some diging at this end
DanaG:
Clatch: I'm trying to educate myself on how to better setup my radeon xpress 200m with Ubuntu. I haven't been successful finding a definitive guide on the web. Any suggestions? It's a great card under windows. But I haven't found much support for Ubuntu.
kcodyjr: MostAwesomeDude, thought you were working on gallium, starting to look like you should have a look at your nic... or cluebat your isp if it's comcast ;)
edt: should KMS always start at the native resolution of your screen? If not how do you tell it what to use for the console?
airlied: edt: currently writing code to override it
edt: grin
airlied: but it should always pick the correct mode
edt: I have disabled it for now. I have not been able to get dri2 to enable itself with the kernel here - keep getting the module mismatch message...
edt: here instead of 1900x1200 it gets a vga type screen. after x has run its using the full size screen for a console
edt: this is an r600 (rv780)
edt: or was it rs780
edt: eg boot 640x480 startx 1900x1200 quit X and console is 1900x1200
airlied: was that KMS X or the one you had earlier?
edt: thats with kms x (without accelled dri)
airlied: that sounds like not kms
edt: the dmesg showed new messages from kms
airlied: the X driver had no kms support
edt: how smart is the kernel at loading modules for kms early?
edt: I did build it all with modules
edt: It might make more sense to build kms stuff into the kernel though
airlied: this isn't about the kernel
airlied: its about the X driver
airlied: though I'd build fbcon into the kernel always
edt: X driver at boot time? I'll try with fbcon in the kernel tomorrow. Now its sleep time here. Thanks for the help.
kcodyjr: wait. there's your answer edt. if you're building kms/drm as modules, then it's not initalizing until well after boot.
airlied: gives up and goes back to hiding
kcodyjr: maybe it's not such a shock airlied, most people who only care about X, this is the first they've heard of fbcon
airlied: kcodyjr: his X was broken as well ;-)
kcodyjr: i would imagine so, i doubt the server probing for the drm module would initialize KMS
kcodyjr: thus creating that same new path / old path problem we were talking about back in february, right?
kcodyjr: and he was lucky it didn't just plain lock his box
kcodyjr: is there a reason radeon_mem.c went with a heap allocator, and is that still even relevant with ttm in the picture?
stikonas: agd5f: do you know if running r600 KMS driver can *theoreticaly* be the reason behind laptop monitor breakage?
airlied: stikonas: can't think of anything it could do
airlied: kcodyjr: radeon_mem.c isn't used with kms
stikonas: then it is most likely hardware fault
airlied: kcodyjr: drm_mm.c
airlied: stikonas: did it used to work?
stikonas: yes, it worked for 2 weeks
stikonas: I still have warranty for it
stikonas: and VGA-out works OK with that computer
stikonas: only LVDS shows nothing
airlied: does it work in the BIOS?
stikonas: yes, it does
stikonas: but only VGA-out
stikonas: main screen is completely black
airlied: so if you don't plug in VGA at all you see nothing?
stikonas: correct
airlied: yeah thats usually a send it back type event
stikonas: and the timing is the worst possible, I have to fly to Cambridge, UK this Sunday, and no computer...
kcodyjr: airlied, ok that looks better ;) but still a heap allocator based on a single freelist. is there an affirmative preference for that algorithm?
airlied: kcodyjr: nobodys shown any issues with it yet so it doesn't change
airlied: kcodyjr: i.e. we have worse things before the performance of that allocator comes into question