spstarr: turning off VBOs doesn't do much
spstarr: not ready back to Intel GMA
spstarr: KMS + r6xx = lockup X after initial use (few seconds)
spstarr: r6xx w/o KMS = limited 3D, Second Life wont run (see errors above), glxgears is ok
joosu: spstarr: log secondlife so it becomes clear why it refuses to run
spstarr: it crashes on rendering world load up
spstarr: joosu: I will say the r6xx is not ready for production anyway
spstarr: its got ways to go
joosu: spstarr: ok. i never used but bugle should dump all the traffic to file , even if it's binary format closed binary/game
spstarr: uh
joosu: gl api trace
spstarr: its open source client
spstarr: GPL license
joosu: ok, then post a gdb backtrace
spstarr: the server side isn't open source (opensim is a reverse engineering)
spstarr: implementation of the server
spstarr: i will wait, it is still quite rough 3D for the r6xx/r7xx
joosu: last time someone said 32 will have it, and there was a line that was needed to be changed, deucher i belive
EruditeHermit: hey MAD
MostAwesomeDude: I was here before. :3
MostAwesomeDude: Hey.
EruditeHermit: oh
EruditeHermit: lol
spstarr: is 64bit
EruditeHermit: spstarr, they made you 64bit?
EruditeHermit: =p
spstarr: yes, new and improved
dileX: EruditeHermit: now, I know what you mean by "MAD" (associsated alfred e. neumann from mad magazine first I read it here)
EruditeHermit: lol
EruditeHermit: MAD is famous
EruditeHermit: he is a painist!
EruditeHermit: err
MostAwesomeDude: XD
EruditeHermit: pianist
dileX: LOL
dileX: painist haha
EruditeHermit: he may be a painist too
EruditeHermit: but I can't say
EruditeHermit: go ask his gf
EruditeHermit: or significant other
dileX: maybe both is correct? hehe
MostAwesomeDude: GF?
MostAwesomeDude: I didn't know I had a GF.
EruditeHermit: well
EruditeHermit: go ask someone who knows him
EruditeHermit: in real life
dileX: MostAwesomeDude: girlfriend
soreau: dileX: I think he knew that ..
dileX: soreau: didnt know that real xorg/radeon hackers have a "real" GF. I started
dileX: my 1st GF was an amiga computer
joosu: MostAwesomeDude: core mesa ones i ment in shader/slang there is everything available, is it possible to get those rolling? most functions are static, compile and emit, and wrap registers?
dileX: amiga (ES: girlfriend)
EruditeHermit: amiga is a game console
EruditeHermit: =p
EruditeHermit: it makes so much sense!
joosu: famous, starting from 90's all sweds had it, i've seen one too
EruditeHermit: its a substitute for a real gf
joosu: EruditeHermit: do they manufacture amiga still?
EruditeHermit: no
Batou: Any news on slow Firefox scrolling on r600 with KMS?
joosu: couple allready available http://news.softpedia.com/news/Point-of-View-Unveils-Its-Own-NVIDIA-ION-Netbook-117293.shtml
joosu: ion based netbooks 10.1 inch
dileX: MostAwesomeDude: I could try to disable UTS/DFS with gallium-radeon
MostAwesomeDude: dileX: Go for it if you like.
dileX: Option "ExaNoDownloadFromScreen"
dileX: Option "ExaNoUploadToScreen"
dileX: is that ServerFlags section?
MostAwesomeDude: I think so.
Batou: I've also noticed that with KMS enabled, Firefox randomly crashes when closing tabs. tbh this is less annoying than the incredibly slow scrolling speed though.
joosu: http://www.pointofview-online.com/userfiles/product-images/zMobii/ION Mobii Mini NB/NB-ION7010-B-back.jpg looks to be little fatter then eeepc MAD i'm telling should hurry up with open source shaders
EruditeHermit: broken link
joosu: remove one space , 1,4 kg 1000H is lighter
joosu: and it isn't 1.45, well well
dileX: MostAwesomeDude: its Section "Device"
EruditeHermit: hey, does anyone else get corruption on kms when opening PNG files?
dileX: MostAwesomeDude: OK, UTS/DFS disabled but seems not to be the culprit
MostAwesomeDude: Hm.
dileX: gallium-radeon does *not* work in non-kms, right?
EruditeHermit: nope
EruditeHermit: it does not work in non-kms
MostAwesomeDude: dileX: Are you not in KMS?
dileX: I have KMS enabled
dileX: but I have also a non-kms Xorg.log
spstarr: Batou: r6xx and KMS == dont work :)
spstarr: unless you dont lockup
dileX: (reason for reboot)
Batou: Depends on your definition of 'working'
Batou: It's less complete than the DRI1 path, sure... but it's up and running right now.
Batou: glxgears works fine, I have opengl compositing in kwin working and even Quake Live works. The 3d is better off than I expected.
Batou: It's the 2d that's bugging me now.
dileX: MostAwesomeDude: dmesg (trace)
dileX: MostAwesomeDude: I got a Call Trace I meant
dileX: (kernel is 2.6.31-git18 with drm-next on top)
MostAwesomeDude: dileX: Hm. I have no idea what causes that, but I'd wager it's related.
joosu: MostAwesomeDude: has someone tried i915 gallium drivers recently, i don't have any report besides drjakobs one 1year ago ?
MostAwesomeDude: joosu: Jakob keeps working on it regularly.
joosu: so MostAwesomeDude: is there a prototype that runs, maybe then console rendering could work out, needs lots code though:(?
hifi: could you believe this: when I activate output DVI-0 from my HTPC which is connected to our TV over a DVI->HDMI adapter, the DVB-T receiver in the TV dies
hifi: if I --auto VGA-0 and --off DVI-0 the receiver works again
joosu: hifi: is it possible to do hdmi to rca for old standart tv's?
hifi: no
hifi: HDMI is digital only
hifi: though if you have some kind of converter device, of course
joosu: hifi: yeah, only new lcd panels receive such input
joosu: hifi: hmm, ok, they are pretty annoyingly big i belive
hifi: what are?
joosu: converters
hifi: I don't know if they even exist
joosu: or adapters, signal converters or similar whatever
joosu: hifi: they should exist, if card doesn't have one then prolly adapter takes care of the signal converting, such a circuit
dileX: dmesg says: [drm:drm_mode_rmfb] *ERROR* mode invalid framebuffer id
soreau: dileX: That means the framebuffer id is invalid
soreau: xD
dileX: seems not to be in mesa code
soreau: Shot-in-the-dark: Might be in drm code
dileX: drm_mode_rmfb() is in the kernel
dileX: (not in libdrm)
soreau: and?
dileX: (investigation-mode)
nanonyme: spstarr: KMS+r6xx has worked for me but granted, I don't have newest drm-next commits, probably.
spstarr: oh
nanonyme: Actually currently running latest Linus' tree.
nanonyme: (or would be running if I was home)
nanonyme: (or latest since when I left home a day or so ago)
nanonyme: :p
nanonyme: spstarr: But yeah, assuming you've newest ddx from git and newest libdrm from git... Sounds unfun.
nanonyme: Which chip?
spstarr: FireGL rV635 i think
spstarr: lemme check
spstarr: its a FireGL 512MB RV63x
spstarr: FireGL V5600
spstarr: or 7600
spstarr: no 7600
spstarr: FireGL 7600
spstarr: im not sure ;p
spstarr: since my real R6xx is a mobile PCI-E card in desktop
josmala: Xorg -configure crashes I think the reason is that I have both radeon 4670 & 4350 installed how can I check if thatst the reason without opening the box?
mcgreg: maxbe try to disable one gfx card in bios?
mcgreg: *maybe
joosu: MostAwesomeDude: but you belive Dr_jakob tries to trigger glsl in to gallium drivers as well, that is expose it?
josmala: There's no bios option which does it.
joosu: guess i can't follow that and i belive can't reach to Mesa one also, 10days left it's unlikely that anything more beautiful then libsh can get ready, prolly needs a funding to tungsten to try poting them, would be sure i'd put 2000aud, 10 others also then theyd consider i belive
josmala: Have others had problems of getting multiple graphics card to work together with radeonhd drivers?
josmala: And by that mean, multiple different radeon cards driving separate displays.
nanonyme: spstarr: Yeah, unsure... Could possibly check bug tracker on the issue. Mine is rv670 but since there can be different behaviour across chips, that's no proof of that yours might've regressed...
nanonyme: joosu: You mean funding to VMWare? :) That's the owner nowadays, that is.
nanonyme: josmala: I don't think that's possible yet.
nanonyme: Simply having the cards in at the same time can cause trouble.
joosu: nanonyme: yeah sure, i'd be in the beach, since i've wasted lot, and i know and actually i knew that right away, that i get bullshit as longs as until the end of time, i'd go funding right away 12000AUD, just that laptops could save someones mind
airlied: MostAwesomeDude: http://people.freedesktop.org/~airlied/tmp/0001-r300g-rewrite-RS-state-setup.patch
airlied: MostAwesomeDude: I'm not sure what that memory_pos stuff was around, I suspect I need to change some FS stuff maybe
airlied: but RS packets needs to be packed afaik.
dileX: hi airlied, trying gallium-radeon. with latest mesa/xorg-server/drm-next I get error-messages. debug.txt: http://pastebin.ca/1581267 dmesg.txt: http://pastebin.ca/1581268 Xorg.log: http://pastebin.ca/1581269
dileX: might have a look?
joosu: nanonyme: if those open cards will go up to ogl 2.0/1 then they are preffered to me for instance over nvidia KMS and xorg video is and generally all xorg is allready ok
joosu: and i belive kernel is also ok, shader magic probably should be done in libgl only
joosu: nanonyme: but vmware i don't use at all, wine is in good shape, xephyr and xdmx i'd prefer
joosu: but chromium also needs shading language entry points, somewhat higer version come with anistrophic filtering and such don't need them too, buy glsl i guess would be needed, otherwise intel as first open source driver seemed to run
joosu: that i have tried
joosu: nanonyme: when should this video flickering happen that lot's talk about, like tearing, you know, i never saw that with Xv?
osiris: MostAwesomeDude: r300_emit_invariant_state is something like r300ResetHwState in classic mesa driver, right?
joosu: moved the video window how i liked with composite and without, i never saw that bug, and vblank wasn't on either
joosu: nanonyme: so those nouveau and radeon, other programs like full games etc. question wether they run mostly also, not only gears:)?
joosu: in open source
joosu: none really report the results, i know with intel they did, like warcraft and others:), try games, they show bit more
osiris: has anyone figured out already why the r300g is locking up on glxgears?
osiris: zhasha: does r300g have some debugging options for CS? I'd like to see what registers are written
zhasha: yeah, but nha changed it recently
osiris: so how do I use it?
osiris: some env var?
zhasha: osiris: I think this is it, in r300_cs.h, change VERY_VERBOSE_*
zhasha: it used to just output everything, so the change is a good thing :P
joosu: http://www.china-wholesale-supplier.com/netbook-nvidias-ion-platform-101inch-1024-x-600-resolution-screen-atom-230-frequency-of-16g-1gb-ram-geforce-9400m-160gb-hard-drive-wifi-3cell-battery-mini112_p12244.html only nvidia one, rest are intel mostly , couple of via's no radeons for netbooks
joosu: so some group of libgl hackers should take glsl on, else nvidia and via are prolly flying with 3.2 version of ogl allready
osiris: zhasha: hmm, I've changed it and enabled debugging with RADEON_DEBUG, but still no debug for CS
osiris: only VP and FP
zhasha: did you compile it with --enable-debug?
osiris: nope
zhasha: osiris: I'm pretty sure debugging is still disabled if the driver isn't compiled with --enable-debug
zhasha: fp/vp are always printed out AFAIK
osiris: ok, rebuilding now
osiris: zhasha: it works now. thanks
laska: josmala: this is known bug, i suppose. Secondary radeonhd uses a bios of primary card.
zhasha: osiris: you're very welcome. are you going to fix things now? :D
BCMM: i'm using the "radeon" driver. my card is totally silent at bootup, but the fan get unpleasently loud within 5 minutes
BCMM: i'm not using 3D accelleration; haven't even set it up yet
BCMM: is there anything I can do about this?
osiris: zhasha: I hope so. it would be great if the regs num where replaced with its human readable forms though
zhasha: osiris: working on it with rsim
zhasha: right now actually
osiris: zhasha: great. I could use it even if it doesn't work for every case
zhasha: right now rsim shows you roughly the same as r300g does
zhasha: except in a pretty treeview
BCMM: is it possible to underclock the gpu?
zhasha: osiris: you'll be happy to know that it's driver neutral :) so it'll work for your r300 mesa baby
osiris: that's great
osiris: so it parses raw CS?
biotube: BCMM: yes; there's a utility called rovclock that should be able to, but it never worked for me
zhasha: osiris: yeah, and it used a rulesng xml file to load the register info
zhasha: uses*
BCMM: and what about the way it's getting really loud without me loading it much? are there power-management features still to come, or did i just get a noisy card?
zhasha: BCMM: which card is it?
BCMM: it's a radeon hd 3870
zhasha: I don't think there are power management features for r600+ yet
zhasha: you might just want to use fglrx for now
BCMM: i'll find out if it gets quieter using fglrx
BCMM: it also might be a noisy card
BCMM: it's a pretty generic one, looks a bit like the reference design and has no logo
BCMM: i think perhaps dell made it
joosu: airlied: i am going to use my last 10 days also reading mesa code then, any special hw code isn't seen on i965, but i assume outside the drivers even if same structs are used theres no accel, but leaves impression that intel/ dri manages those and hw is always handled when brw_context.h is included
BCMM: luckily i got it cheap in ebay, so if i can't stand it i can probably sell it again without losing money
joosu: depends how long the include nesting has power, i'd belive forever, need to check from c tutorial
spreeuw: active coolers are a hack
joosu: how deep
joosu: c book not with me
BCMM: spreeuw: ?
zhasha: spreeuw: water cooling with special heat transferring fluid
BCMM: i wanted a passive heatsink, but they are kinda expensive, and this appeared on ebay
spreeuw: fair enough
zhasha: someone should make a netbook with powerful hardware and turn the entire casing into one giant heatsink
zhasha: would be awesome
spreeuw: most entry level cards with 2nd generation wafer production have just an aluminum cooler
BCMM: i also probably wanted something a bit less powerful than a 3870, but the reason it was cheap was that they were very vague about what exact card it was
spreeuw: the slightly fatsre ones have heatpipes
spreeuw: thats a bit more expensive to make yeah
spreeuw: but the first ones are ideal for linux box
spreeuw: since you're some years behind in technology then too
spreeuw: I think mine is a 3450
spreeuw: club3d with a normal aluminum profile cooler
spreeuw: it seems about 150 -200% performance of my older x700
spreeuw: may get better whne the drivers mature
zhasha: I hate how the open linux 3d drivers are so far behind, when most other drivers are pretty much perfect by now T_T
BCMM: well, they're pretty new
BCMM: and things are only getting better from here
spreeuw: yeah it looks more promising than ever now
zhasha: IMO, too much work going into classic mesa drivers, and too little going into g3d
adamk_: zhasha, Then you better start coding for g3d.
zhasha: I know, but I'm not as smart as MAD
zhasha: adamk_: the guys who are actually familiar with the cards would probably be a better choice :P
adamk_: Hmmm... Latest Mesa from git doesn't want to build here on FreeBSD: http://pastebin.com/m6bfef9c4
zhasha: adamk: it looks like
zhasha: adamk_: #include
adamk_: Well it's not included from glxhash, but even if I add the include, it fails.
zhasha: huh
nanonyme: suspects someone was ill-informed enough to have missed his point
nanonyme: (hint: joosu)
adamk_: Slightly different: http://pastebin.com/f419ad869
adamk_: the storage size of 'rd' seems to be problem, even after including stdint.h.
nanonyme: Hmm.
MostAwesomeDude: airlied: Hm, shouldn't be too much of a difference from what's already there.
MrCooper: MostAwesomeDude: actually the current problem I'm seeing with r300g gears is no longer lockups but a segfault in the draw module after a couple of seconds
MrCooper: we seem to be in kind of a whack-a-mole phase there :}
osiris: MrCooper: what gpu?
MrCooper: RV350
nanonyme: adamk_: Wonder if there's a bug in that specific macro.
osiris: MrCooper: ah :(
MrCooper: osiris: I take it your R(V)5xx is still locking up?
osiris: MrCooper: r300g is putting indices directly in CS and if there are too many indices we get segfault (at least that's what I'm seeing when running progs/trivial/vbo-drawelements)
MrCooper: yeah that sounds plausible
osiris: MrCooper: yes. I'm reviewing the CS right, and already found one possible cause
MostAwesomeDude: Hm. How many indices are we talking about?
osiris: 80k
MostAwesomeDude: Ooh, yeah, that might be going over CS size limits.
MrCooper: in theory we shouldn't need to use the draw module at all in 'normal' cases but just use the vertex/index buffers directly, right?
MostAwesomeDude: Feel free to fix the indexbuf code, BTW.
MostAwesomeDude: MrCooper: Yeah, we can. Haven't written it up yet.
MrCooper: someone'll get around to it eventually :)
osiris: MostAwesomeDude: where are the driver capabilities set?
MostAwesomeDude: osiris: r300_chipset and r300_screen.
nanonyme: adamk_: Actually. It's just sizeof(struct random_data) that fails, right?
adamk_: nanonyme, It complains about the storage size and that 'rd' is an usused variable.
nanonyme: adamk_: rd is initialized as struct random_data by a macro on the previous line.
nanonyme: As in, HASH_RANDOM_DECL declares struct random_data rd;, HASH_RANDOM_INIT does sizeof(rd);
adamk_: wishes that more Xorg/mesa developers used FreeBSD...
adamk_: I have a feeling FreeBSD will always be playing catch up.
nanonyme: (HASH_RANDOM_INIT is the line you got the first error with)
rnoland: adamk: i posted a patch for mesa...
nanonyme: Well, I could always set up a FreeBSD VM. ;)
nanonyme: (though I'm not a dev)
rnoland: ian broke it...
adamk_: Oh, heh...
adamk_: Let's take him out back and shoot him.
adamk_: rnoland, You don't have commit access to Mesa?
rnoland: adamk: i do... but i'm not sure that my patch doesn't leave OSX and solaris broken...
rnoland: so i was kinda leaving it up to brianp and ian to figure that out...
nanonyme: rnoland: Where's the patch, nye?
nanonyme: Btw even.
rnoland: nanonyme: sent to dri-devel
nanonyme: Hrm...
rnoland: also here... http://people.freebsd.org/~rnoland/0001-Fix-build-on-non-GLIBC-platforms-FreeBSD-at-least.patch
adamk_: Cool. Thanks. Looks like there was no conclusion on the mailing list.
rnoland: adamk: as far as i can tell... we didn't have the problem that ian was trying to fix...
rnoland: adamk: right... no "final" decision yet.
nanonyme: rnoland: At least the function calls you used seem to be plain POSIX...
rnoland: it may not be entirely thread safe, but we do seem to get properly random numbers both with the original setup and my changes...
rnoland: nanonyme: yes... i think it should work on OSX, less sure about solaris...
rnoland: my version should save global state, which it didn't before..
nanonyme: I'd say it's *highly* likely it at least compiles on Solaris.
rnoland: nanonyme: probably... but as usual intel has no issues with breaking everyone elses stuff....
nanonyme: That thread-safety which you mentioned is the only thing really that makes me wonder whether or not it would actually also work on Solaris.
nanonyme: Since it might be implementation-specific whether or not it works as expected if it's not guaranteed to.
rnoland: well, afaik, you only get into trouble if multiple threads are banging on random at once...
nanonyme: Yeah.
rnoland: but the test program from the original bug, just works on FreeBSD both before ian "fixed" it and with my patch...
osiris: MostAwesomeDude: there's a problem with mapping tgsi semantic inputs in r300_vs_tab_routes. we are getting two TGSI_SEMANTIC_POSITION inputs
nanonyme: doesn't really like the assumption much that everyone is using glibc *shrug*
osiris: MostAwesomeDude: how is this possible?
MostAwesomeDude: osiris: I'm not sure.
osiris: is it allowed in tgsi?
adamk_: rnoland, Well this is fascinating... Latest libdrm, -CURRENT (from last night), and Mesa from git as of this morning... glxgears gives me 0.999 fps. :-)
rnoland: sigh...
MostAwesomeDude: Shouldn't be.
nanonyme: adamk_: The glxgears fps code is botched to begin with.
rnoland: i haven't updated libdrm in a bit...
nanonyme: It's not portable.
nanonyme: Use gears.
adamk_: nanonyme, That botched, though? Besides, this seem to be the case with all GL apps :-)
adamk_: rnoland, Alright, so switch back to my previous libdrm?
rnoland: adamk: not sure...
nanonyme: adamk_: Iirc same happens if you disable the unportable code segment in glxgears. :)
rnoland: gimme a minute
rnoland: adamk: oh... wonder if you need the kernel bits...
rnoland: i should commit those...
osiris: MostAwesomeDude: why you are checking for r300->rs_state->enable_vte in r300_vs_tab_routes?
MostAwesomeDude: osiris: I'm sure I had a reason. :3 Lemme pull up that code.
nanonyme: adamk_: As in, what you said sounds like what I get on Linux on glxgears with #undef BENCHMARK
MostAwesomeDude: osiris: Hm. That looks very wrong.
MostAwesomeDude: I mean, it's guarding the SW TCL tab setup.
MostAwesomeDude: But VTE enable shouldn't have anything to do with that.
MostAwesomeDude: What happens if you remove that check?
osiris: one moment
nanonyme: adamk_: Actually the unportability claim in the source sounds odd to me since I can't find anything there that wouldn't be defined both by BSD *and* POSIX...
rnoland: adamk: ok, for whatever libdrm i have... i'm still getting 2k+ fps from glxgears
rnoland: but i have a few kernel updates from alex...
adamk_: rnoland, I tried libdrm from ports and have the same results.
rnoland: ok, it's probably kernel then...
osiris: MostAwesomeDude: yay, it works
osiris: i.e. no lockup
osiris: and vbo-drawarrays is working
rnoland: adamk: http://people.freebsd.org/~rnoland/drm-radeon-3dfix.patch
nanonyme: Nice combo patch.
MostAwesomeDude: osiris: Woot. If it looks like things generally are correct with that, then push it maybe.
nanonyme: Have I been looking at commits too long if I remember what that consists of? :)
nanonyme: (at least most of them)
rnoland: hehe, yeah it is a diff of my last 4 commits...
adamk_: rnoland, Thanks... I'll get back to you :-)
rnoland: i'll commit them individually, but it was easier to give adam 1 patch...
osiris: MostAwesomeDude: the driver is leaking very much
MostAwesomeDude: osiris: How so? Leaking memory?
nanonyme: Right, the one part I didn't recognize apparently was newer than that I've seen.
osiris: after about 2 seconds in glxgears ttm is starting swapping
MostAwesomeDude: osiris: Hm.
osiris: and after about 5 seconds the app crashes
nanonyme: Maybe valgrind could help?
nanonyme: (or hmm, maybe not for kernel memory usage)
osiris: hmm, it looks like it's not the userspace part that is leaking, because top don't show high mem usage for glxgears
osiris: MrCooper: didn't you push some patch plugging a leak in cs parser in radeon drm module recently?
zhasha: osiris: would vmem show up in top?
osiris: zhasha: yes, glxgears is eating all virtual memory
zhasha: osiris: I meant video memory
osiris: no idea
osiris: anyway glxgears is working until there's enough memory for it to run
osiris: valgrind isn't very helpful
MrCooper: osiris: yeah, but that was a while ago
MrCooper: you can see GEM object memory usage in /proc/dri/0/gem_objects
MrCooper: osiris: and that leak occurred on each CS ioctl call regardless of which userspace code did it
glisse: yeah i was the one to blame for that :)
osiris: MrCooper: already checked it. this bug doesn't affect me. will check the gem_objects file
nanonyme: Can't spot everything, I guess. :(
zhasha: osiris: do you want my app even though it just shows the CS as a tree?
zhasha: and doesn't translate any names
adamk_: rnoland, Roughly 800 fps now.
osiris: zhasha: will wait for the names
rnoland: adamk: on? cpu/gpu?
zhasha: kay, working on loading the XML
adamk_: RV620, dual core 3 gig xeon.
leth: do anyone know if there is support for the FireMV 2400 Card?
adamk_: The anholt timedemo in OA gives me 48.1 fps, which is just a few short of what I was getting on Linux with drm-next and the latest Mesa.
rnoland: adamk: ok... i'm rv730/c2d e7400 amd64
rnoland: we seem to be cpu bound in glxgears...
osiris: MrCooper: the number of BOs is increasing, looks like we don't dereference them
zhasha: it USED to work with no memory leaks
zhasha: who did this?! :P
osiris: so there are few possibilites of leaking bos: vertex buffers, color/z buffers, CS buffer
osiris: I bet it's the vertex buffers
zhasha: yeah, very likely
MostAwesomeDude: Might be OQBO, although I really doubt it.
MrCooper: osiris: but so it should recover after the process dies?
leth: or do anyone know if there is support for any 4 output card?
osiris: MrCooper: yes, it recovers
zhasha: does glxgears even do OQ?
zhasha: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_render.c?id=1df539ce87ab38ebae67d63a353b01f4cf5edc79#n226 <- is that ever freed?
MostAwesomeDude: What. Why is that not commented out.
MostAwesomeDude: Comment that out, seriously.
osiris: that's not the problem
osiris: MostAwesomeDude: how to free a buffer created with pipe_buffer_create?
zhasha: it used to be commented out
zhasha: pipe_buffer_reference(buf, NULL)
MostAwesomeDude: Pretty much. There might be an explicit pipe_buffer_destroy() but I don't think so.
zhasha: don't think there is. you just need to reduce the reference count to 0
osiris: ok, found the leak
zhasha: where is it?
mjr: /msg #nvidia oh no, I've been compromised!
MostAwesomeDude: ?
osiris: in r300_render_allocate_vertices
zhasha: how so?
zhasha: oh, no unref
osiris: yeap
MostAwesomeDude: Hm.
MostAwesomeDude: Yep, need to unref old before making new.
zhasha: You know, I was 99% sure that was where the error was, so I looked at it, then immediately dismissed it because it looked perfectly fine. I'm a terrible debugger
zhasha: why would glxgears need to reallocate it's vertices every frame?
osiris: because r300g doesn't support real vbos currently
zhasha: using draw?
osiris: yes
MostAwesomeDude: Hm. When I try to build either dri or egl, I get a wall of errors from extension_helper.h. Any clues?
MostAwesomeDude: remap_index stuff not being declared, etc.
zhasha: MostAwesomeDude: I propose we switch fully to scons
zhasha: and replace softpipe with llvmpipe when available
MostAwesomeDude: zhasha: Agreed on the first part, but not the second.
MostAwesomeDude: Softpipe's there as a safe fallback.
MostAwesomeDude: Maybe if/when we revive failover, we'll use llvmpipe.
zhasha: MostAwesomeDude: I meant that if you specify that llvmpipe should be built as in drivers=llvmpipe,r300,etc. radeon should default to llvmpipe for software rendering
MostAwesomeDude: zhasha: Hm.
zhasha: so if you want to use softpipe, just don't give it llvmpipe
MostAwesomeDude: If you can write the make rules...
zhasha: I used to have a patch for that
zhasha: but there were numerous compile problems with the shader compiler
zhasha: as in, r300compiler wouldn't build with scons
MostAwesomeDude: Dammit, it should be seeing my glapi/dispatch.h...
zhasha: MostAwesomeDude: what be ye fixing now?
MostAwesomeDude: zhasha: Trying to get things to build.
rnoland: adamk: since it seems to be cpu bound... it could be the difference in the scheduler fairness...
adamk_: Yeah, I might do some more tests when I'm done portupgrade'ing a few items.
adamk_: In the mean time, openarena is quite playable.
opaq: hi everyone. I'm trying to get the bleeding egde stuff running, build libdrm+ddx+mesa and a kms-enabled kernel. When i start with that kernel drm cannot load the firmware, though it's there (it seems to me).
biotube: did you do a make firmware_install?
opaq: erm, not explicitly, make install is not enough?
biotube: nope
biotube: IIRC, you also have to use modules_install to get those
opaq: where should i call firmware_install, inside the kernel?
biotube: from the build directory, as an argument to make
opaq: k
opaq: , maybe i was missing that part because i used debian-stuff for the kernel build
biotube: ah
biotube: I've no idea how to work that
opaq: kernel-package and make-kpkg
agd5f: airlied: I think the blinking problems are watermark related. probably need to double check that code
dileX: re
nanonyme: agd5f: I was just able to possibly gather more information on the Xv bug I'm experiencing: lower-right section of the Xv window stays consistently correct when dragging another window over it.
nanonyme: Irregardless of how I move it over it. Rest blacks out.
nanonyme: Also some EXA corruption when having Xv window on top and scrolling Firefox underneath.
nanonyme: I think the case with the corruption is when the section that normally should be drawn was previously under the Xv window.
nanonyme: Although I suspect it nowadays might just be slow rendering issue since it's momentary, before it stuck. :)
nanonyme: Oh, managed to get it stuck again. >.< False good news.
juergbi: i see a lot of glyph and other corruption using kms with 2.6.31-git17, radeon master from 6 days ago, and libdrm 2.4.14
juergbi: is this a known issue?
juergbi: i'll try with 2.6.31-git18 and today's radeon master later when i get around
dileX: which gpu
juergbi: sorry, forgot to mention, it's on a r600
juergbi: rv635
juergbi: and i'm using two monitors in case it matters
juergbi: redrawing of windows also appears to be quite a bit slower than without kms/dri, however, i guess that's expected for a while
nanonyme: agd5f: Found a more trivial way to replicate the bug: resizing an Xv window causes it too.
nanonyme: And now that I watch it more consistently: it seems Xv is not *clearing* the whole window but only part of it on resize.
nanonyme: It's leaving lower-right section as originally was, clearing the rest, then drawing resized video.
dileX: juergbi: have no r600. dave's drm-next has latest stuff, pull into linus-tree if you like. WIP, so 4 days is sometimes too old. ;-)
nanonyme: Anyone with r600 want to see if they can duplicate the issue?
juergbi: dileX: i might give drm-next a try
agd5f: nanonyme: what player?
nanonyme: mplayer
juergbi: nanonyme: i have r600 here, resizing xv appears to work fine or what exactly should i be looking out for?
agd5f: nanonyme: do anyt other players exhibit the issue?
zhasha: MostAwesomeDude: can you get r300compiler to build with scons?
nanonyme: agd5f: Appears VLC behaves quite dissimilar.
nanonyme: So this could be a player bug?
nanonyme: VLC is a bit slower with scaling but does not have the same lower-right corner thing.
nanonyme: I wish my eyes had less latency. :)
nanonyme: I have no idea whether it's partial clear->redraw or full clear->redraw (buffer is not yet updated and has partially stuff from old frame)->redraw(full new frame)
agd5f: nanonyme: maybe mplayer does some colorkey painting stuff from the overlay days
nanonyme: That could cause what I see?
agd5f: it it's trying to paint the colorkey it could be fighting with Xv
nanonyme: I think that'd be a bug then. There's a separate -vo xv:ck for colorkey'ing.
nanonyme: -vo xv shouldn't use it.
nanonyme: Is there a way to find out if it does?
nanonyme: Ahm, hmm.
nanonyme: I might've been wrong... Trying out.
spreeuw: http://picasaweb.google.com/completeannihilation/Screenshots#5145975055863045906 such a gorgeous game ;p
nanonyme: Well, it happens even if I do -nocolorkey.
nanonyme: agd5f: Hey, more clues: it only happens if Xv is over a certain size.
nanonyme: And the leftover area is proportionally bigger the bigger Xv window is.
nanonyme: Erm, I suspect that's wrong. What I meant was leftover:window closes 1 as window size approaches full-screen.
nanonyme: And this does not happen with gl outputs.
nanonyme: [drm:drm_fb_helper_check_var] *ERROR* Requested width/height is greater than current fb object 1600x1200 > 1280x1024 # looks like a bug as well
nanonyme: (irrelated though)
nanonyme: I think the original video size is 640x480.
nanonyme: (though the other message is probably true though, it would need resize code in any case)
nanonyme: I'm pretty happy with the VT switching having become faster though. ^^
nanonyme: Oh. The resizing code shouldn't actually be required...
nanonyme: Something's just passing botched coordinates here.
nanonyme: Specifically var->xres and var->yres are *way* bigger than sensible.
nanonyme: Which means the struct fb_var_screeninfo *var fed to drm_fb_helper_check_var contains altogether silly values...
Honoome: hello — is there any way to avoid the corruption seen in http://www.phoronix.com/forums/showthread.php?t=18687 with compiz and non-KMS radeon git driver?
nanonyme: Why not just use KMS? ;)
Honoome: nanonyme: heh, I guess the answer to that would be "because it locked up the system about three hours later, and I'm told that's supposed to be" :P
nanonyme: *shrug*
nanonyme: Works for me.
nanonyme: Hrm...
nanonyme: suokko: What was the way to figure out the caller of a function again? I think I really would want to do it for drm_fb_helper_check_var... :)
Honoome: [although I have to say that I'm getting more lock-ups today.. not sure if it's fglrx or something since I see no panic message :(]
nanonyme: Was it __CALLER__ or what?
Honoome: guess I'll give it another shot to radeon with KMS enabled...
nanonyme: Honoome: Make sure you clean all remains of fglrx if you're using open drivers.
juergbi: Honoome: i see corruption with r600 and kms, so it might not even help
nanonyme: juergbi: Errr, I don't.
juergbi: lucky you ;)
Honoome: juergbi: I tried kms before non-kms, and it worked fine with no corruption
nanonyme: juergbi: Are you sure you're using Compiz in a direct context?
juergbi: it's without compiz
Honoome: guess it matters that it's on an hd4350 (for the lock-up)
nanonyme: You're getting Compiz-related corruption without Compiz? o.O
nanonyme: That sounds twisted. :)
juergbi: no, i get compiz-unrelated corruption without compiz ;)
juergbi: i mainly tested with metacity without compositing
nanonyme: Well, we're talking of Compiz-related corruption here.
juergbi: enabling compositing fixed most issues except that i had a hard system crash right after that
nanonyme: So yours isn't related.
Honoome: goes for a full rebuild for git for safety, then powercycle
nanonyme: And no, I haven't seen the font corruption under Compiz except with DRI1.
Honoome: oh by the way, is it right that I (still?) have to patch the kernel to remove a check for _DRM_DRIVER ?
nanonyme: ?
nanonyme: Never heard of that. What kind of a patch is this?
Honoome: nanonyme: http://pastebin.com/m77d1a6bb
Honoome: found on comments on a post from airlied (the first radeon kms build doc I think it was)
Honoome: X fails to start without
juergbi: X started here without that
nanonyme: Honoome: Works here.
Honoome: okay I'll try without that patch and report the exact error if it doesn't :)
nanonyme: Just checked.
Honoome: nanonyme: uh okay it works fine without the kernel change, maybe I did something wrong before, that's a good start ;)
Honoome: ah but it was without modeset
kaballas: hi guys
kaballas: i am interested in improving power consumption for the radeon driver
Honoome: with modeset the first problem I get is that console disappear; framebuffer gets outputted out of range for my monitor (DVI)
kaballas: at the moment I am getting ~35% more power usage on my laptop using radeon than using fglrx
kaballas: is there anybody already looking at this, that needs specific help, or am I on my own?
nanonyme: kaballas: The radeon next-gen PM functionality will be written on top of KMS in its due time. :)
kaballas: nanonyme, i am happy to get my hands dirty and have "in due time" maybe happen a bit faster?
nanonyme: Hmm. I recall someone was writing preliminary patches to adding some PM support, just don't remember who.
kaballas: does the discussion about PM happen on the xorg-driver-ati mailinglist?
Honoome: nanonyme: is there any way to change the mode for framebuffer?
nanonyme: Honoome: File a bug if defaults don't work. I think airlied coded in a video= param though for changing resolutions there.
nanonyme: Rule of thumb there is that it should work out of the box and you should only need to do anything special for tweaking it to your needs.
Honoome: okay so I'll file a bug (as soon as I find a way to get network back, the git kernel killed it :P)
kaballas: bloody hell, the stuff in radeon_pm.c is not pretty
yangman: kaballas: we're waiting on documentation on PM still. what's there right now is what was deemed safe after experimenting
kaballas: ok, I had a quick look at the documentation mirrord on the X wiki, and didn't see anything that screamed power management at me
nanonyme: can't find a radeon_pm.c in kernel sources
kaballas: no its in the xf86-video-ati sources
nanonyme: Oh, that's the old PM then.
nanonyme: The new PM won't be there.
kaballas: ah, does all the new stuff live in the kernel then?
nanonyme: Yups. PM walks hand-in-hand with KMS.
kaballas: so where exactly is the split between kernel and userspace with the new driver?
nanonyme: The isn't one. :p
nanonyme: There even.
nanonyme: All hardware functionality is in kernel.
biotube: so what's left in the server?
nanonyme: (or okay, I guess that's a split too)
kaballas: ok, so does X end up calling kernel code directly?
kaballas: or does the kernel still expose a device (/dev/dri) which interacts with X?
nanonyme: It ends up implementing video using kernel's userspace API's through ioctl's as far as I've understood.
adamk_: rnoland: BTW, any update on that problem allocating memory that disables DRI sometimes when the X server restarts?
rnoland: adamk: no... either bus_dma needs to get smart enough to alloc non-contig pages... or i need to retool and request a page at a time...
glisse: kaballas: kernel setup the hw and userland provide rendering cmd and setup configuration
kaballas: ok
kaballas: so is the information on http://wiki.x.org/wiki/radeonBuildHowTo accurate for obtaining the latest sources?
biotube: its working for me
rnoland: was really hoping the draw_prims bit would help framerate in vdrift...
rnoland: at one point i was getting 30+... now i'm getting 18
nanonyme: rnoland: Wasn't draw_prims disabled because of problems?
rnoland: nanonyme: fixed
nanonyme: Oh, neat.
rnoland: richard re-enabled it a while ago...
biotube: kaballas: however, mkinitramfs doesn't seem to pack the firmware, at least in Debian
nanonyme: rnoland: Apparently 46 minutes ago. ;)
nanonyme: Thanks.
rnoland: yep
nanonyme: I didn't even notice.
jcristau: biotube: hmm. afaik it should.
biotube: jcristau: when I built it in, it said it couldn't find the firmware
biotube: modprobed it after boot, and it found it
jcristau: when you built what in?
biotube: the radeon module
jcristau: when the radeon module is builtin it's a good idea to set CONFIG_FIRMWARE_IN_KERNEL as well, afaik
nanonyme: Sounds sane, yeah...
biotube: ....
biotube: PEBKAC
nanonyme: rnoland: Hmm. For me vdrift simply didn't start with latest Mesa...
nanonyme: http://pastebin.ca/1581708
nanonyme: Got latest drm-next too, I think.
Honoome: sigh, I'm definitely out of luck lately... I can choose to have either the video card working or the wireless card it seems :P
Zajec: HDMI audio ported to KMS! :)
MostAwesomeDude: You've done it?
MostAwesomeDude: Or somebody else did it?
Zajec: no, not me
Zajec: Christian did, of course :)
Zajec: original author for radeonhd ddx
Zajec: see dri-devel@ or radeonhd@
spreeuw: nice work
spreeuw: so you have audio hackers too now ;p
Zajec: going to test after hour or so
Zajec: :)
spreeuw: how is it hooked into alsa?
spreeuw: just pass through?
yangman: alsa has supported it for ages
spreeuw: ah ok
yangman: the part where video gets involved is mixing the audio packets into the video stream
spreeuw: all that lacked was the pipe intake so to speak?
spreeuw: oh is it mixed with the video?
spreeuw: for sync or so?
spreeuw: imagined it would just be a set of extra independant wires
yangman: nope
yangman: just a single data stream
yangman: well, there are several wires, but it's a single data stream
MostAwesomeDude: The trick, IIRC, was that you've gotta respect display bandwidth priority.
legume: Re-enabling draw_prims is causing problems for me using drm-next.
legume: with modeset=0 I have a big 3d memory leak
legume: with modeset=1 no leak, but openarena quits with [drm:r600_cs_packet_parse] *ERROR* Can not parse packet at 568 after CS end 568 !
nanonyme: legume: Same for me. :)
legume: nanonyme: both 0 and 1?
nanonyme: Didn't try with 0.
nanonyme: Considering it involves reset...
legume: nanonyme: I thought it was a bit quick :-)
nanonyme: 22:38 < nanonyme> http://pastebin.ca/1581708
airlied: osiris: you pushed those r300g fixes?
osiris: nope
osiris: I wanted to fix some more bugs before pushing
osiris: but I can push it now if you want
MostAwesomeDude: Hm, I think I may have finally built something usable.
MostAwesomeDude: airlied: Thanks for the fixes you pushed.
airlied: osiris: no hurry, just wanted to see what was going on :-)
airlied: MostAwesomeDude: I think I'll push the RS fixups my brain convinced me at 3am they were correct
osiris: airlied: do they fix the clear color problems?
airlied: osiris: probably not, I was hoping they'd fix multi texturing
MostAwesomeDude: airlied: They don't look terribly off. I'm not sure my stuff is wrong either though.
airlied: MostAwesomeDude: it is ;-)
airlied: memory_pos isn't at all correct
MostAwesomeDude: XP
MostAwesomeDude: Alright.
airlied: you seem to be trying to route from the VP memories in the RS
airlied: but the RS just gets two packets, one color, one texture
MostAwesomeDude: As long as we're not going back to that ugly clump of code in r300.
airlied: it doesn't directly access the VP memories
airlied: MostAwesomeDude: the ugly clump of code was working'
MostAwesomeDude: Hm. Alright.
airlied: and is well debugged
airlied: it reflects ugly hw
MostAwesomeDude: :T
MostAwesomeDude: Thinking of it as two packets, I can see how your code would fix multitex.
MostAwesomeDude: Anyway. EGL info works.
MostAwesomeDude: So I'm pleased.
MostAwesomeDude: Wonder if EGL gears works too.
airlied: I need to check the VS routing code as well
airlied: and actually figure out what is roken in multitex
MostAwesomeDude: Dang, EGL surfaces don't actually display.
soreau: How can I make a patch for the drm-next kernel with a change I made to it?
airlied: soreau: git commit, git format-patch HEAD~
nha: cool, work on r300g, thank you
nha: I haven't been able to look at that patch, I only got back a short while ago... this week will hopefully bring happiness
soreau: airlied: Thanks
soreau: nha: What kind of happiness is in store for the week upcoming? :)
airlied: nha: don't worry abuot the email I discovered how to dump the FPs
nha: oh ok
soreau: airlied: afaict you already fixed the tv-out issue I bisected, yes?
soreau: s/fixed/pushed the fix for
boghog: im like this [--] close to ordering a 5870
MostAwesomeDude: Holy shit.
MostAwesomeDude: glxgears locked up the card...
MostAwesomeDude: ...but then it unlocked.
boghog: its been too long since I had a shiny new GPU
nha: MostAwesomeDude: check dmesg, the kernel got good at GPU reset
MostAwesomeDude: AND X DIDN'T DIE!
airlied: soreau: should have
MostAwesomeDude: must buy glisse beer
MostAwesomeDude: nha: Yeah, it's there.
MostAwesomeDude: I'm just kind of floored.
soreau: airlied: Cool, thanks
nha: yeah, it's very cool :)
soreau: If I wanted to try r300g, could I just change radeon to modesetting or would I need a certain branch of some component(s)?
nha: soreau: first make sure KMS works with classic Mesa
nha: soreau: then you must enable building of the gallium components and all that
MostAwesomeDude: soreau: I would *not* recommend trying the xorg st right now.
nha: when did soreau say he wanted to try xorg st?
MostAwesomeDude: The modesetting DDX?
soreau: MostAwesomeDude: I was just curious if there was some other branch of something that was required or if it's already built in to everything
nha: ah okay, that statement could be read in different ways
soreau: nha: I already have dri2/kms as well as ums with all latest components. I was asking.. yea ;)
nha: I agree that xorg st on radeon is not a good idea right now
soreau: What is xorg 'st'?
MostAwesomeDude: xorg state tracker
soreau: ok
EruditeHermit: gallium is really broken right now
EruditeHermit: atleast for me, gears gives 3-4fps
EruditeHermit: and there is massive corruption
EruditeHermit: actually kms itself has corruption with png files for me
soreau: EruditeHermit: How so?
nha: EruditeHermit: R300 or R500?
EruditeHermit: r300
EruditeHermit: opening a png file in kms causes corruption
nha: EruditeHermit: yeah, I saw that too
soreau: Hmm.
EruditeHermit: nha, which one? the corruption or the gallium stuff?
osiris: airlied: the r300g doesn't compile anymore
soreau: EruditeHermit: Which program are you using to view the file?
nha: EruditeHermit: the utter brokenness of glxgears with r300g
osiris: airlied: rs_tex_count is undefined
EruditeHermit: soreau, eog
EruditeHermit: eye of gnome
EruditeHermit: its the default gnome image file viewer
MostAwesomeDude: On one hand, it was *not* broken when I stopped working on it a few months ago.
MostAwesomeDude: On the other hand, it was broken on a lot of non-gears things.
legume: reverting draw_prims doesn't fix the drm-next memory leak with modeset=0
airlied: osiris: oops r300 code
EruditeHermit: nha, yeah, the good thing is, it didn't hang the machine. It lagged the machine badly for 20 seconds or so after I killed it, but I was able to recover
nanonyme: legume: Does it fix that other bug though?
legume: nanonyme: Yes
soreau: EruditeHermit: I'm assuming the png corruption doesn't happen with gimp for instance?
osiris: airlied: I've pushed my fixes
EruditeHermit: soreau, I didn't test that
EruditeHermit: soreau, does it happen with eye of gnome for you?
soreau: EruditeHermit: I use a standalone X session with some xfce components. No gnome installed here and I don't really have the resources to build it here on gentoo
EruditeHermit: ok
nanonyme: legume: Maybe some regression testing in order then to get to the memory leak?
EruditeHermit: i'll test with gimp on next reboot
Zajec: i would export clocks values in KMS to some file... do you think i can use proc_create_data and some /proc/gpu/0/clocks for that? or something else? i mean KMS of course
Zajec: *would like to
airlied: Zajec: probably just use debugfs
biker_rat: Well, my x1900GT is now playing nexuiz perfectly on rawhide.
Zajec: airlied: but i don't want this to be just debug information
Zajec: airlied: would like to export this for normal end-user
airlied: Zajec: normal end users don't care about clocks
Zajec: airlied: ...?
Zajec: airlied: er, how did you get that idea?
airlied: I cannot think of one normal end user I know that would care what their gpu clocks area
nanonyme: airlied: Maybe they would care about some relative values though?
nanonyme: As in, minimum, maximum and in between. :)
airlied: /sys might be okay but no more /proc
airlied: nanonyme: dmesg then
Zajec: airlied: every one interested in power management care for that
Zajec: airlied: and i think every end-user using notebook cares about power management
airlied: Zajec: they don't, they care aboutt battery life
airlied: they don't care what their clocks are
airlied: they expect us to set the clocks to not screw them
airlied: hence why I'd expect debugfs until we find a real reason for it to be set in stone somewhere
nanonyme: They might want modes like performance, max saving, dynamic and so though. Like cpufreq has. ^^
airlied: nanonyme: they don't erally
Zajec: airlied: ok... so what about user that wants to tell GPU "i need maximum battery time"
boghog: i guess people that don't trust their systems powermanagement might be curious to know, but I guess those don't fall under 'normal end-user' :p
Zajec: airlied: that's real case, isn't it
Zajec: ?
airlied: Zajec: haven't we gone over this?
airlied: did you read any of mjg59s mails?
nanonyme: airlied: Hmm, how come?
legume: nanonyme: Yea I'll try a bit later, not that much has changed in drm-next.
Zajec: airlied: thought so...
Zajec: airlied: ok, maybe i shouldn't start this here
Zajec: k, i'll just re-read that topics
airlied: we don't want power states because invariably they result in crappy UIs
airlied: and no user ever uses them effectively
nanonyme: :p
airlied: like running the gpu at full power might save battery life if it gets the job done quicker
airlied: as long as you ramp it down again when its idle
nanonyme: That's a point.
airlied: if we are going to do testing interfaces, do them in sysfs
Zajec: airlied: interesting... didn't think about that
airlied: sorry debugfs
airlied: if we decide they should be used by GUIs we can refine them later
airlied: and bette rif UIs start using the ones in debugfs we can rip them out
osiris: yay, dinoshade is working on r300g with minor glitches
osiris: I just got glxgears running for more than 1 sec
airlied: osiris: lockup or out of memory?
osiris: no, it works now. before it worked only for about 1 sec and then corruption
MrCooper: MostAwesomeDude, zhasha: r300g shouldn't need any software rasterization for OpenGL, the state tracker should take care of it
airlied: llvmpipe might be handy for non-tcl cards vs impl maybe
zhasha: MrCooper: is that true for all state trackers?
MrCooper: basically yes
osiris: does anyone remember what was the fix for "radeon_cs_space_add_persistent_bo: Assertion `cs->bo_count < (32)' failed"?
airlied: doing bo checks properly
airlied: unless we add 32 vbos
MrCooper: airlied, osiris: btw it's great to see you guys picking up on r300g! :)
airlied: MrCooper: I said I'd try and fix one bug a week in it ;-)
MrCooper: you should be good for years to come already :)
airlied: yeah I built up a few weeks just in case
osiris: MrCooper: yeah, but when I realize we will have to recheck and fix the VP and RS setup my head aches
osiris: I've spent months hunting and fixing bugs in there for classic r300 driver, and it ain't easy job
airlied: osiris: yeah I'm hoping we can just "port" the code
airlied: I've pretty much copied the rs code now ;-)
osiris: airlied: I wonder whether it would be worth to write unit tests for this part of driver
airlied: better in piglit I suspect
airlied: if we'd put tests in piglit when we fixed r300 we'd know we hadn't regression by now ;)
MrCooper: FWIW the python state tracker might be useful for unit tests
MrCooper: there's a few already in src/gallium/state_trackers/python/tests/
MostAwesomeDude: pulls
osiris: airlied: setting up VP/RS incorrect ends up usually with GPU lockup, that's why I would prefer to do it without actually pushing the commands to GPU
MostAwesomeDude: I'm getting some remarkably strange corruption on e.g. dinoshade.
MostAwesomeDude: gears too.
osiris: MostAwesomeDude: the problem is with reusing the same bo for few draws. if we're out of memory in current bo for next vertex data, we allocate new one and that's somehow broken. as a workaround I allocate new bo for every rendering operation
MostAwesomeDude: osiris: Seems reasonable. I think then that the problem is that we're racing something.
hbbs: airlied, I just noticed something trying to watch a x264 720p movie, my CPU time increases on a couple of minutes to a point that I can't watch it (garbled images) and everything video related becomes slow, even SD content on others video players, firefox included. Is that a known bug?
airlied: sounds like the flushing issue in normal driver
MostAwesomeDude: Hm.r
MostAwesomeDude: I wish there were some saner way to organize "when to flush."
airlied: emitting CS with a DMA bo, but having vertex data already in the DMA bo for next CS
MostAwesomeDude: Maybe we need to attach BOs to CS objects and then rotate between CS?
airlied: we only need one CS
airlied: they don't hang around I saw some comment about that
airlied: where you missed the point
MostAwesomeDude: I seem to be doing a lot of point-missing these days, sorry. :C
MostAwesomeDude: I am going dull and soft, like an aging monitor.
airlied: I'd need a bit more time to look at winsys/r300 driver stuff,
airlied: hopefully someone else can look as I probably don't have that time soon.
MostAwesomeDude: I've looked at it a lot, but I'm not seeing it.
MostAwesomeDude: Probably doesn't help that I wrote most of this mess.
hbbs: The thing is I already watched this very same movie a couple of months ago without problems. I knew video performance decreased within a couple of days, but never so quickly like now.
MostAwesomeDude: :C
MostAwesomeDude: The more I look at this, the more convinced I am that the only good code is in r300_state.
MostAwesomeDude: Freakin' OQ still not behaving. Hangs indefinitely in radeon_bo_map waiting for the OQBO to become available.
legume: Testing some kernels I already had built it looks like drm-next 513bcb4655e68706594e45dfa1d4b181500110ba introduced a memory leak with modeset=0
airlied: legume: wierd it only adds two malloc and adds two frees
legume: airlied: I may need to test harder then, but I've got a kernel with head at 2f67c6e0220e5311bb14895d32852250b2d9652b with
boris64: legume: i think i see the same on my system with the latest drm from airlied when i run any 3d program (like kwin or glxgears). Something eat's up all my memory (about 10-20 Megs per second), which isn't visible by top or htop.
legume: airlied: adea4796cfb9b74d340f9e32ba523fb61305d0b7 reverted that leaks and another with 513... reverted aswell that doesn't
airlied: ah I see it
airlied: I should consolidate some of that code I suspect
legume: boris64: Yea that's what I see - doesn't show against the app or ever come back - SUnreclaim
joosu: oo, freedesktop has doxygen API on the net now http://dri.freedesktop.org/doxygen/gallium/i915__winsys_8h.html 27sept generated, up to date
Honoome: hmm little doubt: is drm-next supposed to apply over 2.6.31 _release_ or the current 2.6.31ish Linus master?
airlied: Honoome: it should pull mostly cleanly into either.
biotube: it merges just fine over 2.6.31.y
airlied: maybe some small conflicts
edt: airlied almost 2 day up using .31 + drm-next and friends from friday 19:30ish EDT, kms with kwin enabled, googleearh works ok, etrace ok, glxgears about 500fps, tuxkart is jerky (new for friday) with R600 (RS780). Thanks!
edt: s/etrace/extreme tux racer/
Honoome: okay then I definitely feel stupid :P
joosu: edt: one question, does google earth work with atmosphere on, prolly it does right, hmm..?
edt: let me check
joosu: cause i think i used radeon way back open source in 2007 also that one on
joosu: superior video driver was it
edt: joosu seems to be ok
edt: as it stands how r600 had behaved better than expected here. It gets about 20-30% the frame rate of the ati drivers. Probably sideport memory support would help a bit and using irqs in stead of busy waits would be nice too.
joosu: edt: ok need to figure out why that falls for intel some time, can't download, but then it can't be glsl shading, i doubt 2007 radeon open release had it, nor gallium wasn't there
joosu: not intel, i915
joosu: only
dileX: 2.6.32-rc1 released
EruditeHermit: now if only someone would package it for me
EruditeHermit: =)
joosu: EruditeHermit: grab it from one of the distros then
joosu: ubuntu mailine kernel ppa doesn't have it yet
joosu: since suse factory has a robot that makes daily builds , they surely have it
EruditeHermit: i'll wait till ubuntu kernel ppa builds it
adamk: The x2800 is an r600 family GPU, correct?
EruditeHermit: yes
EruditeHermit: except its not called x2800 is it?
EruditeHermit: HD2800 is r600
adamk: http://www.google.com/search?q=x2800+ati
adamk: There's a lot of hits for x2800 and ATI.
adamk: I'm not sure if there is a difference between x2800 and HD2800, which is why I asked here.
EruditeHermit: hrm
g-zu: adamk: as far as I know the only difference is the text
joosu: EruditeHermit: so what is the difference between those x starting models and hd, and those two channels , theres also #radeonhd?
EruditeHermit: adamk, yes its r600. I think they changed the name to HD on release
EruditeHermit: joosu, they changed the model names to use HD after they included the UVD block
g-zu: joosu: #radeonhd is for xf86-video-radeonhd driver while #radeon is for xf86-video-ati
EruditeHermit: UVD does HD video decoding
EruditeHermit: r600 has UVD1 r700 r800 have UVD2/UVD2.1
EruditeHermit: joosu, and about the channels, what g-zu said
g-zu: fat lot of good are those, since there's no documentation for using them
joosu: something above dvd reso? ok
EruditeHermit: 720p and 1080p
EruditeHermit: yeah
EruditeHermit: they are not used on Linux
EruditeHermit: yet
g-zu: joosu: if you have a < r500 card you can only use xf86-video-ati, otherwise you can use any of the drivers
EruditeHermit: radeonhd only covers radeon HD cards
EruditeHermit: radeon covers all radeon cards
EruditeHermit: they started with different philosophies regarding atom bios
EruditeHermit: but now both use atom bios
joosu: EruditeHermit: currently have intel, i haven't made a research wether radeon has some mobile integrated cards, dunno wether 945 supports hd decoding, need to search
EruditeHermit: 945 does not
EruditeHermit: joosu, do you have a netbook?
virtuald: what is radeonhd focusing on now? shadowfb?
xovan: any idea what would cause my system to only use a software rasterizer instead of direct rendering? I got my new kernel (2.6.31) and xorg set up for it just like all the wikis and man pages say.
EruditeHermit: xovan, pastebin /var/log/Xorg.0.log
rehabdoll: in my case it was screwed up perms in /dev
xovan: EruditeHermit: what do you need to know from it, I'm working from irssi right now.
EruditeHermit: xovan, its hard to say
yangman: virtuald: it's mostly stagnated since Novell made cut backs
joosu: EruditeHermit: yeah those i use, via, now nvidia, and intel are possible
yangman: virtuald: mostly misc fixes
virtuald: hm ok
xovan: wait a sec while I open gnome
joosu: EruditeHermit: eeepc quite good, some distros also built around it, at least is now when intel 2d driver has improved and mobo fixed
EruditeHermit: joosu, so you have an EEE PC?
joosu: yup
joosu: 1000H
EruditeHermit: joosu, do you mind doing a glxinfo and pastebinning the result?
joosu: but optimized builds work faster , allthough ubuntu and debian are very good
joosu: EruditeHermit: currently i accidentaly removed glx module, i'd need to download for arch, usbstick crash i had, but it's 1.4OGL + fbo that are needed for textures
joosu: without glsl over 1.5 is not allowed to advertise
joosu: and with dri2 texture_from_pixmap glx extension is in direct mode, not indirect
EruditeHermit: its a limitation of the card though
EruditeHermit: the intel driver has OGL 2.1 on newer cards
joosu: EruditeHermit: what, hd -- ah i hardly need anything sharper then dvd?
EruditeHermit: oh I mean it won't do OpenGL 2.1 ever
EruditeHermit: the card is the limiting factor
joosu: EruditeHermit: i don't think it is a limitation of the card, but who knows, i haven't red all the mesa
EruditeHermit: not the driver
joosu: EruditeHermit: 2009 april someone said that osx has it, but should be true, winxp drivers didn't have shading lang as well
EruditeHermit: OSX has it for 965
EruditeHermit: as does Linux
MostAwesomeDude: The plan, actually...
joosu: EruditeHermit: well then the guy was mistaken, he said 950, i can prolly find the thread, but yeah i didn't confirm it
MostAwesomeDude: ...is to have gl st advertise everything, and then use software fallbacks for things the card can't do.
MostAwesomeDude: Because apparently *no* hardware is actually fully OGL 2.0 compliant.
biotube: really?
biotube: anything in common left unimplemented?
EruditeHermit: MostAwesomeDude, only gallium will do that though right?
MostAwesomeDude: EruditeHermit: Yeah.
MostAwesomeDude: Unless the meta ops thingy becomes more popular.
MostAwesomeDude: But off the top of my head...
MostAwesomeDude: r300 doesn't have GLSL vertprogs, r500 doesn't have true NPOT textures.
joosu: MostAwesomeDude: what do you think are the features that aren't supported, dynamic flow - aka branching?
MostAwesomeDude: i915 doesn't have GLSL vertprogs. i965 doesn't have texture borders, if I understood idr right.
joosu: if elseif brk etc.
MostAwesomeDude: No HW supports NOISE in GLSL.
MostAwesomeDude: Or, rather, they all half-ass it in a very disappointing way.
joosu: what is it?
MostAwesomeDude: Similarly, no HW supports pixel-precision fragment derivatives.
joosu: glsl compiler has also three modes to emit the code
MostAwesomeDude: r500 and nv40+ only have derivs within each quad of pixels.
joosu: ok
MostAwesomeDude: NOISE is a random fragment with some certain properties. fglrx and nvidia just return constant 0.5 or 0 depending on the texture mode.
MostAwesomeDude: Not random at all.
MostAwesomeDude: AFAIK there's no hardware with HW accumulation buffers, although maybe some of the old-school SGI stuff has it.
joosu: glsl vertprog shoudn't be anything other then arb_vp maybe that's the one that falls with earth, could be also color transform shader for vertex data
joosu: prolly theres something wrong with vp and fp too still for i915
MostAwesomeDude: Ditto GL overlays. (ISTR some FGL cards have them...)
airlied: i915 doesn't have vertprogs.
airlied: its all done on the cpu, so GLSL vertprogs aren't that much harder
joosu: hmm, that's why verts are in i915_fragprog.c
joosu: and that's why it falls also
EruditeHermit: i'm waiting for ion netbooks
joosu: out allready, i gave you the link, selling in australia as well, but that shoudn't mean that intel shoudn't get some fixes
EruditeHermit: I wasn't able to see the links
EruditeHermit: the only one I am aware of is HP 311
joosu: via also has binary drivers that can do 3.0
joosu: ah that's 12"
joosu: i'm talking about 10"
joosu: those were available before allready 12 ones
EruditeHermit: which brands?
joosu: one company produces them, and some others all over the world sells them, the one i pasted mini II something 1.45kg
joosu: manufactures, mobos have been available also
joosu: http://www.china-wholesale-supplier.com/Netbook-Nvidia-s-ION-platform--10-1-inch-1024-X-600-resolution-screen--Atom-230--frequency-of-1-6G---1GB-RAM--GeForce-9400M--160GB-hard-drive--Wifi--3-cell-battery---mini112-_p12244.html
joosu: same one , but dealer is from china
joosu: eeepc equivalent
EruditeHermit: that is a weak Atom CPU
EruditeHermit: 133MHz FSB
EruditeHermit: hrm
joosu: i don't think eeepc has something stronger, it's generally quite week also, cpu drains batter lot
biotube: super socket 7?
EruditeHermit: dunno why it runs at 133 though its rated for 533
joosu: is a ATOM 230, Diamondville core, 45-nanometer manufacturing process, clocked at 1.6GHz, 533MHz FSB,
joosu: bios can change them probably i haven't done it
EruditeHermit: hmm
EruditeHermit: I am waiting for Dell to do ION
joosu: jsut an expensive vendor nothing else, iuck
EruditeHermit: keyboards are bigger
EruditeHermit: and screens are nicer
EruditeHermit: higher res is possible
biotube: and namebrands always get the nicest ones
biotube: though occasionally the factory just makes too much
joosu: i wodn't bury intel at all yet, 1. nvidia grabs the server much , some others are lot smoother, but good thing is they also prolly have oss driver but none tested, only those glxgears
joosu: generally resource hungry:) but prolly propr. drivers have a textured video possibilities etc. gallium has some hw video pages for noveau also
EruditeHermit: I wish AMD would enter the netbook market
EruditeHermit: spice things up
joosu: EruditeHermit: hmm i guess they don't have much for netbooks, i don't understand that big laptop thing, i either work at the table or read with a minimal netbook
joosu: EruditeHermit: intel corp. is lot bigger then nvidia, but they specialize to gpu, prolly amd now makes all, but lacks netbook gpu's
joosu: EruditeHermit: but via has them, never had such branc card, they manufacture also lot's of stuff mobos, chips everything, network cards , like intel
joosu: airlied: so you think to role a hw vertprog for intel isn't possible, you have done some radeon ones, maybe you have a know how, plus intel dri mm?
joosu: or lets say generally lot working code, multi-master , kms etc.:D
joosu: so that's what to target then before glsl, hw vertprog
joosu: MostAwesomeDude: i belive idr is certainly right, but earth is the only program i tried that borks and that's binary, there you could check with bugle the and then grep the logs to see the pipeline, ibelive there are some that can be stepped through as well
joosu: so vbo lightners/transforms fall probably that maks sence either way
joosu: MostAwesomeDude: http://chess.liverating.org/ nr4. that's probably guy who beat kasparov when was 13years old 1990:) norweigen
xovan: well I got dri working, for some reason running openbox through gdm instead of startx solves the problem
soreau: xovan: Can you pastebin the X log from the failed session?
xovan: doh. forgot to cp the log file
soreau: xovan: Sometimes it gets stored in a file with .old appended
xovan: let me check
xovan: http://pastebin.com/m2b9ac445
xovan: i think that should do it.
EruditeHermit: soreau, the png corruption happens with gimp as well
EruditeHermit: actually any image file
EruditeHermit: png, jpg tested
soreau: EruditeHermit: That's weird.. doesn't happen here from what I tested with gimp loading pngs
biotube: xovan: nothing looks wrong there; it's a good DRI1(non-KMS) initialization
xovan: yeah but its the wrong chipset. glxinfo detects it as r300 when my onboard chip is r400
xovan: so textures have come out weird
EruditeHermit: hmm
EruditeHermit: soreau, text corruption now
xovan: i think if I change the chipID i can get it working perfectly
biotube: but you said it detects it right when using gdm?
xovan: its wierd. When I use startx it detects it but doesn't use it.
xovan: when i use gdm it uses it
xovan: both times it doesn't detect completely right but right enough to play super tux 2
xovan: is there a chip id list somewhere?
biotube: it's compiled into the driver
soreau: xovan: The thing I see is (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.31.0
xovan: ok
soreau: idk why gdm would use different dri lib
xovan: brb gonna try something
EruditeHermit: hmm ext4 being weird
joosu: EruditeHermit: what it is ment for, while reiser can outperform it and restore deleted files and have driver in window also?
biotube: reiser always ate my filesystems whole
biotube: plus, it's the only FS I know of not able to host images of itsself
biotube: itself?
EruditeHermit: reiser killed someone
EruditeHermit: =p
airlied: ddueds topic
joosu: airlied: new circule, needs opengl , but that's ati grr, looks like vertex buffer is taken from tnl entirely for i915
joosu: circle, needs opengl reading again alot
airlied: i915 has no vertex hw, all sw rendered
DanaG: I'm curious... that new 5870 with 3-monitor support... does that mean 3 CRTCs? I wanna' see xrandr output from one of those.
airlied: yeah I think some of them have 6 crtcs
joosu: airlied: yeah what i remember reading those are fragments are texture and some special trans. and vp vertex, but some variations were also possibl.
joosu: those are/those
joosu: though vbo's prolly work itself there
DanaG: I hope the 3 will be assignable any way.
DanaG: Some cards have the DVI and HDMI physically tied together, so you can only use one or the other.
DanaG: Or maybe only IGPs do that.
airlied: thats no crtcs
airlied: thats just how the output hw works
joosu: airlied: but you think frag p works right for i915, i'd belive it should, but not tested myself?
DanaG: hmm, is there any way to tell, without going out and buying a dvi-to-vga adapter, whether the two outputs are tied together like that?
joosu: hmm, one head then, inspect the card with magnifying glass
MostAwesomeDude: joosu: It does.
MostAwesomeDude: Works fine.
DanaG: eeeeeevil: http://www.rage3d.com/reviews/video/sapphirehd4650/
DanaG: I'm also curious what you could do if you stuck a PCIe-based one alongside it.
joosu: MostAwesomeDude: yup, makes sence i915_program.c gives registers to frag program
luther333: hey guys I have a ATI Mobility 3650 card on my thinkpad (with 2.8ghz proc) and I get a ridiculous 145FPS on glxgears . I can't watch any video reallly...and I was wondering if you guys could help out..
xovan: ok changing my chip id didn't do anything
xovan: tried a bunch of them too
airlied: xovan: the reporting won't matte, r400 is r300 family really
xovan: ah
xovan: well 3d works sort of so I guess the real solution here is to open up my wallet and get a real card
hifi: luther333: what distribution
hifi: Mobility HD3650 is R6xx ish?
DanaG: RV635.
luther333: hifi: gentoo linux sir..
luther333: hifi: what does R6xx'ish means?
hifi: luther333: so... you have firmware installed and up-to-date mesa/kernel/xorg?
luther333: hifi: I *think* so . how do I confirm/check?
hifi: luther333: the chip name is RV635 as DanaG pointed out
hifi: tells us more than the marketing name
luther333: hifi: Im sorry I am not sure how to find the chip name..when I do glxgears I get "unknown chip id 0x9591, can't guess" don't know if thats what you need
airlied: thats old mesa then
airlied: if I had to guess
luther333: airlied: how can we confirm..?
hifi: luther333: thats ok, 3650 already told us it's RV635
hifi: luther333: who made you use gentoo when you don't know how to use it? :)
airlied: luther333: what version of mesa is it?
luther333: hifi: hehe first time linux user..a friend recommended that I install it and I spent the last 1.5 weeks setting it up but its far from done..
luther333: airlied: whats mesa ? :/
hifi: luther333: you were screwed, big time :p
yangman: default x86/amd64 profiles are running mesa-7.3
hifi: well ok, it *is* a nice from ground up experience
hifi: I suppose gentoo has masks for dev versions?
DanaG: It's like learning how to drive a car, by building a go-kart from scratch.
DanaG: Or something like thagt.
DanaG: that.
hifi: yeah, pretty much
joosu: MostAwesomeDude: prolly needs 1000line code or so in libgl and things start to look good, but that part is difficult, anholt dumped/decoded all the reigsters and made vbo work
luther333: so is it a bad idea?
hifi: luther333: depends on person
hifi: I did learn most of the inner workings trough gentoo
hifi: but I wouldn't even touch it with a long stick today
hifi: though todays processors are much faster for compiling
luther333: hifi: why wouldnt you touch it with a long stick?
luther333: I sort of like it so far...
luther333: hifi, airlied so do you think you guys could help me out getting this video card situation fixed...its one of the major problems I am facing right now..
yangman: luther333: you're going to have to run packages marked as testing
yangman: luther333: 3D accel for your card isn't in a released version of mesa yet, so I would suggest you just ignore that for now
yangman: luther333: otherwise, just unmask xf86-video-ati for your arch, and use the latest version. see http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3
luther333: yangman: wait, do you think full 3d accel will be available soon?
yangman: already mostly works. but none of it is in released versions yet
joosu: MostAwesomeDude: best is to cd around and open different shader*.* and slang files , and some client side tutorials and hex and c, those catalogues include all the slang types and ops and commands to try start calculating allocation for vertexes in hw
luther333: yangman: 3d accell basicalyy means that EVERYTHING works right for that particular graphics card? how long do you think till it will be released
yangman: luther333: it means you'll have hardware accelerated OpenGL. 2D is already accelerated
hifi: luther333: no, it doesn't mean everything works
hifi: just that most things work but probably at least slowly
joosu: luther333: what is accelerated 2d? i found vesa quite accelerated too for programs i needed?:)
joosu: airlied: but exa is actually still around, and the last working build i remember wasn't way back, there were some widget's only rolling as flipped, but for 3d desktop what i didn't try was direct mode textured compiz environment, with compiz exa was lot faster
airlied: joosu: not sure what info you are giving me that I don't know
airlied: also not sure why you are nick highlitinh randominhlu
luther333: joosu: my video sucks right now ...
luther333: hifi: when would EVERYTHING in regards to video card will work? is this even possible
joosu: i don't know that too, how exa would had worked if fbos would had been triggered from direct mode, they worked in direct mode allready with exa, so basically could be tried if exa in direct composite could match uxa, and if so fix that backbuffer matching
joosu: luther333: Xv, worked 2006-2007 always reliably with r300?
joosu: was xaa back then though i belive
luther333: joosu: you just confused me by 3 orders of magnitude
joosu: but yeah that's the only accel that isn't needed anymore, cause that one didn't connect to fbos
airlied: he was getting confusing again
luther333: joosu: I just want to have a well performing desktop and able to watch videos with absolutely no problems and hopefully run compiz and/or doomm3
soreau: he's been showing signs of confusion for days now
soreau: luther333: As I told you in #gentoo last night, you probably want to use ati-drivers for your card for right now
joss_: luther333: why, Xv doesnt need 3d that's true?
soreau: If you did want to test the latest radeon code, all the info you need is in the link in the topic here
soreau: joss_: you're not helping
luther333: soreau: yo! yea I am emerging everything right now asyrecommended
luther333: * yangman recommended..
soreau: luther333: Further, if you're using ati-drivers the channel to get support for them is #ati
luther333: soreau: ohh I see