BackLash|TheFly: -yawn-
spstarr: drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
spstarr: [ 2548.524584] [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16401
spstarr: [ 2548.524588] [drm:r600_cs_legacy] *ERROR* Failed to initialize parser !
spstarr: evil legacy DRI1 shit
airlied: spstarr: yet again your insight is totally usless
spstarr: well the old non-KMS route
airlied: its nearly the exact same code on r600
spstarr: so then why would we want any legacy code paths for r6xx+ (?)
airlied: its got some slight differences
airlied: but its not the reason for your problem
airlied: userspace shouldn't be submitting IBs that big, and the kernel is refusing to deal with them when it does
spstarr: something in second life is doing so?
airlied: mesa driver
spstarr: interesting
airlied: it should flush earlier at some point
spstarr: bug should I log?
airlied: probably I'm sure someone will track it down eventually
spstarr: i paste those sorts of things on here because people do look at the log :)
airlied: why do you follow-up with the dumb comments though ;-)
agd5f: spstarr: does disabling draw_prims fix it?
airlied: jeez getting cloning right is just for shit
agd5f: spstarr: comment out this line: vbo->draw_prims = r700DrawPrims; in r700_render.c
agd5f: airlied: yeah cloning sucks
airlied: not sure how to express, you can clone DAC on the DVI connector with VGA DAC, but not clone the same DAC on tv connector with VGA DAC
airlied: agd5f: you remember what the rn50s really wanted to do?
agd5f: airlied: most servers have two vga port of vga and dvi and they want them cloned always
airlied: and most likely they don't have TV bits to hurt me I suppose
agd5f: s/of/or/
agd5f: I put a hack in the ddx to forcibly assign the same crtc to all connected outputs on rn50
airlied: so I'm guessing we won't get TV1_SUPPORT on an rn50 ever anyways
agd5f: since the randr core code seemed to fail to set cloned properly most of the time
agd5f: not likely, but it is possible
pepee: bye
airlied: yeah I don't think my code that picks initial state works at all
agd5f: and in most cases the monitor connected to the rn50 never has an edid
airlied: I suppose I could hack the driver to pretend I have only one crtc
luther333: soreau: hey if your not buys I have a non-radeon non-fglrx (but gentoo related) question for you...if you are up for it.
luther333: *busy
agd5f: could probably just special case rn50 as 10x7@60 on all outputs
agd5f: airlied: that's what I ended up doing
spstarr: agd5f: i'll have to grab mesa git from trunk, im using Oct 11th build packages
airlied: agd5f: hmm tempting
airlied: though if experience in RHEL has thought me anything, some idiot will deman 1280x1024 works
spstarr: agd5f: the fact the the DRI driver from Oct 11th allows me to use my card is a good sign things are progressing -fast-
spstarr: agd5f: I will now be testing mesa git master daily as i have packages coming each day now
spstarr: feels the AMD GPU warming under his palm
luther333: spstarr: whats your card?
spstarr: Mesa DRI R600 (RV635 9591) 20090101 TCL
agd5f: I ended up faking one crtc to test it, not the 10x7, but...
spstarr: ATI Technologies Inc Mobility Radeon HD 3650
spstarr: 512MB vram
amarks: spstarr: why pull daily? if there is a bug of interest, sure, if not, why bother
agd5f: airlied: could only set clones up for rn50
luther333: spstarr: thats your card???
spstarr: ya on laptop why?
spstarr: i have the desktop version on my quadcore
luther333: spstarr: HOLY CRAP. Thats exactly the same card I have (thinkpad w500)
spstarr: same laptop as me :)
agd5f: since they are usually 1:1 encoder to connector
spstarr: I bought this in may
luther333: spstarr: nice dude
airlied: agd5f: for single crtc cards thats tempting alright
spstarr: hehe
spstarr: luther333: you will be able to use 3D more or less now on this card.. get to it! :)
luther333: spstarr: I want to exchage email add's in a bit ...so we will be in the same page
airlied: ponders low bw dual-crtc gpus ;-)
spstarr: luther333: im *always* on irc
spstarr: heh
luther333: spstarr: really? I thought I had no hope? and its not stable is it
spstarr: well KMS no, non-KMS, its working
spstarr: i haven't had a crash yet
luther333: spstarr: you in this channel? weird how you didn't catch me..Ive been stopping here and on #gentoo for weeks
spstarr: just severe warnings from kernel
spstarr: not gentoo
luther333: spstarr: which one are you using?
spstarr: i use Fedora and Buntu on laptop
agd5f: airlied: the board vendors should have just split the dac traces rather than using both dacs for the two vga ports
luther333: spstarr: I see. With 3d are there significant improvements when watching video etc. ?
amarks: spstarr: you chickened out and didn't go gentoo on the laptop?
airlied: agd5f: probably some resistant loading reasons for that
airlied: will mull it over some more tomorrow
airlied: I have only one rn50 locally and it has only one output
BackLash|TheFly: whos got 64bit linux and wine working?
BackLash|TheFly: working
BackLash|TheFly: working*
BackLash|TheFly: wow
spstarr: airlied: it seems that error happened when the SL client was dumping way too many textures to render at once
amarks: BackLash|TheFly: i've installed it, that's about it
amarks: (win64)
BackLash|TheFly: somethings messed up with my irc.. cutting words off i cant see that i typed all of it
BackLash|TheFly: brb
agd5f: spstarr: I suspect it's the vertex buffer in the draw prims code. I think the accounting there is a bit funky
spstarr: agd5f: I can test stuff as your making changes to the DRI code
spstarr: now that im in a snapshot environment
agd5f: spstarr: I'd suggest disabling the draw_prims code as I suggested
spstarr: making a note to disable that
BackLash|TheFly: amarks youve installed it? could you run a game in it? i am still having problems getting multilib support aparantly
spstarr: agd5f: I also note, I cannot enable VBOs
dileX: agd5f: thanks for "drm/radeon/kms: properly handle mode id with native mode changes"
spstarr: or things will fail with Second Life client throwing errors about vbos and memory
amarks: BackLash|TheFly: i'm on no-multilib, haven't had a chance to play with it yet
BackLash|TheFly: hmmm methinks it wont work :/
luther333: spstarr: do you have full functionality with your card?
spstarr: luther333: "functional" 3D
spstarr: but this GPU is feeling hot hot hot under my palm
luther333: spstarr: when do you reckon there will be stable drivers ?
BackLash|TheFly: linux? stable? 3d? huh?
BackLash|TheFly: 0_o
luther333: sigh
spstarr: luther333: the driver is not optimized yet, things are changing still
spstarr: luther333: it is usable i will say however
luther333: spstarr: yea..if you were to guesstimate a timeframe, how long do you think till full functionality ?
spstarr: luther333: you might want to ask agd5f, airlied and other amd/radeon developers that :)
spstarr: things have picked up pace in the last few months
luther333: agd5f: airlied :) wanna chime in ?
agd5f: luther333: when it's done
luther333: spstarr: got a few questions. a.) how do you like your machine so far , b.) what do you use it for primarily
BackLash|TheFly: well god damnit* didnt work
luther333: agd5f: hehe Im sure you are SICK and TIRED of people asking that question :)
spstarr: luther333: development, Second Life/3D stuff, document writing?
BackLash|TheFly: well my chipset supports pae... maybe i should consider the ease of 32bit
BackLash|TheFly: wants that 15% performance increase(respectively) but at what cost
luther333: spstarr: do you do C++ primarily?
spstarr: yep
luther333: cool.
luther333: spstarr: so I know who to ask in a few months if you have everything working :) Im too scared to mess with the git sources
spstarr: not dangerous :)
spstarr: you wont fry your GPU
luther333: lol with gentoo, I am afraid of even turning on my computer some times haha
amarks: you get console. everything else is a bonus :)
luther333: yea I agree
amarks: if you are afraid of gentoo why are you using it?
luther333: spstarr: btw, does your keyboard volume controls work fine ?
luther333: amarks: fear makes me respect it :)
taiu: agd5f: it does't seem that r600 trig functions take -PI..+PI as args like in doc, seems more like 0..1
amarks: git-sources isn't that bad
luther333: yea
spstarr: luther333: depends on which distro
amarks: if it doesn't work for you, revert
taiu: progs/tests/arbfptrig draws quite a few bands for -pi..pi range
agd5f: taiu: could be. I'll try and comfirm with the hw folks
agd5f: taiu: the r700 isa guide is more correct
agd5f: the r600 one had a lot of errors
leio: BackLash|TheFly: or you consider using multilib and keep yourself on-topic on here :)
BackLash|TheFly: ive been trying to use multilib it crashes EVERY time
leio: don't see any difference possible with it when not running 32bit apps.
luther333: spstarr: btw what are you getting on glxgears?
BackLash|TheFly: emerges multilib libdrm-9999 for example...
leio: luther333: irrelevant.
spstarr: the numbers mean nothing :)
leio: then again, you have the same hardware and can go compare your bus speeds or something ;p
luther333: thats what I meant..
BackLash|TheFly: Oh lookie imagine that http://www.pastebin.ca/1617353 failed
luther333: leio: well I was just curious because I am getting incredibly low scores etc...I figured I could compare with spstarr since we have the same machine
amarks: why is the glxgears number irrelevant?
BackLash|TheFly: glxgears isnt a proper 3d acceleration test.
amarks: what is it then
leio: BackLash|TheFly: no idea what you are doing and where are you getting some libdrm-9999 that you call multilib
BackLash|TheFly: leilo from the gentoo bugsite
BackLash|TheFly: its 32bit and 64bit in one ebuild which is necessary for me to run 32bit 3d accelerated wine apps
amarks: multilib is a system profile, not related to packages
leio: amarks: http://qa-rockstar.livejournal.com/7869.html http://wiki.cchtml.com/index.php/Glxgears_is_not_a_Benchmark
BackLash|TheFly: libdrm-9999.ebuild libdrm multi-lib ebuild
BackLash|TheFly: argue with gentoo bug site
BackLash|TheFly: plz
amarks: leio: thanks
amarks: BackLash|TheFly: libdrm-9999 runs perfectly fine on no-multilib
Pallokala: luther333: with gentoo using git-versions is really easy
amarks: luther333: yes, mpagano keeps the git-sources ebuilds current
luther333: Pallokala: yea, except I would rather wait a few months till the drivers improve
luther333: amarks: btw are there significant improvements with 3d support (IE: better video playback etc..?)
agd5f: luther333: most video uses Xv which is already implemented
amarks: my mplayer is set to use xv, is there any reason to make it gl?
amarks: xv works perfectly fine
Pallokala: for me, the git-drivers are an improvement ;)
agd5f: amarks: not really.
Pallokala: yup, xv + slow 3d works already, some displaycorruptions happen though
Pallokala: xv with textured video is quite good
luther333: amarks: XV doesnt work for me. x11 does
amarks: pardon my ignorance, what is xv anyway, software path?
Pallokala: http://en.wikipedia.org/wiki/X_video_extension
luther333: actually I take that back....all VIDEO is bad in my system, if I want to watch a movie/video without any lag/out-of-sync I have to CLOSE everything else (IE: browser, VM, documents) then MAYBE i could watch it full screen normally
agd5f: luther333: you need drm support for all accel on r6xx/r7xx
luther333: agd5f: yea.. :/ I don't have drm atm.
agd5f: amarks: video scaling/csc accel api
amarks: agd5f: ack.
Pallokala: luther333: with the use x11 overlay (man layman) and git-drivers, xv works and the movies are fast (for me 5fps -> 25fps)
agd5f: luther333: Xv and 2D drm support for r6xx/r7xx has been in the kernel since 2.6.30
amarks: what causes video tearing? (i've seen it forever on my older T60 thinkpad X1300
agd5f: amarks: shouldn't see it with new enough ddx
luther333: agd5f: yea havent gotten to it yet :/
agd5f: amarks: scan out while rendering to the scanout buffer
amarks: 6.12.4 under 2.6.28, i think i still see it
Pallokala: video-drawing not synchronized with refresh
agd5f: the crtc sends the data to the monitor while the drawing engine is in the middle of writing to the same buffer
amarks: ok and you are saying tearing is 100% gone now?
agd5f: amarks: multiple monitors? if you have a cloned setup, you can only sync on one head at time
amarks: agd5f: the T60 is on a dock with ext DVI, so yes cloned right
agd5f: amarks: right, so you will only get tear-free on one head
amarks: agd5f: can i configure which head to be tear free?
agd5f: lack of a presentation layer in X makes it harder to do any better right now
agd5f: amarks: switch the crtc assigned to each head with xrandr, or turn off the other output
amarks: agd5f: ok i'll try that later
amarks: agd5f: my only other gripe with the T60 ext DVI, i could NEVER get 1600x1200 working, it would refuse with my NEC 2080UX+
agd5f: amarks: what do you mean?
amarks: agd5f: 1600x1200 would always cause the monitor to have a heart attack - or i'd see green pixels like TV noise and the monitor would go black/flicker on and off i moved the mouse or clicked on a menu etc
amarks: agd5f: but i'm using the monitor now on 1600x1200 on my RV790 and it works perfectly so i know it's not the monitor
agd5f: amarks: I think the dock only supported monitors up to 1280x1024
amarks: agd5f: how lame
amarks: why?
agd5f: amarks: you could try git master and Option "DisplayPriority" "HIGH"
amarks: agd5f: isn't the dock just providing an electrical extension?
agd5f: amarks: that's how ibm designed it I guess. probably limited by the length of the traces or something
amarks: agd5f: :(
amarks: agd5f: displaypriority is for?
agd5f: amarks: sets the priority of the display controller in the memory controller to the max
amarks: agd5f: umm what does that mean?
amarks: agd5f: what does "max" give me?
agd5f: amarks: means the Memory controller will treat display requests as a priority over other clients like the 2d or 3d engine
agd5f: the blinking and flickering you see is possibly underflow to the display controller
amarks: and green pixel noise?
agd5f: yeah
amarks: i see
agd5f: could be underflow or it could be a hw limitation
amarks: is underflow detectable in h/w, s/w? i.e. not by visual inspection etc
agd5f: you should be able to calculate it based on mem bandwidth, etc.
amarks: i
amarks: i'll have to go back to the thinkpad and touch the system, it's been a while since i updated anything
amarks: i was hoping i could wait until my company swaps it out for the next model
amarks: does the T400 use the same dock? i assume if it does, it would also suffer from the 1280x1024 limit
agd5f: amarks: not sure
amarks: i'll investigate
agd5f: I suspect it uses a different one
amarks: i'm annoyed by lame low res on docks
losh: Hi, are there any developers here who can comment on the state of the radeon driver for ATI 9100 IGP and dual head functionality. There's mention of an issue with the 9100 igp not having an internal TMDS. I have one of these cards and am trying to get dual head working with the radeon driver, but when both RGB and DVI are used, the moniters stay in power saving mode like there's no signal.
agd5f: losh: the external tmds on those chips doesn't work right now
losh: agd5f: there's a bug in the chipset?
agd5f: losh: no, just no one has written working support for them yet
amarks: agd5f: thanks for the insight btw
agd5f: amarks: np
losh: agd5f: I read that ati wasn't forth coming with the chip specifications. Has that changed? Is there an ETA for this support?
agd5f: losh: the info is out there, just no one has had the the hw or time to sort it out
losh: agd5f: I'm not a developer but I do have the hardware, what would be the best way I could help?
nanonyme: agd5f: Regarding the Nexuiz xrandr 1.2 bug from yesterday: how is an application supposed to deal with that kind of stuff? Can it ask somehow what a driver supports and then try to use the best it itself supports or what?
nanonyme: (as in: hi, do you support this api->ok, i use that->try next api)
nanonyme: er, second -> should be |
BackLash|TheFly: hi nano
nanonyme: Hey.
agd5f: losh: someone needs to implement support for the hw i2c engine IIRC
nanonyme: Trying to figure out how things should work in an ideal world and what I should report as a bug so we would close in on that.
agd5f: nanonyme: use randr for changing the mode rather XvidMode or whatever it currently uses
BackLash|TheFly: nanonyme: like an intel related bug for instance -.-
losh: agd5f: OK, thanks for the information. It looks like I'll have to give up on the idea of dual head at this stage.
nanonyme: Backlash: Currently seems it's not a bug.
nanonyme: Rather a matter of i486 being the oldest supported CPU arch.
BackLash|TheFly: what no love for the 286?
BackLash|TheFly: lol
nanonyme: Well, this *was* about Intel GPU's...
dileX: MostAwesomeDude: compiling...
BackLash|TheFly: mm
nanonyme: Rule goes: if compiling libdrm for i386 or older, use --disable-intel.
BackLash|TheFly: i dont know about all of that im having a cairo error now
BackLash|TheFly: alright i need to go to the store and stuff my face with crappy food
nanonyme: I think might make sense to poke Intel so that the compiling would be autodisabled on i386 or older though. Might do it if I have time.
nanonyme: It's imo the correct fix.
BackLash|TheFly: probably
BackLash|TheFly: who uses intel graphics anyway that needs 3d acceleration
Pallokala: nanonyme: interesting, how would you compile it to i286? I thought that linux + other compatible unix-like systems dislike 286
BackLash|TheFly: ;)
Pallokala: being 16bit and all
Pallokala: not having protected mode
Pallokala: etc.
nanonyme: Pallokala: Know of any Intel IGP's for such CPU's?
Pallokala: does plain VGA count?
nanonyme: Probably not.
Pallokala: :/
nanonyme: Only if it uses Intel display driver.
nanonyme: Plus, if Intel's stance is to kill off legacy support, they should at least do it so that they don't kill legacy support for everyone else.
nanonyme: Hence configure test for arch and only enabling Intel on i468 and up.
nanonyme: (or even disabling the compiling if the atomic test fails; that'd be trivial)
dileX: MostAwesomeDude: run_r300g-debug.sh X.stderr
leio: nanonyme: you are still able to make a modern system for i386? ;p
nanonyme: leio: Not a Linux one.
nanonyme: Otherwise yes.
chithead: even on linux, most things should still work. exceptions include squid, glibc and libdrm_intel :)
nanonyme: Besides, that's not the point. They're using configure tests wrong.
nanonyme: They should be failing configure instead of letting compile fail.
nanonyme: chithead: Hmm, yeah. Having a Linux without glibc is a bit tricky though, that's why I went for non-Linux (since it would probably have another libc too).
chithead: glibc-2.5 should work, as will uclibc
nanonyme: Does uclibc actually work with most of the userland?
nanonyme: Only used it for embedded solutions.
nanonyme: Hrm, #intel-gfx seems to be silent. Guess I'll just have to file a bug.
chithead: #intel-gfx people are probably asleep now
nanonyme: *sigh* I'll wait and get back to school then. Annoying to bump into timezones when you figure out the right solution. :p
nanonyme: (which of course is to fail on configure and tell *there* that the user has alternatives to disable Intel or specify i486 or newer arch)
nanonyme: ->
dileX: MostAwesomeDude: sorry (had 5 minutes as expiration in wgetpaste), here the new paste
dileX: MostAwesomeDude: kern.log Xorg.0.log
BackLash|TheFly: what mesa version do i need for x1950xtx?
BackLash|TheFly: r5xx
jcristau: r5xx was added in 7.2, i think
BackLash|TheFly: hmmm next question. emul-linux-x86-xlibs <-- does anyone know which version added the support
BackLash|TheFly: the version that is available stable is 20080810
chithead: this package is gentoo specific. I doubt any radeon developer can tell you this
reinoud2: adamk: nope, still haven't heared anything from the NetBSD drm maintainer....
BackLash|TheFly: chithead: Well do you know?
chithead: I don't know if any version of that includes mesa 7.2 or newer
BackLash|TheFly: time to hunt n peck then i guess
BackLash|TheFly: tried the newest rc's mmm its good to live on the edge
dileX: BackLash|TheFly: can you summarize and tell what was your initial question and what you are trying? its hard to follow you
BackLash|TheFly: i know im a bit of a nut :) remember last night i was getting a libgl error?
BackLash|TheFly: well its the 32bit libraries im missing
BackLash|TheFly: the multilib packages werent compiling so now im trying the absolute latest emul-linux-x86 libs
nanonyme: Do a 32bit chroot? :)
BackLash|TheFly: i think dark was working with me on that early this morning but i had been up all night and has to go to bed
BackLash|TheFly: had*
nanonyme: Should make your system Just Work when configured properly.
BackLash|TheFly: would certainly be nice..
nanonyme: Since you get to use normal 32bit portage. \o/
honk: nanonyme: errh.. multilib works just fine, too :}
BackLash|TheFly: is that where you get the i686-pc-linux-gnu folder going?
dileX: BackLash|TheFly: yeah, I remember the libgl errmsg. but again: what is your target? what shall run or not? 32bit game in wine on 64bit-host with 32bit-emu-libs?
BackLash|TheFly: mm anything 32bit opengl
BackLash|TheFly: tried googleearth a min ago
nanonyme: honk: It does when the you get 32bit compat libs separately instead of them being lumped together. :)
dileX: on a 64bit host?
BackLash|TheFly: yeah im running 64bit
honk: nanonyme: it works just fine the way it is.
nanonyme: Then why doesn't it work for him? ;)
BackLash|TheFly: hey i might lock up and crash so ill brb in that event
BackLash|TheFly: drmRadeonCmdBuffer: -22
BackLash|TheFly: wtf does that mea
BackLash|TheFly: n
BackLash|TheFly: lol
nanonyme: Pretty much: error.
dileX: I am not a fan of mixing arches
BackLash|TheFly: hmmm well i didnt get the libgl error i had previously
nanonyme: Something went wrong with ioctl's
BackLash|TheFly: could be the fact im using REALLY new emu libs
BackLash|TheFly: they are rc's
honk:
nanonyme: Probably not.
BackLash|TheFly: no im running rc1
BackLash|TheFly: newest ;)
nanonyme: That was to Backlash.
honk: uhh, I'm not ;p
honk: and it works ;p
BackLash|TheFly: what version
BackLash|TheFly: 20080910? or whatever
nanonyme: rc1 of what?
honk: everything is on 20081109
BackLash|TheFly: doesnt support my card
BackLash|TheFly: 1109 might
BackLash|TheFly: ill give it a try
nanonyme: Kernel is part rc4 afaik.
honk: what do you mean? "doesnt support my card"?
nanonyme: Past even.
honk: nanonyme: he's talking about the emul thingies
nanonyme: Blah, right.
BackLash|TheFly: mesa 7.2
BackLash|TheFly: r500
nanonyme: *really* hopes you're not attempting KMS
honk: BackLash|TheFly: just saying.. googleearth works just fine even on my 4850
BackLash|TheFly: uh well then you wouldnt be having the same problem as me
nanonyme: But yeah, upgrade to Mesa 7.6. :)
BackLash|TheFly: and your emu libs are newer than stable and older than what i was just using
honk: BackLash|TheFly: ~ obviously
BackLash|TheFly: so im gonna try your ver
BackLash|TheFly: ;)
BackLash|TheFly: <-- likes to work in reverse :P
nanonyme: 7.2 is pretty much from stone-age. ^^
BackLash|TheFly: indeed
honk: 7.2? wtf
honk: how long has it been since your last world update? O.o
BackLash|TheFly: who
honk: ...
nanonyme: honk: The emul packages have classically lagged behind on Mesa a lot.
honk: nanonyme: I'm not quite sure he's talking about the emul libs there ;p
nanonyme: *shrug*
honk: how do you find out anyway?
BackLash|TheFly: i am lol
nanonyme: Find out what?
honk: the version of your 32bit mesa libraries that is
BackLash|TheFly: i just installed my mesa-foo is strong
honk: kk ;)
nanonyme: There's a page in Gentoo website that told.
nanonyme: Don't remember where.
nanonyme: Ah, heh.
nanonyme: "If you want working googleearth, try multilib overlay. For more info connect to #gentoo-multilib-overlay on freenode irc" I'm a bit out of date, it seems.
nanonyme: Premek Vohnout, Gentoo bug tracker. ^^
honk: I'm not using any multilib overlay and it works ;p
honk: how old is that post? ;p
nanonyme: 2009-08-14
BackLash|TheFly: well google earth is crap i dont really want it however its a native test i can use to see if my 32bit libs work
BackLash|TheFly: ;)
nanonyme: honk: As in, relatively new.
nanonyme: Newer than my information on Gentoo anyway.
honk: yeah.. weird :]
honk: blames stable for being outdated :)
BackLash|TheFly: i am half temped to pull a fresh reinstall
BackLash|TheFly: all the stables are WAY outdated
BackLash|TheFly: debian gentoo ubuntu
honk: well, go for ~ then :)
BackLash|TheFly: havnt tried fedora because their livecd sucks so bad i couldnt install
BackLash|TheFly: lol
nanonyme: honk: I hope this is out of date or the emul libs for graphics *suck*. :p http://www.gentoo.org/proj/en/base/amd64/emul/content.xml
honk: nanonyme: nah, seems to be correct
honk: but as I said: it works just fine
nanonyme: Newest there is 6.5.2-r1.
BackLash|TheFly: the last time i ran google earth wit those rc libs it was very promising tho the opening screen popped before i got that error and it was clean whereas it was all broken before
nanonyme: honk: Yeah, would be impossible to get 32bit OpenGL with KMS with those though.
nanonyme: Needs Mesa 7.6, I think.
honk: nanonyme: so what? mesa is on 7.5 in gentoo anyway unless you're using overlays
nanonyme: honk: 7.6, not 7.5.
nanonyme: 7.5 is too old.
honk: yeah, my point exactly
honk: if it's too old in 64bit, there's no point in providing newer emul libs
nanonyme: Hmm, point.
nanonyme: expects major rework in Gentoo deptrees when Mesa 7.6 gets in
honk: those rc emul libs BackLash|TheFly is talking about probably contain some more recent mesa libs :}
honk: hard to tell, really
nanonyme: BackLash|TheFly: Which emul libs are you using then, exactly?
BackLash|TheFly: hmmm none right now
honk: are you trying to use kms? :}
BackLash|TheFly: i just unmerged 20091004_rc1
honk: all of 'em? why? :}
BackLash|TheFly: -shrug-
BackLash|TheFly: im hip i like to be with it..lol
BackLash|TheFly: does my mesa version have any effect on these emu libs?
nanonyme: It might.
BackLash|TheFly: ie if i uninstalled mesa and just installed emu libs would it matter?
nanonyme: That is, if you have new Mesa, KMS and Gentoo normal emul libs, it definitely does.
nanonyme: Which is why determining what you *do* have is the key. ;)
BackLash|TheFly: mm i have a cigarette... does that count lol
BackLash|TheFly: i have mesa 7.5.1
nanonyme: As 64bit? Then it shouldn't matter.
nanonyme: Much anyway.
honk: 7.5.1 is latest stable *nod*
BackLash|TheFly: so the emu libs will act ENTIRELY independently of 64bit as far as 32bit progs are concerned
nanonyme: (unless there's some userspace-switched options that are supported in the 64bit Mesa and not the 32bit emul lib, then you'd be in trouble too)
BackLash|TheFly: im just making sure its my emu libs that need to be downgraded and not my 64bit libs that need upgraded
nanonyme: Since the card can only be in one state at any one time.
nanonyme: And if your 32bit Mesa and 64bit Mesa disagree on the state and for some reason are running at the same time, can get a bit messy.
BackLash|TheFly: such as a virtual desktop enviornment running in 32bit?
BackLash|TheFly: ie wine
nanonyme: Sure.
BackLash|TheFly: well thats no good..... is it at least based on focus?
nanonyme: (namely same kind of situations as what happened with early r600 Mesa + EXA where those two interfered with each other because Mesa didn't setup all states that EXA expected to be set)
BackLash|TheFly: :x
honk: BackLash|TheFly: could happen != will happen
nanonyme: True, that.
nanonyme: It's not guaranteed to bork.
nanonyme: It's not necessarily even likely.
honk:
honk: just dont run 2 3d apps at the same time
BackLash|TheFly: wishes he could run a 64bit on one core and a 32bit on the other
BackLash|TheFly: lol
honk: use virtualbox
BackLash|TheFly: ehh... wouldnt that be impossible to game on anyway?
nanonyme: Installing the same versions of 64bit and 32bit Mesa, libdrm and ddx works too. ;)
honk: no, it wouldnt
nanonyme: (oh, no ddx required)
nanonyme: My mistake.
nanonyme: Just Mesa and libdrm.
BackLash|TheFly: nanonyme, if you wanna walk me through a sure fire method feel free to direct :) -totally willing to learn and help others with the issue-
nanonyme: BackLash|TheFly: Hey, this proved to be enough of an untrivial problem that I moved to another distro instead of actually trying to solve it with packaging.
nanonyme: Bumped into it a few years ago.
honk: echo 'ACCEPT_KEYWORDS="~amd64"' >> /etc/make.conf
nanonyme: Wouldn't that simply just allow testing packages?
honk: emerge -e system; emerge -e world
honk: like I said: it works just fine ;p
honk: googleearth that is
nanonyme: *shrug* Well, I doubt emptytree world takes that many hours.
nanonyme: (at this point looking at CFLAGS and making sure arch is set would be a good call though; the problems with libdrm made it sound like it isn't)
nanonyme: Or rather march.
BackLash|TheFly: actually.... at some point i guess my march got unset
BackLash|TheFly: wtf.. DAMN YOU GENTOO
nanonyme: Well, definitely set it before running emptytree then.
BackLash|TheFly: wait so echo 'ACCEPT_KEYWORDS="~amd64"' >> /etc/make.conf \\ emerge -e system; emerge -e world will do what exactly?
nanonyme: Compiles first your toolchain, then every damn package.
BackLash|TheFly: for both 32 and 64?
nanonyme: Updating everything to testing.
BackLash|TheFly: will it give me both trees though or just 64
nanonyme: Normal 64bit portage.
BackLash|TheFly: how will that solve my 32bit lib issue
nanonyme: + the compat packages
nanonyme: BackLash|TheFly: It's pretty much the same as reinstalling except you keep your configs...
BackLash|TheFly: oy.... that could take a while
BackLash|TheFly: so im assuming i should re-mask those rc's in the compat tree first eh?
BackLash|TheFly: ok done... now do i need to unmask the 20081109 compats?
BackLash|TheFly: that ones @ you honk (did you unmask those compats before you ran that?
honk:
honk: did you unmask those compats before you ran that <-- no
BackLash|TheFly: ok cool so set march and im good to go
BackLash|TheFly: god i hope this works...
BackLash|TheFly: wants to shoot people soooo obad
BackLash|TheFly: ok ... running this insane command
BackLash|TheFly: and it failed
BackLash|TheFly: great
BackLash|TheFly: pastebinning...
BackLash|TheFly: http://www.pastebin.ca/1617609
BackLash|TheFly: #
BackLash|TheFly: [blocks B ] sys-fs/device-mapper ("sys-fs/device-mapper" is blocking sys-fs/udev-146-r1)
BackLash|TheFly: specifically
nanonyme: BackLash|TheFly: #gentoo, please. ;)
dileX: BackLash|TheFly: you are getting off-topic
BackLash|TheFly: ugh ok
mjt: can anyone tell me what to do with screen corruption (in kms mode)?
yxcv: Hi. I've a ati mobilty radeon x1400 and wanna use the radoenhd-driver. I got a xorg.conf with Xorg -configure . but it doesn't work. The error in the logfile: (EE) RADEONHD (0) : RHDCSStop: Command submission backend is not active!
chainsawbike: why radeonhd?
chainsawbike: afaik radeon and radeonhd support the same cards
chainsawbike: http://xorg.freedesktop.org/wiki/RadeonFeature
yxcv: with radeon, ive a very low performance and no compositing
glisse: yxcv: there is no acceleration difference btw radeon & radeonhd they share same code
yxcv: Do u know the reason for the perfomance-problems with normal radeon?
mjt: drm not enabled?
chainsawbike: pastebin xorg.log would be a good start :)
yxcv: i have no acsess to the logfile atm
mjt: in that case you're not supposed to setup/debug X
yxcv: ok ;) i ll come back later with the log file
yxcv: here it is: http://pastebin.org/44945
yxcv: now with working ati-driver
yxcv: but low performance and no compositing
adamk_: No direct rendering. Are you trying to use KMS?
mjt: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
mjt: [dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
mjt: that means kernel is compiled with kms but radeon_drv.so is without
adamk_: yxcv, I believe you need to update libdrm and xf86-video-ati in that order.
mjt: either turn kms off in kernel or turn it on in radeon_drv.so
yxcv: i think turn it on in radeon_dfv.so is the better way... were can i find this file?
adamk_: As I said, you need to update libdrm and then xf86-video-ati. :-)
mjt: see what adamk_ said
mjt: and see /topic
adamk_: libdrm needs to be built with the experimental radeon api, too.
adamk_: Once you do that, when you build xf86-video-ati it will be built with support for KMS.
yxcv: hmm i already have the actual version of libdrm, 2.4.13 so i don't know how to update it...
adamk_: Check the topic. It explains how to build the required components from git.
mjt: i tried 2.4.13 yesterday, that wasn't sufficient
mjt: installed 2.4.14, it was ok for the radeon driver but not for mesa
hifi: my god, for a second I thought you were talking about linux 2.4
mjt: (but works for latest (7.6) mesa release)
hoo-hah: what's the firmware mentioned in topic?
glisse: hoo-hah: gpu microcode
hoo-hah: oh, sounds like a kernel option?
glisse: yes
glisse: well files came from kernel
hoo-hah: CONFIG_MICROCODE_AMD is not set
hoo-hah: will this pose a problem?
hoo-hah: CONFIG_MICROCODE=m
hoo-hah: the INTEL one is set to Y
glisse: drm won't work if you don't have the microcode
glisse: it will fallback to software
hoo-hah: oh wait, I have an intel cpu/mobo
hoo-hah: (totally forgot my pc specs)
hoo-hah: I was assuming AMD for ATI
kuaera: As a follow-up to my [now ancient] corrupt KDE plasma issue on ATi Mobility 7500/M7: It only occurs when there is no compositing manager. When I switched from Openbox to Kwin, the corruption disappeared.
Pallokala: "drm/radeon/kms: Fix AGP support for R600/RV770 family (v2)
Pallokala: "+ this should fix most of AGP problems or just some?
Pallokala: in 2.6.32-rc4
Pallokala: wonderful work
Pallokala: will try now
wirechief_: cant find build-dep for karmic :(
wirechief_: this is not working with karmic beta http://wiki.x.org/wiki/radeonBuildHowTo#head-b3d62d97855c1d275bc24b44268da568fb24a847
wirechief_: http://pastebin.com/f79abed4f << this is the results of my efforts
wirechief_: i guess this will have to wait or maybe i will install jaunty 9.04 and see if it works
adamk_: You really either need to do all git commands as your user, or all as root. You are doing some as root, some as user, some with sudo.
adamk_: And, to make matters worse, your apt cache seems to be out of date, or the Ubuntu repos are broken.
wirechief_: i got broken links to the repos on build-dep
wirechief_: i thought i did everything as root or sudo
wirechief_: this failed; :/home/wirechief/xf86-video-ati# apt-get -f install build-dep xserver-xorg-video-ati
wirechief_: E: Couldn't find package build-dep
wirechief_: i admit that there were attempts where i forgot to use sudo but i re did it and it went forward.
wirechief_: i was thinking maybe build-dep could possibly be ignored and i went to the next step with the script but it failed with
wirechief_: /home/wirechief/xf86-video-ati# ./autogen.sh --prefix=/opt/xorg && make && sudo make install
wirechief_: ./autogen.sh: 9: autoreconf: not found
Ghworg: wirechief_: Command is "apt-get -f build-dep xserver-xorg-video-ati", no install
wirechief_: argh
wirechief_: crapsky
wirechief_: your right.
wirechief_: well it resulted in the same though /home/wirechief/xf86-video-ati# apt-get -f install build-dep E: Couldn't find package build-dep
adamk_: Arghhh.
wirechief_: gonna make sure the apt-get update is done
adamk_: build-dep is not a package.
adamk_: build-dep is the commande.
adamk_: apt-get -f build-dep xserver-xorg-video-ati
wirechief_: ok, let me review the wiki
wirechief_: apt-get build-dep xserver-xorg-video-ati
wirechief_: hmm
wirechief_: i bet thats why i didnt have install
wirechief_: i just copied it (without verifying it was correct)
wirechief_: wait, is apt-get build-dep a command ?
adamk_: 'apt-get build-dep' tells apt-get to install the build dependencies for whatever package is listed.
wirechief_: rubbs sleep out of eyes
wirechief_: well now that i did it right, its working ;)
wirechief_: Now restart your xserver and have fun with new bug fixes :) <<
gsedej: btw. nexuiz is working perfectly on "medium"
agd5f: gsedej: you might try Option "DisplayPriority" "HIGH"
gsedej: agd5f: Have you played game? I'ts like, if you see object (table, barrel,...) directli, its ok, but at sertant angle it is black (no texture)
gsedej: and game is much slower FPS rate than nexuiz
agd5f: gsedej: I thought you meant the dispaly itself was flickering
gsedej: most of games are flickering with Compiz on
gsedej: (bug on nvidia proprietary too)
gsedej: agd5f: is there a way around, not to kill compiz while playing?
soreau: gsedej: KMS fixes the flickering
gsedej: yes... there is no KMS on ubuntu beta, so won't even on stable...
gsedej: btw, my friend x1400 has reduced FPS on 3D (glxgears, nexuiz...) when he enabled KMS (on Arch). Is this normall?
agd5f: gsedej: yes
gsedej: ok... I rather play without compiz than have like half FPS killed :D
agd5f: kms is currently optimized to reduce tearing
gsedej: agd5f: on the cost of GPU power (lower FPS rate)? Will this progress?
agd5f: gsedej: if you comment out line 308 (info->accel_state->vsync = TRUE;) of radeon_dri2.c it should perform much faster
gsedej: agd5f: btw.. in 2.6.31.11 I can (almost allways) normally switch to CLI (F1-F6), but with 2.6.31.13 there is no way (graphics totally broken)
agd5f: but you may get tearing
gsedej: agd5f: sorry, curently I have work with study and my new project, where I have problems
gsedej: agd5f: Its about mono, SDL and radeon. Full bug report: https://bugs.launchpad.net/ubuntu/+bug/450263
agd5f: gsedej: you might try the upstream drm stuff. see the topic. there have been a lot of drm fixes since 2.6.31
gsedej: agd5f: see the links in comment below
gsedej: agd5f: where? on forum?
agd5f: gsedej: the topic of this channel
agd5f: http://wiki.x.org/wiki/radeonBuildHowTo
gsedej: agd5f: thank you... I hope I will get time soon
gsedej: btw, is there a place, where can I report my bug? (on lauchpad)
gsedej: report to developers
agd5f: gsedej: https://bugs.freedesktop.org
gsedej: agd5f: I have no idea what to choose at "First, you must pick a product on which to enter a bug."
jcristau: gsedej: xorg.
agd5f: gsedej: mesa for 3D bugs
jcristau: or DRI, for drm stuff
gsedej: game (and framework) has no 3D yet, so I will just give xorg
gsedej: Is AMD/ATI paying for development of oder radeon drivers (non HD), or the progress is only because of opensource developers?
PuffTheMagic: can someone help me get kms working, i get a hardlock as soon as the module loads (builtin w/ radeon.modeset=1 and as a module with modset=1)
chithead: gsedej: amd and linux distributors employ some of the developers
glisse: gsedej: amd is paying 3/4 people on 3d/2d and Red Hat is paying 2 peoples
chithead: PuffTheMagic: how hard? kernel panic? magic sysrq/ping/ssh still works?
PuffTheMagic: chithead: hard, sysrq dont work
PuffTheMagic: have to hold the power switch to turn off/on
glisse: PuffTheMagic: which gpu ?
PuffTheMagic: r500
glisse: exact gpu name please
PuffTheMagic: m56
PuffTheMagic: x1600 mobility
PuffTheMagic: or is that m52
glisse: is it apple macbook pro ?
PuffTheMagic: no Acer
chithead: lspci will tell
tlp: PuffTheMagic: ah, you're in here too.
PuffTheMagic: chithead: M56P
glisse: PuffTheMagic: which kernel version ?
glisse: PuffTheMagic: does it works if you boot in init 3 and then do modprobe radeon modeset=1 ?
PuffTheMagic: right now .32-rc4 but it happened with every .31 and .32 i've tried and i think i twas even happening on .30
PuffTheMagic: i dont remember when it worked last
PuffTheMagic: its been a while
PuffTheMagic: glisse: no it hardlocks when i do that also
PuffTheMagic: tlp: you cant escape me im everywhere
chithead: do you have X86_PAT or other funky stuff enabled?
PuffTheMagic: yeah i beleieve I do that that enabled
PuffTheMagic: i can try with out it
PuffTheMagic: not a prob
PuffTheMagic: chithead: i take it you want me try no PAT?
glisse: no it should works fine with pat
chithead: I have seen ugly things happen with PAT, especially with 2.6.31 kernels
glisse: best is to open a bug attach lspci -nnxx, kernel config
PuffTheMagic: which bug tracker?
glisse: there was bug in pat in 2.6.31 but i think final version did have all the fixes
glisse: bugs.freedesktop.org
PuffTheMagic: k
chithead: 2.6.31 pat shipped with serious dataloss issues, which are supposedly fixed now
gsedej: chithead, glisse: so my RV350 is "offically" supported in linux?
PuffTheMagic: i will try no PAT after i finnish building a few things, i really dont care about mat
glisse: gsedej: have been a while since it's officially supported
nanonyme: gsedej: Define official. It's supported by Linus Torvald's kernel tree if that counts as official. :)
BackLash|TheFly: chithead, yeah i believe they fixed that in 2.6.31.2
nanonyme: But no, not official as in supported by AMD/ATi.
nanonyme: So whether it's more or less officially supported in Linux nowadays is debatable.
sannes: hm, anyone experience that the screen turns off after some time (standard feature) .. then later (couple of hours) when you get back you move the mouse the screens turns on and then off again? .. hm
gsedej: glisse, nanonyme: I just meant the open-source drivers. I mean, I will be able to use my RV350 GPU in the future too (like 2 years)? Proprietary are not supported by new kernels, right?
biotube: yes to the first
biotube: mach64 should still be usable
nanonyme: gsedej: Then the answer is yes, it is supported and will likely continue being so.
BackLash|TheFly: nanonyme, 29 packages left
nanonyme: As in, indefinitely.
glisse: gsedej: yeah in 2 year you should be able to use your gpu with lastest kernel
gsedej: nanonyme: thank you for answer :) Today I can even play advanced 3D games on Linux using RV350 :P
gsedej: nanonyme, glisse: what about performance? will go up? (now I have ubuntu 9.10beta mesa7.6, no KMS, radeon 2.6 (or something))
jmho: hi, are there debian sid packages for r600 3D available?
nanonyme: Performance is a bit hard to predict. You can expect improvement at least in the field of being able to run programs that demand higher versions of OpenGL eventually. (r3xx are new enough that they'll be getting a Gallium driver which means they'll eventually get OpenGL 2.x)
BackLash|TheFly: ooOOOoo
nanonyme: Stressing the word eventually. :)
BackLash|TheFly: thats ok it will probably take me that long to get opengl support
jcristau: agd5f: should i enable r600 in debian's mesa 7.6 package, or better wait for 7.7?
nanonyme: Are you packaging the DRM? :)
agd5f: jcristau: wait for 7.7
jcristau: nanonyme: well we'll get 2.6.32 eventually
jcristau: agd5f: ack, thanks
agd5f: jcristau: it works in 7.6 but there is that compiz text issue
nanonyme: chuckles at airlied's kitchen-sink-testing
BackLash|TheFly: as in everything AND the kitchen sink?
nanonyme: I don't know, I just like the name.
nanonyme: It's the name of one of the git branches.
BackLash|TheFly: lol
gsedej: nanonyme: Is my driver currently supported by openGL 2.0? (RV350 has pixel shader 2.0 support)
nanonyme: gsedej: Without KMS you have maximum of 1.4 and with KMS and newest Mesa 1.5.
nanonyme: Will still take time to get to 2.0.
kig: what's the status on glsl support on the open drivers? what's missing?
gsedej: not it's OpenGL 3.1 out :) btw Has 3.x any really useful advantage than 2.x ?
kig: 3.x is more dx-like? and deprecates the whole fixed pipeline
BackLash|TheFly: would love to see OpenGL creal dx ...
BackLash|TheFly: cream*
nanonyme: kig: nha would know where we are in regard to GLSL, he's doing much (or most?) of the compiler writing.
nanonyme: gsedej: Probably not. Mostly tons of 2.x extensions are part of 3.x.
gsedej: nanonyme: how come, that I can use opengl 2 option in nexuiz with RV350? Software randering?
kig: http://www.slideshare.net/Mark_Kilgard/opengl-32-and-more <- mark kilgard on opengl 3.2
nanonyme: gsedej: Either that or it's not checking if everything is supported. Latter would sound prone to crashing.
gsedej: ok :)
nanonyme: gsedej: OpenGL 3.x also won't ever be supported by older than r6xx as far as the radeon feature grid says.
glisse: we don't support glsl yet so no gl 2.0 support
gsedej: older than r6xx has no hardware opengl 3.x support, right?
nanonyme: glisse: Yeah, he just said the game runs. Might be failing on every single GLSL call or then that's software rasterizer.
agd5f: kig: glsl compiler needs work
agd5f: gsedej: righ only r6xx+ has hw support for GL 3.x
BackLash|TheFly: needs a new video card...
nanonyme: (theoretically failing calls might not mean it's unplayable if the game is tolerant enough)
agd5f: but we currently only support 1.4
agd5f: in the open driver
nanonyme: Which is less than older cards have. ;)
kig: it'd be nifty if all the open drivers eventually used the same (solid) glsl frontend. like the cpu-targeting programming languages do
agd5f: kig: the hard part is the GPU compiler
agd5f: you have to convert GLSL into the native shader language of the card and properly optimize for each chip's quirks, etc.
nanonyme: Hmm, aren't they partly in Gallium? As in, frontend means an intermediary form there, then drivers handle compiling from intermediary form to something the GPU understands.
kig: yeah, but the frontend can output an AST of the language and maybe fold constants and other simple things. the GPU-specific backends could pick up from there.
biotube: isn't TGSI used for that?
biotube: (although bitcode probably isn't the best way to do it)
kig: oh, looks like that
agd5f: kig: it's still a lot of work. especially for older chips like r300 with limited flow control
kig: yeah
nanonyme: biotube: That's exactly what I meant by intermediary form.
nanonyme: Hey, could anyone sort this mess of thoughts out for me?
nanonyme: If I want two monitors *not* to be part of the same desktop, will they have to have separately logged into X?
nanonyme: And if I have two monitors under the same login to X, can I do VT switch to just one of them and not both?
nanonyme: This is all assuming a system with KMS.
nanonyme: And if the second is possible, how is the input determined?
nanonyme: As in, which monitor owns mouse and keyboard at the point.
adamk_: It's certainly not possible at the present moment.
nanonyme: Having a single login to X would be preferrable since otherwise Gnome might end up being stupid and running the same process twice and end up with locking issues with files.
nanonyme: Or worse yet, race conditions.
BackLash|TheFly: Nope.... libgl error -sigh
ferret_: Yeah, that "libgl error" is really annoying
ferret_: so undescriptive
nanonyme: And also wondering whether it's fair to start asking airlied about these weird use scenarios when we're just about to get a working KMS. ;)
BackLash|TheFly: hey nano are you running 64 with 32 compat? and have working 32 accel?
ferret_: BackLash|TheFly: FWIW, If you're using gentoo, most of your relevant 32-bit libraries are provided by emul-linux-x86-xlibs or whatever it was called. And they are extremely outdated.
ferret_: looks in backlog... perhaps you know about this already
BackLash|TheFly: ferret_ yeah.. ive been battling it for 2 days not getting anywhere but a headach
adamk_: I have 32 bit acceleration working on Slackware64 13.0
adamk_: But I also have a 32 bit machine that I build things on :-)
ferret_: It works fine... it's just the version is extremely old
ferret_: Back in the dark ages the gentoo emul-linux-* libGL.so is from, the xpress 200m just immediately crashed because it tries to do TCL
BackLash|TheFly: yeah lol googleearth locks up my entire system
BackLash|TheFly: sad really
ferret_: exactly
nanonyme: Backlash: The trick is I don't.
BackLash|TheFly: you dont what
nanonyme: I run a 32bit Linux.
ferret_: BackLash|TheFly: It's this bug: http://bugs.gentoo.org/show_bug.cgi?id=242662
BackLash|TheFly: bah nano
adamk_: BackLash|TheFly: Install 32 bit gentoo inside of qemu :-)
adamk_: Or VirtualBox
ferret_: That's the most complex solution
ferret_: :P
BackLash|TheFly: lol
nanonyme: And unnecessary.
BackLash|TheFly: least complex solution is reinstall 32bit
nanonyme: No.
BackLash|TheFly: lol problem solved instantly.. but sad 65bit panda
nanonyme: chroot suffices.
BackLash|TheFly: 64*
nanonyme: The kernel can run 32bit code just fine.
ferret_: you can just install the multilib overlay
BackLash|TheFly: shake head
BackLash|TheFly: tried
nanonyme: It can't run 16bit though which is why I don't use it.
nanonyme: You need a 32bit kernel for that.
BackLash|TheFly: theres probably a really good reason but im gonna ask anyway.. why do you need 15bit
BackLash|TheFly: and why cant i hit 6 today
nanonyme: 16 bit games? :) (not that my current CPU couldn't run them in an emulator)
nanonyme: Running 16/32 bit Windows games over Wine is impossible without a 32bit kernel though.
adamk_: Well running 32 bit windows games over wine can work on amd64.
nanonyme: Only pure 32bit games work on a 64bit kernel.
adamk_: wine just has to be a 32 bit app.
adamk_: Ahhh..
BackLash|TheFly: i hope you mean 16 & 32 because 32 bit games run on wine with compat (or so it has been written)
adamk_: Sorry, I thought you mean 16 bit or 32 bit, not both :-)
BackLash|TheFly: bah i was too late
BackLash|TheFly: lol
nanonyme: Naw, those old good hybrid games.
BackLash|TheFly: there were a few.. i think risk was one
BackLash|TheFly: so i gonna try that chroot and see if it works for me
nanonyme: Well, call me a nostalgic but imo most good games were made during that era or before. ^^
BackLash|TheFly: there were MANY good games because graphics werent a factor so it was all about gameplay
ferret_: Huh?
ferret_: Do you know how long it takes to make decent looking sprites?
rah: yes but people didn't used to buy games because they had the most realistic looking sprites :)
rah: "Wow, have you seen the sprites in Space Demons 2? They're *amazing*!"
ferret_: yes they did
rah: did you?
ferret_: Remove your rose tinted spetacles for a while and recall that people haven't changed since then :P
ferret_: Sure. The graphics in the dizzy games on the C64 were brilliant
ferret_: They weren't the sole reason to buy the games, but the same applies today. It's no different
rah: mmm
BackLash|TheFly: hey the rose tinted glasses stay
BackLash|TheFly: -.-
osiris_: who wrote the new debug code for radeon?
osiris_: does anyone know how to make the new radeon's debug code print the cmdbufs?
nha: osiris_: insert radeon_cs_print in the appropriate place
nha: there's a, I believe, radeon_cs_emit function that sends of the CS
nha: search for that and add radeon_cs_print in front of it
nha: I'm considering taking the bait on Phoronix
osiris_: ok, I meant the emitted states not bare cmdbuf
nha: I have some doubts that people who are that scared of the lack of documentation will be able to contribute too much, but I'm prepared to let myself be positively surprised
nha: aha
nha: in r300g or in classic mesa?
osiris_: classic
nha: in r300g there's a VERY_VERBOSE_CMDBUF somewhere
nha: hmm
nha: there used to be a flag there, but it may have disappeared in the rewrite
nha: btw, what are you debugging?
osiris_: I'm trying to fix the wine d3d9 tests
nha: I see
osiris_: what's the Pauli Nieminen irc nick?
nha: suokko
glisse: it's easier to match my name with my nick ;)
nha: true
nha: I guess my nick is not entirely self-explanatory either, but at least it's derived from my real name
osiris_: nha: I gave a quick look at your glsl code, really cool stuff. I hope to play with it once I fix some bugs in classic mesa driver
nha: osiris_: Thanks, and I'd be happy to help increase the bus count of the driver ;)
Pallokala: anything I can do to get compiz working?
Pallokala: it gives: compiz (core) - Fatal: GLX_EXT_texture_from_pixmap is missing
Pallokala: RV630 + git everything
agd5f: Pallokala: run compiz in a indirect context
agd5f: LIBGL_ALWAYS_INDIRECT=1 compiz
adamk_: Most distributions have compiz-manager available, which will start compiz with the correct options, too.
Pallokala: agd5f: is it wise to put that as systemwide environment variable?
agd5f: Pallokala: not really. generally you want direct
agd5f: Pallokala: most compiz startup scripts handle that automatically
Pallokala: ok, thanks
osiris_: airlied, glisse: can you explain me why in check_vpu (r300_cmdbuf.c) the extra is 5 for kms?
nha: osiris_: see emit_vpu
nha: osiris_: that code is a horrible kludge to work with the differences in the drm commandbuffer emit interfaces
osiris_: nha: I don't get it. in check_vpu we add 5 only for kms, and in emit vpu we subtract 5 always
nha: only after using it for BEGIN_BATCH_NO_AUTOSTATE
nha: but you're right, that could is horribly bad
nha: you could move the +5 to the BEGIN_BATCH_NO_AUTOSTATE
osiris_: nha: so it's the BEGIN_BATCH_NO_AUTOSTATE is the macro that requires different values for kms/nonkms?
nha: yes, because non-kms has a special packet header to indicate VPU data, whereas KMS expects CS in the hardware format
tzaeru: mh, well, concluding in the end, that NWN is a bit unplayable due to the amount of performance issues.
nha: tzaeru: :/
nha: tzaeru: KMS? on which card?
tzaeru: zooming in and out drops the FPS down to 0.1, as do any screens with loads of stuff to render =[
tzaeru: nha, r9600
nha: okay
nha: hmm, I think I have a copy of NWN at my parents'
nha: long time...
nha: unfortunately, feature work on r300g is higher priority for me personally right now
nha: but it would be cool if somebody worked on such performance issues
nanonyme: nha: Hey. What's today's challenge in the compiler? ^^
nha: nanonyme: no compiler hacking today; depending on my mood, next thing will either be some more optimization work, or branching for vertex shaders
agd5f: tzaeru: comment out line 308 in radeon_dri2.c in the ddx
nha: or maybe some small cleanups, who knows
nanonyme: Ah, ok. :)
agd5f: info->accel_state->vsync = TRUE;
agd5f: that will prevent the ddx from vline stalling when doing dri2 copy region
BeteNoire: hi
BeteNoire: is there any known bug that makes switching to tty impossible? i get a white/gray shivering screen
tzaeru: agd5f, uh, okey, this is going to take a moment then, need to change off packet manager..
osiris_: nha: darn, looks like we don't call R300_STATECHANGE somewhere, because when I reemit full state after every flush the bug is gone
nha: hmm
nha: I recall some discussion on mesa3d-dev a while ago where Keith (?) posted patches removing some dirty state setting
nha: it's a long shot, but perhaps it's related, so if you feel like testing that...
nha: or maybe some bisect
nha: obviously depends on how old the bug is, because that was like last week or so
osiris_: nha: no, I've seen that bug since ever
nha: okay
nha: by the way, is there a piglit test for it?
osiris_: nha: nope
nha: *nudge* *nudge* ;)
nanonyme: giggles at nha
MostAwesomeDude: nha: Did you see any of that wall of text in #dri-devel from last night?
nha: MostAwesomeDude: uh, I don't think so
nha: what was it about?
MostAwesomeDude: Hm, lemme summarize.
MostAwesomeDude: Here's r300g currently on readPixSanity: http://paste.pocoo.org/show/144652/
MostAwesomeDude: It will die if you don't have GALLIUM_ABORT_ON_ASSERT=0
MostAwesomeDude: Fails are all of this form:
MostAwesomeDude: expected (0.513726, 0.992157, 0.305882, 1)
MostAwesomeDude: got (1, 1, 1, 1)
MostAwesomeDude: Correct alpha, bad RGB.
MostAwesomeDude: (And also alpha's getting replicated to RGB.)
tzaeru: agd5f, can seem only find radeon_dri.c
agd5f: tzaeru: not using kms?
agd5f: if not, then nevermind
nha: is it really alpha being replicated to rgb? could also be something throwing up its hands, saying "Fail to do anything, return 1.0 by default"
tzaeru: wait, huh, what's kms supposed to be and should one have it? :P
MostAwesomeDude: I picked a bad example, but yes.
MostAwesomeDude: expected (R, G, B, A) got (A, A, A, A)
nha: if this is a common pattern, it's gdb time
nha: and then slightly tedious tracking it down
MostAwesomeDude: Oh yeah.
nha: it helps to hack the glean source so that only a single failing test is run, then you get less static from irrelevant function calls
tzaeru: mh, oh, Spring is another game that suffers too much performance loss when there's a lot to render..
MostAwesomeDude: Also, I dug a bit more into the viewport scale bug, and found that it's definitely not our fault.
tzaeru: my CPU usage is always the highest even though the actual hardware is average.
MostAwesomeDude: The same assertions are tripped when they're put into the st instead.
MostAwesomeDude: Haven't found the cause yet.
glisse: MostAwesomeDude: what is this vp bug ?
MostAwesomeDude: glisse: st passes us a scale of 0.0 for viewport.
glisse: dumb question isn't their a pipe cap about scale/offset which leads gallium to sned you 0 if you didn't set this cap ?
MostAwesomeDude: Maybe. I was under the impression that it was illegal to have a scale of 0 in any direction.
glisse: i think it's legal, just stupid
nha: the interface apparently lacks documentation :)
MostAwesomeDude: I also experienced hardlocks way back when, when I first started writing the viewport setup.
MostAwesomeDude: So r300g asserts on zero scale.
MostAwesomeDude: But maybe we could experiment with hiding those away.
tzaeru: I wonder if logging out from KDE also restarts X..
tzaeru: hurr, should kms be used for maximum performance and features?
agd5f: tzaeru: if you aren't using mesa 7.6 or 7.7, you might try that
tzaeru: 7.6, so guess not
da1l6: hi
da1l6: Is it currently possible to use an amd chipset integrated gpu and a dedicated card and setup a multi-screen desktop using both chips?
gsedej: Hello! I commited patch about my RV350, OpenGL and mono framework: https://bugs.freedesktop.org/show_bug.cgi?id=24502
gsedej: I hope it's ok
nha: it's a bit unfortunate that there's just a link
nha: isn't launchpad supposed to have feature for better bug tracker linking?
gsedej: I can copy text
nha: nah, don't bother right now
gsedej: it's more ubuntu bug, sice in 9.10 isn't working at all, in 9.04 it has broken graphics... see the link
gsedej: nha: would you like to try the game?
gsedej: If it's working at you
nha: gsedej: no time right now, but my problem with the report is that I can't parse the backtraces
osiris_: nha, glisse: found the bug. the problem is in r300RunRenderPrimitive - we set R300_VAP_VF_MAX_VTX_INDX incorrectly somehow
nha: gsedej: I don't see a single backtrace that looks like it's crashing in our driver
nha: gsedej: it doesn't look like the SDL_Delay() is to blame, and if it were, it wouldn't be our bug
gsedej: nha: I could't track it... I do ubuntu-bug manually
gsedej: nha: 9.10 is beta, so it doesen't run at all. I meant the 9.04 version where it runs, but graphics is broken
nha: gsedej: since I don't know mono at all, I'd have to ask you to do your homework again, please; there are several statements in that bug report that say "I think the problem is this one:", and they all contradict each other
gsedej: how can I track this?
osiris_: I'm not sure in what situation it could be getting wrong values, but it does
nha: gsedej: so please, make up your mind
nha: osiris_: uh oh
nha: osiris_: do you know whether the value is too high or too low?
glisse: yesv/
osiris_: nha: surely it's too low
gsedej: nha: sorry I was bothering you. I don't have enough knowledge about bug tracking and idea about everything.
osiris_: nha: looks like it's off by one
osiris_: nha: but I'm not 100% sure, because the indices are {0, 1, 2, 2, 3, 0}
nha: gsedej: I think you should ask somebody who knows about Mono to help you identify what the problem really is, because to me I just don't see at all how even came up with the idea that it's related to our driver
nha: osiris_: so max_vtx_indx is only 2?
osiris_: no, it's 4
nha: but then it's not too low, is it?
osiris_: when I set it to 5 it's ok
osiris_: 4 is somehow too low
osiris_: strange
nha: wtf
gsedej: nha: on several nvidia cards same code at same framework works well, but on radeon it has problems, so I taught I can help you with this bug...
nha: osiris_: quoth the doc: If index to be fetched is larger than this value, the fetch indx is set to MAX_INDX
osiris_: yeah, and all indexes are lower than MAX_INDX so no clamping should occur
nha: gsedej: okay, but except for that it's just mysterious to me how it could be related to the radeon driver, because as I said the backtrace points nowhere near it; maybe I'm missing it, or you failed to copy it, or whatever; all I'm saying is: it may be our bug, but if it is, you'll need to find a clearer pointer to it
nha: osiris_: is there some register that allows one to add an offset to all indices
nha: ?
nha: even 4 should actually be more than enough... these is a very weird bug
gsedej: nha: ok, I will try...
gsedej: nha: thanks for help anyway
nha: gsedej: np
rnoland_: so, piglit linestipple seems to be fairly broken.
osiris_: nha: yeap, 208c. will check it
osiris_: nha: hmm this regiser doesn't exist on r300 :/
nha: now that's just swell
nha: maybe they forgot to add it to the docs?
nha: but then we're probably never writing to it, so it shouldn't matter anyway
osiris_: nha: yeah, it's never written
osiris_: hmm, there are two rendering operations. the second one is the failing one. but if I comment the first one, the second one is passing
osiris_: both render from the same indices, but from different vertex arrays
osiris_: it's not a problem in the wine test, nor in the mesa core because the tests passes with software rendering
osiris_: I really have no idea what's going on
tzaeru: mh, yay, TC:E and Tremulous work with good FPS, only problem is that mouse doesn't work in latter ^^
stikonas: has upgraded to XServer 1.7
nha: osiris_: does wine change a live VBO? in that case, there may be insufficient flushing?
nha: osiris_: as you said, a full state re-emit fixes things, so maybe you can do some divide and conquer approach to figure out *which* of the state re-emit is responsible for fixing the problem?
osiris_: nha: I've checked it and it was the vap_vf_max_vtx_indx state. because the states are always emitted at the end of cs, the vap_vf_max_vtx_indx statechange was overriding the OUTBATCH
nha: oh I see...
nha: this is a very weird bug :(
osiris_: yeah
osiris_: anyway there are only 34 failing tests (out of 3928)
nha: osiris_: we rock! ;)
nanonyme: Great going. :)
nanonyme: You're gonna need more tests soon. ;)
nanonyme: It's a sign that there's a problem in testing utility if driver passes all the tests. ^^
nanonyme: (as in, it doesn't test many enough things)
nha: well in fairness, the driver has become pretty decent :)
nanonyme: Well, I don't deny that. :)
nha: for compiler stress-testing, it would be cool to have a program that generates shaders randomly
nha: i.e. a fuzz testing kind of thing
nanonyme: nha: Mostly the generic "no software can be perfect; if a testing utility claims a software is perfect, testing utility is inperfect" claim. ^^
nha: might be interesting in general: generate a random sequence of semi-reasonble OpenGL calls and see what happens
nha: yeah, there's some truth to that ;)
airlied: osiris_: did you figure out the vtx indx emit? (/me watches for fixes in master ;-)
nanonyme: nha: Would probably have to figure out how to have people gather DRM errors automatically in regular use cases.
nanonyme: And Mesa errors.
osiris_: airlied: you mean the problem with R300_VAP_VF_MAX_VTX_INDX?
airlied: yup
airlied: just reading backlog.
osiris_: airlied: nope. I'm out of ideas.
nanonyme: Considering nothing's more effective in poking at driver bugs than throwing an armada of games and other programs that implement standards in a rough fashion. ^^
nanonyme: Throwing those at 'em even.
airlied: osiris_: its not getting flushed at the wrong moment? are you on kms?
osiris_: airlied: yes, it is kms
airlied: so the kernel prints the error about max vtx/
nanonyme: (at least after the "whose bug is this? doesn't look like mine" dance is done)
osiris_: airlied: no, it doesn't
nha: I am doing some reorganization and updating of Radeon-related Wiki content
spstarr: airlied: im pleased to now be using the AMD GPU on a regular basis now :)
spstarr: cheers
spstarr: w/o KMS though
airlied: osiris_: so what is the sympyom i missed what you were actually seeing
osiris_: airlied: it's the wine d3d9 test, it's failing
bryce: agd5f, mind taking a look at https://bugs.freedesktop.org/show_bug.cgi?id=24414 ? It's a regression on R100 with mesa 7.6, since mid-august
osiris_: airlied: if you want to reproduce it, compile current wine, then enter the wine/dlls/d3d9/tests and run 'wine ./d3d9_test.exe.so visual'. the failing test I'm talking about now is fog_test
agd5f: bryce: regression since mid august or regression is some older version of mesa?
agd5f: s/is/since/
bryce: agd5f, regression since a mid-august snapshot of git master
agd5f: bryce: ok
bryce: since commit 7c422387 on august 17
bryce: i.e. bug showed up after moving to 7.6 from that version, and goes away by downgrading back to that version
agd5f: bryce: any chance it could be bisected?
bryce: agd5f, hmm user is not a native english speaker and seems non-technical.
agd5f: bryce: ok. I'll take a look
osiris_: nha: nice work on the wiki. you want to encourage new developers?
nha: osiris_: that would be good, yes
osiris_: nha: hmm, maybe post a blog entry about it or ask Michael Larabel for a news
nha: osiris_: I'm on it :)
nha: MostAwesomeDude: your texture cleanup patch has something like (retval >= usage)
nha: something tells me that that's not what you really want if you're talking about bitfields
nha: at best it's confusing, but it might be wrong
nha: something like usage & ~retval may be more appropriate
MostAwesomeDude: nha: I wanted to prevent something like PIPE_TEXTURE_USAGE_RENDER_TARGET | PIPE_TEXTURE_USAGE_SAMPLER from matching something that's only a texture, not a renderbuffer.
MostAwesomeDude: Feel free to clarify it.
nha: It would be nicer if you did it yourself ;)
nha: Using >= in the context of bitfields is icky
MostAwesomeDude: nha: I'll fix it.
nha: R500 supports SM 3.0, right?
nha: I always get confused about Direct3D terminology
zhasha: nha: yes
zhasha: they support DX 9.0c which introduced SM 3.0
osiris_: airlied: does the bug #5353 still apply?
airlied: osiris_: not yet
sdsdsd: KMS doesnt works on mu computer. I have the .31 kernel with KMS enabled, grub enabling it, latest drivers, latest Mesa, and a RS690M card on Debian Squeeze. Anyone knows why it didnt work?
sdsdsd: if i use radeon.modeset=0 i can get hardware acceleration (700fps with low cpu use) and if i put radeon.modeset=1 i get 200fps with high cpu use.
osiris_: airlied: can you close it, then?
airlied: osiris_: when we finally enable extra VRAM we should close it
MostAwesomeDude: What's needed before we can use that non-BAR'd VRAM?
sdsdsd: i listen something about kms not compatible with IGP cards... can anyone help me?
sdsdsd: what i have to do if i want to try KMS?
MostAwesomeDude: sdsdsd: Sounds like you already got KMS working, you're just having problems getting 3D working on top of it.
sdsdsd: MostAwesomeDude how to fix it?
zhasha: sdsdsd: get a fedora 11 live CD (if you're on Radeon X1900 or below). if you have an HD2000 or better, try fedora 12
sdsdsd: i have last radeon driver and last mesa
zhasha: and latest libdrm?
sdsdsd: i think yes
zhasha: and latest kernel?
zhasha: well, latest kernel modules
sdsdsd: of course
sdsdsd: zhasha, change distro is just the easy way to solve problems
zhasha: sdsdsd: you said try, and I said LiveCD
sdsdsd: and get a lot of new ones
zhasha: that's the easy way to try it without killing your system
sdsdsd: :-)
sdsdsd: anyone knows what may be happening? I got the kms working but with 3D problems.
sdsdsd: igp card
MostAwesomeDude: sdsdsd: Could you pastebin the output of $ LIBGL_DEBUG=verbose glxinfo
sdsdsd: i must be on kms mode 1 (grub)
sdsdsd: or no?
MostAwesomeDude: Yes.
MostAwesomeDude: Pastebin the output of that command while KMS is enabled.
sdsdsd: OK, ill reboot
sdsdsd: http://pastebin.com/m40b8c24d
sdsdsd: MostAwesomeDude it is my output
MostAwesomeDude: sdsdsd: You need to rebuild Mesa with r300 enabled.
MostAwesomeDude: Or r200. Whichever chipset you had.
MostAwesomeDude: Yeah, r300.
sdsdsd: how to enable it?
sdsdsd: enabled kms and rebuilt?
MostAwesomeDude: You're on gentoo, right?
sdsdsd: no Debian
MostAwesomeDude: Oh.'
[Enrico]:
MostAwesomeDude: When you build mesa, you need to add --with-dri-drivers=r300,swrast to your configure line.
sdsdsd: ok, thanks
sdsdsd: like ./autogen.sh --prefix=/opt/xorg --with-dri-drivers=radeon,r200,r300 --disable-gallium && make && sudo make install
sdsdsd: i have used it to build
MostAwesomeDude: That works.
sdsdsd: i have built this way
MostAwesomeDude: Hm. Or is it --with-dri-driver? I can never remember, lemme check.
MostAwesomeDude: Nope, --with-dri-drivers. Sorry.
sdsdsd: (but i was running with radeon.modeset=0, maybe it interferes)
sdsdsd: so dont you have a clue why 3d isnt working?
MostAwesomeDude: Sure. You didn't build r300_dri.so.
osiris_: nha: looks like there's an easier way to get depth component of position vector available in fragment shader
nha: osiris_: indeed :)
sdsdsd: MostAwesomeDude if havent build, how can i get hardware acceleration without kms?
sdsdsd: maybe an old lib?
sdsdsd: i build the lib on mesa autogen command?
sdsdsd: it makes the lib?>> ./autogen.sh --prefix=/opt/xorg --with-dri-drivers=radeon,r200,r300 --disable-gallium && make && sudo make install
MostAwesomeDude: sdsdsd: Your old Mesa drivers are still around.
sdsdsd: how to remove them?
MostAwesomeDude: sdsdsd: Are you checking your Mesa build to make sure it's not erroring out?
sdsdsd: yes... no errors found.. i keep watching the compilation
osiris_: nha: the negative offsets in relative addressing can be emulated. ADD TEMP[0], CONST[A0 - 5], INPUT[2] would be SUB A0, A0, 5; ADD TEMP[0], CONST[A0], INPUT[2]; ADD A0, A0, 5;
sdsdsd: ill boot up on KMS off.. its faster
rnoland: agd5f: something seems not quite right with r600_cs_process_relocs()
sdsdsd: please see my output without kms
sdsdsd: http://pastebin.com/m73aecb41
sdsdsd: well i see that i didnt compiled the libdrm by myself
MostAwesomeDude: You didn't?
MostAwesomeDude: Well, that'd be the root of a lot of it.
MostAwesomeDude: You *need* updated libdrm for acceleration with KMS.
sdsdsd: i updated by package manager (compatible version)
MostAwesomeDude: Now I'm confused. If you're getting packages for this stuff, why are you building your own Mesa?
sdsdsd: i just though that once i have a newer libdrm i must work
sdsdsd: what i need to do?
MostAwesomeDude: First, could you pastebin your Xorg.0.log?
sdsdsd: i downloaded drm-2.4.15.tar.gz
MostAwesomeDude: With KMS enabled?
nha: osiris_: yeah, but they *should* Just Work, and I don't understand why they don't
sdsdsd: once i have restarted i will post the xorg.0.log.old ok?
hnsr: nha, did you have a blog?
nha: hnsr: I still do ;)
sdsdsd: http://pastebin.com/m2505dc39
hnsr: nha, hmm I was wondering what the url was, google is letting me down :p
nha: hnsr: http://nhaehnle.blogspot.com/
hnsr: thanks
sdsdsd: MostAwesomeDude http://pastebin.com/m2505dc39
agd5f: rnoland: something look strange?
sdsdsd:
MostAwesomeDude: sdsdsd: Ah, the potential problem reveals itself. Your DDX isn't built for modesetting.
sdsdsd: oh, so what may i do to build DDX for modesetting?
MostAwesomeDude: Just build the DDX as usual. During configure, it should spit out "Kernel Modesetting: yes" or something similar.
sdsdsd: Sorry i dont know how build a DDX, im a real n00b
sdsdsd: its build with MESA? or with radeon?
MostAwesomeDude: sdsdsd: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati
MostAwesomeDude: This.
sdsdsd: do the driver so...
sdsdsd: i need to compile it booted with kms on?
MostAwesomeDude: I don't think so, no.
MostAwesomeDude: Check the configure output; it will tell you whether or not it's enabled KMS.
sdsdsd: ./ configure?
sdsdsd: may i pick the branch kms-support or 6.12-branch?
sdsdsd: http://www.x.org/wiki/radeonBuildHowTo < i use this guide, what i need to change to use kms?
dileX: nha: looking at
dileX: s/to/two
sdsdsd: (to build DDX with kms)
sdsdsd:
nha: dileX: yeah, the separate X.org / DRI wikis cause some confusion; feel free to improve it
MostAwesomeDude: sdsdsd: I believe master is the correct branch to use.
dileX: nha: I started with a v2 of the build-wiki here, but it is not only a build-howto with additional infos (troubleshooting, etc.). so a split or re-org would be fine *or* a single long (annoying?) one :-)
sdsdsd: ill have to enter some parameter to get modeseting DDX?
biotube: last I checked, ddx requires --enable-kms passed to configure
sdsdsd: sorry biotube but configure is ./autogen.sh --prefix=/opt/xorg && make && sudo make install ?
sdsdsd: or configure.ac
biotube: autogen.sh passes its arguments on to configure
biotube: after it creates it
sdsdsd: when i need to put the --enable-kms ?
biotube: pass it to autogen.sh
sdsdsd: ok
sdsdsd: then just restart
sdsdsd: same error: http://pastebin.com/m4c430d7d
sdsdsd: same error: http://pastebin.com/m4c430d7d
TASADAR-F: I have a small problem I used radeonbuildhowto for 3D r600 and r700, I install "drm" perfectly but when I compile mesa appear this Requested 'libdrm >= 2.4.15' but version of libdrm is 2.4.3
sdsdsd: ill stay using non-KMS a litlle more..
TASADAR-F: I use Ubuntu 9.04
virtuald: TASADAR-F: You can get the latest crack from the xorg-edgers ppa
TASADAR-F: ok thanks
TASADAR-F: thanks you very much. This ppa is very update and is more easy than compile
rnoland: agd5f: yes... Invalid source texcoord for TEX instruction
rnoland: validated 0x802c15c80 [0xF030E000, 0xF030E000]
rnoland: above end: 0x802c15c80 0x00000000 0xF030E000
rnoland: that is from piglit shaders/fp-fragment-position
rnoland: offset_dw is initialized to 0 and never changes.
rnoland: cs->packets[relocs[i].reloc_indices[j] + 1] = offset_dw;
rnoland: we set the cs->packet[] to 0
rnoland: oh, hrm... there offset_dw is updated....
MostAwesomeDude: agd5f: Thanks for the awesome new docs.
MostAwesomeDude: There's pretty pictures now.
airlied: MostAwesomeDude: the assert assert(tex && tex->buffer && "texture is marked, but NULL!");
airlied: any reasons thats not totally bogus?
MostAwesomeDude: airlied: It used to be that I'd get NULL pointers or bad cbuf counts.
MostAwesomeDude: But I haven't seen that one get hit since before summer.
airlied: you can get NULL texture pointers quite validly
MostAwesomeDude: It could be taken out, I suppose.
airlied: if the second texture unit is enabled but not the first
MostAwesomeDude: airlied: Wait, which one? There's several of those.
airlied: the texture one in emit_dirty_state
airlied: it needs to have a if (!tex) continue alright
MostAwesomeDude: Oh.
MostAwesomeDude: Hm, can't remember if that can happen. Lemme switch comps.
airlied: ah fixing that leads to more wrong ;-)
airlied: it can happen quite easily
MostAwesomeDude: Hm. Unless I misunderstood, you can't turn on tex0 and tex2 but not tex1.
airlied: you can turn on tex1 but not tex0
airlied: I've pushed the fix with the reproduce
airlied: now I just have to figure out what is messing up that the textures don't blend
airlied: I'm going to go with frag prog
MostAwesomeDude: Ooh, I see. Interesting.
PuffTheMagic: are there any special options i can set via cmdline that might get kms working for me again, this hardlock sucks and i miss native res fb
spstarr: hmmm
spstarr: drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
spstarr: 2009-10-14T01:47:39Z newview/lldrawpoolbump.cpp(806) : error
spstarr: 2009-10-14T01:47:39Z ERROR: ~LLBumpImageList: ASSERT (mBrightnessEntries.size() == 0)
spstarr: looks
spstarr: [20360.136639] [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16398
spstarr: [20360.136643] [drm:r600_cs_legacy] *ERROR* Failed to initialize parser !
spstarr: oh yeah overloaded IB
spstarr: i will have to try what agd5f mentioned
spstarr: interesting
spstarr: 7 bits ?
Ghworg: The error message "unexpected texture format in setup_hardware_state" is coming from mesa right?
spstarr: ew
spstarr: this sim im in is killing the CS
spstarr: [21129.459953] [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16389
spstarr: too many objects to render
spstarr: grabs today's mesa
spstarr: im gonna build the change as agd5f suggested now
spstarr: oh
spstarr: void r700InitDraw(GLcontext *ctx)
spstarr: ...
spstarr: /* to be enabled */
spstarr: I see, its not ready 'yet'
agd5f: spstarr: that message is old
agd5f: it is enabled
spstarr: oh
spstarr: i am disabling the call now
rnoland: agd5f: so i'm ending up with a bo of size 0
agd5f: rnoland: we don't handle shader compile failure too well yet
MostAwesomeDude: agd5f: This whole AA texstuff thing isn't quite making sense; is this pretty generic, or is it Radeon-specific?
agd5f: MostAwesomeDude: you could do it on any chips but the stuffing and such is radeon specific
MostAwesomeDude: Well, I mean, I guess I'm not understanding how to integrate it.
MostAwesomeDude: So the stuffed texcoords, they reference a stuffed texture? Or are they meant to be texkill'd?
_Groo_: hi/2 all
agd5f: MostAwesomeDude: I think I figured this out at one point, but it's been a while
_Groo_: agd5f: hi agd5f
agd5f: _Groo_: hi
_Groo_: agd5f: i quick bu report since my battery is almost out
_Groo_: like you guys know, i have a evil rs485
_Groo_: im using latest linus tree from today, mesa/ddx/drm and xorg git from last week
_Groo_: im having a strange regression
agd5f: _Groo_: please file a bug so we can track it
_Groo_: when i activate kms , fbcon enables the 1280x800 mode (max for my lvds) BUT i gets confined to a 800x600 area.. and from that point, X thinks my lvds s 800x600
_Groo_: it* gets confied
_Groo_: confined
MostAwesomeDude: agd5f: Well, it'll be a source of endless entertainment in the weeks to come, I'm sure.
_Groo_: ocasionally without me changing anything, fbcon gets the resolution and screen area correctly
agd5f: _Groo_: what gets confined?
_Groo_: is there any way to force fbcon to start with 1280x800 rez?
_Groo_: when kms/radeon/fbcon gets activated in the boot process, the lvds changes to 1280x800
dmb: agd5f, any luck with my video card bug yet?
agd5f: dmb: bug number?
_Groo_: BUt instead of ocupying the entire lvds area, it gets confined to a 800x600 space area
agd5f: _Groo_: is there another monitor attached?
_Groo_: agd5f: on online laptop native, always
_Groo_: no
_Groo_: i mean, no external monitor, just native lvds
_Groo_: 99% of the time, fbcon gets that space cofined problem, but sometimes it boots correctly, same sequence, no changes
agd5f: _Groo_: but what gets confined? I'm not following. can you get a picture?
_Groo_: agd5f: the only thing strange is this [ 41.579222] [drm] not detecting due to 00000004
_Groo_: agd5f: imagine this
_Groo_: when booting, the screen changes the font to the correct rendering it should have for 1280x800
dmb: agd5f, 24313
_Groo_: BUT instead of showing text in the entire screen area
_Groo_: it only shows text in a 800x600 screen area, the rest gets left black and isnt updated, only fills the 800x600 square of the 1280x800 resolution
_Groo_: since its tty i cant get a picture, unless i use a cellphone
SmallCat: _Groo_, kms should support any reso as long as your monitor is capable enough to display it
_Groo_: this never happened before, started when you guys introduced the virtual resolutions code
_Groo_: SmallCat: it does...
agd5f: _Groo_: can you pastebin your dmesg?
_Groo_: SmallCat: it just detects it wrongly
_Groo_: agd5f: ok just a sec
SmallCat: _Groo_, then what you can do is change the reso with fbset, i915resolution or vga parameter
SmallCat: but that's radeon, sorry about i915
agd5f: SmallCat: none of those work with kms at the moment
_Groo_: agd5f: exactly
soreau: I know what Groo is talking about, but this only happens for me when it detects S-video is plugged and only on boot. When X starts, things are ok
_Groo_: http://pastebin.ca/1618605
_Groo_: soreau: i dont have s-video
_Groo_: soreau: and X sometimes crashes with xf86mode crash because of this same bug, since im forcing it in xorg.conf to the 1280x800 rez
_Groo_: and kms declares 800x600
_Groo_: agd5f: you have my email (paulo dot miguel dot dias at gmail) so if you need more testing let me know, my bat is almost out
agd5f: _Groo_: the tv is getting detected as attached
_Groo_: agd5f: i dont even have tvout!!!
_Groo_: agd5f: this acer aspire doesnt have a connector!
soreau: _Groo_: Well at least I know what you mean by having the output confined to the upper left 800x600 of the screen
agd5f: _Groo_: well, then we need to add a quirk since it seems to think there is one
_Groo_: agd5f: i always suspected the darn bastards at acer used the same card, just ripped tvout off
agd5f: #
agd5f: [ 25.990654] [drm] Connector 2:
agd5f: #
agd5f: [ 25.990657] [drm] S-video
agd5f: #
agd5f: [ 25.990661] [drm] Encoders:
soreau: Ha, s-video is getting detected as connected ;)
agd5f: #
agd5f: [ 25.990665] [drm] TV1: INTERNAL_DAC2
_Groo_: ok, but i DONT have even a physical connector
agd5f: _Groo_: send me your pci ids lspci -nv
agd5f: _Groo_: then we just need to add a quirk
soreau: It is interesting that it would still have the same res in X though
soreau: agd5f: You think that it will be possible to have it fill the entire screen on main monitor even when tv-out is connected?
soreau: on boot of course
SmallCat: fiill what?
_Groo_: http://pastebin.ca/1618612
agd5f: soreau: airlied already added support for forcing modes on different outputs in the console
agd5f: _Groo_: can you send me your vbios rom too
_Groo_: soreau: it probably thinks the 2 outputs are the same, since i only have one
_Groo_: agd5f: how i do that?
soreau: SmallCat: When S-video is detected as connected, the main monitor is at native resolution, say 1280x1024 but output only displays in upper left 800x600 pixels
spstarr: agd5f: done, disabled routine.. testing
soreau: agd5f: Is it possible to force mode from kernel parameter?
agd5f: as root: cd /sys/bus/pci/devices/
agd5f: soreau: yes
SmallCat: soreau, ok, same issue again, guess that hasn't been yet implemented, 800x600 was the max when i tried also
soreau: agd5f: Can you please tell me how to do that? :D
_Groo_: agd5f: pass me yout mail private , my bat will go out any sec
spstarr: er
spstarr: agd5f: now its hung
soreau: SmallCat: When you tried what?
agd5f: _Groo_: alexdeucher AT gmail DOT com
spstarr: agd5f: seems without that call SL doesnt even start
SmallCat: SmallCat, radeon and tv-out 6.1.x something ancient driver, then i asked that question
_Groo_: ok gonna dump and send
agd5f: _Groo_: include the lspci output too
SmallCat: soreau, and agdf responded, some conversions to support cloned on allmodes are difficult to implement
spstarr: tries again
spstarr: now it worked
soreau: Well agd5f just said support to force modes has been added. Now I want to know how to set it as kernel parameter :)
SmallCat: soreau, he talked about kms probably and on primary display
spstarr: 2009-10-14T03:09:14Z INFO: addToMessage: STAT: Version: 0
spstarr: 2009-10-14T03:09:14Z INFO: addToMessage: STAT: Vertex Buffers Enabled: 0
spstarr: hmm
spstarr: no VBOs
spstarr: turned off since it crashes
agd5f: soreau: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=d50ba256b5f1478e15accfcfda9b72fd7a661364
agd5f: soreau: the modes are set properly, it's just the console is limited to the smaller area of the two modes since they care cloned
agd5f: s/care/are/
agd5f: otherwise you wouldn't see everything on the smaller head
soreau: hmm..
SmallCat: there were fbcon parameters to trim console too
SmallCat: i see default video= is in use now, nice
soreau: agd5f: 1) How do I know if support for that is in my kernel? 2) Does this mean I can have VGA-0 fill all screen with output at 1280x1024 or I would have to downscale it to 800x600 to get it to fill?
soreau: Currently, I am using 2.6.32_rc4
SmallCat: http://tldp.org/HOWTO/Framebuffer-HOWTO-18.html
SmallCat: agd5f, but let's say xrandr in X for svideo now supports 1024x768 output cloned with radeon drivers?
agd5f: soreau: 1) you'll have to find out. drm-next has it 2) it just lets you force modes on connectors, you'll still be limited by the smaller of the two heads
SmallCat: ah ok
soreau: Alright, now what is the git url for a kernel version that drm-next will install cleanly on top of?
agd5f: SmallCat: r5xx+ cards can scale most modes for tv-out. only r1xx-r4xx is currently limited to 800x600
SmallCat: hmm, haven't got much idea's how s-video works, dbvgcluster just add's swapbarriers to sync, but reso with which to project to, kernel side
soreau: Wow, that was really recent
soreau: Thanks agd5f
soreau: How can I clone 2.6.31_rc1 using git?
agd5f: soreau: what's really recent?
soreau: agd5f: The video= stuff for fb/kernel param
agd5f: soreau: yeah
agd5f: well for kms
soreau: The instructions in the topic link fail because the kernel listed there wont allow drm-next on top of it cleanly
soreau: conflict issues
SmallCat: http://developer.vrjuggler.org/wiki/OradDVGCluster i mean spreading like 3d textures of windows like outlined here, may be possible with those earlier cards also maybe with s-video
soreau: I'm trying to get drm-next installed again. What kernel should I clone? Last time airlied said 2.6.31-rc1 but I don't even know how to clone this kernel using git
dmb: glances at agd5f :P
airlied: soreau: when did oyu get conflicts lst?
agd5f: dmb: are you using the DVI or HDMI port?
soreau: airlied: I am doing a fresh clone exactly as describe on the wiki to see
dmb: agd5f, DVI
dmb: this is any mode
soreau: (21%)
dmb: vga works
SmallCat: i still haven't tried that juggler, but it seems interesting, chromium to take stream in and conf's to project it in parallel, and spu seems like that local one, so extensions can be added
dmb: VGA driver works also on dvi
dmb: just some kind of modesetting thing with radeon
soreau: airlied: http://pastebin.com/m7f2167ce
airlied: ah intel code just don't build it ;-)
dmb__: stupid electricity keeps going out here
soreau: airlied: rnoland said it's easy to fix but I don't know how
SmallCat: soreau, someone pushed it yestirday, conversation on #intel-gfx ickle cworth
soreau: Well it failed very similarly last time I tried a couple weeks ago
soreau: May have not been exactly the same but I recall it was something intel related
soreau: More importantly though is how do I fix it?
SmallCat: soreau, yeah an explicit intel_drm.so build and others left out/ignored, when march is bigger then i386, as they said
SmallCat: cherry last commit probably from master or somewhere, ask nanonyme
airlied: soreau: just don't build the i915 driver
airlied: or edit i915_sdvo.c find the <<<<<< lines
airlied: and clean up whats happened
fudje: git mergetool?
soreau: hmm
fudje: So, uh... Currently KMS will give a kernel oops when trying to load an AGP graphics card without a working AGPGART.... I guess this isn't intended behaviour?
soreau: Well I took the intel driver out of config but now when I do $ git pull airlied_drm_remote drm-next it says: You are in the middle of a conflicted merge.
airlied: soreau: just edit the i915_sdvo.c and remove the <<<<
airlied: and git commit
airlied: really though you probably want to throw that tree away next time you need somethnig new
soreau: Yea, I need to start over I think
airlied: no I mean next time
airlied: if you repeat it now you'll just end up with t he same thing
fudje: loves merge conflicts with git
soreau: fudje: Then you can help me with this one
soreau: Because I just don't get it
soreau: fudje: Can you look here and tell me how to fix this? http://pastebin.com/m7f2167ce
fudje: Well what airlied has said is more or less correct. If you don't need to build the code just remove that bit from the file and commit the tree
soreau: fudje: I tried that, but it didn't work http://pastebin.com/m3f00ab96
fudje: for a more robust (but still not foolproof) "resolution" you can run `git mergetool' on the commandline
soreau: Well I will do that on this fresh clone again
soreau: fudje: What does git mergetool do?
fudje: it'll bring up something to help you find and fix the conflicts.
soreau: ok
mattst88: airlied: just resent a s/4096/RADEON_GPU_PAGE_SIZE/ patch for drm/radeon/kms; please review and commit
agd5f: airlied: radeon_atom_mode_fixup() doesn't seem to be called in the initial modeset or when starting X
agd5f: with kms
agd5f: which leads to adjusted_mode not getting setup properly in some cases
airlied: agd5f: not sure how.
airlied: all the modesetting happens via one function
soreau: fudje: What should I do? http://pastebin.com/m29c6a06c
fudje: press y :)
fudje: then git commit
soreau: ok :)
airlied: agd5f: unless encoder->crtc isn't setup properly
airlied: debug the loop line 665 or drm_crtc_helper.
soreau: fudje: Cool it worked!
soreau: thanks a lot
fudje: Just don't expect the i915 driver to compile, eh?
soreau: airlied: Where it says [note this requires an fb patch posted to linux-fbdev-devel already] does it still require that patch or is that in drm-next? http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=d50ba256b5f1478e15accfcfda9b72fd7a661364