Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-11-24

Search This Log:

EruditeHermit: I was rebuilding a computer with my friend once and he had an "Austin Power Supply"
happycube: owowow.
happycube: did it fry the mobo by the time you got it?
EruditeHermit: no
EruditeHermit: it worked wonderfully
EruditeHermit: we were salvaging parts from old computers
happycube: austin = deer = *foom*
EruditeHermit: Austin powers!
ossman: airlied, reping
hifi: funny how kms is more stable than ums
Guest42908: i never had this problem before but... http://fpaste.org/W9Uk/
Neo_The_User: i wasn't registered. did anybody get my link?
cxo: yeah
Neo_The_User: k
cxo: You do not have the x11proto dev packages installed on your distro
cxo: (dont ask me what they are called in Fedora)
Neo_The_User: no i use my own distro thanks i forgot about that
cxo: hifi, thats Linus for you. Only the best will do
Neo_The_User: oh i was missing glproto not x11proto. thanks though. im out
happycube: kms/dri2 is just more elegant
Neo_The_User: radeon_dri2.c:349: error: ‘DRM_MAX_MINOR’ undeclared (first use in this function)
Neo_The_User: http://fpaste.org/yOYR/
Neo_The_User: flyback: weren't you the guy who was kicked out of #coreboot or something for talking about your acid reflux for months?
happycube: acid reflux... is that a flash chip replacement technique?
Neo_The_User: was that a joke?
happycube: yeah. ;)
happycube: (thankfully with locked boot blocks, most mobos can be debricked...)
cxo: haha
DanaG: heh, my firmware is UEFI... not much I can do to it. It's probably the most closed-source part of my system, in fact.
DanaG: HP proprietary -- not even "Insyde"-based.
eosie: EruditeHermit: did you say you have RV350?
EruditeHermit: eosie, yes
EruditeHermit: why do you ask?
eosie: EruditeHermit: do you feel adventurous? I'd like you to test something
EruditeHermit: eosie, what?
eosie: if you have time, please git apply this to latest mesa/master: http://storm.unas.cz/pure-chaos.patch , compile r300g and test everything that worked before, and report if it still works
EruditeHermit: eosie, what is the patch for?
EruditeHermit: if its mesa compile then its easy =)
EruditeHermit: kernel compiles suck
EruditeHermit: take 2hrs
eosie: there is a commit message which explains it all
EruditeHermit: ok
EruditeHermit: give me 30mins or so
MostAwesomeDude: eosie: Get airlied's ack on that patch, please; he was the last guy to clean up RS setup.
EruditeHermit: eosie, to see it can I do git log?
eosie: "git apply" doesn't commit
EruditeHermit: right
EruditeHermit: i would have to do the commit
EruditeHermit: but then I would be supplying the message
eosie: you can see it with git diff or git status
eosie: git am EruditeHermit: does it show your commit message?
eosie: with git am, yes
marvin24: mmh, glxgears crashes here with r300/gallium (on rs690)
marvin24: trace at http://pastebin.com/m4c59d8e9
MostAwesomeDude: marvin24: Known bug, RS690 is a SW TCL chipset and r300g's SW TCL is broken.
MostAwesomeDude: Sorry. :C
marvin24: MostAwesomeDude: I just saw some commits related to swtcl, I though I could give it a try
marvin24: have to wait than
spreeuw: was there a bug introduced yesterday that enforces software rasterizer?
MostAwesomeDude: marvin24: It's getting more cleaned up, but it got broken months upon months ago, and I haven't felt like fixing it until recently.
spreeuw: I tried to enable KMS/DRI2 on mesa git
marvin24: MostAwesomeDude: thanks anyway for your great work!
spreeuw: with libdrm .15 linux 2.6.32rc8 and mesa git
spreeuw: should that combo work?
spreeuw: .15 was compiled with the options from the wiki
MostAwesomeDude: marvin24: Sure. I'll probably make some noise when I know that it works again. Or maybe some silly messages in the git log. :3
spreeuw: and ddx was form git too
spreeuw: I had one xorg log entry saying [KMS] modesettign not supported
dman777: i have a problem with opacity in compiz and with mesa that caused my typing to be slow and laggy. i did the 9999 mesa and seem to improve it alot. but now it is getting laggy again. i am using urxvt if that helps any. ultimately i think the problem comes down to mesa and radeon and i was wondering if anyone could help here.
EruditeHermit: eosie, hi
eosie: eosie: hi
EruditeHermit: that time of day when you are talking to yourself?
eosie: unfortunately, I am sleepy
EruditeHermit: so what do you want me to test?
eosie: EruditeHermit: let's something complex, e.g. openarena _provided_ it worked before
eosie: *let's say
EruditeHermit: hmm
EruditeHermit: so I hit the bug with different resolutions not working with kms if I try openarena
EruditeHermit: how about xmoto
eosie: xmoto is ok
EruditeHermit: ok xmoto doesn't work
EruditeHermit: I am not sure if it did before
EruditeHermit: its printing a lot of stuff about Pkt3
EruditeHermit: and Pkt0
eosie: then it's probably not about this patch
EruditeHermit: glxgears works
eosie: I should have thought it through
EruditeHermit: I have texture corruption
EruditeHermit: on my o3d website
EruditeHermit: that worked with gallium before
eosie: EruditeHermit: link?
EruditeHermit: oh3d.org
EruditeHermit: you will need o3d plugin
EruditeHermit: are you on Ubuntu?
eosie: yes
eosie: I am
EruditeHermit: https://launchpad.net/~ubuntu-webtech/+archive/o3d-daily
EruditeHermit: you'll need that plugin
DanaG: hmm, for me, o3d just crashed.
DanaG: nspluginwrapped, it was, too.
EruditeHermit: 64bit doesn't work well
DanaG: yeah, I'd say it doesn't work at all.
EruditeHermit: yeah
EruditeHermit: its hard to test anything with that resolution switch bug present
EruditeHermit: I have to compile drm-radeon-next I think
EruditeHermit: but the only tests I could try failed
EruditeHermit: eosie, were you able to test o3d?
eosie: EruditeHermit: no, I have ubuntu 64bit
EruditeHermit: ah
EruditeHermit: eosie, gnight
eosie: airlied: could you possibly review this r300g-related patch? http://storm.unas.cz/pure-chaos.patch it might be more readable applied
eosie: EruditeHermit: gn
EruditeHermit: eosie, did you get to test it on xmoto?
eosie: EruditeHermit: I think the xmoto issue is unrelated to this patch
EruditeHermit: try something that uses textures
EruditeHermit: eosie, try blender with it
eosie: I definitely works here, tested with piglit
EruditeHermit: eosie, try tunnel in the demos dir
eosie: and I've also run my own tests on it, it behaves exactly like swrast, softpipe, and r300c
eosie: which is not the case with current mesa/master
EruditeHermit: all text is messed up here
DanaG: o3d doesn't work on ANY driver for me... swrast, fglrx, radeon... I think I've tried all three.
DanaG: I think.
EruditeHermit: DanaG, its because the libCg is too old
EruditeHermit: DanaG, download libCg2.2 or newer and put it in /usr/lib/o3d/
DanaG: aah.
EruditeHermit: if you are using ATI cards
EruditeHermit: Cg 2.1 has a bug
EruditeHermit: it only works with nvidia
DanaG: Sure would be nice if it had TOLD me that. =P
EruditeHermit: they don't know
EruditeHermit: =p
EruditeHermit: also
EruditeHermit: if on 64 bit
EruditeHermit: download 32bit firefox
EruditeHermit: and run it as 32bit in there
eosie: EruditeHermit: that's ok, fog coordinates never worked, but it's very high on my list
EruditeHermit: eosie, what about multiarb
EruditeHermit: that also doesn't work like it does in standard kms
EruditeHermit: eosie, Ah try textures
EruditeHermit: none of the textures show up for me
EruditeHermit: progs/demos/textures
EruditeHermit: DanaG, its fairly easy to download firefox and unzip it to a directory and run a 32bit version from that directory
eosie: EruditeHermit: does it work without the patch?
EruditeHermit: err let me check
EruditeHermit: if I didn't commit it
EruditeHermit: can I just git reset --hard
eosie: git reset --hard HEAD~1
EruditeHermit: eosie, ok it doesn't work without the patch either, BUT
EruditeHermit: with the patch the textures look like tv static noise
EruditeHermit: without the patch, they are solid colours
EruditeHermit: multiarb works without the patch
EruditeHermit: it fails with the patch
EruditeHermit: actually it doesn't work without the patch
EruditeHermit: but it renders better
EruditeHermit: it fails less
EruditeHermit: tunnel also works
EruditeHermit: partially
EruditeHermit: with the patch, the text in the tunnel demo is corrupted
EruditeHermit: without the patch, the text is not corrupted
EruditeHermit: eosie, does it work for you?
eosie: EruditeHermit: the tunnel demo shouldn't work, I intentionally assert if fogcoords are used
EruditeHermit: eosie, pick any demo with text instructions
EruditeHermit: eosie, the text is always garbled
eosie: all works for me
EruditeHermit: well
EruditeHermit: are you PCIe?
EruditeHermit: or AGP?
eosie: PCIe
EruditeHermit: what generation?
eosie: RV530
EruditeHermit: ah that might be why
EruditeHermit: so your patch works for r5xx maybe but not for r3xx
EruditeHermit: eosie, do you need a screenshot?
eosie: I have a PC 32bit with R300 AGP around, so I am gonna test it if I can get ubuntu onto it
eosie: EruditeHermit: yes, please
eosie: EruditeHermit: nevermind, I've found the bug
EruditeHermit: http://imagebin.org/72784
EruditeHermit: darnit
EruditeHermit: eosie, what was it?
eosie: .xxxx swizzle on texcoords instead of .xyzw
eosie: EruditeHermit: http://storm.unas.cz/pure-hell.patch could you re-test?
EruditeHermit: sure
EruditeHermit: yeah that fixed it
EruditeHermit: perfect
eosie: cool
EruditeHermit: fixes textures in o3d too
EruditeHermit: how did it work for you
EruditeHermit: you should have seen the same corruption shouldn't you?
eosie: EruditeHermit: there is a different codepath for R500
eosie: EruditeHermit: thanks for the assistance
EruditeHermit: no worries
EruditeHermit: thanks for working on r300g
EruditeHermit: eosie, btw, gearbox demo exhibits a weird background colour issue
EruditeHermit: glxgears used to do the same thing but MostAwesomeDude fixed it I think
eosie: EruditeHermit: this a known issue, it's there since hwtcl was merged
EruditeHermit: ah ok
EruditeHermit: so we are waiting on hw clears
eosie: still too many bugs/incomplete things on my radar
EruditeHermit: eosie, are you just fixing all the bugs?
eosie: that's the plan
eosie: well, the plan is to make as much piglit tests pass as possible
eosie: EruditeHermit: there is no point in making it faster if it cannot run games
EruditeHermit: well if it can do as much as classic mesa
EruditeHermit: then it might be worth making it fast enough so that some people would be willing to try it out permanently
EruditeHermit: then you get more testers
EruditeHermit: and then slowly add features from there
Ghworg: Premature optimisation is the root of all evil
EruditeHermit: i think both ways have their problems and benefits
EruditeHermit: but the devs know best =p
cire: hmm, my direct rendering is gone. Also, Windows don't paint fully sometimes... (mesa+drm,ati-radeon from master, kernel is drm-next)
cire: but kde4 desktop effects work
EruditeHermit: eosie, ok gnight
eosie: EruditeHermit: gn
cire: glxgears gives me 1500 fps
cire: gn
cire: perhaps someone wants to have a look at my screenshot at http://yfrog.com/bhkde4weirdp
cire: xlog is: http://pastebin.ca/1685248
Ghworg: cire: Windows not updating is possibly bug https://bugs.freedesktop.org/show_bug.cgi?id=25193
Ghworg: cire: In which case try reverting 286bf89e5a1fc931dbf523ded861b809859485e2
cire: thansk for the hint, I'll check that
cire: hmm, libgl_debug=1 glxgears gives me
cire: ...r600_dri.so: undefined symbol: radeon_bo_is_referenced_by_cs
cire: same problem as 286bf89e5a1fc931dbf523ded861b809859485e2
fpoibaf: cire: you need to updated libdrm_radeon up to include at least http://cgit.freedesktop.org/mesa/drm/commit/?id=b4312b639d56a6cad78953af0fd4f863182007e3
cire: I just did a git pull
cire: as Alex said in discussion http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44745.html, it should be resolved
cire: in master
cire: WHat's the easiest way of cloning the git again?
fpoibaf: cire: that was another problem, you need an updated *libdrm* from git if are using latest mesas
cire: I think I am using drm (and libdrm?) master
cire: git://anongit.freedesktop.org/mesa/drm
fpoibaf: cire: "r600_dri.so: undefined symbol: radeon_bo_is_referenced_by_cs" disagree, try updating again
cire: okay...
Vash63: I started having the same issue a few days ago, though my libdrm isn't from git so probably the same fix too.
cire: I did git pull followed by make clean and am compiling now again
Vash63: I just switched to XRender for now, doesn't have as many issues.
Vash63: I've also noticed that the performance of 2d acceleration has gone way up recently, possibly with the pixmip patch.
Vash63: pixman no longer uses 100% of one thread while I scroll upa nd down in Firefox.
Vash63: Flash seems to be working much faster now too, though maximizing it isn't working... the performance improvements are pretty nice.
EruditeHermit: airlied, my laptop just died : (
bjacques: What is the best way to accomplish antialiasing with the free radeon driver?
glisse: bjacques: what kind of antialiasing you want ?
hifi: ok, my HD 4650 is in the hands of DHL, please please come before weekend
bjacques: glisse: I'm drawing, basically, complex polygons filled (and outlined) with textures
bjacques: and their contours should be smooth
bjacques: I'm using the GLU tesselator to generate the complex shape
glisse: bjacques: well any gl technics which doesn't use msaa would work, of course the more tesselated your primitive are the better it will be
bjacques: so far as I understand it the only technique available is using the accumulation buffer, but this is very slow, at least on my hardware
glisse: accumulation buffer is done in sw iirc
bjacques: Yeah. glxinfo marks it with a "slow" caveat
bjacques: So what other options are there? I can't use simple polygon antialiasing, because the shapes are made from many polygons and each polygon would antialias against another.
Ronis_BR: hi all
Ronis_BR: airlied: fellow, is there any chance that the commit commit 5c934ce0168d6c2829af2f38a94914ebe66c441c can fix incompatibility between KMS and tuxonice?
glisse: bjacques: not much other solution
glisse: Ronis_BR: got a link ?
Ronis_BR: glisse: link of what? :)
Ronis_BR: glisse: ?
glisse: Ronis_BR: of the repo of the commit
Ronis_BR: glisse: no, I don't
Ronis_BR: It was commited to drm-radeon-testing yesterday
Ronis_BR: Author: Dave Airlie
Ronis_BR: Date: Mon Nov 23 12:01:09 2009 +1000
glisse: this patch has nothing to do with s/r
glisse: it's most unlikely that i will influence tuxonice
Ronis_BR: :( ok :D
Ronis_BR: thanks glisse!
glisse: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=5c934ce0168d6c2829af2f38a94914ebe66c441c
glisse: Ronis_BR: btw hibernate works here
glisse: just tested it
Ronis_BR: glisse: really? uwsusp?
glisse: Ronis_BR: fedora 12
glisse: just clicked on hibernate
glisse: computer shutdown
Ronis_BR: glisse: but uwsusp or tuxonice?
Ronis_BR: glisse: I don't know what fedora uses
Ronis_BR: glisse: (I have problem at resume btw)
glisse: Ronis_BR: we don't use tuxonice
Ronis_BR: so it must be default kernel system
Ronis_BR: for me it is bad because I just have 512MiB of swap :D
Ronis_BR: and I'm not planning to increase it
Ronis_BR: glisse: I'll have to backup things first :D
bjacques: glisse: is line & point smoothing implemented?
glisse: bjacques: not on all gpu
evil_core: hi all
evil_core: Anybody can help me getting better R500 performance? And also compatilibty, especially in wine
gimzo: evil_core: the best way right now is to wait for improved drivers and wine
evil_core: I have stable driver, so maybe soime bleeding edge
evil_core: gimzo: is there some special R500 branch, like for R600/700?
evil_core: I am using R300 Mesa dri driver
adamk_: evil_core, There is not.
evil_core: generlly I am using now stable code, but its not problem to change it
biotube: evil_core: there's no special branch for any of them
adamk_: r3xx through r5xx all use the same driver, from the same branch.
adamk_: You could update to a git version of Mesa.
evil_core: so Mesa matter at most?
adamk_: That might give some performance boost, but that's probably not definite.
evil_core: I want FBO/pbuffer, GLSL
adamk_: You can want all you want :-)
evil_core: and cureewntly DRI doesnt work when KMS is enabled, in both radeon and radeonhd
bjacques: is GLSL not supported currently? At least in compiled form?
adamk_: GLSL isn't gonna happen till the r300 gallium3d driver is ready for mainstream use.
adamk_: DRI works just fine with KMS enabled.
evil_core: I remember that there wrere some inter ranches with FBO and GLSL
evil_core: and I cannot find gallium in mine distro
biotube: evil_core: that's because it's extremely experimental
adamk_: If it doesn't work for you, then you should figure out why :-)
adamk_: And, and don't use radeonhd with KMS. That just won't work.
evil_core: adamk_: they told me different thing anyway ;)
adamk_: evil_core, osiris was working on FBO, iirc. GLSL will only be available with gallium3d.
evil_core: gallium3d works?
adamk_: No, not really.
adamk_: Last I tried (last week) textures were all screwed up.
gimzo: what happened to glsl in r300 idea people were talking about few months ago ?
evil_core: now xmoto crashesh often, and I got soime errors about buffer leakage
rnoland: agd5f: question
adamk_: gimzo, To my knowledge, nothing. GLSL was just committed to the r6xx/r7xx mesa driver, but I haven't heard of anything for r300.
rnoland: radeon_drm.h now includes linux/types.h
rnoland: i'll have to ifdef that, or include drm.h which takes care of it already
evil_core: and they told me tat /whois adamk_
rnoland: agd5f: which do you prefer?
gimzo: adamk_: I seem to remember MostAwesomeDude was saying he hopes to get glsl in r300 before r300g somewhere in september
evil_core: r300g is gallium?
adamk_: gimzo, Interesting.. That's the first I've heard of it, but it would be cool if it's true.
biotube: yes
gimzo: evil_core: yes
biotube: evilcore: ^
gimzo: adamk_: that's the last I've heard of it :)
evil_core: so what I get in current radeon R300?
evil_core: I got pbuffer?
biotube: IIRC, there's hardware blitting
evil_core: I want to set correctly wine registry keys to match new driver
evil_core: and is R300 limited to 256MB aperture? anything I set above, then DRI disables
evil_core: and I was reading that XAA acceleration is avaible up to radeon 9600, and I shoulkd use EXA with newer ones. but EXA brokes fonts for me after running some game
adamk_: Try a newer version of the driver and if it's still broken, open up a bug report.
evil_core: hmm..I was thinking that fonts are officialy broken ;)
evil_core: anyway, it were mostly questions
evil_core: is it true that I need KMS for power saving?
adamk_: Seriously, if you want it fixed, open up a bug report.
biotube: evil_core: other way around
adamk_: Or see if one already exists. I believe all font corruption issues are thought to have been fixed.
biotube: KMS has no PM support at the moment
adamk_: And, no, you don't need KMS for power savings. Indeed, there are no power savings with KMS at the moment.
evil_core: hmm...in #radeonhd somebody told me that :/
biotube: radeonhd doesn't support r500
evil_core: anyway I got 2.6.32-rc8, on stable DRI wasnt working
evil_core: what mean "doesnt support"?
biotube: nevermind
evil_core: I was able to get DRI on it, but it was crashing
adamk_: biotube, Errr. What?
biotube: seems they do
adamk_: biotube, radeonhd supports r500+
biotube: i seem to love the taste of my foot :)
mokoloko: can't blame you it is tasty
adamk_: mokoloko, You've tasted his foot?
soreau: lol
mokoloko: ...busted
aaahaaap: Hi all, does anybody know if component/RGB-out via the DIN-connector is supposed to work?
evil_core: DIN is circle? Isnt that s-video?
aaahaaap: yeah, circle, its not an official s-video connector, but an s-video connector can be plugged in it
aaahaaap: but it can output s-video, composite and component
gimzo: aaahaaap: I think component means YPbPr, not rgb
aaahaaap: yeah, when RGB is mentioned specifically it means YPbPr
TobiasTheCommie: aaahaaap: isn't the DIN-connecter usually used with a dongle? where the dongle has all the s-video, etc, things...
TobiasTheCommie: at least, that's how it has been with a few of my cards
evil_core: Sega Mega Driver has maybe similar one, check how to build it
aaahaaap: TobiasTheCommie: yeah it is, I've got a composite and a component adapter-cable (can be a dongle adapter as well)
evil_core: there are sites with many different DIY RGB adapters
evil_core: even old SMD/Genesis ans SNES can output beatiful RGB
gimzo: I think the best rgb is from vga output :)
evil_core: anyway, can I make s-video in T60p?
evil_core: but you dont have VGA in SNES console
aaahaaap: k, I already thought so, will have to solder an VGA->RGB adapter then
evil_core: or evewn video
aaahaaap: just odd I cant use the output in some way
gimzo: evil_core: I meant PC graphic cards output :)
aaahaaap: I can drive my monitor through component
evil_core: but I want ot get TV-OUT out of mine T60p, officiallhy its impossible
aaahaaap: evil_core: you want s-video outpunt on a t60p?
evil_core: but if other laptops got this with equal cards, then why shouldnt it work on mine?
evil_core: yeah, it can be usable sometimes I think
aaahaaap: evil_core: they just didnt add it to the mainboard
aaahaaap: it's not on the docks either
evil_core: anyway the biggest problem is integrated noise generator
evil_core: on the dock I got DVI and VGA
evil_core: this integrated nosie generator is real it
evil_core: run AIGLX glxgears, and you got effecdt like cat /dev/urandom > /dev/dsp
evil_core: its even bad for movies
gimzo: evil_core: that sounds like realtek audio chip ?
evil_core: any integrated card works like that, remember "Spread Spectrum" in old BIOSes?
evil_core: its AD something
aaahaaap: you need it for proper audio playback?
gimzo: I had that problem with laptop, so I got cmedia usb thinggy, not perfect but works ok
evil_core: not for proper, it was noise-smoother ; )
evil_core: dont like c-media, would yu audigy2zs for notebook
aaahaaap: well, I guess the only option would be an external soundcard
aaahaaap: search for usb-dac
evil_core: but I then wil not get output on speakers easily, and it will stick out of it a bit
gimzo: and I since have alc888 in my desktop, I don't feel the urge to put audigy2 back in
evil_core: mine firdn doesnt wsnt to solder anything else in it, he told me that he did such thing only once and last in his life
evil_core: I dont like realtek, but mine analog Devices doesnt sound proper even on headphones
aaahaaap: http://www.hippohifi.com/products/bloat/bloat.html
gimzo: I didn't like realtek but it looks like they are getting better
evil_core: i dont believe in anything integrated
evil_core: iut will always interfere with other components
kdekorte_: evil_core, I have a T60p, and don't get much noise from it over audio
evil_core: kdekorte_: try running aiglxed app
kdekorte_: evil_core, if it bad, you might try a USB headset or USB audio card
kdekorte_: evil_core, I run clutter apps (3d video) and they are fine
evil_core: I made direct for 32 bit apps too
evil_core: if you not install Msa-dri-driver-ati-R300 for 32it multilib, then it gough trough "indirect acclelerated glx"
evil_core: it also depends robvably waht HZ inb kernel you use
evil_core: because frequency must interfere with sound to be so much audible
kdekorte_: evil_core, I'm just using Fedora 12, but I did upgrade mesa from git.. otherwise it is stock F12
evil_core: I am trying to build laptop kenrel in PLD, but mine buiuld environbemnt is broken, so I am forced to make it currently on remote machine
biotube: glslnoise still locks up the GPU
biotube: though fslight works fine
kdekorte_: biotube, how did you enable glsl?
biotube: -DR600_ENABLE_GLSL_TEST
evil_core: I want such flag for R300 ;)
evil_core: R500 isnt more similar to R600 than R300?
bridgman: 5xx is more like 3xx from programming point of view
aaahaaap: evil_core: I have no nosie issues either on my t60p, its running windows though, don't know if that matters
kdekorte_: R500 is a R300+
evil_core: i called it noise generator because if shitty sound quality, not becaue this one noise problem i fixed ;)
gimzo: what is r400 then ?
bridgman: ok, 400 is 300+, 500 is 300++ ;)
bridgman: better ?
kdekorte_: something to be avoided...
evil_core: R500 isl ast 2D accell chip?
bridgman: 2D and 3D
bridgman: and display
evil_core: yeah, but llast 2D?
bridgman: yes, last one with the traditional 2D acceleration block
evil_core: I run many acient games, espoecially allegro and hot-babe sucks on modern cards
evil_core: try running hot-babe on gf 7xxx or newer, it sucks
bridgman: might be that it does a lot of overlapping blits; that's the one thing that's hard to do on 3D engine
bridgman: most of the other 2D operations run faster on 3D engine than 2D
bridgman: are they side-scrollers ?
evil_core: hot-babe is classic CPU usage visualizer
evil_core: try it
gimzo: r600 doesn't have hw blitter ?
biotube: gimzo: it doesn't have 2d hardware
evil_core: it has framebuffer
gimzo: can't blitting be done using dma ?
gimzo: *dma hardware
evil_core: so I canm use XAA on mine R500?
bridgman: 3D engine is a lot faster
bridgman: you can use XAA on r5xx but I wouldn't bother
kdekorte_: evil_core, hot_babe probably just needs to be ported to GTK2 and use double buffering...
MostAwesomeDude: XAA's worthless on r5xx because it doesn't accel Composite ops.
evil_core: kdekorte_: maybe, but it worked fine on 1666MMX, 16MB RAM and 1MB S3 Trio
evil_core: so for me its regression :P
bridgman: if you only want to do the stuff you could do on the S3 then XAA is probably fine
bridgman: if you want to run anything from like the 21st century you might want to consider EXA ;)
evil_core: I want to run WindowMaker and xterm mainly
kdekorte_: I took a look at the code and it is running in a loop with a usleep, might be better to put it in an idle loop
evil_core: but w3m/linksh-hacked not supported feautres would force me to gecko
evil_core: or webkit
evil_core: kdekorte_: I got bash skills, and am able to write hello.c ;)
evil_core: but it owulod be one function in code replacement?
kdekorte_: evil_core, Let me mess around with it...
evil_core: ok, thx :D
evil_core: anyway, radeon supports pbuffer? and what about shaders?
MostAwesomeDude: Pre-GLSL shaders work. GLSL shaders need some hax thanks to some stupidity further down the line.
MostAwesomeDude: Pbuffers and FBOs work.
evil_core: I got R500
evil_core: MostAwesomeDude: yeah, they told about you before! So all it works on R500 in Mesa R300 driver?
bridgman: you need KMS for pbuffers and fbos, don't you ?
evil_core: dunno, I heard I need r500/r600 before
phoenix64: http://cgit.freedesktop.org/mesa/mesa/commit/?id=15740eb03ca8fb7eda585c612c1b36ec9df4474a <- what about http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel btw?
evil_core: bridgman: but KMS? probably Gallium or osmethinf
MostAwesomeDude: Yeah, you need KMS for FBOs.
MostAwesomeDude: You also need KMS for Gallium.
phoenix64: why btw? UMS does not allow persistent graphics card memory?
evil_core: MostAwesomeDude: so what I need to do for R300 to et that all? Gallium annd al lis in master?
evil_core: all that is*
evil_core: is that all*
MostAwesomeDude: phoenix64: Largely, yes.
soreau: evil_core: See the link in the topic
evil_core: sorry for mine horrible english ;)
MostAwesomeDude: evil_core: Gallium's in Mesa, but it's not turned on by default, and I don't recommend it unless you want to file bugs.
soreau: MostAwesomeDude: Someone was saying that you were talking about r300 classic mesa glsl? I assume you ma have been jesting?
MostAwesomeDude: soreau: No, not really. nha's been doing some cool compiler work. Whether or not it actually works is another story.
soreau: haha
soreau: MostAwesomeDude: Nice
soreau: I know at least compiz mag fisheye mode is broken in latest mesa and I seemed to have tracked it down to nhas merging 7.6 into master r300 compiler stuff
soreau: I filed a bug with the good commits I found; hope it gets fixed
evil_core: MostAwesomeDude: So I simply need to get al from master branches and dont bother about Gallium to get FBO/pbuffer?
soreau: evil_core: Right. As adamk said earlier, gallium is not ready yet
evil_core: yeah, but trhey also told me thats only supported by gallium or for R600/R700
tsamolotoff: Hi guys!
soreau: evil_core: Who is this they you keep talking about?
evil_core: I was reading it, and theres about kernel 2.6.31, I dont need new kernel modules?
tsamolotoff: KDE desktop effects are now broken - who's to blame on?
evil_core: peoples there
soreau: evil_core: there?
bridgman: it's not *supported* on anything yet; there's work in process on 3xx-5xx and 6xx-7xx and this week the 6xx-7xx seems to be a bit ahead ;)
tsamolotoff: And still, wrong texture size for compressed textures is not dealt with...
tsamolotoff: evil_core: Are you refferring to my problem?
evil_core: tsamolotoff:
bridgman: tsamolotoff; evil_core is talking about glsl & gl2.x implementation
bridgman: and looking for answers we don't have yet ;)
evil_core: soreau: not sure, maybe they told only about GLSL, I am in many channels now
bridgman: evil_core; what you are getting right now is guesses; until the work is actually finished nobody knows for sure
tsamolotoff: bridgeman: And what's about KMS and s3tc incompatibility
bridgman: didn't think the two were related
ajax: there's nothing intrinsic to kms that makes it incompatible with s3tc
tsamolotoff: The problem exists for 2 month as of now, and nobody's fixed that?
bridgman: KMS works, s3tc not
evil_core: tsamolotoff: wtf? what is corelation between both?
tsamolotoff: evil_core: [drm:r100_cs_track_texture_check] *ERROR* Texture of unit 1 needs 1310720 bytes but is 352256
ajax: that looks like a bug alright.
tsamolotoff: this is the corellation. With nomodeset all the things work perfectly on my M56
evil_core: I got V5200, not sure if its M56 also
evil_core: anyway, DRI didnt worked for me with KMS
tsamolotoff: ajax: You know, there's even bug report at freedesktop.org, with severety set to major and none was done as of yet
soreau: evil_core: It works fine
soreau: evil_core: You should have latest kernel, libdrm, mesa and ddx
evil_core: lates == master, or stable?
soreau: master
tsamolotoff: And now all KWin's d-effects are reported as non-functional
tsamolotoff: all what I've done was git-pull and compiling all the latest stuff from fdo
evil_core: kernel is 2.6.32-rc8, so its master?
soreau: evil_core: That will work
soreau: adamk_: Are kwin effects broken for you with latest code?
evil_core: soreau: but can I install all ins /usr/local and LD_LIBRARY_PATH?
evil_core: wxcept ddx
ajax: tsamolotoff: heavens.
ajax: a bug in free software
soreau: In theory I guess
soreau: evil_core: Read the link in the topic
adamk_: soreau, Haven't tried, and I can't really at the moment.
soreau: adamk_: I was just wondering as I had never got them to work and tsamolotoff is now reporting they dont
MostAwesomeDude: It's just a bug in the CS checker.
soreau: It just needs to be fixed ;)
tsamolotoff: MostAwesomeDude: And the corresponding bug at fdo's bugzilla?
tsamolotoff: The folks there seemed to blame each other for the brokage
tsamolotoff: *breakage
MostAwesomeDude: Dunno. Link?
tsamolotoff: http://bugs.freedesktop.org/show_bug.cgi?id=24593
MostAwesomeDude: Huh. Doesn't look like people are blaming each other.
MostAwesomeDude: osiris pointed the same place I pointe.
MostAwesomeDude: *pointed, even.
tsamolotoff: Well, you're the expert
tsamolotoff: It's still the same with 32-rc8
jakemills: Hi there, I have been in the Fedora channel asking about the experimental driver and trying to get it to work with my Radeon HD 4350
jakemills: I can't seem to get it working as was told that I should try asking in here
MostAwesomeDude: tsamolotoff: Yes, we know. We haven't fixed it.
soreau: jakemills: What is not working about it?
tsamolotoff: MostAwesomeDude: Well, a pity. And what's about KDE desktop effects?
tsamolotoff: A week ago they've worked perfectly...
soreau: tsamolotoff: Perhaps you can perform a bisect
tsamolotoff: soreau: It's just an academic question, I don't really care about them
lordheavy: hi, currently xf86-video-ati (from git) fail to build with libdrm (from git) : http://pastebin.fr/6095
kdekorte_: evil_core, Can I send you a patch to hot_babe and see if it solves your flickering?
agd5f: rnoland: doesn't matter to me. airlied might have a preference
rnoland: agd5f: forgot exactly what i asked now... but i think we have radeon sorted....
rnoland: mga is screwing me now... in mesa build
rnoland: ah, i see why now....
evil_core: kdekorte_: sure, but I didnt tested even normal hotbabe on radeon, but athlon aith geforce stills next to me :D
agd5f: aaahaaap: no component out support yet
agd5f: rnoland: linux/types.h
rnoland: yes... i think i have replace that with include "drm.h" most everywhere now
rnoland: and drm.h defined the silly __uXX types
kdekorte_: evil_core, you should be getting a file from me
lordheavy: xf86-video-ati fail to build with undefined DRM_MAX_MINOR in radeon_dri2.c, defined in libdrm file xf86drm.c ......
zhasha: lordheavy: are you compiling it against a new enough libdrm?
lordheavy: yes, from git , master branch
Neo_The_User: can somebody please help me? http://pastebin.com/d73c0b740
lordheavy: Neo_The_User : same problem here :-p
Neo_The_User: oh ok
Neo_The_User: oh right
Neo_The_User: yeah i asked last night and didnt get an answer so i went to sleep.
soreau: Neo_The_User: lordheavy: Have you guys already compiled latest libdrm beforehand?
Neo_The_User: you bet ya. with --enable-radeon-experimental-api :)
soreau: Maybe there are some stale headers left of your system
Neo_The_User: i ran sudo make uninstall in drm and sudo make install
Neo_The_User: afterward
soreau: Does drm/drm.h define DRM_MAX_MINOR?
lordheavy: no, produce through packages so cleanly removes
lordheavy: soreau: no, only in xf86drm.c
lordheavy: here
soreau: lordheavy: You need to correctly install latest libdrm
Neo_The_User: i compiled my whole distro from source by hand with no package manager and everything else installed fine
soreau: That doesnt answer the question though ;)
Neo_The_User: i have latest libdrm installed is my point.... correctly.
soreau: Still not a matching answer
Neo_The_User: unless somebody broke libdrm
Neo_The_User: what answer are you looking for?
lordheavy: built like this : http://pastebin.fr/6096
Neo_The_User: are you using archlinux?
Neo_The_User: just curious
soreau: or gentoo
lordheavy: yes
soreau: You are using arch AND gentoo?
Neo_The_User: hahaha
rnoland: adamk: are you still seeing issues with mesa?
lordheavy: arch :-)
rnoland: if so, how to reproduce?
soreau: lordheavy: I know at least on gentoo there was a problem where the ebuild would not git pull correctly leaving stale code lying around
soreau: lordheavy: Deleting the git libdrm directory the package holds fixed it
lordheavy: ok will remove dirs and pull again
Neo_The_User: wait what are you guys doing?
Neo_The_User: just re cloning the libdrm git repo and re installing?
soreau: You are obviously not paying any attention
rnoland: i just pushed some changes to libdrm as well.
Neo_The_User: i dont understand this part, "the package holds fixed it" as that is improper grammar.
Neo_The_User: unless "package holds" is term
Neo_The_User: ^a
soreau: Neo_The_User: First, which distro are you using?
Neo_The_User: my own. basically linux from scratch 64-bit which doesn't exist yet IIRC
soreau: Neo_The_User: Second, does your drm/drm.h define DRM_MAX_MINOR?
Neo_The_User: I don't even see drm.h in the drm source code root folder.
soreau: That file should have been installed to the standard include directory, /usr/include on most systems
ech0s7: hi
ech0s7: what is the sitauation about driver on rv620? Compiz and power managemt are supported ?
Neo_The_User: soreau: no its not there
soreau: Neo_The_User: It should be wherever you installed libdrm to
Neo_The_User: no the file is there
Neo_The_User: not the header
soreau: The file is a header file :)
flyback: is fine, a little sore but fine, sorry about last night, the pain got to me after 3+ yrs of fighting this
soreau: You mean the define is not there?
Neo_The_User: ok sorry my english is all screwed up. yes exactly
biotube: ech0s7: power management's not well done, ForceLowPowerMode at most with UMS and a slightly buggy patch with KMS
soreau: Ok, that means you have old libdrm header
soreau: You need to install latest libdrm correctly
Neo_The_User: deletes the whole drm folder in /usr/include
soreau: If you did not specify a prefix for it to install, I believe the default is/usr/local
Neo_The_User: nope its in /usr
lordheavy: soreau: same problem with clean git checkout
soreau: lordheavy: That define is still not in the drm header?
lordheavy: no
lordheavy: not in master here
soreau: Well I dont know what to tell you then
Neo_The_User: somebody needs to fix them codes :P
lordheavy: perhaps in another branch ?
soreau: except that this is how it is on my system and it is working
Neo_The_User: you have latest master?
Neo_The_User: i removed all drm libraries on my hard drive and re-installed and ill try it again
lordheavy: found ! removed here (an error ?) http://cgit.freedesktop.org/mesa/drm/commit/?id=500f5b524000ed5930301f4303744cb4c0a19b75
Neo_The_User: yeah still didn't work
soreau: Neo_The_User: What is failing to build? ddx?
soreau: lordheavy: Are you on 64bit by chance?
Neo_The_User: yuppers
Neo_The_User: i am
lordheavy: xf86-video-ati
lordheavy: yes x86-64
soreau: hmmm
lordheavy: DRM_MAX_MINOR is removed from commit 500f5b524000ed5930301f4303744cb4c0a19b75
lordheavy: from drm.h
rnoland: i think that should now be in xf86drm.h
Neo_The_User: races as fast as he can to get a patch in
Neo_The_User: before anybody else. >:)
lordheavy: but it isn't actually :-), it's in xf86drm.c
rnoland: you might ask krh
rnoland: he and airlied were the ones that were trying to sort that part out....
soreau: Well damn. It is broke here too
soreau: Was working yesterday
lordheavy: :-)
soreau: ok, so you need older libdrm, not newer :)
lordheavy: i agree :-)
Neo_The_User: ill wait for them to fix it
lordheavy: it's the better choice
Neo_The_User: somebody probably already sent the email
lordheavy: ok i've found the bug, it's only a bad cut&paste error
soreau: lordheavy: ?
lordheavy: http://cgit.freedesktop.org/mesa/drm/commit/?id=500f5b524000ed5930301f4303744cb4c0a19b75 here it's removed but not correctly pasted
lordheavy: in xf86drm.h
lordheavy: nice now it build
soreau: Yea you are right
soreau: it is simple cut/past error
lordheavy: found with your help
soreau: I notified krh so hopefully it will be fixed soon
lordheavy: thanks
rnoland: did you just move it to the header file?
lordheavy: i've added '#define DRM_MAX_MINOR 15' in xf86drm.h
Neo_The_User: flyback: glad you are feeling better
Ghworg: Next time I decide to go fiddling with my kernel config someone needs to slap me
Ghworg: I made a lovely unbootable kernel
Neo_The_User: im really good at trimming down kernels
Neo_The_User: down to 1MB
Neo_The_User: that work very good
syskill: 1MB with everything you need or you add lots of modules?
Ghworg: I just wanted to get the compile time down a bit
Neo_The_User: welll mine is 1.5 MB with all the DRM code compilin INTO (Y)
Neo_The_User: *compiled
Neo_The_User: and its all i need
Ghworg: Now I have to wait for a new one to compile to get my KMS back
Neo_The_User: Ghworg: i can help you
Neo_The_User: Post a dmesg on pastebin and ill make a super small one for you :)
syskill: nice, 2.7MB kernels /w sound as modules
Ghworg: Neo_The_User: I appreciate the offer, but I'm now banning myself from doing that
Neo_The_User: my dad got kernels down to 600K before when he did coreboot development
galtgendo: as it seems that 2.6.32 should be released shortly, how much of git will still be needed with open driver ?
Neo_The_User: ...
adamk_: galtgendo, What I said on #ati is still the answer :-)
galtgendo: Well, AFAICT KMS version of xf86-video ati is not yet released, but
spreeuw: adamk_: which was?
galtgendo: what about things like mesa and some of xorg-server stuff ?
galtgendo: (protos and libs)
spreeuw: the guide from the topic does not describe the needed kernel options
adamk_: spreeuw, 2.6.32 should provide KMS and 3D acceleration for r6xx/r7xx. Obviously new development will continue to go into drm-next in git.
spreeuw: all it says you need for KMS is a libdrm with speial configure flags
adamk_: galtgendo, The kernel only impacts the DRM components. If you needs Mesa from git, that will continue even with 2.6.32.
spreeuw: adamk_: is it still possible to use modules? like with the old seperate drm tree
galtgendo: The question was : will I need it ?
spreeuw: that was much nicer for testers
adamk_: spreeuw, Sure.
adamk_: spreeuw, Wait, do you mean that the modules will be available in a separate tree or that the DRM can be compiled as modules?
spreeuw: why yeah seperate tree hooking into the kernel du jour
adamk_: galtgendo, And the answer is that if you had to compile non-DRM components (such as libdrm or mesa) from git, you will still have to do so.
adamk_: spreeuw, You will need to either use the DRM in the kernel or from drm-next.
spreeuw: ok, I just got unsure of things since I cant get kms to work using the guide
spreeuw: but with 32rc8, libdrm .15 (oct8), mesa git, ddx git
adamk_: If you tell us what problem you run into, we might be able to help.
spreeuw: should this combo work at all?
adamk_: Yes.
adamk_: I think, anyway. I guess libdrm might need to be from git, but I'm not 100% certain of that.
spreeuw: what are the kernel settings that are needed?
spreeuw: they are not mentioned in the guide
adamk_: Just radeon drm.
spreeuw: please use the kernel NAMES_KMS
adamk_: That's all that's necessary. You can enable KMS by default in the staging section.
spreeuw: and which are the ones it warns for Not to enable?
adamk_: Nah, I'd rather not.
spreeuw: there is mention of some conflicting modules
adamk_: Enable radeon drm, do not enable any specific framebuffer driver.
spreeuw: ok
spreeuw: the KMS helpers modules are children of drm?
soreau: lordheavy: Neo_The_User: krh said it's fixed now
adamk_: spreeuw, KMS helpers modules?
spreeuw: ok gonna give it another try then
Neo_The_User: thanks soreau :)
spreeuw: drm_kms_helper
adamk_: spreeuw, The KMS code is in the radeon DRM.
galtgendo: Is libdrm 2.4.14 enough ?
adamk_: galtgendo, If you are using Mesa and xf86-video-ati from git, no.
galtgendo: And on that note: will going KMS mean droping uvesafb ?
adamk_: galtgendo, Yes.
lordheavy: thks soreau
galtgendo: Are any libdrm/mesa releases planed after 2.6.32 release to address radeon KMS ?
Ghworg: I imagine there will be releases at some point yes
lordheavy: i've got lot of colour corruption : http://imagik.fr/view-rl/167698 (kde 4, no effects, kms, all from git)
syskill: i cannot get git xf86-video-ati to compile: radeon_dri2.c DRM_MAX_MINOR undeclared
soreau: syskill: It has just been fixed.
glisse: galtgendo: it's still a staging driver and i think there is few things that needs to change before freezing api
soreau: Update libdrm
syskill: cool, ty
galtgendo: We both know, it's not what I asked about; anyway, with mesa, does KMS means enabling gallium will be required ?
MostAwesomeDude: No.
glisse: galtgendo: no api -> no stable userspace release
MostAwesomeDude: Gallium requires KMS, not the other way around.
glisse: no freezed
galtgendo: In such case, just how stable is radeon KMS anyway, for normal work that is ?
glisse: hard to say
glisse: best is to try if it suits your need, there is still lot of things we need to polish
kdekorte_: galtgendo, for me it is pretty good
galtgendo: compared to non-KMS significantly better/worse ?
Ghworg: It's solid for me, but there is so many hardware variations it runs on it can vary a lot
kdekorte_: galtgendo, really not a lot of difference for me.. I think that 3d actually works better in KMS mode of DRI1
galtgendo: actually, the part that interests me most is DRI2
lordheavy: some corruptions here, and colours problem, but it's stable
kdekorte_: KMS gives you DRI2
galtgendo: mostly opengl/composite enhancements
markinfo: I have problems with my ATI mobility graphic Card - ATI X1800 - it should be M58. With DRI it freezes and only hard reset helps (at the end of logs is repeating- (WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! ). With DRI off it starts but the window when is moved does not redraws background - in a direction it is moved. Is unusable. I have compiled just now both driver ATI and RAdeonhd from GITs. I have tested also 2.6.30 and 2.6.31
kdekorte_: markinfo, did you follow the guide in the subject?
markinfo: kdekorte_, you mean about "firmware" ? or that http://wiki.x.org/wiki/radeonBuildHowTo ?
kdekorte_: well the build howto and the firmware are two separate things
kdekorte_: so look at the Build HowTo
markinfo: hm - firmware should be installed - dmesg: [drm] Loading R500 Microcode
soreau: markinfo: Maybe you should get help in #radeonhd. This channel is for the radeon driver
kdekorte_: your error might be related to an old libdrm
soreau: radeonhd wont work with kms
adamk_: soreau, I suggested he come in here after trying with the radeon driver and confirming it had the same issue.
soreau: adamk_: Ok
markinfo: kdekorte_, hm should i Try to install libdrm2 v2.4.15-1 instead of v2.4.14-1 ?
markinfo: from debian unstable
adamk_: markinfo, What is your goal here? Are you trying to use KMS or just get 3D acceleration working?
kdekorte_: markinfo, probably want the one from git, but if using a package you'll want 2.4.15, but mesa git proabbly won't compile with it
markinfo: I need only 2D ...at the moment is only vesa driver working - with incorrect resolution.
cxo: painful
glisse: markinfo: sadly i think you are facing gpu lockup
glisse: new ddx might improve the situation
glisse: kernel most of the time don't impact that much that kind of issue
adamk_: He's tried the latest xf86-video-ati and xf86-video-radeonhd from git.
markinfo: it has stopped to work after upgrade to xserver 7.4 (together with radeonhd driver update) a few months ago.
kdekorte_: might try just using packages from debian, kernel, libdrm2, and radeon and see how that goes first
kdekorte_: The x1800 is just an r300 level card, so it should work pretty easily
markinfo: I have even tested to install newest fedora linux - it also locks on start.
kdekorte_: The Fedora 12 live CD?
markinfo: hm - I have installed fedora on the new LV on the disk.
markinfo: 11.2 ..I think
markinfo: or 12.1
kdekorte_: markinfo, get 12, lots of things got fixed between 11 and 12 final release.. also "nomodeset" on the kernel line in grub may help
kdekorte_: there is no 12.1
markinfo: sorry - that it is: "Welcome to openSUSE 11.2 "Emerald" - Kernel \r (\l)."
markinfo: it locks also after xserver is started
kdekorte_: Try Fedora 12, I have it running on an R6xx and R5xx machine and it works well.
cbmuser: airlied: log of a typical X crashes back to gdm: http://pastebin.org/56784
markinfo: But is it not differnt if it is mobile or normal version of GPU?
kdekorte_: My r5xx is an M56 (FireGL) and it is ok
markinfo: my is "RADEONHD(0): Detected an M58 on an unidentified card"
kdekorte_: markinfo, please switch to the radeon driver
markinfo: ? I have tested radeonhd and also radeon from my debian testing distribution and also both of them from GIT.
kdekorte_: markinfo, is seems you have a mess with different components.. By trying the Fedora 12 Live CD we can start with a known state
markinfo: I can try libdrm2 from unstable. Hm - should I download Fedora live CD? Is it worth of testing?
markinfo: kdekorte_, is this one that? http://gd.tuwien.ac.at/opsys/linux/fedora/linux/releases/12/Live/x86_64/
kdekorte_: markinfo, yeah that will probably do...
kdekorte_: as long as you are on x86_64
markinfo: kdekorte_, with KDE?
kdekorte_: you can add KDE to it, but just get the basics going, there is a KDE live cd, the other is gnome
ossman: any crtc experts present?
ossman: I'm having issues with the card hanging with vblank interrupts and I need some help from someone who knows the hw
agd5f: ossman: ask away
ossman: agd5f, the basic premise is that my rv370 locks upp the entire machine hard whenever KMS is used with only S-video enabled
mokoloko: Cool with latest f12 kernel from koji all the glitches under kde are gone! GREAT! :)
ossman: agd5f, after too many hours of tracing, I narrowed it down to breaking when vblank interrupts are enabled
mokoloko: I <3 U all
ossman: the strange thing though, is that it is enabling vblank ints for the other CRTC
agd5f: ossman: yeah. probably a crtc routing accounting error in the tv-out code
ossman: agd5f, so my first question is if that is okay to do?
ossman: not really, I dug further and this seems to be explicit
ossman: the odd thing is why it only causes problems for S-video
ossman: hang on, I'll check the code and point at the problems
ossman: agd5f, have a look at radeon_crtc_dpms() in radeon_legacy_crtc.c
agd5f: why is the code trying to enable vblanks on crtc 1 when it's not used
ossman: I have no idea
ossman: hence I need someone who understands this better :)
ossman: when sending the DPMS call to turn off a CRTC, it calls drm_vblank_pre_modeset()
ossman: now looking in drm_irq.c where that is defined, it calls drm_vblank_get()
ossman: which in turns enables vblank interrupts for that crtc
ossman: IOW, doing DPMS OFF for a CRTC causes vblank interrupts to be turned ON
ossman: which makes absolutely no sense to me
agd5f: I don't think that code should be there
agd5f: drm_vblank_p*
ossman: and I'm also very curious why this isn't breaking left and right for every case where only one CRTC is used
ossman: agd5f, it's commit 7ed220d738cf16adff6bc3b31ad25b8848a2fa9c
ossman: summary is "drm/radeon/kms: Fix up vertical blank interrupt support."
ossman: seems to be the initial commit for vblank interrupts though...
MrCooper: ossman: it's needed to keep the userspace vblank counters accurate across intervals of the CRTC being disabled
agd5f: MrCooper: we don't do it for avivo chips
MrCooper: then those are probably broken in that regard
ossman: MrCooper, but if the CRTC is disabled then it's not incrementing?
MrCooper: ossman: exactly, this dance ensures that the userspace counter will compensate for that when the CRTC is enabled again
agd5f: disabling it zeros the counters
ossman: MrCooper, so really, poking the hardware is undesirable here?
agd5f: IIRC
MrCooper: of course it wouldn't be strictly necessary to actually enable the hardware vblank interrupt bit...
ossman: it seems like it's reading the vblank counter from hardware that causes the hang
ossman: perhaps the hardware doesn't support that for a CRTC that's turned off?
MrCooper: sounds like it
ossman: keeping userspace happy seems like something that should be abstracted away in the drm layer though
MrCooper: maybe the 'get counter' callback should just return 0 or something for disabled CRTCs
ossman: and not fiddle with the hardware like this
MrCooper: ossman: it is, at least to some degree
ossman: but pre/post_modeset does not seem like functions that were meant to keep the vblank counter sane
ossman: so it looks to me like an abuse of existing functions for their side effects
MrCooper: maybe they don't seem to, but they are precisely
ossman: the counter is reset on mode change?
MrCooper: yes
MrCooper: at least on some hardware
MrCooper: ossman: there's a lot of history behind this on the dri-devel mailing list and in the standalone drm repo...
ossman: should we also refuse to enable vblank interrupts?
ossman: my gut feeling is that a disabled CRTC should be left alone as much as possible
MrCooper: ossman: possibly; as it is it's really up to the driver to make the vblank callbacks behave reasonably under any circumstances
ossman: I'll try to whip up a patch
ossman: I don't suppose there are any RH guys here who can fix a new Fedora kernel build for me later? :)
MrCooper: ossman: but then you'll also need to make sure to enable the interrupts as requested by the callbacks when the CRTC gets enabled
ajax: maybe.
MrCooper: might be simpler to only deal with it in the get counter callback if that is sufficient
ossman: MrCooper, I'll start small and see what's sufficient to get rid of the hang
agd5f: ossman, MrCooper: should probably fix up the atom crtc dpms path to call drm_vblank_p* as well
MrCooper: yep
ossman: I don't have any good test cases for it, so that will have to fall on MrCooper
ossman: agd5f, I'm still waiting for interrupts on my atom hw ;)
agd5f: ossman: any day now
agd5f: we just got sign off
ossman: woo
MrCooper: I don't have any ATOM setup for testing
ossman: agd5f, what's the remaining steps then?
MrCooper: anyway off for dinner, bbl
ossman: MrCooper, do you have a test case for me though?
stikonas: so irq's will be in 2.6.33?
agd5f: ossman: just waiting for one last answer on the new ucode for the interrupt controller
ossman: ah. so the ucode is not the same as used by fglrx and the windows driver?
agd5f: ossman: same ucode, just a new one
MostAwesomeDude: Just another bundle of ucode, probably.
agd5f: different block
MostAwesomeDude: Remember, nobody's done any r600 RE with fglrx.
MrCooper: ossman: something like modeswitching or DPMS off while a 3D client with sync-to-vblank is running
MostAwesomeDude: It's entirely possible that all the goodies are in fglrx, but we haven't looked for them because we're trying this whole "talk with the vendor" approach.
agd5f: the interrupt controller has it's own ucode
ossman: MrCooper, it will break any OpenGL app with vsync, not just some corner cases?
ossman: MostAwesomeDude, agd5f, ah, I see. figured it was just one big blob
agd5f: ossman: it's actually pretty neat. It's a ring buffer of irq vectors
agd5f: similar to the CP, but in reverse
ossman: agd5f, you're going to have to elaborate on that :)
agd5f: ossman: the gpu writes irq packets toa ring buffer and the host reads them off
ossman: so instead of reading all over the place to figure out why it triggered, you get a nice ordered list of events?
agd5f: ossman: yup
ossman: that does sound neat :)
ossman: does it support multiple interrupt channels though?
agd5f: plus you can have a huge number of interrupt sources
ossman: not having to read anything at all would still be even better :)
agd5f: ossman: it supports ptr writeback to a page in system memory similar to the CP
MostAwesomeDude: Can OQs be done like this too?
agd5f: MostAwesomeDude: OQs already do
ossman: OQs?
agd5f: it's handled via a special packet 3 and writes to a GPU address
agd5f: MostAwesomeDude: code's already in mesa
MostAwesomeDude: agd5f: Ah, I must not have reached that yet.
agd5f: ossman: occulsion queries
airlied: agd5f: MSI working?
agd5f: occlusion even
MostAwesomeDude: Still trying to figure out the new packet3s.
agd5f: airlied: yup
agd5f: MostAwesomeDude: packet0's are hardly used at all anymore
ossman: ok, back to my issue for a bit. when enabling a CRTC a whole bunch of bits is set. Is is prudent to check all of them to determine if a CRTC is on, or is RADEON_CRTC2_EN sufficient?
MostAwesomeDude: Yeah, looks like packet3 is used insted.
MostAwesomeDude: *instead, even.
ossman: and where is RADEON_CRTC_EN ?
MostAwesomeDude: Not too sure I like the whole ASIC_OFFSET thing.
airlied: ossman: just the _EN bit
ossman: can't you enable CRTC2 without CRTC1 already being on?
agd5f: ossman: yes. crtcs are independant
ossman: but the code only fiddles with CRTC2_EN, not CRTC_EN
ossman: hang on...
ossman: there's just a lack of symmetry in the code between the two CRTCs
ossman: reads again
ossman: ok, never mind that question :)
agd5f: ossman: crtc2 is nicely consolidated into CRTC2_GEN_CNTL. crtc1 is spread across CRTC_EXT_CNTL and CRTC_GEN_CNTL
agd5f: due to pre crtc2 hw
spreeuw: why would my kms mesa insist on using software rasterizer
ossman: yeah, I noticed. I was looking at the mask bits generated earlier and it lacked a CRTC_EN
olaf: hello , last xf86-video-ati do not build today because "‘DRM_MAX_MINOR’ undeclared" ? or it's me ?
ossman: I will feel very sorry for you guys the day someone adds a third CRTC. :)
spreeuw: http://pastie.org/713283 heres my xorg.log
agd5f: ossman: evergreen hw supports 6 crtcs
ossman: there's a lot of code along the lines if (crtc_id) do_something; else /* assume CRTC2 */
spreeuw: it does initialize r600 for AIGLX
spreeuw: why not for openarena
agd5f: olaf: update your libdrm
agd5f: spreeuw: LIBGL_DEBUG=verbose glxgears and see what the problem is
ossman: agd5f, was evergreen r800, or is it the next gen?
agd5f: ossman: yeah
ossman: that wasn't really a yes or no question :)
agd5f: hd5xxx
spreeuw: LIBGL_DEBUG=verbose glxgears
spreeuw: libGL: OpenDriver: trying /usr/local/lib/dri/swrast_dri.so
agd5f: ossman: evergreen is r8xx
ossman: ok
ossman: any work started on that yet?
spreeuw: hey I just spotted it
spreeuw: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed (libdri too old)
spreeuw: pfff
spreeuw: wonder why I missed it before
evil_core: spreeuw: paste previous lines
agd5f: ossman: I started working on modesetting. code's all written, still has issues with digital outputs though
evil_core: spreeuw:it can be too new also ;)
spreeuw: evil_core: there were no previous lines
olaf: agd5f, thanks but , do not solve the pb.... will try again
spreeuw: I'm using libdrm libdrm .15 with kms flags
evil_core: look into/var/log/xorg.$DISPLAY.log
ossman: agd5f, new 3d engine again, or will you be able to reuse much of the r600/r700 work?
spreeuw: with kernel 32 rc8
evil_core: spreeuw: disable kms, and reboot
evil_core: buyt disable before reboot
evil_core: for me DRI works only w/o KMS
spreeuw: disable how?
evil_core: on R500
evil_core: /etc/modprobe.d/modprobe.confi.e.
evil_core: modinfo radoen
agd5f: ossman: should be able to reuse a fair amount
agd5f: olaf: looks like the fix isn't pushed yet
spreeuw: I had normal acceleration working just fine
ossman: agd5f, good. you guys could use some time to catch up :)
evil_core: options radeon modeset=0
spreeuw: I was trying to get KMS going
spreeuw: and dri2
evil_core: spreeuw: yeah I know, dri works, but not in MEsa
evil_core: had equal problem, installing 2.6.32 and disabling kms helped
ossman: agd5f, not that you haven't been putting in a tremendous effort so far :)
agd5f: does anyone know how create a fw file using ihex?
ossman: aren't there tools in the kernel tree?
agd5f: ossman: are there?
airlied: agd5f: objcopy I think
ossman: well the installed files are binaries, not ihex
airlied: the binutils one
syskill: what am i doing wrong? still getting DRM_MAX_MINOR undeclared. i'm using gentoo's layman overlay (maybe that's the problem?), but i would think that the git command would grab the latest sources anyways
agd5f: syskill: libdrm breakage
syskill: yeah, recompiled libdrm 4 times already, and cleared everything and re-git'd
evil_core: for DRI2 Gallium is needed?
agd5f: evil_core: no
airlied: though not sure what the corret incantation is
syskill: EGIT_REPO_URI="git://anongit.freedesktop.org/git/mesa/drm" <-- that wrong then, looks correct to me?
airlied: ah objcopy -I binary -O ihex
airlied: then remove ctrl-ms from the output
agd5f: syskill: it's broken in git
airlied: now you just need to make sure the binary input is correct
agd5f: at the moment
syskill: oh, so don't git libdrm then
syskill: sorry, thought libdrm, mesa, xf86-video-ati all needed to be from git
agd5f: syskill: they do. but krh's last change broke it, and it hasn't been fixed yet
syskill: ah, guess i was too slow to download then ;-)
evil_core: is there any video decoding acceleration in free drivers?
gimzo: evil_core: I don't think so
gimzo: but somebody is / was working on something
agd5f: syskill: fixed now
spreeuw: is xorg server 1.7.1 supported?
agd5f: spreeuw: yes
markinfo: kdekorte_, unbelievable - Fedora live CD runs perfect - even external DVI Output on my laptop works - with external LCD panel there s possible to define dual View. And even Suspend to RAM work - it awakes - ...It has never worked before.
spreeuw: why does it complain about a too old libdri then?
spreeuw: its part of my 1.7.1 server
spreeuw: maybe I disabled kms or so
agd5f: spreeuw: something built wrong on your end
spreeuw: I like it how the new xserver no longer requires a mesa dir
ossman: agd5f, removing the vblank counter read isn't sufficient unfortunately :/
agd5f: ossman: it's probably due to enabling vblank interrupts on a non-active crtc
ossman: yeah, I'm disabling that next
ossman: but it is opening up a can of worms when it comes to how upper layers deal with a failure
agd5f: ossman: upper layers shouldn't be interrested in a disabled crtc
ossman: one problem case is this:
ossman: 1. something turns of a CRTC. This attempts to enable vblank ints
ossman: 2. while the CRTC is disabled, some app gets interested in vblank
ossman: 3. the CRTC is reenabled. but the reference count for vblank ints never drops to zero, so a new attempt to enable vblank ints is never made
ossman: so just returning failure when the CRTC is disabled can result in problems
agd5f: the logic in 1. seems wrong
nille02: hello everonye can someone say me how to set an display as primary?
ossman: agd5f, well, that's how the current code is and it seems to require quite a bit of work to get out of that mess
nille02: he want currently use DVI-1 everytime as primary desktop and not DVI-0
ossman: agd5f, I'll have a look and see if I can fix up something better
soreau: nille02: switch the monitor cables :)
kdekorte_: markinfo, glad it works for you. Also that tells me that either the debian software is old or is in a weird state
soreau: votes for old
soreau: maybe even both
nille02: soreau i know this maybe work but i think its not the best solution ^^
ossman: agd5f, hmm.. the problem really remains even if you remove the vblank fiddling in step 1 and 3
soreau: nille02: Yea, Im mostly joking
ossman: agd5f, an application that starts waiting for vblank on a disabled CRTC will run into problems
nille02: currently im trying in the xorg Option "Primary" but its not working
markinfo: kdekorte_, I heard it works because Fedora use KMS.
agd5f: nille02: your desktop enviroment has to support the primary option
ossman: agd5f, how about this, we return success to upper layers, but refuse to actually set the interrupt bits?
ossman: then we can just update the interrupt bits when the CRTC is turned back on
ossman: and the state of vblank ints should sort itself out
agd5f: ossman: sounds good. should double check with MrCooper or krh. I try and avoid the drm vbl stuff :)
ossman: tss. vbl is a most crucial feature :)
adamk_: rnoland, FYI, OA is not panic'ing, but it's showing the same errors in dmesg. I'm updating -CURRENT and the DDX now to see if it makes a difference.
nille02: agd5f im using gnome but i cant find any option. but if im set DVI-0 manual as primary it work
airlied: ossman: find something that doesn't crap out your hw then discuss it ;-)
agd5f: nille02: you can add it to your xorg.conf
ossman: airlied, I'm hoping to reduce the number of trial and error iterations :)
rnoland: adamk: hrm....
nille02: i know but i dont know the config name :( i have Tryed Option "Primary" but its not working
rnoland: adamk: are you amd64?
ossman: does the aptly named r100_irq_set() cover all generations?
airlied: ossman: yes
airlied: ossman: r5xx might have another
airlied: since its vl is different
airlied: vbl
agd5f: airlied: kms dp: http://www.botchco.com/alex/xorg/dp/
agd5f: suffers from the same issue as the ddx. if link traing succeeds, the display is blank...
airlied: agd5f: ouch
agd5f: airlied: also, I think we need may need an atom mutex
airlied: I'll merge them into that branch and we can debug in drm-next
airlied: agd5f: yes probably
Zajec: airlied: are you aware of some patches that didn't go into any tree yet?
airlied: hopefully we can avoid atom for irq contexts
airlied: from even
Zajec: airlied: like ring info debugfs fix, typo fixes for PM and memory set
airlied: Zajec: the first two yes
Zajec: ok :) just wanted ask if you didn't miss them
Zajec: it's fine then
Zajec: third one is: "[PATCH] fix typo in define: engine -> memory"
Zajec: 4.11.2009
Zajec: 0001-drm-radeon-kms-fix-typo-in-define-engine-memory.patch
kdekorte_: markinfo, yes KMS can really help with suspend and resume.
ezzieyguywuf: what are the dependencies of ati 6.12.4? I keep getting some very weird compile errors: http://linuxfromscratch.pastebin.com/m6b7a37a1
ezzieyguywuf: the wiki suggests using a package manager, but my linux system does not use one
agd5f: ezzieyguywuf: you need libdrm
ezzieyguywuf: agd5f: whereis libdrm shows libdrm: /usr/lib/libdrm.la /usr/lib/libdrm.so
ezzieyguywuf: am I missing one? or is it expecting it somewhere else?
agd5f: ezzieyguywuf: you need the devel headers
agd5f: ezzieyguywuf: check your configure output and see why the dri is getting disabled
ezzieyguywuf: ok h/o
rnoland: will OA try to used compressed textures if it is available?
sylware: hi, where is the up to date ATOM bios and/or the up to date code repo for the ATOM bios?
sylware: (err.... forgot first "ATOM bios documentation"
ezzieyguywuf: agd5f: hm, it says it couldn't find /usr/include/xorg/dr{.h,struct.h}. Also missing sarea.h. Lemme go see if I haven't put them in a non-standard loc
gimzo: gallium works for me, and the framerate is interesting: http://global.phoronix-test-suite.com/?k=profile&u=gimzo-4501-11637-20703
ezzieyguywuf: agd5f: is dri part of mesalib?
soreau: gimzo: Are the textures messed up for you?
gimzo: nope
gimzo: looks identical to me
soreau: gimzo: With gallium, I mean..
gimzo: It looks identical between gallium and non-gallium run
sylware: Shall I use ATOM bios parser in DDX or the one in the kernel for up to date code?
gimzo: soreau: I didn't watch with a loupe but I can't tell a difference
soreau: hmm
soreau: gimzo: Using st x driver?
gimzo: x driver is git a few days old, everything else is from today
gimzo: *everything else being mesa
airlied: agd5f: btw where are you seeing atom reenter?
airlied: sylware: depends on what you want to do with it
gimzo: soreau: I'll take another look, in case there is subtle corruption
airlied: sylware: the atombios.h which contains struct defs is pretty much the same
airlied: the atom interpreter is where the big differences aer
agd5f: airlied: the fb-base stuff
agd5f: during connector detect
agd5f: for aux ch
agd5f: airlied: if I have dvi and dp connected: http://pastebin.ca/1685977
gimzo: soreau: I just tried UrT, and textures look ok, it just froze, but only the game (I could vt-switch and kill it)
airlied: agd5f: is that not just atom re-entering itself? + some bad backtrace
agd5f: airlied: I haven't really delved into it too far yet. just guessing
airlied: atom tables call atom_execute_table
airlied: though I've seen get_src_int fails before in some logs on bugs
soreau: gimzo: Reason I ask is because last time I tried OA with r300g, it just gave black screen on my rv350 iirc
soreau: gimzo: Right now I'm trying to get input to work running it 'normally' :P
soreau: gimzo: Are you just setting LIBGL_DRIVERS_DIR or how are you starting it with gallium?
gimzo: soreau: LIBGL_DRIVERS_DIR is set for the system, like the wiki says
gimzo: soreau: I'm just running padman, and it seems slower than classic mesa, but textures look normal
soreau: gimzo: The wiki? :o
soreau: gimzo: Can you link me to wherever it says that please?
sylware: airlied: then I shall use the atom bios interpreter from the DRM driver. is it your git repo which has the most up to date code for the interpreter?
soreau: gimzo: I found with OA, if I click as soon as I start it, input is disabled. If I let the splash screen complete, it works
sylware: (airfor instance does it include all the latest table defs for eye infinity programming?)
mokoloko: Anyone playing quakelive here? I was just wondering how to join to game because I cant see any menu? Otherwise it looks great :)
soreau: gimzo: Because I am only setting LIBGL_DRIVERS_DIR on a per app basis and for things like OA, it just does black screen then gray screen for the menu
gimzo: soreau: it says in wiki (topic): "and to /etc/environment you need to add new environment variable that tells libgl where to look for dri drivers (example r300_dri.so)"
Ronis_BR: glisse: have you discovered which suspend system fedora use?
Ronis_BR: uses*
soreau: gimzo: Ah ok, I thought there was some special gallium wiki page I did not know about
soreau: I wonder if this will make a difference..
gimzo: soreau: only difference from the wiki I did is mesa configure and renaming the lib
airlied: sylware: eyeinfinity isn't anything in ato
airlied: sylware: as I said the parser and that tables are separate
ossman: agd5f, airlied, odd. CRTC2 is enabled
airlied: sylware: we have no evergreen support yet
ossman: yet reading the vblank counter hangs
soreau: cp radeon_dri.so r300_dri.so, right?
ezzieyguywuf: yea, ati keeps looking for /usr/include/xorg/dri.h and /usr/include/xorg/dristruct.h . I don't have these headers (I think they're headers?). I have installed libdrm and do have a /usr/lib/drm dir with all sorts of goodies in there, but obviously I am missing something. someone mentioned the libdrm dev headers, but where do I get those from?
ossman: and I have no idea what BIOS has set up CRTC2 to drive
gimzo: soreau: yes
soreau: gimzo: hmm
soreau: gimzo: What does 'glxinfo|grep nGL' report as gl string?
agd5f: ossman: maybe tv
ossman: agd5f, there are not routing restrictions for encoders?
ossman: no
agd5f: ossman: nope
ossman: so it is possible BIOS started with CRTC1 off and CRTC2 connected to S-vidoe?
agd5f: ossman: yes
ossman: and the driver is now trying to swap that
gimzo: soreau: vendor string: X.Org R300 Project renderer: Gallium 0.3 on RV515 version: 2.1 Mesa 7.8-devel shading language: 1:20
ossman: but when we enable CRTC 1, what happens to CRTC 2
ossman: ?
ossman: will it be left without an encoder? or do we have two CRTCs feeding the same encoder?
sylware: airlied: ok then, where is the up to date code for the parser and then where are the latest defs for the tables? For evergreen support, what do we miss?
soreau: gimzo: Well I set the path in /etc/environment but it didn't work apparently because glxinfo show classic mesa gl string
agd5f: ossman: should probably be disabled. I thought there was a drm helper the turned off unused crtcs/outputs
gimzo: soreau: at one time it didn't work for me so I added it in bashrc
agd5f: ossman: routing is one or the other
soreau: gimzo: Cool, thanks
agd5f: so you can't have two crtcs driving the same output
ossman: agd5f, I did some debug output and the code doesn't disable CRTC 2 until the very end
ossman: it does say "[drm] crtc 0 is connected to a TV" though
ossman: is that information about the state before the driver starts fiddling?
agd5f: no
agd5f: that's what the driver did
ossman: k
agd5f: we don't currently pay attention to what the bios did
ossman: so the question still remains why things are hanging
ossman: and how to avoid it
ossman: what is RADEON_CRTC2_DISP_REQ_EN_B ?
agd5f: ossman: disabled crtc memory access
agd5f: *s
gimzo: soreau: looks like I started celebrating too early.... black screen in warsow
ossman: so you can keep the CRTC running without it touching memory?
agd5f: yeah.
soreau: gimzo: Only game I can get working with setting the env var on a per app basis is neverball and compiz but both have texture issues
ossman: agd5f, is it inverted though? i.e. it needs to be set for things to work?
gimzo: soreau: I'll take a look
ossman: I dumped the GEN_CNTL reg, and only the _EN bit is set
soreau: gimzo: Of course it may be working on r5xx better than r3xx
DanaG: http://www.phoronix.com/scan.php?page=news_item&px=NzcyNw
DanaG: Oooooooooooh.
gimzo: soreau: but I can say that openarena and world of padman work (at least demos work, haven't tried actually playing), UrT locks up at one point and warsow gives black screen
agd5f: ossman: setting RADEON_CRTC_DISP_REQ_EN_B disables memory access
ossman: ok
ossman: so having just _EN set is the normal state of things
ossman: agd5f, any possibility of having the hw guys look at what can cause a read of the vblank counter to hang?
agd5f: yeah
DanaG: so, is that powersavings a branch in git? and how much power can I expect to save?
agd5f: I can try, but not likely to have much luck as the pre-avivo hw is pretty old
ossman: I feared as much
soreau: gimzo: Seems I can't get it working globally with my standalone X session though I'd like to think it wouldn't make a difference (as opposed to trying on a per-app basis)
ossman: agd5f, do you have any more ideas what could me messing things up?
Ronis_BR: DanaG: it will be amayzing! My laptop stays just 1h on on linux and almos 1:40 on windows :(
ossman: agd5f, any other enable bits?
agd5f: ossman: should probably turn off unused crtcs and vbls for unused crtcs
gimzo: soreau: have you tried adding export line in ~/.bashrc ?
ossman: I think it's trying to do the former
DanaG: Just today, I randomly had fglrx not offer powerplay, for some reason. 38 watts, versus 22 or so with powerplay.
ossman: agd5f, the problem is that it hangs before it touches the CRTC enable bits
Zajec: DanaG: wait for 33-rc1
Zajec: DanaG: there I hope most will hit it
ossman: agd5f, so something is amiss with that CRTC. the question is how to detect it
Zajec: DanaG: for now just manual patch applying
DanaG: https://wiki.ubuntu.com/specs/KernelLucidKernelDecision
Zajec: DanaG: will have time to work on in this weekend
DanaG: ah, will it be a config option to enable?
Ronis_BR: to be at the bleeding edge of radeon development which branch I needed? drm-next or drm-radeon-testion
Ronis_BR: drm-radeon-testing*
DanaG: I'm pondering the future: will I need my own kernel, or will the ubuntu mainline packages work?
agd5f: ossman: may want to turn off all crtcs at load time
Zajec: DanaG: first yet until we make sure it's safe
Zajec: DanaG: i mean it doesn't lock up machines or crash
soreau: gimzo: Yes, nothing works. I suspect my standalone X session doesn't use these settings somehow
Zajec: DanaG: don't mean burning your hw of course :)
DanaG: hmm, I wonder if you could merge it in as an off-by-default module parameter.
Zajec: DanaG: well, KMS in .32 will be usable but not really feature exciting
DanaG: Probably would make the code messier, though.
ossman: agd5f, seems like a bit of a workaround rather than a fix. what if this state can be achieved via certain settings from the driver?
Zajec: DanaG: i want this to be off by default for .33, so I Ubuntu guys decide to backport some radeon patches, it should hit 10.04
Zajec: DanaG: in Phoronix article you have link to dri-devel archive
Zajec: DanaG: i wrote you have to load radeon with dynclks=1 for now
gimzo: soreau: I just tried on my R400, and I get openarena intro animation ok, and instead of menu I get "open arena" logo at the top in wrong colours, and everything else black
gimzo: but on R500 it works
soreau: gimzo: Ok.
soreau: gimzo: Well no wonder
soreau: I just remember I was testing something for MAD yesterday and switched to classic mesa branch to patch
gimzo: soreau: I just noticed that on R400 gallium (with broken picture) has much less input lag than classic mesa
gimzo: in openarena
soreau: gimzo: Do you happen to know if it's any different if you do not set it globally?
soreau: I would think it should be the same
gimzo: soreau: on the laptop (R500) I have archlinux and gallium is currently set globally, on my desktop (R400) I have today's git classic mesa set globally and gallium set locally to try OP
gimzo: I don't think screen breakage has anything to do with this :)
soreau: yea me neither
ossman: agd5f, it seems CRTC2 refuses to disable
ossman: clearing _EN doesn't seem to stick
ossman: ever heard of that?
agd5f: ossman: weird.
ossman: I need to go to bed now, but if you have someone you can poke and see if they know more then I'd appreciate it
agd5f: maybe it won't disable if there is an active encoder on it
agd5f: ossman: It may not get disabled until the next vblank
airlied: sylware: drivers/gpu/drm/radeon/atom*.[ch] is mostly is, no idea what we are missing for evergreen until AMD review and publish it
agd5f: either that, or you need a delay for it to go through the rbbm fifo
ossman: agd5f, I don't have any timing on my dmesg output unfortunately, but there are quite a few lines between when it is supposed to be disabled and when I see that _EN is still set
agd5f: sylware: there aren't any parser changes for evergreen, just new/changed tables
sylware: airlied: from your drm-next branch?
ossman: agd5f, reads are done directly but writes are through the fifo?
airlied: sylware: yes, atom parser hasn't changed in a long while though
Ronis_BR: should I built mesa with gallium support?
airlied: sylware: have you a goal for it? since I suspect you might be trying to do something atom has nothing to do with ;-)
airlied: since you mention eyefinity by name
gimzo: Ronis_BR: AFAIK It doesn't matter, it only matters what you use
agd5f: ossman: different queues IIRC
gimzo: Ronis_BR: you can compile gallium and classic mesa, and have different apps use different driver
ossman: agd5f, so every read would need a fifo flush or it's just another race condition waiting to happen? :/
sylware: airlied: may try to code a new atom parser and interpreter for linux
Ronis_BR: ok
sylware: agd5f: what's waiting AMD to release the evergreen ATOM table new defs?
airlied: sylware: why bother?
airlied: we have two already
airlied: we also have a port of the kernel one to userspace in glisse's atomtools
sylware: (airlied:license issue)
airlied: sylware: its under MIT
soreau: gimzo: It seems at first test run that specifying gallium globally makes a significant difference
sylware: (airlied:yes that the pb)
gimzo: soreau: what happens? I'll try it
airlied: sylware: what the problem? MIT is compat with GPL
agd5f: ossman: just guessing, not sure to what extent the display stuff is fifoed
sylware: (airlied:it's not GPL)
mjg59: sylware: You know that MIT code is compatible with basically every other license?
airlied: sylware: fork it, call it GPL
mjg59: Including closed ones
sylware: airlied: ok
airlied: sylware: but don't send any patches near me
ossman: agd5f, I'll have to play more with it another day. but if you can find anything that avoids too much guessing in the dark then please share :)
agd5f: sylware: it's waiting for me to send it off for review
airlied: sylware: or upstream
airlied: though that atom parser is pretty complete
mjg59: You don't even need to do that - you can keep MIT code in a GPL project
airlied: so I'm not sure what could be gained by a GPL only patch to it
sylware: airlied: don't worry... I know your cannot add GPL code if you want to run in bsd kernels
soreau: gimzo: compiz does this dark blue screen thing where you can see silhouettes of windows but cube works except skydome image is white where as OA the startup splash screen does not display but the game works after that
airlied: sylware: no I don't care as much for BSD as the fact that we got the code under an MIT license from AMD and I'd like to maintain that
airlied: sylware: I've no idea why anyone would do anything different
soreau: gimzo: OTOH, when setting the path while classic is global, compiz works at a glance but things like cube and expo demonstrate texture problems and OA does not work at all (black or dark screen)
gimzo: soreau: I'll take a look, the wiki says that compiz doesn't look at LIBGL_DRIVERS_PATH, but I haven't thought about OA.. I'll take a look
airlied: its not like any contribution you make to the parse is going to be useful
soreau: gimzo: Oh yes, compiz definitely use opengl and the dri driver
airlied: or even large enough to warrant copyright since the parser is technically complete
sylware: airlied: I'll use that bsd code as documentation.
gimzo: soreau: so to make it global you need to install in /usr ?
airlied: sylware: for what though?
airlied: why do you think a GPL atom parser that isn't the current code is useful?
sylware: airlied: for the one I may wrote
sylware: airlied: I may fork and start from here.
airlied: sylware: like I really don't care if you are stupid enough to waste time sucking off RMS, but please don't go asking any questions in here about it
soreau: gimzo: No, I just exported it before the X startup line in my X standalone script
airlied: I don't want you wasting other ppls time
gimzo: soreau: ok, I'll try that
soreau: gimzo: I have not tried with installing it to /usr, but I assume this would have the same effect
airlied: its not like anything you produce will be used by anyone else at all
gimzo: it has to do something with ld I guess ?
airlied: considering the whole radeon kernel driver is under MIT
airlied: not just the atom parser
airlied: and all the KMS code
soreau: dunno
sylware: airlied: I know
airlied: sylware: so if you want to waste your time, consider doing it not in this channel
airlied: why don't you rewrite ZFS under GPL
sylware: agd5f: when do you plon to release the evergreen ATOM table defs?
agd5f: sylware: as soon as I have approval
sylware: airlied: just need to share programminf infos, code won't be shared because of theh license. Anyway I will probably never end with something working, so you don't need to worry.
airlied: sylware: so why bother, atom parsers are not exactly the core of modern tech
flyback: disables /amsg and leaves /ame only for away messages
airlied: like even HURD would have a hard time using it
mjg59: sylware: Why would you *want* a GPLed ATOM interpreter?
ajax: mjg59: ice cream, mandrake. children's ice cream!
tsamolotoff: It's me again, a developer-bothering nothing :)
tsamolotoff: radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy->is_pending <= bo->cref' failed. Happens when I run Doom 3 for some time...
sylware: agd5f: I code GPL
agd5f: sylware: MIT
airlied: sylware: that doesn't say why you want an atom parser though
airlied: actually why do you want an atom parser?
sylware: airlied: I want to try to code a AMD GPU driver, since AMD si not evil like "the other". I don't know if one day I will get something working
mjg59: sylware: Forking people's code under incompatible licenses is generally regarded as evil
airlied: sylware: we have an AMD gpu driver
airlied: like I'm sure a GPL wheel would be useful, but we already have a generic wheel
airlied: but the thing is you can import the whole of our AMD gpu driver
airlied: and call it GPL and work on it yourself
airlied: and then why have it GPL
airlied: since you won't distribute it
soreau: gimzo: I am very surprised setting it globally made the difference. Thanks for helping me to see this :D
airlied: the license is pretty meaningless until you actually distribute the code
gimzo: soreau: I so far don't see the difference, will try after restarting
soreau: gimzo: You mean globally+r4xx?
airlied: but mjg59 is right forking code into an incompatible license if pretty evil
gimzo: soreau: yes, I'm just unwilling to restart my main machine :)
sylware: airlied: closing open source code is even more
soreau: gimzo: I did not restart the machine, only X
airlied: sylware: the atom parser is closed code that got made open
sylware: airlied: but ok I'll write my own from stratch
soreau: gimzo: As long as glxinfo is reporting gallium without manually setting the path, it should be set globally
airlied: the thing is if you made a useful large contribution to the parser under GPL then you could worry about it
gimzo: soreau: well, same thing for me, I have 5 apps running I don't want to close right now, So I'll probably just shut down and go to sleep, and check stuff in the morning
airlied: but really I can't see where you can make any useful contribution that anyone could make into closed source
soreau: gimzo: No doubt. Have a good night :)
gimzo: soreau: thanks, you too
sylware: airlied:I just need doc to write one. AFAIK, the doc is that MIT licenced code.
airlied: sylware: okay do you mind doing it somewhere else then?
tsamolotoff: Anyone to help me?
airlied: I really don't want to forget in the future that you are pointlessly wasting time
sylware: airlied: Just need doc
sylware: and it's here
airlied: sylware: okay really if you enjoy wasting your time
airlied: but not in here
airlied: set up your own channel #ati-gpl-4eva or something
sylware: airlied: what is teh proper channels for specs/programming infos?
airlied: sylware: you can email AMD directly I assume, but this channel isn't it
Ronis_BR: airlied: radeon driver isn't gpl?
bjaglin: hi, i have been trying for a while and reading here if i would find any info, but without any success so here is my problem: I am trying to get KMS using xorg-edgers packages on ubuntu, on a 2.6.32 kernel from the the kernel ppa, and i always get software rasterizer because of http://wiki.x.org/wiki/radeonBuildHowTo#head-6c8a52410a5bf5f5de31505920156363a0d543bc
sylware: Ronis_BR: if you run it with Linux, yes. If you run it with bsd (MacOS etc...) nope
airlied: Ronis_BR: no MIT
airlied: I don't think anyone would use our driver on MacOSX
airlied: or any closed source platform
Ronis_BR: airlied: MIT?
Ronis_BR: what is the difference?
Ronis_BR: why don't make it GPL that is more common? :)
bjaglin: i haven't tried to build xf86-video-ati myself though, because it does work on a 2.6.31 stock kernel, and i want to deploy it on several computers with the same hardware... i have a RV250. Any idea?
airlied: Ronis_BR: because x.org
airlied: is all MIT license
airlied: which is like BSD license
airlied: and most of the code comes from X.org
tsamolotoff: http://bugs.freedesktop.org/show_bug.cgi?id=24131 - According to this, my problem is solved... It seems that today's mesa doesn't think so
airlied: and we'd like BSD OSes to be able to use it they wanted.
airlied: also the original radeon drm drivers were under BSD license because they were written for FreeBSD
agd5f: bjaglin: 3d is hadled by mesa, not xf86-video-ati
Ronis_BR: airlied: but when a source code is licensed by GPL, it can be used anyway you want right?
airlied: or at least it was FreeBSD that TG were paid by the Weather channel to produce a driver for
airlied: Ronis_BR: no you can't close it
Ronis_BR: airlied: ahhhh
airlied: but relicenseing all our MIT code under GPL at this point would be considered quite rude
Ronis_BR: airlied: so you want to let radeon to be closed right
airlied: Ronis_BR: no I just don't want other BSD Oses not to be able to use it, and also to respect the original authors license
airlied: really if someone could fine a closed use for radeon I'd be impressed
Ronis_BR: airlied: ok, good point :)
airlied: considering the really hard bits are in the Mesa driver
airlied: and that can't be GPL
Ronis_BR: airlied: radeon is becoming better than fglrx ;)
Ronis_BR: airlied: Mesa is MIT?
MostAwesomeDude: I'd be *really* impressed if somebody could successfully use this stuff without our help. :3
airlied: Ronis_BR: yes so it can be linked to by closed apps to do OpenGL
Ronis_BR: airlied: now I got the point
MostAwesomeDude: IMO the humonguous success of Xorg over other stacks has been the commitment of the people that actually understand the code to keeping it open.
Ronis_BR: airlied: yes, it makes sense ;)
soreau: MostAwesomeDude: unpossible :)
tsamolotoff: Huh, no one seems to respond... How considerate
airlied: MostAwesomeDude: yeah all the closed forks died badly
Ronis_BR: MostAwesomeDude: heuaheuaheuaheuha :D
Ronis_BR: I'd be *really* impressed if somebody could successfully use this stuff without our help. :3
airlied: well the non-windows ones at least
Ronis_BR: eauehauehauheuaheuaheuaheuahe :D
Ronis_BR: LOL!
agd5f: I don't see a closed source driver based on the open source code really being viable. we already make a closed source driver
soreau: MostAwesomeDude: So I set gallium to be global and now things are working (games.) So what about st X driver? Can this help anything?
soreau: MostAwesomeDude: Actually, how do I use the st X driver?
chithead: you specify it in xorg.conf
MostAwesomeDude: soreau: Build it (the name is "xorg") and then copy it to a place where X can find it and set xorg.conf to "modesetting".
soreau: chithead: I know that much
MostAwesomeDude: soreau: Also I have zero idea if xorg st is usable; I haven't tested it.
bjaglin: agd5f: ok, but i am not sure i understand the error "[dri] radeon kernel module version is 2.0.0 but version 1.8.0 or newer is needed."; the kernel has 2.0.0 and mesa requires 1.17.0? I read somewhere that the orders stuff was compiled mattered, but since i am trying to use ppa only, i am not sure what to do. Are you suggesting to build mesa myself?
MostAwesomeDude: Well, recent tests, anyway. I tested it back when it didn't do acceleration.
chithead: if you use gentoo, you will get it readily installed by building mesa with USE="gallium"
Ronis_BR: chithead: have you installed gallium?
soreau: MostAwesomeDude: So build mesa with --with-dri-drivers="xorg" and it will be installed as what, where? :)
Ronis_BR: chithead: what does it change?
chithead: Ronis_BR: I don't use gallium, there is presently no advantage in using it
agd5f: bjaglin: your kernel is using kms, but your ddx is not kms aware
Ronis_BR: ok
agd5f: bjaglin: turn off kms or build the ddx with kms support
chithead: soreau: modesetting.so in the drivers directory
MostAwesomeDude: soreau: You'll find modesetting_drv.so in lib/gallium. Take that and put it next to radeon_drv.so in your system.
MostAwesomeDude: /usr/lib/xorg/modules/drivers or whatnot.
soreau: MostAwesomeDude: Ok. but --with-dri-drivers="xorg" is correct?
MostAwesomeDude: soreau: --with-state-trackers=xorg
soreau: ah ok
agd5f: bjaglin: ddx = xf86-video-ati
bjaglin: agd5f: thanks, i am going try
gimzo: what does xorg state tracker do ?
chithead: gimzo: http://www.x.org/wiki/GalliumStatus
chithead: at the bottom it is explained
gimzo: thanks
soreau: gimzo: I'm about to find out ;)
gimzo: soreau: good luck :)
factor: do any of the radeon card for AGP have strems?
factor: streams
galtgendo: so, to clear some of my confusion, what, besides git radeon driver, recent libdrm with kms enabled and KMS kernel drivers, would I need to test DRI2 on radeon 9600 ?
chithead: galtgendo: if you want 3d too, you need mesa from git
galtgendo: I'm trying to get away with as less git as possible
soreau: MostAwesomeDude: X just segfaults at runtime using modesetting
soreau: At least I can see gallium in action :)
agd5f: galtgendo: see the topic
galtgendo: which branch (as there are many) ?
MostAwesomeDude: soreau: Hm.
lordheavy: yes ! i can see gallium in action with ..... glxinfo :-p nice !
galtgendo: (topic goes nearly 100% git)
MostAwesomeDude: Man, lots of people trying out Gallium.
MostAwesomeDude: factor: Most of them, no. There's a couple of them with PCIe-to-AGP bridges inside, but really, don't buy AGP cards.
lordheavy: always nice to try even if it doesn't work, the pleasure of testing
galtgendo: would mesa 7.6 be enough ? would it need any special configure settings ? would gallium be required ?
stikonas: mesa 7.6 is enough
stikonas: the only git version that is necessary is radeon
chithead: mesa does not compile with latest xextproto though
chithead: mesa 7.6 i mean
factor: well all I have in my intel is an agp slot
factor: I have a cuda card in my amd with a pcie
factor: but was wanting to see if ati had a stream processor for agp , will be getting a agp card for it before I cant find news one for it
factor: new^
factor: Do the ATI HD series agp work with linux?
galtgendo: and what about libdrm ? on one hand, it seems 2.4.15 has the required bit, on the other there's been some of later activity in the git ?
chithead: libdrm 2.4.15 is ok for mesa 7.6 (needs to be built with --enable-radeon-experimental-api)
Neo_The_User: does anybody know the PCI IDs for the 5770?
agd5f: factor: yes, with the caveat that agp is askign for pain, regardless of the chip
Neo_The_User: im getting a 5770 soon so I was wondering if the DDX has support for it yet. :) I remember asking before and it was, "no."
lordheavy: http://pci-ids.ucw.cz/read/PC/1002/68b8
sylware: Neo_The_User: AMD has not released ATOM tables defs yet for evergreen GPUs.
factor: agd5f:what do you mean it does not work under linnux
agd5f: factor: yes, they are supported, but agp is always problematic
factor: well that is my only option on my intel board
MostAwesomeDude: Whenever you buy an AGP card, somebody gives nVidia a kitten.
factor: that is good to know, just want both of my old systems up to par.
factor: actualy have a third system with a pcie port but is buggy,
factor: ok afk
Neo_The_User: MostAwesomeDude: doesn't that saying come from... something similar?
adamk_: rnoland, Heh... I tried to update xf86-video-ati and it won't configure saying that configure was built with too old of a version of xorg-macros.m4, and that version 1.2.0 or newer is required :-)
cxo: adamk, autoreconf -i -v
flyback: http://download.softphase.org/sfp08/mosaik-01-leandi.mp3 <-- awesome new song from one of my favorite scenemusic artists
airlied: anyone with r600 in non-kms or kms like to tryout http://cgit.freedesktop.org/~airlied/xf86-video-ati/log/?h=r6xx-kms-multi-op
airlied: under kms it should speed up 2D a bit, but want to make sure it doesn't regress on non-kms or cause any unusual failures under kms
DanaG: hmm,
DanaG: Nifty muzak.
cxo: which branch is that?
biotube: 6xx-kms-multi-op
biotube: kwin's split desktop doesn't seem any faster
biotube: but scrolling definitely seems snappier
biotube: I do see some minor irregular text corruption, but that mostly goes away after I finish scrolling
agd5f: I wonder if it would help performance to force pixmaps in gart for exa and Xv
agd5f: since they tend to be short lived anyway
agd5f: and they tend to be read back alot
flyback: http://www.mosaik.se/leandi/ <-- man these are all just awesome
airlied: agd5f: I think I'll push it, non-kms seems to still work for me
airlied: we can just revert the enable patch if kms regressions show up
k]t: question: is the radeon 4650 (r7xx) capable of 3d support?
biotube: k]t: yes
biotube: need git code(see topic)
k]t: radeon build howto?
biotube: yes
k]t: ok, thanks
cxo: pulls hard
k]t: ftr: i downloaded radeonhd-1-3-0, drm.2-4-5, and mesa.7-6-1, but my problem isn't actually the radeon driver, it's mesa(opengl) saying that glx and dri cannot be load/cannot find module. =\
k]t: s/load/loaded/
biotube: you need a 2.6.32 kernel
cxo: airlied got 500,00 in x11perf -aa10text?, if i get 3,200,000 is that a bug?
k]t: but if I use libgl-mesa-swx11.... 3d support is active but _slow_
cxo: ^500,000
cxo: k]t, 2.6.32rc8, drm (git), mesa (git), xf86-video-ati (git)
k]t: 2.6.30 really isn't in the upstream now. i was porbably thinking to wait until it wis in the repositories
cxo: all should be fine then
k]t: s/wis/is/
k]t: hmm, might i add that i am using amd64 kernel. Is there anything else i should worry about?
biotube: no, but you need the newer DRM
k]t: drm.2-4-5 is old?
biotube: not libdrm, but the kernel module
cxo: dont be a git, get git, then git out of here :)
k]t: sorry, i meant 2-4.15
k]t: last quesiton: has anyone else every had the error, "xlib extension: GLX missing on display?
cxo: ooooh
cxo: gets his split board out
biotube: netjoin!
cxo: rides the split - *WOOOOOOOOT*
cxo: puts the split board back in the closet
flyback: has a dentist app black friday :(
cxo: hey maybe you could get a black friday deal
cxo: Anyone know what that is ---> "Allocating 16 x 16 radeon RBO (pitch 16)"
DanaG: hmm, is that powersavings thing against drm-next?
DanaG: git pull --verbose --log --stat
DanaG: fatal: read error (Connection reset by peer)