EruditeHermit: I was rebuilding a computer with my friend once and he had an "Austin Power Supply"
happycube: did it fry the mobo by the time you got it?
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: 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: 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...)
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: 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: 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
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: 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: you will need o3d plugin
EruditeHermit: are you on Ubuntu?
eosie: I am
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: 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: 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/
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: 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: 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: 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: are you PCIe?
EruditeHermit: or AGP?
EruditeHermit: what generation?
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: 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: yeah that fixed it
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: 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://email@example.com/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
fpoibaf: cire: "r600_dri.so: undefined symbol: radeon_bo_is_referenced_by_cs" disagree, try updating again
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: 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.
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"?
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?
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
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?
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: 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?
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?
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
MostAwesomeDude: Dunno. Link?
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
soreau: Does drm/drm.h define DRM_MAX_MINOR?
lordheavy: no, produce through packages so cleanly removes
lordheavy: soreau: no, only in xf86drm.c
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
soreau: You are using arch AND gentoo?
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
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: 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: 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: i am
lordheavy: yes x86-64
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
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
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: 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 ?
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_: 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: 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 :)
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 ?
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.
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
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?
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: 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
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
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
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
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 :)
spreeuw: LIBGL_DEBUG=verbose glxgears
spreeuw: libGL: OpenDriver: trying /usr/local/lib/dri/swrast_dri.so
agd5f: ossman: evergreen is r8xx
ossman: any work started on that yet?
spreeuw: hey I just spotted it
spreeuw: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed (libdri too old)
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: 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