JohnDoe: For Radeon 9600 technologies of acceleration of video are accessible? mplayer refuses to -vo xvcm
airlied: possible, but not implemented
JohnDoe: interesting :)
MostAwesomeDude: Not really. XvMC can be hacked together on most shaderful chipsets.
MostAwesomeDude: But nobody bothers because it doesn't provide much of an advantage.
JohnDoe: airlied: "no tcl hw in those chipsets" Therefore it is visible only a black square in glxdemo?
agd5f: nanonyme: ignore the no rrb message. that function gets called before a render buffer is setup. it's fine
agd5f: during context creation
agd5f: JohnDoe: no tcl means no vertex shader or user clip planes, so that stuff has to be done in sw
airlied: JohnDoe: everything should render fine
JohnDoe: On radeon9600 I see a yellow square in glxdemo. On RS482 only a black window and a conclusion in the terminal.
airlied: does tcl_mode=0 glxdemo on the radeon 9600 give the same?
JohnDoe: airlied: yes. and attention
JohnDoe: The yellow square appears if to change the size of a window. If then a window to move again a black window
JohnDoe: airlied: Now near at hand is not present 9600. Only 482
soreau: glxdemo is a yellow square on my 9600 rv350 as well
soreau: wonders what its supposed to do
agd5f: draws a yellow square with swrast as well
Nightwulf|work: hi all
soreau: ATTENTION: default value of option tcl_mode overridden by environment.
soreau: ATTENTION: option value of option tcl_mode ignored.
soreau: Thats what I get for tcl_mode=0
g-zu: wow, this is really cool, mesa head from the future Age -94 min. i965: fix cube map on IGDNG master
ferret_: That's a new feature of git
ferret_: Occasionally it can get you improved code from the future
quicksilver: the event horizon is moving outwards, too.
g-zu: cool, next step, time-travelling
quicksilver: by 2012, the radeon branch will have support for cards to be released in 2015.
g-zu: that would be the coolest step possible in the evolution of free software
g-zu: pulling patches and features from the future :))
stikonas: if AMD will switch to git for their design documents, they will be able to pull card designs from the future
simplexe: stikonas: nice voice
boghog: sweet
g-zu: nah, this is only possible in mesa, due to that guy which has his email @skynet...
g-zu: oh way, he quit coding for mesa a long time ago
g-zu: ^^wait
g-zu: oh, c'mon, nobody got the terminator joke?
twoerner: nice work guys - r6xx mesa is great
mikkoc: hi, if i read correctly, support for 785G has been added, right?
mikkoc: im thinking about getting a mobo with 785g
glisse: everythings is still very experimental
glisse: won't be supported in most distro
mikkoc: yea, i compile from git anyway
mikkoc: but should 785g use the old code for r600 or r700?
mikkoc: *shoudlnt
glisse: it's not old :)
glisse: but it should use same path i think
mikkoc: yea i mean, old as in "more supported"
glisse: i am always a bit lost with commercial name
mikkoc: better stick to 790gx?
glisse: mikkoc: don't understand your question
mikkoc: would the older chipset be a better choice?
mikkoc: i think it's called 790?
glisse: take the lastest one
glisse: assuming lastest being better
mikkoc: that would be the 785G then :P
mikkoc: (i think)
papillon81: mikala: you want onboard graphics?
papillon81: mikkoc: sorry
papillon81: this was meant for you
mikkoc: yea, i dont need games
papillon81: mikkoc: go for 785, i'd say
papillon81: wanted to buy this one, too, but then decided i'd need a better gfx, so no onboard stuff
papillon81: i have the 770 now for about a week
mikkoc: i wouldnt need 3d, but is 2d acceptable? (I'm assuming it works pretty much like r600)
mikkoc: with git
papillon81: i'm currently runnging fglrx :-(, but radeon worked fine
mikkoc: eheh, u need 3d?
papillon81: mikkoc: yes. i don't play much, but am a Flightgear addict :-)
mikkoc: hm, im reading a review and it says "Full hardware decode acceleration of H.264/VC-1/MPEG-2 (full hardware decode acceleration of MPEG-2 is not supported in HD 3200?) "
mikkoc: but im wondering... does it need drivers for that?
mikkoc: hw decode accel
mjr: presumably...
mikkoc: so i presume it's too early for radeon to support this?
papillon81: sounds like xvmc
mikkoc: i would be watching 720p and stuff
mjr: (also, many "full hardware decode acceleration of h264" thingies impose some limits on the encoding)
mjr: 720p stuff should be sw-playable on modern cpus...
JohnDoe: sounds like dxva in offtop
mikkoc: yep
mikkoc: im reading this btw: http://www.guru3d.com/article/amd-785g-chipset-review-ecs-a785gmm-test/2
mjr: anyway, yeah, no (free) driver support for decoding at this point
mikkoc: ok
mjr: (and the proprietary one seems lagging with that also, but haven't followed that closely)
mikkoc: u think this will eventually be implemented?
mjr: but as said, you'd probably play 720p fine on software unless with a low-end cpu
mikkoc: im thinking x4 955 so it's fine
mjr: as someone not actively developing anything here, I'd guess "yes", as afaik uvd2 should be documented, but I'm just me
mjr: perchance you'd like a more informed guestimate though
mjr: (I'm not positive on the docs either; at least I heard that uvd1 would not probably be documented since it'd violate intel ndas on drm...)
mikkoc: eheh ok
mjr: uvd2, iirc and afaik, was more modular in that one could spill the beans on the decoding without going into drm
mjr: but again, someone might want to verify this?
mjr: (or say I'm full of shit)
glisse: damm i need to finish this init cleanup to allow easy fallback on agp fail
nanonyme: mjr: Afaik you're right, the actual acceleration API probably gets implemented in userland. (eg VDPAU in Gallium3D)
agd5f: mikkoc: 785 is supported
mikkoc: agd5f: yes i read u added support
mikkoc: so it should work like any other r600?
nanonyme: agd5f: Btw, very good work with the blitting, the speeds appear to be usable already.
agd5f: mikkoc: yes. it's rv620 based
mikkoc: ok thanks
rnoland: hrm, i'm seeing font corruption with aiglx.
adamk: rnoland, r600?
rnoland: hd4650, rv730
adamk: rnoland, Seems to be a common issue, if that's the case.
adamk: r600 driver, anyway.
nanonyme: Where do you see the font corruption, btw?
rnoland: yeah, only see it when running compiz
nanonyme: Hmm.
rnoland: nanonyme: in my xterms.
adamk: I saw it when using compiz in gnome-terminal and rxvt.
nanonyme: rnoland: I didn't get it iirc.
rnoland: i only use xterm, so
adamk: konsole did not have that issue, as I recall.
rnoland: oh, my xchat was screwed as well
rnoland: updating mesa again now...
nanonyme: adamk: Neither did Gnome terminal for me.
nanonyme: I did get upper-right part of the screen blink white during one frame though.
nanonyme: Possibly the same as you get with glxgears.
nanonyme: Ah, right. I get it now too.
nanonyme: adamk: Funny that only compiz seems to suffer from the problem and compiz-gtk not.
rnoland: ok, the corruption seems to be only text that i type
nanonyme: rnoland: Yeah and after you press enter, probably fine.
rnoland: the irc window is fine except for text input box
MrCooper: nanonyme, rnoland: unless you use xterm -fa, xterm text is rendered in software whereas most other text is rendered by the GPU
rnoland: nanonyme: well, no
MrCooper: so maybe there's a cache coherency issue
rnoland: hrm, yes actually....
rnoland: mrcooper that is...
rnoland: i have a case where i map SG memory as uncached in the kernel, but it gets mapped WB in userland...
nanonyme: MrCooper: No switch -fa for xterm here.
rnoland: I think our vm guys gave me a patch to test... lemme look for it...
rnoland: nanonyme: your on linux?
nanonyme: Yeah.
rnoland: nanonyme: ok, so not specifically my bug
MrCooper: could also be a missing texture cache flush or so
nanonyme: rnoland: But yeah, as said, imo it's odd that compiz suffers from it bug compiz-gtk not.
nanonyme: Maybe compiz is trying to do something more that fails?
rnoland: on a brighter note, i get 518fps in gears now.
suokko: nanonyme: not realy. Cache issues are timing problems so if compiz-gtk trashes cache in somewhere it will hide cache bugs
nanonyme: Ah.
nanonyme: rnoland: Under compiz?
nanonyme: Roughly the same as what I get then.
rnoland: nanonyme: yes, under compiz as well
rnoland: same when using metacity...
nanonyme: I get 1400 with metacity and 500 with compiz. *shrug*
nanonyme: I assume that'd be the expected amounts.
nanonyme: (since compiz is evul)
rnoland: wonder if it depends on aiglx being loaded or not....
nanonyme: Hmm.
nanonyme: I had it loaded.
nanonyme: As in, both with and without compiz.
rnoland: nanonyme: hrm, i've never seen a perf difference with or without compiz...
rnoland: even on r500
nanonyme: There should be afaik. ^^
rnoland: i run like 3k fps either way on x1650
nanonyme: Since you can't do direct rendering in the OpenGL windows under compiz.
nanonyme: (in DRI1)
rnoland: test
rnoland: ok, that is weird...
rnoland: my text corruption in xchat is now gone...
rnoland: after changing channels
rnoland: test
adamk: rnoland, Did you incorporate the latest changes from agd5f from the last 12 hours or so?
rnoland: adamk: i did for mesa... i haven't checked drm today.
rnoland: so, it seems if i have gears running... things are better
nanonyme: Apparently there's menu corruption for me under plain compiz too.
rnoland: i get the occasional unrendered character, but no random corruption
adamk: Someone mentioned that using Xv also seems to help with the font corruption too.
MrCooper: rnoland: that could make sense, something else would make it less likely for stale data to hang around in GPU caches
MrCooper: something else running
nanonyme: Neat, finally a different explanation for the causality. ;)
rnoland: MrCooper: ok, if gears is running i don't see menu corruption...
rnoland: if not, i do... appears as if some damage is not cleaned up.
legume: rnoland: FWIW glxgears = 1000 fps LIBGL_ALWAYS_INDIRECT=1 glxgears = 300 fps for me, no compiz involved rv670 (clock at 1/2)
agd5f: legume: commands go through glx in the indirect case
nanonyme: Yeah and don't you have to do LIBGL_ALWAYS_INDIRECT=1 to start compiz at all?
rnoland: nanonyme: yes
legume: agd5f: Yea, just pointing out that it's not compiz as such.
agd5f: at least here, compiz checks direct then indirect before starting
MrCooper: legume: you only have to set it for compiz though, nothing else
MrCooper: agd5f: that's a wrapper script
nanonyme: It also requires texture_from_pixmap, me thinks.
adamk: I thought that with the --indirect-rendering option, the LIBGL_ALWAYS_INDIRECT variable was no longer needed as of compiz 0.8.2, but perhaps I'm wrong.
adamk: Hmm... Apparently I'm right.
nanonyme: Yeah, either works.
rnoland: adamk: it just sets it behind the scenes
legume: On a seperate note, geartrain now seems to block until I move the mouse (I also have some x11perf that do this).
rnoland: MrCooper: so with gears running, occasionally a character that i type won't be displayed until i type the next character, but no corruption
suokko: That might be caused by scissors not set in r600_Exa
suokko: At least similar effect happened for r200
rnoland: if gears is not running... then corruption in menus and typed text...
suokko: What happens if you resize gears to fill whole desktop and keep it in background runngi while you type to terminal?
rnoland: suokko: well, in aiglx, the the gl window always stays on top... so that won;'t work
rnoland: minimizing the gears window gives corruption.
nanonyme: Heh, fun. r600 dri driver would possibly already be fast enough for tuxextremeracer if it didn't crash. :3
adamk: In terms of speed, it handled neverball pretty well yesterday.
adamk: Of course it looks awful :-)
legume: nanonyme: Yea openarena is fast, just too corrupt and timedemo caused a bailout.
rnoland: well, forgetting that glxgears is not a benchmark... this is already as fast or faster than my g45
MrCooper: rnoland: that's an issue of DRI1 vs. Composite, not AIGLX
nanonyme: rnoland: Yeah but the cool thing it *is* already getting far enough to run actual benchmarks. ;)
rnoland: MrCooper: yeah, i knew it had something to do with composite... but iirc, it works ok if i'm not in compiz...
MrCooper: because then you're not compositing
rnoland: MrCooper: right...
nanonyme: As soon as it can run OpenArena without corruption, there's already at least one benchmark available. :3
adamk: It's an issue with any compositor, even one not using AIGLX/opengl.
MrCooper: it's the primary raison d'être for DRI2
adamk: +1 for the use of french.
nanonyme: Do we grant points nowadays? ;)
adamk: I do.
adamk: -1 to nanonyme for questioning me.
agd5f: suokko: we do set the scissors on r600. we always clip to the destination pixmap
DanaG: try "glexcess" perhaps. or the rss-glx package's screensavers.
DanaG: nexuiz doesn't work; I tried that yesterday.
nanonyme: Hmm, playing OpenArena with r600 seems very exciting.
nanonyme: You have to guess where the walls are. :3
suokko: agd5f: ok. I just tough that it might be related to that because I had similar sounding corruption without ddx commit 9243791322e
netbie: help again
netbie: hi
netbie: when dri load Xorg hang
nanonyme: legume: The corruption starts straight in the menu screen, apparently.
suokko: nanonyme: You just have to remember the levels :)
nanonyme: suokko: That'd work.
nanonyme: You can roughly see your enemies so it might theoretically be playable if you indeed actually remember the levels by heart.
legume: nanonyme: Yea - it's pretty bad, running indirect is better but low fps.
suokko: So you have to paly some oa first wit software renderer to learn the level
nanonyme: legume: Err, why does that make a difference in terms of corruption?
legume: nanonyme: I think the game uses different gl stuff as indirect doesn't do everything direct does.
nanonyme: legume: Actually no, it doesn't even start with LIBGL_ALWAYS_INDIRECT for me.
rnoland: agd5f: hrm... more drm update...
nanonyme: Apparently it requires direct rendering. Or at least the new versions do.
agd5f: rnoland: performance improvements
legume: nanonyme: it did for me fullscreen 1280x1024, but I only got 9fps on a timedemo.
nanonyme: Heh.
rnoland: starts merging...
netbie: hi?
nanonyme: Hmm, I was just about to comment on that...
nanonyme: thinks of a communication method which prevents users from leaving for the next thirty minutes unless kicked out
rnoland: woot, i don't have to fix the patch...
nanonyme: Nice.
adamk: lol
rnoland: adamk: you want an updated patch?
adamk: Well I won't have anything to test it on for a while, and at the rate agd5f is going, there will probably be more changes before I can get to it anyway :-)
adamk: So maybe I should pass this time.
rnoland: heh, ok... thought you were running r6+ something
adamk: I do have a HD3450 in a machine, but I won't be near it for a while. Probably not till Monday, unfortunately.
rnoland: ah, ok...
rnoland: rebooting, brb...
rnoland: \o/, 2100 fps
kdekorte: rnoland, what is your setup...
kdekorte: and what are you running
rnoland: kdekorte: hd4650 on FreeBSD
rnoland: that is just glxgears
DanaG: oh yeah, so what's new in the last 12 hours or so?
kdekorte: agd5f, are you interested in a message from etracer? It crashes with some cp information
DanaG: for r600, that is.
agd5f: kdekorte: sure
kdekorte: when I run glxgears on my rv635, I get about 1100FPS in gears which is better than the 300 from the other day.. but I also get a message about "no rrb"
rnoland: appears to be stabilizing aroud 1380 fps indirect.
agd5f: kdekorte: ignore that
rnoland: 1390
kdekorte: agd5f, this is from a crash of etracer
kdekorte: CS section size missmatch start at (r700_chip.c,r700SendContextStates,458) 0 vs 3345
kdekorte: cs->section_ndw = 0, cs->cdw = 3344, cs->section_cdw = 3345
kdekorte: CS section end at (r700_chip.c,r700SendContextStates,465)
kdekorte: etracer: radeon_lock.c:65: radeonGetLock: Assertion `drawable != ((void *)0)' failed.
rnoland: agd5f: nice work...
agd5f: rnoland: thanks
suokko: agd5f: Last error message from kdekorte's errors should because by application calling swap without any current context
rnoland: corruption issue unchanged
kdekorte: etracer worked about 2 weeks ago (when some geometry fixes when it) but it was really slow... now it gets past the first thing and then crashes when you start to play
agd5f: kdekorte: you could re-add rcommonFlushCmdBuf( &context->radeon, __FUNCTION__ ); to the end of R70RunRender
agd5f: that fixes some apps at the expens of others
kdekorte: give me a sec
kdekorte: agd5f, yes that fixes the etracer issue
kdekorte: adding that function in, however makes glxgears flicker horribly
kdekorte: agd5f, is there a better place to put the flush than in RunRender?
agd5f: kdekorte: right, like I said, fixes some, breaks others
agd5f: kdekorte: normally via the flush function of it the command buffer gets full
agd5f: s/of it/or if/
kdekorte: how about if there is a section size mismatch... like where the above error message is emitted?
agd5f: putting it in runrender causes a flush after every draw
agd5f: not sure what's causing that off hand
kdekorte: agd5f, tried putting the flush at the end of SendContextState... etracer works, but REALLY messy
osiris_: airlied: so what do you think about removing non-TNL branch from r300 driver?
flo|linux: it's me again xD (in the correct channel xD)
glisse: osiris_: why do you want to do that ?
glisse: there is r3xx chips without tnl
osiris_: glisse: I'm talking about SW TNL path not SW TCL path
flo|linux: changing the bus mode to 1 didn't help, however my Terminal window now resizes correctly (with agp 1 or agp 4...)
agd5f: flo|linux: what about 2 or 8?
glisse: osiris_: what is the subtilities btw the 2 ? clipping ? :)
flo|linux: i haven't tried yet... i wanted to try that thing with the terminal window...
osiris_: glisse: yes, and I haven't seen any app that would use this path
glisse: osiris_: so you want to set default clipping ?
flo|linux: to be honest, i doubt that i will get the radeon driver working... many times i fixed some problem and the next update brought five new problems ._.
osiris_: glisse: I just want to remove the unused code. sw TNL will be handled now by r300_swtcl.c just like sw TCL is now
agd5f: flo|linux: bug that don't get filed don't get fixed :)
flo|linux: i filed the bug.
flo|linux: (one bug. glitching fonts)
MostAwesomeDude: flo|linux: The reason for your terminal window's strangeness is because of your terminal.
flo|linux: MostAwesomeDude, but it has to be much faster
flo|linux: i mean, on my fedora 10 system on the same machine, the same window of the same program resizes correctly
MostAwesomeDude: It resizes in multiples because it's kind of useless to have half a line or column.
MostAwesomeDude: flo|linux: Turn on EXA.
flo|linux: the only difference is that f10 uses the fglrx driver
flo|linux: MostAwesomeDude, i don't complain about resizing in multiples.
flo|linux: i complain about resizing in multiples being so slow
agd5f: flo|linux: try EXA
flo|linux: restarting X...
flo|linux: (and waiting for the next crash ._.)
flo|linux: and... fail
flo|linux: * No GLX_EXT_texture_from_pixmap with direct rendering context
flo|linux: ... present with indirect rendering, exporting: LIBGL_ALWAYS_INDIRECT=1
flo|linux:
flo|linux: says fusion-icon
flo|linux: (the thing that keeps crashing)
flo|linux: 2660 FPS in glxgears... is that much?
adamk: glxgears can't be used as a benchmark.
boghog: more then you'll ever be able to percieve
adamk: And the GLX_EXT_texture_from_pixmap warning is normal.
adamk: Are you using F11 now?
flo|linux: but the "indirect rendering" isn't, is it?
flo|linux: F11? you mean F10?
flo|linux: no i'm not
adamk: In that case, the indirect rendering message is also perfectly normal.
flo|linux: in what case?
flo|linux: erm, what do you mean with F11?
flo|linux: maybe i misunderstood...
adamk: Fedora 11 is out. It supports GLX_EXT_texture_from_pixmap with direct rendering.
flo|linux: ok
adamk: It is, at the present moment, the only distribution that supports that.
adamk: So if you aren't using F11, you will almost certainly need to run compiz via indirect rendering.
flo|linux: aha...
flo|linux: but, isn't indirect rendering awfully slow?
MostAwesomeDude: No.
flo|linux: ... or was that "software rendering"...
MostAwesomeDude: Yes.
flo|linux: aah :)
flo|linux: ok, then...
flo|linux: then it would be great if that damn compiz would NOT crash my X server...
flo|linux: is it normal that switching on/off compositing in my WM causes the windows to dis- and reappear?
MostAwesomeDude: Yep.
adamk: Yes.
flo|linux: ok
flo|linux: then, maybe it's a compiz bug...
flo|linux: if i don't answer within 10 sec, my machine has crashed again
flo|linux: hmmm
flo|linux: compiz reloads successfully
MostAwesomeDude: Actually, if compiz causes a crash, it's a driver/X/kernel bug.
MostAwesomeDude: Or you set something up wrong.
flo|linux: only the original WM can't reload
flo|linux: another possible-crash...
flo|linux: yay?
flo|linux: replacing the WM via command line also works
flo|linux: yeah?
flo|linux: what does the "loose binding" option in fusion-icon cause?
flo|linux: with that option, it works fine
flo|linux: may be occasionally... dunno
MNZ: wow so much improvement in so little time! great work on the r7xx drm!
nanonyme: wonders if we'll get working r600 DRI2 by Christmas
flo|linux: wow...
MrCooper: that seems quite likely
MostAwesomeDude: nanonyme: Do you mind softpipe? :3
flo|linux: the EXA method did it :)
flo|linux: could please anyone explain me, why it works now?
flo|linux: what does the EXA-method do / what does it change
nanonyme: MostAwesomeDude: I was thinking of classic Mesa.
nanonyme: I thought it might be a more realistic Christmas present wish.
flo|linux: MostAwesomeDude, why does turning on EXA help?
nanonyme: There's at least explanation attempts I've heard thus far.
MostAwesomeDude: flo|linux: Because XAA sucks?
MostAwesomeDude: No, wait.
MostAwesomeDude: Need a more authoritative answer.
MostAwesomeDude: *ahem*
flo|linux: what is XAA ^
MostAwesomeDude: Because XAA sucks.
flo|linux: ok?
nanonyme: :D
MostAwesomeDude: XAA is the old acceleration system.
flo|linux: what is XAA and why does it suck?
flo|linux: ah, ok
MostAwesomeDude: And it bites on cards that were made after 2001 or so.
nanonyme: Plus doesn't play well along with 3d rendering?
agd5f: flo|linux: several reasons XAA doesn't support surfaces or pixmaps of multiple depths, and at this point it's so bit rotten, doesn't support offscreen pixmaps anymore
MNZ: there's been a few regressions though. Lots of the mesa test have increased corruption now
suokko: more frames in second=more corruption in second :P
alberto: hi
alberto: X hang with ati radeon 9250
alberto: dri cause the problem
alberto: How to fix it?
alberto: with AGP mode
nanonyme: suokko: Naw, it's not that. There was geometric corruption even before the new blitting code. :3
agd5f: alberto: Option "AGPMode" "X" where X = 1 or 2 or 4 or 8
agd5f: in the device section of your config
alberto: all
alberto: i tried all
agd5f: alberto: Option "BusType" "PCI"
DanaG: oh yeah, I figured out another way I could get a serial console on my system: usb-serial converter, combined with an fpga board with a video output and PS/2 input.
agd5f: alberto: are you using kms?
alberto: kms?
agd5f: kernel modesetting? are you using fedora 10 or 11? if not then you most likely aren't using kms
nanonyme: DanaG: Theoretically with firewire you could also solve the lockups. ;)
alberto: Option "BusType" "PCI" : it causes x work during 5 minutes an then hang
nanonyme: As in, heard that firewire is allowed to write to any arbitrary system memory location so you might be able to overwrite kernel memory to solve a lockup.
alberto: y use Ubuntu
DanaG: I don't have any other systems with firewire, that are also in working condition (aside from my old desktop).
nanonyme: Yeah and this is anyway just theory. I've heard people say concerns about system security with a computer with firewire but I haven't heard even of any proof-of-concept attacks.
alberto: any solutions?
DanaG: heh, and usb 3.0.... wonder what kind of CPU usage that'll have.
nanonyme: Anyway.
DanaG: Considering, usb 2.0 is actually slower (in real use) than firewire400.
nanonyme: alberto: This is stock Ubuntu, right? As in, you haven't installed any drivers on it?
agd5f: alberto: try EXA? or a newer driver snapshot?
alberto: i use EXA
suokko: alberto: I think one solution is toupgrade your grapics driver because I think Ubuntu jaunty has broken r300 driver
alberto: upgrade? how?
suokko: oops r200 card :/
alberto: i
agd5f: alberto: you might try newer ddx and mesa snapshots
alberto: how?
nanonyme: suokko: Might be still worth a try.
alberto: i can't access on UBUNTU
agd5f: xf86-video-ati from git master of 6.12-branch and mesa from git master
suokko: alberto: https://launchpad.net/~xorg-edgers/+archive/ppa
agd5f: alberto: I think one of the ppa repos has test packages
alberto: xf86-video-ati? ati is a selector
alberto: ¿no?
alberto: ok
agd5f: alberto: that's the name of the driver
alberto: ok
alberto: Xorg.conf Driver "radeon?
alberto: Xorg.conf Driver "ati"?
agd5f: alberto: same driver
agd5f: ati is just an alias
alberto: radeon or ati?
agd5f: wrapper actually
agd5f: alberto: doesn't matter, both load the same driver
alberto: ok
alberto: Delete ati drivers from ubuntu?
alberto: ok
agd5f: alberto: just grab the updated packages
alberto: wait please
nanonyme: Hehe, apparently Adobe Flash works with r600 Mesa driver just nice. :3
agd5f: I thought flash required glsl?
nanonyme: (how can I know it's actually using that? there's the same part-of-screen-white corruption as in other OpenGL apps)
nanonyme: Or at least if that's not caused by GPU acceleration, I'm starting to blame the rest of this system for my r600 Mesa issues.
nanonyme: agd5f: I overrided GPU validation, it probably doesn't check for supported extensions.
MostAwesomeDude: Flash has issues.
nanonyme: Probably.
alberto: aaarrrggg
DanaG: Flash is eeeeeevil.
nanonyme: agd5f: I dunno, I was probably wrong.
alberto: Ubuntu is running in low-graphics mode!!!!
nanonyme: Though if I was, it might imply Flash has started validating open drivers too.
DanaG: It probably violates ADA guidelines, too, if you consider how it steals tab and ctrl-tab.
nanonyme: Oh, true.
nanonyme: And ctrl+pgdown and ctrl+pgup down work either there.
xc88: I have an ATI X1550, and I'm using ubuntu jaunty. My max resolution right now is 800x600, but my monitor's max is 1600x1200. Ive tried various tutorials involving editing xorg.conf and using the command xrandr, but these do nothing. How can I fix my resolution?
alberto: Problem not solved
alberto: "Without signal" error
nanonyme: alberto: How about pastebinning xorg log?
alberto: x hang
alberto: I can't
alberto: Now i using a laptop
alberto: but wait
alberto: I will restart :(
DanaG: oh yeah, what ever happened to those old ctrl-alt-+ and ctrl-alt-− shortcuts to change screen resolution?
ajax: they don't work anymore.
ajax: randr makes the whole notion kind of fuzzy
ajax: say you have two displays plugged in, and they're left/right of each other, and you hit c-a-minus. what happens?
agd5f: alberto: you might still have to mess with agpmode
alberto: ok
alberto: Problem not solved
alberto: X hang again
alberto: cause Dri enabled
alberto: How to fix it?
agd5f: alberto: try different AGPModes
agd5f: or bustype pci
alberto: i tried 0 and 1
DanaG: hmm, oddly enough, the xorg manpage still mentions them.
DanaG: It might be good to at least let them work when you have only ONE monitor.
agd5f: alberto: for AGPMode? 0 isn't valid, 1,2,4,or 8
DanaG: Sure would be good for fixing those times when games crash and leave the desktop at the wrong resolution.
alberto: arrgg
alberto: "without signal" again
alberto: I tried 2 and 8
agd5f: alberto: can you pastebin your xorg log?
alberto: AGP mode causes "Without signal" error
agd5f: alberto: what does that mean? the monitor doesn't get a singal? some error message?
alberto: yes
alberto: the monitor doesn't get a singal
alberto: X run with PCI mode
alberto: But It hang
alberto: any solution?
alberto: i will post x og
suokko: alberto: But no hang if you have Option "DRI" "off" in xorg.conf?
suokko: alberto: Do you have compiz running?
alberto: yes - no
alberto: comiz can run but i not using it
suokko: alberto: Can you login with ssh when hang happens?
alberto: no
alberto: ok
alberto: problem semi-solved
alberto: Vlc run very slow
alberto: Using XVideo
suokko: DId PCI mode solve it?
alberto: no
alberto: ohh no
alberto: X hang again
alberto: "Without signal" error
suokko: Your monitor is saying no signal I guess
alberto: yes
alberto: X work during 5 minutes and then hang
alberto: any solution?
suokko: No idea. Some GPU hang which I'm not good at debugging
agd5f: alberto: file a bug https://bugs.freedesktop.org and attach your xorg log and config
alberto: ok
alberto: bye
hifi: [ 335.564329] [drm:r300_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 2080000 have 1921024) !
hifi: kernel too old?
hifi: [ 335.564336] [drm:r300_cs_track_check] *ERROR* [drm] color buffer 0 (800 4 0 650)
hifi: or a nasty bug
hifi: http://pastey.net/120921-2g5f package versions
nanonyme: Hmm, sounds like the dri state tracker is getting necessary support for compiz.
AStorm: firmware is necessary? what firmware?
AStorm: re: topic
nanonyme: The microcode is packaged separately in Debian.
AStorm: ahh.
AStorm: so now the free driver uses some kernel blob?
AStorm: uh, Rxxx kernel
nanonyme: It always has done that...
hifi: it has always used
AStorm: ahh, I fail then
hifi: debian folks splitted the firmware out of the main kernel package, nothing special
MNZ: I think a wiki page is needed on this subject
AStorm: oh, Debian always does that
hifi: and pushed it to non-free repo
nanonyme: I think it's somewhat annoying kernel can't be licensed so that it wouldn't be allowed to split parts of it out. :p
hifi: thats a debian issue, debian wiki?
suokko: hifi: What is causing that error?
hifi: suokko: browsing the openarena menu
suokko: (sounds like bug to me)
nanonyme: hifi: Which kernel version are you using, btw?
hifi: I get the usual drmRadeonCmdBuffer: -22
hifi: nanonyme: i *think* it's 2.6.31-rc5 with some ubuntu patching
nanonyme: And is it KMS or not?
hifi: KMS
nanonyme: I don't want to guess, could ask one of the guys actually working on KMS memory handling to what can cause that.
hifi: it did work a week ago, updated today
hifi: also lost really much performance at the same time
hifi: though it might be related
AStorm: oh, how does work on R6xx KMS go?
hifi: trying to figure out which vanilla source is used
nanonyme: AStorm: Progressing slowly.
AStorm: eh. :/ What about 3D?
suokko: hifi: Did you only update kernel?
hifi: everything
nanonyme: AStorm: OpenArena runs fast but with corruption.
hifi: including libdrm, mesa, ddx
suokko: so problem could be anyone of them then
AStorm: hmm
AStorm: so there's something to work on already? cool
nanonyme: Pretty severe corruption at that.
hifi: I'll try the older kernel, I still have it
AStorm: vertex, texture or shader?
hifi: I think I can revert packages until I find which one is the culpirit
nanonyme: Namely you can't navigate the hallways because you can't distinguish the walls from the floor.
AStorm: ah, so texture uploads fail
agd5f: AStorm: some sort of geometry issues
agd5f: AStorm: textures work fine
AStorm: interesting
AStorm: I don't know how can you mess up geometry ;P
AStorm: do you have to translate plain old OpenGL into full shader programs?
agd5f: AStorm: it's a bug in the driver
AStorm: I know it is, how otherwise.
nanonyme: Possibly a regression even.
hifi: ok, I can count kernel and ddx out now
agd5f: nanonyme: not really
AStorm: the question is if the driver does OpenGL -> vertex shaders, or does the card take vertices directly
nanonyme: agd5f: Well, iirc teapot worked at one point.
agd5f: AStorm: mesa converts fixed function GL into shaders
agd5f: we just load what mesa tells us to
AStorm: hmm
AStorm: so the problem is while loading?
AStorm: or are the programs broken...
agd5f: nanonyme: right. you can "fix" it by adding a flush at the end of R700RunRender(), but that will break other apps
nanonyme: Ah.
AStorm: hmm
AStorm: maybe some padding is missing?
agd5f: it used to work when we always flushed in r700RunRender
suokko: agd5f: Maybe some state change is not marked dirty? so after flush something gets emited but not if there is no flush
hifi: actually I'm not sure if openarena menu has worked ever on r500 kms
nanonyme: Iirc MrCooper said "something else would make it less likely for stale data to hang around in GPU caches" when mentioned that Xv helps with OpenGL corruption.
nanonyme: This pondering would sound to me in line with that flush would help with some rendering problems.
agd5f: AStorm: I think it's either a state emission problem or some issue with stale vertex data, like issues with caching of gart mem
AStorm: hm
AStorm: possible too
nanonyme: *shrug*
AStorm: isn't there a partial flush available?
AStorm: as in a cache flush
AStorm: not queue flush
nanonyme: There's a whole chapter about synchronization and cache flushing in r6xx/r7xx 3D guide. *shrug*
nanonyme: "For pre-R600 ASICs, entire ASIC cache can be automatically flushed when GUI becomes idle, using PM4_IDLE where needed. R6xx/R7xx does not have this auto flush mechanism." is the part that always jumps at my eyes from there, dunno why. :)
AStorm: check other parts about where it should be flushed
nanonyme: But yeah, I'm confident agd5f knows the guide pretty through and through knowing he was writing it...
nanonyme: AStorm: There's more than one choice.
nanonyme: The guide gives a few alternatives and describes some flushing techniques.
nanonyme: Go read if you're interested.
MNZ: where are the AMD released documents btw?
nanonyme: x.org/docs/AMD/
DanaG: heh, single-letter domain name.
ajax: yeah, we're old school
suokko: What is difference between radeonScreen->driScreen->dri2.enabled and radeonScreen->kernel_mm?
nanonyme: suokko: They are not oneway.dependent of each other?
nanonyme: s/\./-/
nanonyme: As in, you'd think you can have mm without dri2 but no dri2 without mm.
MostAwesomeDude: I believe that that is correct.
suokko: But for radeon there is no plan to use kernel_mm without dri2 so they are same in code
nanonyme: *shrug* I've guessed enough. You could check whether radeonScreen is based on some shared data structure.
suokko: shared?
nanonyme: As in, between drivers.
suokko: It is same between radeon/r200/r300
nanonyme: I meant other than radeon. I found at least one place where some common data structure was just typecasted into a radeon one. :)
MostAwesomeDude: nanonyme: It's C classes.
nanonyme: Hrm.
suokko: Why emit_zstencil_format function doesn't have begin and end batch?
suokko: I guess that is possible but not standard way of emiting state ...
agd5f: suokko: it it called from some context that wraps it with a begin/end?
agd5f: *is it
suokko: It should be called from radeonEmitState
suokko: Or better say I'm 99 % sure it is called from there
agd5f: probably a bug
airlied: osiris_: yup collapsing swtcl and swtnl into swtcl is fine by me
suokko: Is it possible to do remote testing with ssh? I mean I would like to run opengl application with offscreen rendering and then transfer rendered image stream over ssh for checking.
airlied: having 3 paths is getting messy to keep track off
suokko: I guess something like that might work with vnc
airlied: suokko: not really simply
airlied: suokko: zstencil sounds like a bug
airlied: and dri2 enabled and kernel mm are really the same thing
airlied: originally when I wrote the code I had a test path where mm worked on dri1
airlied: but I killed that
nanonyme: So is it a remainder then?
airlied: kernel_mm is also shorter to type ;)
MostAwesomeDude: airlied: Good call. :3
suokko: #define IsDri2(radeon) (radeon)->RadeonScreen->driScreen->dri2.enabled
nanonyme: :p
airlied: suokko: well is_dri2 :-)
suokko: maybe IS_DRI2 because it is macro
nanonyme: thinks this is getting silly :3
suokko: thinks that dynamic virtual desktop scaling would be popular feature.
MrCooper: suokko: what's 'dynamic virtual desktop scaling'? :)
suokko: MrCooper: Feature that would make virtual deprecated in xorg.conf.
MrCooper: suokko: should already work with KMS
MrCooper: or at least be easily fixable, it's definitely working with the intel driver
suokko: ok :) I haven't had 2nd monitor after moving to kms
MrCooper: suokko: note the 'maximum' output of xrandr
suokko: 4kx4kx4=a lot memory for front buffer ;)
MrCooper: though it says 4096x4096 here, which still seems artificially low
airlied: yeah fb resize works fine
airlied: thats the scanout maxes I thought on < r500
MrCooper: the pitch limit?
airlied: pre-avivo I think the crtc was rk
suokko: good. I remember restarting X because I wanted to plug 2nd monitor or projector to my laptop
airlied: 4k
airlied: post avivio its 8k
MrCooper: k, but what imposes the vertical limit? :)
MrCooper: 4k means you can only arrange 30" monitors vertically ;)
MrCooper: shatter to the rescue
suokko: 2nd card :)
MostAwesomeDude: More like 2nd-stage shatter.
MostAwesomeDude: And I still haven't got fully working 1st-stage shatter.
airlied: MrCooper: if you can find a pre-r500 radeon with two X dual-link ;-)
airlied: 2xdual-link even
nanonyme: Argh, Mesa doesn't compile. :/
DanaG: It'd have to be a FireGL.
DanaG: ... for the old cards.
airlied: I think the firegl I got had only a single dual-link transmitter on it
nanonyme: Where should glutInit be defined?
airlied: nanonyme: is it in the demos?
nanonyme: Yeah.
nanonyme: skinning.c
nanonyme: Maybe a missing include.
airlied: try now I pushed a fix to the makefile that might do it
nanonyme: progs/glsl/skinning.c, to be exact
nanonyme: airlied: Works.
suokko: ouch. I might not rebase my tree :/ that indent commit looks bad for my glx patch that has been lying in mail list for a while
nanonyme: Err, why was that done at all? o.O
nanonyme: As in, the indent thing. Surely it doesn't matter that much that a few lines are indented differently.
suokko: nanonyme: If there is mixture of tabs and spaces it may be horrible to read
nanonyme: Hmm.
nanonyme: Also I've never really understood why not use tabs instead of spaces when tabs exist.
nanonyme: (except of course if people have broken text editors)
suokko: I prefer indent to be tabs so I can select tab sizes to be what I want (3 spaces)
suokko: but there is any people who want to have code look exactly some specific way
nanonyme: *sigh*
nanonyme: Damn puritanians.
suokko: Like if I split function parameters to multiple lines they have indent up to same width as first parameter starts
MostAwesomeDude: Actually, the reason for it is that people will *always* mix tabs and spaces in order to get things to line up.
MostAwesomeDude: And so we might as well just prefer spaces.
MostAwesomeDude: Since, of course, the purpose of indentation on (nearly) all languages is to enhance readability.
airlied: the kernel has it easiest, you do what you are told
DanaG: What does the kernel call for?
airlied: opinions don't matter
suokko: Too bad only spaces doesn't work either because many editors default to tabs
MostAwesomeDude: OTBS more or less.
airlied: 8-space tabs
nanonyme: Whoa.
MostAwesomeDude: TBH, kernel-style works out well because the code style is supposed to be simple and straightforward.
nanonyme: You don't want to have very deep indentations with that.
DanaG: http://en.wikipedia.org/wiki/Elastic_tabstop
airlied: nanonyme: thats the point
airlied: you can use spaces for alignment
airlied: if a function has gone over 4 levels of identation maybe you are doing it wrong
nanonyme: :)
nanonyme: Good point.
nanonyme: airlied: Hmm, so that was a copy-paste error then? :)
airlied: nanonyme: not sure, that makefile is fairly shithouse
nanonyme: I was kinda puzzled to notice that's it's static.
nanonyme: I assumed it would be generated with autotools like most of the others.
MostAwesomeDude: Someday, somebody's going to have to get brianp to sign off on proper automake.
airlied: well make can handle that quite easily
suokko: btw, I think that config.status should recreate config/current
suokko: ./config.status -recheck specificaly
agd5f: nanonyme: mesa is still makefile based, you can build with or without autotools
nanonyme: Hmm, right.
nanonyme: Yeah, I must've remembered wrong. Yeah, it doesn't apparently have Makefile.in's.
nanonyme: Carry on then.
nanonyme: Possibly part of the point being in that you can now use scons just as well?
nanonyme: (nor Makefile.am's)
m03sizlak: http://media.myfoxla.com/live/2/
m03sizlak: secret service armed robot fucking with some guy on live tv
soreau: So.. when will the open ati driver have OpenGL 2.1 support?
airlied: when you write it
soreau: Then never. How disappointing ;)
soreau: airlied: Believe me, if I could I would
soreau: wonders what version of opengl the intel driver supports
EruditeHermit: soreau: 2.1
soreau: Is it any easier since the sw routines are already written?
airlied: its just needs the compiler flow control bits written
airlied: at least I assume you care about GLSL and not 2.1 so much
soreau: if shader language is what 2.1 provides, idk. I just know there are still some cool 'stuff' that is falling back to swrast
soreau: making it obviously slow and thus uncool
airlied: we don't even fallback to swrast at the moment
airlied: sinec we don't advertise 2.1
soreau: then I said it wrong
soreau: But LIBGL_ALWAYS_SOFTWARE=1 glxinfo|grep OpenGL shows 2.1
airlied: thats not falling back so much as forcing sw use
soreau: wishes he even knew what 'compiler flow' was much less be able to implement it
soreau: Is it like a real time compiler?
soreau: on the fly?
airlied: GLSL is all on the fly
soreau: Do you have to dip into assembly to write it?
airlied: no its all written in C
soreau: I mean the driver part, of course
airlied: the compiler converts GLSL into GPU assembly
soreau: ahh.. sounds dangerous
bridgman: soreau; the GPU assembly code includes instructions for jumping and looping
bridgman: the shader compiler in the current driver doesn't handle them
EruditeHermit: I thought there was no GLSL support at all
bridgman: mesa turns GLSL into the same kind of instructions the driver's shader compiler handles already
bridgman: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/shader/prog_instruction.h
bridgman: look around line 147
EruditeHermit: ok
EruditeHermit: what does all that mean?
bridgman: right now the driver supports arb_fp and arb_vp
bridgman: so the mesa instructions with X's in those columns are probably supported already
EruditeHermit: how hard is it to work on this stuff?
EruditeHermit: is this some of the harder driver work?
EruditeHermit: or can relatively new people work on it
bridgman: MostAwesomeDude is probably the best person to ask; I think that's kinda where he got started
bridgman: he seemed to have a fair amount of success adding one instruction at a time
EruditeHermit: so the GLSL column needs to be filled
EruditeHermit: even ARB_vp and ARB_fp column aren't half filled
bridgman: all the instructions with X under GLSL but no X under arb_fp or arb_vp need to be implemented
bridgman: or something like that
bridgman: what I'm not sure about is that I thought GLSL handled arrays, which IIRC makes things a lot more complicated
bridgman: not sure how that fits in
airlied: I think flow control is the hard bit
airlied: and I think you'll run into interactions with the compiler with that a lot
EruditeHermit: bridgman: you couldn't steal it from fglrx?
EruditeHermit: =p
bridgman: maybe as a blob
bridgman: I'd rather get our shader compiler guys to help with the open driver
EruditeHermit: well I thought the 3D engine isn't the part that is so secretive
EruditeHermit: the video decode part was
bridgman: it's all up there, the 3d stuff just isn't so far up
bridgman: and it's kinda hard to write a driver without it ;)
vehemens: bridgman: how goes the corruption hunt?
bridgman: honestly ? it feels like we're randomly changing things to see if it gets better ;(
soreau: bridgman: Why arent they already helping? =)
bridgman: don't think we have a good strategy for cornering the problem
bridgman: because good real-time compiler people are really hard to find so they don't have a lot of free time
bridgman: the problem with intermittents is that you either have to find the problem by inspecting the code and tripping over something, or you sort of intuit where the problem is by staring at patterns, or you lay a trap for the problem, catch it and dump history
soreau: doesnt have a lot of free time nor is a good real-time compiler guy :/
bridgman: ok, you can help with GLSL then ;)
soreau: intermittent problems are the worst
soreau: bridgman: )
vehemens: several of the demos (engine for example) show corruption quite well
bridgman: part of the problem right now is that everyone's intuition is pointing in a different direction
bridgman: engine actually completely stopped showing corruption after agd5f's first round of blit code, but the corruption came back just as bad today
bridgman: smells like a race condition of some kind
bridgman: but it's so damn consistent
bridgman: we may have to dump out all the data going to the chip and pick through it
vehemens: i never saw engine work correctly. a show block always had rendering errors.
bridgman: for me it was perfect yesterday; still a bit of surface fluctuation (like the lighting is varying on some triangles but not others) but no geometry
bridgman: that was yesterday
bridgman: tomorrow I'm going to try reverting the drm changes to see if it goes away again
bridgman: what we really want is a tiny simple "draw the same thing over and over again" test that shows geometry corruption when dragging another window around
bridgman: so at least we can lay a trap for that problem
vehemens: which version of code? the original blit, the faster blit, or today's shuffling?
bridgman: memcpy had corruption, original blit had no corruption, faster blit had corruption
bridgman: did drm change again today or just mesa ?
vehemens: the mesa knob changed today. i haven't tried it yet, hence the source of my first question.
bridgman: I didn't really notice any difference from today's changes
bridgman: we probably have to start analyzing applications to find why some corrupt and others do not
bridgman: the GLSnake screen saver always works so nicely, it's buggin' me
vehemens: probably easier to start with the ones that corrupt :>
vehemens: anyway, it sounds like that someone can work on it without agd5f already having a solution in hand.
bridgman: I think so... now that the blit is there I think (hope) the rest of the issues will be smaller in scope, ie you don't have to have the entire stack burned into your head to make progress
bridgman: that's really where other people can start to help
vehemens: yea, one doesn't need a solution, one just needs to identify the cause(s).
bridgman: the solution is usually obvious at that point... don't do
DanaG: hmm, speaking of GL apps, I forgot to try rss-glx things like Skyrocket.
bridgman: skyrocket is very slow, as are the rest of the Really Slick screensavers
bridgman: hyperspace seems to freeze the preferences panel somehow, even though the preview window keeps running
bridgman: the rest are OK but like slideshows
bridgman: feels like they're running in software but not sure what the fallback path is
bridgman: every time I click on hyperspace I have to edit the preferences file to get rid of it ;(
bridgman: imagines DanaG furiously editing the file trying to get his screensaver-preferences panel working again
DanaG: I just run the things directly.
DanaG: in /usr/lib/xscreensaver/
vehemens: bridgman: looks like two problems. general 3d rendering corruption and ddx interacting with 3d rendering.
agd5f: seems like vertex buffers are periodically stale or something, like caching issues when writing or reading vertex buffers
vehemens: one of the problems seems very repeatable. not random at all.
DanaG: ugh, damn ntfs-3g is using 80% of one CPU.
DanaG: 85 percent.
DanaG: Even up to 90.
DanaG: oops, wrong tab.
DanaG: grr, another example of the evils of software patents: http://jonahprobell.com/lexra.html
JohnDoe: morning :)
simplexe: morning
boghog: heya
soreau: hi