Nightwulf|work: hi all
mcgreg: hey guys ... it seems the last commits made the r6/7xx 3d much faster for google earth ... it is totally fluent here now. great work :)
dileX: mcgreg: last commits from drm-next?
mcgreg: no mesa
mcgreg: I doint use drm-next
mcgreg: just for fun I started wow ... it works like 10% ... but wtf does xorg use 75% of my memory?
mcgreg: I have 4gb + swap ...
mcgreg: somehow my linux uses now all 4gb+ all 2gb swap. I wonder how that is possible
twoerner_: since update to latest GIT mesa (5 minutes ago) some GL apps are not working anymore and kernel reports [drm:radeon_cs_ioctl] *ERROR* cs->dwords too big: 16510
twoerner_: GIT Mesa from 8h ago was working as expected
twoerner_: is this a problem with ~agd5f/drm r6xx-r7xx-3d branch?
twoerner_: it seems to be the draw_prin checking
twoerner_: draw_prim
dileX: reads "Cool things with SELinux... Introducing sandbox -X"
bronziii: windows 7 anyone?
MostAwesomeDude: bronziii: /topic
bronziii: can someone help me on how to install drivers for windows 7?
bronziii: oh
bronziii: sorry
soreau: MostAwesomeDude: I have to concur. Bacon is great ;)
nanonyme: MostAwesomeDude: Then he goes to #ati and gets another /topic mention. :P
nanonyme: Since #ati is only for fglrx, not Windows Catalyst. ;)
MostAwesomeDude: soreau: Mm, bacon.
nanonyme: I'd just direct people to ati.amd.com, there's really no channel here for helping such Windows users that I know of.
bridgman: the topic doesn't say anything about bacon...
Lutz_Ifer: hmmmm bacon
soreau: bridgman: That doesnt change the fact that its delicious :)
jcristau: hmm. bacon.
Lutz_Ifer: /topic hmmm. bacon.
nanonyme: bridgman: Yeah, bacon is a good topic.
bridgman: ok, perhaps I misunderstood the logs
bridgman: next time someone asks about windows drivers send them to #bacon
nanonyme: Or missed a section of the conversation? ;)
bridgman: perhaps
bridgman: goes back to sleep
nanonyme: Hmm, can you do a partial modules_install just like you can do a partial modules compile in kernel tree?
Pallokala: not that I know
nanonyme: Ah, well. Done already anyway.
Pallokala: you can though remove modules at will from /lib/modules/ , but it might break your install
nanonyme: That's not the point though.
nanonyme: Running make modules_install is slow.
nanonyme: I suppose I could just copy the modules over myself though.
Pallokala: not that this is related to this channel, but "slow" for me is ~5-10 seconds
Pallokala: it shouldn't take much time
nanonyme: It does.
nanonyme: If you don't optimize kernel configs.
Pallokala: oh, I do that (gentoo)
nanonyme: Ditto.
nanonyme: There's a way to only compile changed modules but not to install only the changed ones.
nanonyme: At least that I've heard of.
soreau: nanonyme: You use gentoo?
nanonyme: Nope.
soreau: Then what were you talking about when you said ditto?
nanonyme: All Gentoo users compile kernels so most of them optimize kernel configs.
gimzo: when is 2d / xv on R800 to be expected ? :)
nanonyme: Planning to buy one? :)
gimzo: I'm planning to buy new gpu in next 2-3 months (currently on x700)
nanonyme: Ah.
gimzo: So I'm wondering to wait for r800 or get r700
nanonyme: Wait 2-3 months and see how far the drivers are then? ;)
gimzo: good thinking :)
Pallokala: r600/r700 is still a hassle to get working
muep__: usually not if you don't necessarily need the opengl support
dileX: Pallokala: look into the build-wiki (URL see topic)
Pallokala: oh I did, but it is still a hassle when I try to keep portage up-to-date by making custom ebuilds
Pallokala: (I have RV630, 2600 Pro AGP)
dileX: Pallokala: according to a dev at quassel.de - portage/ebuild is fine and up-to-date
Pallokala: with some custom overlay? or the general overlay? I'm looking for the yet-experimental 3D acceleration here
Pallokala: I got the slow 2D working easily
Pallokala: but it is quite slow f.ex. when moving windows
dileX: Pallokala: which kernel do you use?
soreau: Pallokala: With the x11 overlay and the drm-next kernel build instructions in the topic link, its pretty easy IMHO
Pallokala: 2.6.31-gentoo
Pallokala: I will look into this after my gcc-upgrade is finished.
soreau: The x11 overlay provides all the -9999 packages you need.. shouldnt have to make custom ebuilds
Pallokala: I will look into this.
nanonyme: soreau: Hmm, they've got a Linus tree -9999 package too?
dileX: hrs ago someone posted a link to ubuntu-daily kernels. they seem not to build since weeks.
soreau: nanonyme: No, read what I said again
nanonyme: soreau: Well, he was talking of the yet-experimental 3D. :3
nanonyme: Ohh, right.
nanonyme: Missed the previous comment.
luboss: hello all, i'm new here, I've got few main problems with the xf86-video-ati driver for my ati 9600 mobility card (RV350)
luboss: I played lot with xorg.conf driver options and also I tried lot of kernel versions and tunnings, nothing helped to get 3d graphics work properly, even 2d has some resolution vs. fullscreen related problems
soreau: luboss: Start by pastebinning your X log to pastebin.com
luboss: I saw some bugs open (most of them on ubuntu launchpad) but I couldn't find the soltuion
gimzo: I think radeon 9600 should work perfectly
luboss: soreau: I created a bug report on gentoo bugs, but I'm not sure it's the right place: http://bugs.gentoo.org/show_bug.cgi?id=274140
muep__: should as in is likely
soreau: luboss: Post your current /var/log/Xorg.0.log to pastebin.com and post the link here
muep__: should also as in "is preferable to" :-)
luboss: muep__: yes, but believe me, I tried probably everything, I investigated it for weeks
muep__: luboss: does it happen if you run a well known live environment, like livecd from ubuntu,fedora or other bigger mainstream distribution?
luboss: muep__: yes, I installed ubuntu only for this reason, compiz worked quite fine with 1184x864 res. but as soon as I turned to 1280 the graphics was corrupted (because of 3d textures)
luboss: the best performance and satisfaction was without attached VGA LCD display, playing Warcraft 3
luboss: (on gentoo)
soreau: luboss: If you dont help us help you, theres probably not much we can do for you
luboss: but as soon as I want to play ut2004 the performance is about maybe 1-5 fps, but according to this site: http://xorg.freedesktop.org/wiki/RadeonProgram the support should be GOLD
luboss: soreau: sorry, exactly what kind of information do you need? everything is reported in the bug I mentioned: http://bugs.gentoo.org/show_bug.cgi?id=274140
soreau: luboss: I want to see your current X log from the session you are running right now
Pallokala: interesting difference with build and current OS
luboss: soreau: sorry, but right now I'm still using fglrx, I can turn to xf86-video-ati, but as I said, there's everything in the bug, Xorg logs, dmesg logs, everything: xorg.log with exa enabled, xorg.log with xaa enabled...
soreau: well forget it. gnite
adamk: luboss: You don't mention what version of Mesa you are using. And, frankly, I'm not sure I'd expect any of the developers to look at distribution specific bug tracking systems.
luboss: soreau: "thank you" for the support, I will be probably only one idiot on the planet using old 1.5 xserver
luboss: adamk: it's not dist. specific! as I said, ubuntu does the same: [driAllocateTexture:635] unable to allocate textu
luboss: some games could not be played at all
adamk: Even more reason *not* to use a distribution specicic bug tracking system but to use freedesktop's.
adamk: has happily played ut2004 in the past on a radeon 9600 with the open source drivers.
luboss: adamk: I know I should use freedesktop's but I saw similar bug there and also I left a comment there but onone is actualy replying
luboss: *noone*
luboss: for example: http://bugs.freedesktop.org/show_bug.cgi?id=18707
luboss: adamk: I'm using mobility 9600, I think there's difference
adamk: Did you try the suggestion in that bug report and limit your virtual resolution?
adamk: That bug report, btw, has feedback from a number of developers.
adamk: And, frankly, the fact that EXA is slow for you makes me think there's even more going on.
adamk: However, it's going to be nearly impossible for anyone to help you make the radeon drivers work better if you aren't actually using them.
adamk: Which, I believe, is the source of soreau's frustration.
adamk: In terms of the 2D performance, my first suggestion would be to try X server 1.6.*
luboss: adamk: look, it took me lot of time to troubleshooted this until I come to quite satisfied point that fglrx works at some level, I would be glad to use opensource driver, that's why I troubleshooted it so much, but simply, it's not working and I think I'm not the only one
luboss: adamk: I switched to opensource and again to fglrx so many times that I'm frustrated of it
adamk: Well what do you want, then? Either stick with fglrx or stick with the open source drivers and politely hang out here and poke developers till this problem is fixed.
luboss: adamk: I don't see good reason why to relly all the information again, this bug is 3 months old, ok, but I tried the opensource driver maybe 3 weeks ago and it's still the same
adamk: If the developers aren't having the same probglem as you (and clearly they aren't) only your feedback and testing (or those of someone else with the problem) will get it resolved for you.
adamk: Did you update log files 3 weeks ago? Did you test with the latest Mesa and X server?
adamk: Again, you didn't even mention the version of Mesa in your bug report.
luboss: adamk: sorry, I'm using mesa-7.3-r1 and mesa-progs-7.3
nanonyme: Wow, that's quite ancient. ^^
adamk: OK, now we're getting somewhere hopefully.
nanonyme: What's the recent release, 7.5.1?
adamk: Is the mobility 9600 an IGP card? Because there was a bug in Mesa for IGP radeon cards for quite a while that caused bad 3D performance.
luboss: according to 2d, the performance is ok, but sometimes as I'm maximazing the window (or hit fullscreen) it only fills 1024x768 pixels, but I'm using 1280x1024 and btw. I cannot turn off builtin LCD in xorg.conf, Ignore and Enable options does not work
adamk: Well that sounds like a separate issue. Did you open up a bug report (or find an already existing one) on freedesktop?
suokko: airlied: Looks like your problem with radeon_get_ib_value might be that it is not inlined
luboss: nanonyme: hmm, it's the most recent version stated as STABLE in my soft brach (it's not masked by portage)
luboss: *branch*
MrCooper: adamk: no, 9600 isn't IGP
adamk: Ahhh, well there goes that idea.
suokko: or maybe not
adamk: I'd still recommend upgrading to a newer Mesa, though, as quite a bit has likely changed in the past 9 months.
nanonyme: luboss: Well, that's what Gentoo has marked stable, yeah. Upstream considers all releases stable though.
nanonyme: Pre-releases not so much. :)
nanonyme: (yours is a git snapshot)
suokko: airlied: Does that parser realy require random access or could you make the iteration simpler if you required that access is always next element?
luboss: adamk: I know it sounds comic but I don't know if it integrated or not :-) I've got this notebook from my friend, maybe I will look around on the internet about the specs
luboss: ok, so I will turn to the opensource driver and will try to upgrade the mesa and maybe xserver too, will see
nanonyme: So we kinda have a funny situation where upstream doesn't actually consider your version of radeon driver stable but Gentoo does while Gentoo doesn't consider newer releases stable while upstream does. ;)
luboss: thank you for your patience and advices
adamk: luboss: MrCooper said it's not IGP, and I'd trust him :-) But, as I said, much has changed in 9 months since Mesa 7.3 was released.
luboss: adamk: oh, really, I looked through
nanonyme: I'd also try with a more recent kernel.
nanonyme: Kernel 2.6.31, radeon driver 6.12.4, Mesa 7.5.1 might be a good set to try.
adamk: Using drm-next + libdrm from git, with KMS activated, 32-bit apps are now giving me "libGL error: failed to create dri screen"
adamk: Hmm... I am getting radeon_cs_ioctl errors from the drm... I thought running 32 bit apps on a 64 bit kernel with KMS was fixed now, though?
Lutz_Ifer: "bo(0x77df400, 65536) is mapped (-1457) can't valide it."
agd5f: twoerner: probably Richard's draw_prims commit
agd5f: in mesa
nanonyme: Hmm...
nanonyme: wonders if there is a bug in r600 CS flush necessity checking code
nanonyme: Hackity hackity, needs more debugging info.
nanonyme: Wait, what...
nanonyme: There's something seriously odd here.
nanonyme: rmesa->cmdbuf.cs->cdw + dwords + 128 is bigger by magnitudes for me than rmesa->cmdbuf.size even if rmesa->cmdbuf.cs->cdw == 0.
nanonyme: Function rcommonEnsureCmdBufSpace. Then again, there's an added assert there that requires rmesa->cmdbuf.cs->cdw not to be 0 which happens very often. ^^
nanonyme: (apparently due to dword counts being ginormous)
suokko: nanonyme: That is bug then
suokko: That driver is trying to emit for single primitive rendering more data than fits command buffer
nanonyme: Yeah...
nanonyme: r700PredictRenderSize
nanonyme: That's the caller
taiu: well it's more that r700PredictRenderSize has't been adopted to draw interface
nanonyme: Ah, right.
nanonyme: It's a known issue then, I'd surmise.
MrCooper: Lutz_Ifer: maybe try the patch I sent to the mesa3d-dev list today in 'Re: [Mesa3d-dev] [PATCH] radeon: Be more resilient to texture image (un)mapping imbalance.'
Lutz_Ifer: i'll give it a try
suokko: MrCooper: Does it fix also DMA buffer reference counts? (aos references)
MrCooper: don't think so, it's about textures
MrCooper: with the new meta CopyTex(Sub)Image
suokko: I jsut was wondering if textures had some references to some DMA buffer
MrCooper: not that I know of
adamk_: Woohoo.... I finally have KMS + DRI2 working 100% on one of my radeons, including 32-bit and 64-bit applications.
MrCooper: yay
adamk_: I'll try drm-next at home and see if it does anything for https://bugs.freedesktop.org/show_bug.cgi?id=23901
Emme_NK: Hi!
Emme_NK: agd5f: Just got your message on Bug #20222
Emme_NK: Flickering is still there
Emme_NK: Xorg log: http://www.nopaste.de/p/aDIlgtfDy
Emme_NK: I'm on -ati git head, latest commit is 97a4e747bfac14f34646c55ddf639e8fe22f2f55
Zajec: what is 3D engine on RV880? is this something new and will need new Mesa driver?
Zajec: or just modification of r600 will be fine?
nanonyme: Assumably its own code paths inside r600 driver.
nanonyme: (partially its own, that is)
Zajec: so hopefully should be easier that writing new driver? :)
Zajec: fine
suokko: Zajec: 3D engine should be mostly same but if rumors about changes to scheduling are true it might need new kernel code
suokko: Of course that could be just some marketing PR and hw didn't really change much ;)
Zajec: thx :)
dileX: MrCooper: I got following errormsg
MrCooper: dileX: that's an X driver issue, not related to Mesa
dileX: MrCooper: I downgrade my xserver to 1.7-rc2 (with no patches from master)
MrCooper: it's most likely strictly a driver issue
MrCooper: though maybe your previous X server didn't trigger it somehow
simplexe1: hi all!
simplexe1: hmmm with draw_prim my rv770 crash any GL app
dileX: MrCooper: you mean DDX?
simplexe1: no, mesa
simplexe1: a sorry, not me
MrCooper: dileX: yes
MrCooper: (strictly speaking DDX is too vague, it also describes part of the X server :)
dileX: today, I build mesa (master) and xorg-server (server-1.7-branch plus 3 from master)
dileX: xserver-xorg-video-radeon (1:6.12.99+git20090920.97a4e74-1~dileX+1)
dileX: shall I rebuild it against new xorg-server? (thought this is not required when videoabi did not change)
MrCooper: it shouldn't be necessary, but it can't hurt
dileX: aua :-)
MrCooper: are you sure you were playing the same videos under the same circumstances before?
kdekorte: simplexe1, I think that is a known issue at the moment
dileX: MrCooper: hmm, I had a vlc-session before watching youtube (will check)
simplexe1: kdekorte: ok
simplexe1: kdekorte: fix aviable?
kdekorte: simplexe1, I'm not aware of one
kdekorte: you can revert that patch out of mesa... git revert HEAD
kdekorte: replace HEAD with the patch id
dileX: MrCooper: sounds foolish but I cant reproduce the problem, again
simplexe1: ok
dileX: LOL, "This video is not available in your country due to copyright restrictions."
nanonyme: :)
nanonyme: dileX: I think it's even more hilarious when they remove audio from clips due to copyright limitations and don't even mention it anywhere.
dileX: nanonyme: I will see to get a VPN connection from CCCP or whereever else :-)
dileX: oops CCCP does not exist anymore
dileX: superbe, I compiled a new mesa. forgot to install it. oh man
nanonyme: :D
nanonyme: Oops. :)
suokko: dileX: Try Tor ;)
suokko: Then you get randomly visible videos I would guess
dileX: suokko: I wanted to enjoy my inet-rides :-)
dileX: thats 1st time after I read about the German law restrictions - so I wondered all the time. lucky me.
nanonyme: feels like a conservative pig every time he talks to Tor advocates :p
nanonyme: (namely I usually deny users from using certain ports, like IRC)
agd5f: taiu1: tex patch looks good. you should apply for an account so you can commit yourself
taiu1: ok, thanks for looking
kcodyjr: nanonyme, what's so liberal about tor?
kcodyjr: seems to me that the wish to remain anonymous and skirt government restrictions is about as politically neutral as it gets.
MrCooper: kcodyjr: this is getting OT, but beware that the meaning of political terms such as 'liberal' can vary wildly depending on the country etc.
suokko: taiu1: http://www.freedesktop.org/wiki/AccountRequests
kcodyjr: good point. i was just looking for the antonym to 'conservative'.
Neo_The_User: how do i debug KMS via gdb through ssh? I have kernel gdb debug option turned on, frame pointers, heavy debug flags on xserver, pretty much everything is set to full debug "give me an error if you hear a pin drop" but i dont know how to debug kms via the kernel gdb feature.
Neo_The_User: and yes i have 3 different computers
suokko: I would think you should look for kernel debugger guide somewhere. Maybe from kernel source tree
Neo_The_User: oh thanks! i totally forgot about the in-tree kernel docs!
marvin24: http://marc.info/?l=mesa3d-dev&m=125313332012351&w=2, do the other no-tcl radeons need a similar patch?
suokko: nanonyme: Did you already learn that you can pass SUBDIRS for any kernel make option? :)
suokko: That means also for modules_install
suokko: marvin24: I think swtcl is different for all generations :/
suokko: You can test it if you set RADEON_NO_TCL=1 or something like that in you environment
marvin24: suokko: I have no tcl which i could disable .. :(
suokko: Do you have rendering problems with it?
marvin24: suokko: still searching for the cause of https://bugs.freedesktop.org/show_bug.cgi?id=23532
nanonyme: suokko: Nope.
marvin24: suokko: can you test it with RADEON_NO_TCL=1
nanonyme: suokko: Sounds good.
nanonyme: modules_install is painfully slow as it is.
nanonyme: That should help, me thinks.
suokko: marvin24: drmRadeonCmdBuffer: -22 means kernel doesn't accept the command stream
suokko: So you would have to look what dmesg says when that happens
suokko: nanonyme: It helps a lot for me. But depmod still takes time if I run X and three is no memory to keep all module info in cache
suokko: and I think that r300 swtcl handles flush if primitive changes
suokko: and some state has to be changed
marvin24: suokko: dmesg is shown in comment #1
suokko: marvin24: So problem is Z is used in state but no Z buffer reserved
Neo_The_User: if i want the radeon DDX from git to be installed to /usr/lib64, do i do --prefix=/usr/lib64 because it uses /usr/lib when i do --prefix=/usr :S
marvin24: Neo_The_User: --libdir is your friend
adamk: And --with-xorg-module-dir
Neo_The_User: so --libdri=/usr/lib64
marvin24: and s/dri/dir/
Neo_The_User: what is s/whatever/whatever mean?
Neo_The_User: i see that everywhere
marvin24: Neo_The_User: s/a/b/ means substitute a by b (man regex)
Neo_The_User: i think i got it now. --prefix=/usr --libdir=/usr/lib64 --with-xorg-module-dir=/usr/lib64/xorg/modules/drivers
adamk: That looks good to me.
Neo_The_User: thank you adamk! :) *goes back to re-installing gcc, ppl, bintuils, mesa, and everything else to /usr/lib64* have a great one everybody!
suokko: eats multilib
kcodyjr: yeah, i don't know why people have such a fetish for that. if you need 32-bit app compatibility, it's unlikely that any single process is going to need >2G, so why not just run a 32bit userspace
suokko: maybe because 32->64 kernel interface has some overhead
kcodyjr: so does the extra memory consumption. 64-bit doesn't necessarily mean faster, it just means more ram available at once
kdekorte: kcodyjr, but it can mean faster since 64bit has extra registers to use and the fact that I can use all my RAM and 64bit is where everything is going
kcodyjr: those extra registers are often counterbalanced by having to copy twice the pointer size around, and you only need a 64bit kernel to use all your RAM.
kcodyjr: and, not everything, i haven't seen too many 64-bit pda's
kcodyjr: the only reason firefox needs to be 64-bit is if 5K or so simultaneously opened jpg images just isn't enough for you
kdekorte: kcodyjr, you have your opinion, I have mine...
kcodyjr: there's little room for differences of opinion when quantifiable facts are available. 64-bit userspaces are unnecessary in most common use cases. wanting to do it, and thinking it's cool, is not the same as necessary.
kcodyjr: that said: it's cool for a different reason than performance. it forces app developers to behave correctly about bitness in their sources.
adamk: I've seen a few people with this error in their dmesg, and no direct rendering... Does anyone know what would cause it? ERROR Cannot use PCI Express without GART in FB memory
kcodyjr: confusing error message
rnoland: adamk: that looks like linux w/kms?
rnoland: what it is telling you is that the GART has been allocated in main memory rather than in VRAM
adamk: In this case, I doubt that the user has KMS, but I'll run that possibility past them.
kcodyjr: actually, from reading the source
kcodyjr: that error will happen when userspace has not supplied the pcigart offset
kcodyjr: are you using a kms kernel with a non-kms ddx ?
adamk: This is someone on the compiz-fusion forums ( http://forum.compiz-fusion.org/showthread.php?t=11934 ). I just replied asking them to show me /proc/fb .
adamk: It sounds like this is a stock Jaunty system, though, so I doubt KMS is involved.
kcodyjr: what kernel version?
adamk: 2.6.28-15
kcodyjr: shouldn't be any kms in that.
adamk: Yeah, that's what I was thinking. I might need to get him to enable debugging in the drm.
kcodyjr: i can't swear that's the kms code path anyway though, so it's probably still the same cause - userspace not doing appropriate setups
kcodyjr: sounds like it's probably not worthwhile to tell the user to start grepping through their kernel sources.
bfrog: is 5870 still r700 or is that some new chip?
luboss: adamk: hi adam
adamk: Hello.
otaylor: MrCooper: You can explain to me "Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug!", right? (remember seeing something scroll by a few days ago)
ajax: seems straightforward to me...
otaylor: ajax: well, it would be straightforward, except that warning occurs in places that glXCreatePixmap apparently works
otaylor: ajax: so I'm wondering if it's a) mesa being pedantic and annoying and making life hell for real apps or b) some sort of bad setup where mutter/clutter isn't initializing GL correctly
ajax: probably a), but probably also our fault for leaving open a case where CreatePixmap works even though we don't advertise 1.3
adamk: The compiz developers remarked that they had some discussion on #dri-devel about that error.
otaylor: ajax: I'm pretty surprised that the F12 intel drivers don't advertise even 1.3 ... I thought they had GLSL, etc. (OK, off-topic for this channel...)
luboss: adamk: I've upgraded all possible related things to most recent versions but the same problem with "unable to allocate texture" still exists
ajax: GLX version != GL version.
otaylor: ajax: true, but if something supports GL 2, it would be suprirsing not t support GLX 1.3
adamk: luboss: Update the bug on Freedesktop with your most recent Xorg.0.log file, then.
adamk: Time for me to head out.
otaylor: ajax: I don't have a particular idea of what's in GLX 1.3, though
adamk: bbl.
ajax: well, glx is only up to 1.4, come to that.
otaylor: ajax: OK, if it's probably not bad setup, I'll file a bug in fedora bz to patch that warning out (assuming that there really are missing 1.3 components)
ajax: and we really should have glx 1.4 implemented by now. but idr gave some reason why we're not there yet that i forget offhand.
otaylor: ajax: since you can't use TFP without glXCreatePixmap
ajax: yeah
luboss: adamk: I think it would be better to start over with new bug, in the bug they mention [driAllocateTexture:636] unable to allocate texture, I've got the same text except the number (mine is 635), does it matter?
adamk: Given the age of the original bug, and the fact that the reporter is not in the picture any more, opening up a new one is not a bad idea, IMO.
adamk: And now I'm heading out.
luboss: thank you adamk, bye
suokko: ajax: Problem was to read the supported version from dri driver in xserver so version is hard coded to 1.2
agd5f: otaylor: see the #dri-devel archives from this morning
agd5f: idr discussed the issues regarding glx 1.3
otaylor: agd5f: are there archives of the channel somewhere? (practically speaking, I'm happy just punting the problem over to ajax if I know it's not my code's fault)
osiris_: otaylor: http://people.freedesktop.org/~cbrill/dri-log/
otaylor: osiris_: ah, found that with google, but 9-23 was empty, guess it's in an unexpected timezone
otaylor: (my assumption was that it was just broken, didn't check 9-22)
otaylor: wow, idr was *not* being helpful
nanonyme: He wasn't?
suokko: agd5f: Richard added VBOs to r600 using copy/paste code from r300 which has still r300 variable name in there
agd5f: suokko: yeah, needs some cleanups
suokko: That cause compile problems for cjb
agd5f: suokko: got the error somewhere?
suokko: cjb: r700_render.c:858: error: 'r300' undeclared (first use in this function)
otaylor: nanonyme: well, I htink the conversation ended in an OK place "Hkmm, this is all screwed up, we need to fix it", but the initial suggestion of "you should jsut change your code to call glXCreatePixmapSGIX instead, it will work the same, but be pendantically correct" didn't strike me as helpful
kcodyjr: the way i read it, pedantic correctness from the outset would have prevented the issue that led to the conversation
agd5f: suokko: fixed
otaylor: kcodyjr: well, yes, if glXCreatePixmap() hadn't been made to work, then some other solution would have been found, but practically speaking glXCreatePixmap() is the current mesa api and you can't make it warn post-hoc
kcodyjr: what is the goal: mesa api compliance, or opengl api compliance?
kcodyjr: that's a rhetorical question. and the reason why the conversation may have been unsatisfying for some.
MostAwesomeDude: GLX, not OGL.
MostAwesomeDude: The "goal" is "just works," and following the spec is a convenient shortcut.
otaylor: kcodyjr: just seemed to be blaming the victim ... my take on library maintenance is you keep your users apps working and not spewing warnings until you can't. And since presumably the actual goal is to just support GLX 1.3, starting to spew warnings that won't matter in a bit didn't seem helpful to me.
rnoland: agd5f: could the font/menu corruption be related to 32bit visual?
kcodyjr: thank you MostAwesomeDude on both counts.
kcodyjr: and -not- following the spec leads to not so convenient problems, but otaylor is right about what's done is done and now live with it
MostAwesomeDude: Eh. I'm just glad that this can be fixed relatively painlessly while the only two big consumers of this are KDE4 and Compiz.
agd5f: rnoland: maybe, but it doesn't seem likely. so far I've had no luck tracking it down
rnoland: agd5f: sigh... the data is there, it just seems like it isn't flushed properly....
otaylor: MostAwesomeDude: Actually, if you read that to the end, it can't be fixed in KDE4 and Compiz (and gnome-shell!), because there's no way to use TFP without GLX 1.3
otaylor: MostAwesomeDude: if you follow the spec exactly
agd5f: rnoland: I know. the fix is probably a one liner...
otaylor: MostAwesomeDude: So, the only thing that could be done currently in Compiz (et. all.) is to refuse to work with the current open source drivers
kcodyjr: if there's really relatively few users, there will never be a better chance to repair the api divergence, and make compiz/kde4/gnome-shell become aware of the needed extensions in glx1.2 cases
otaylor: kcodyjr: If glx1.3 is unimplementable in the open source drivers, then maybe
kcodyjr: what about all the hardware that's limited to 1.2
kcodyjr: or is that really reaching too far back to care?
otaylor: kcodyjr: well, remember that Compiz can't start using some new extension until the current Mesa versions flush out of use anyways and everbyody has the new extension, which is roughly speaking 2 years from now
MostAwesomeDude: otaylor: They could fix it now and let distros pick it up on their own time.
otaylor: kcodyjr: I dont' have a good view of glx-1.3 what's required there from a hw point of view
MostAwesomeDude: That *is* the entire point of things, after all. Apps are allowed to be bleeding-edge because distros will pick out the versioning problems.
kcodyjr: i'm with MostAwesomeDude on that one, if the distros want to hurry something to widespread deployment, that's their problem. remember gcc-2.96.
otaylor: MostAwesomeDude: uh, so, say, I'd patch gnome-shell in a way that would make it not work on anybody's system, then when people coplained I"d say "you don't have a new enough version of mesa, you can apply this patch?
MostAwesomeDude: otaylor: I have no clue what gnome-shell is and google points me towards gnome-terminal.
MostAwesomeDude: But I gather it's 3D and cool.
MostAwesomeDude: And sure, you could make it do whatever. Make it require a stupidly fresh Mesa.
otaylor: MostAwesomeDude: http://live.gnome.org/GnomeShell - GL based compostiing compositor/window manager/app launcher/app switcher/etc.
kcodyjr: what it comes down to for me is, much of mesa was written when i was still waiting for the legal privilege to buy booze, half a lifetime ago. long term maintainability therefore trumps short term make-it-work, and by definition, any hack to "make it work" is unlikely to survive major reworking under the hood
MostAwesomeDude: Ooh. Snazzy.
otaylor: MostAwesomeDude: core gnome 3.0 component.
kcodyjr: leave it to widget toolkits to mandate accelerated gl for browsing the web.
MostAwesomeDude: otaylor: Ah. I see nothing wrong with asking distros to pick up the newest drivers in order to get the newest shinies.
nanonyme: For one reason or another GnomeShell is *horribly* slow for me on r600. :)
otaylor: MostAwesomeDude: we like having testers
agd5f: nanonyme: profile it and find out why
kcodyjr: end users running end-user distros don't make for good testers, you wind up doing more coaching than testing
otaylor: MostAwesomeDude: Testers tend to use released versions of mesa
otaylor: nanonyme: does compiz work?
nanonyme: agd5f: I mean horribly slow as in I can't even click any buttons, the environment is virtually unresponsive. :)
otaylor: nanonyme: have you tried turning on the mesa debugging of sw fallbacks? wouldn't surprise me if clutter is just using some part of GL that hasn't been gotten to yet
nanonyme: otaylor: Yeah, nice and fast.
nanonyme: KDE compositing and Compiz run lightning-fast, GnomeShell is just *slow*.
otaylor: nanonyme: it's probably pretty simple, though it's possible that whatever the simple answer is non-trivial to implement
osiris_: nha: I'd like to push the patch from #22741 any comments?
nanonyme: I guess I could start sysprof, then switch to GnomeShell, let it fallback to Metacity and have sysprof analyze results.
nanonyme: Starting sysprof in GnomeShell is pretty much impossible due to the speed.
otaylor: nanonyme: sysprof also has a text-only collection mode
otaylor: nanonyme: though I dont' think there is much advantage over that than just running the gui as you describe
nha: osiris_: Acked
kdekorte: I'm using clutter and gstreamer to playback some video and on r600 (using todays mesa) the image looks like this http://imagebin.org/64978 (might have to reload it a couple of times if it comes up white).. any way we can fix the grey areas. Willing to send test code
kdekorte: guessing may the normals are wrong?
zhasha: MostAwesomeDude: ping
MostAwesomeDude: zhasha: Pong.
zhasha: I have something you should see
MostAwesomeDude: That sounds familiar. :3 Go ahead.
zhasha: imagebinhttp://imagebin.org/64981
zhasha: err
zhasha: http://imagebin.org/64981
zhasha: It's coming along nicely
MostAwesomeDude: o/
zhasha: been struggling with a custom treemodel for Gtk
zhasha: next step is reading the damn xml spec file :P
AMD_Fanboy1993: k system is all re-build... now.. erm... how do you turn off KMS by default in the kernel again without recompiling?
AMD_Fanboy1993: drmnomodesetting?
chithead: radeon.modeset=0 boot parameter
zhasha: AMD_Fanboy1993: radeon.modeset=1
kdekorte: radeon.modeset=0
zhasha: err, =0
AMD_Fanboy1993: wow! thanks guys! fast reponse too!
zhasha: MostAwesomeDude: do you have a the vala compiler?
MostAwesomeDude: zhasha: No.
zhasha: so I should send this as C code I guess
zhasha: won't send this useless version to you, just wanted to show off my new treemodel :P
MostAwesomeDude: I guess. I don't know what vala is.
AMD_Fanboy1993: wants to know
zhasha: a new GNOME language making my life easier
AMD_Fanboy1993: oh nice
MostAwesomeDude: Ah.
AMD_Fanboy1993: doesn't use gnome but still thinks its cool
zhasha: it's like C++, using GObject
AStorm: hmmh
AStorm: with latest mesa, I get:
AStorm: make[5]: *** [r300_draw.o] Error 1
AStorm: and I can't find any r300_draw.c build
AStorm: weirdness
AMD_Fanboy1993: oh that reminds me! the microcode takes 5 mins to load at boot
zhasha: it compiles to C, so it's not a problem to just compile it and send it over
AStorm: AMD_Fanboy1993: huhwhat?
AStorm: hmm
AMD_Fanboy1993: usually brews some coffee during the microcode to load for the radeon card
AStorm: ah, I ran out of space
AStorm: curses make for not having better error messages
agd5f: AMD_Fanboy1993: it shouldn't. I suspect something else is wrong
AMD_Fanboy1993: oh...
AMD_Fanboy1993: yeah when the kernel loads, it stays at something about microcode then keeps going
AMD_Fanboy1993: USB and network dont work yet on boot
AMD_Fanboy1993: does the microcode actually re-flash my GPU?
AMD_Fanboy1993: permanently?
nanonyme: No, it doesn't Flash your GPU at all.
nanonyme: s/F/f/
agd5f: AMD_Fanboy1993: no. it just loads the ucode onto the chip. it has to be loaded everytime it's powered up
AMD_Fanboy1993: how do i debug the microcode loading so i can see more of whats going on?
idletask: Good evening
AMD_Fanboy1993: GOOD EVENING!! :) how r u?
idletask: Fine, I guess
idletask: Thanks to the knowledgeable folk in this very channel, I could get KMS and DRI at the same time
AMD_Fanboy1993: hopes its NOT me
idletask: But I still have a dmesg message that bothers me, and have done so for quite some time
spreeuw: what does it say?
idletask: "mtrr: type mismatch for d0000000,8000000 old: write-back new: write-combining" <--- d0000000 is reported as "region 0" by lspci -vvv for my graphics adapter
AMD_Fanboy1993: what is with all these MTRR errors? i've been getting some too
spreeuw: mtrr: MTRR 3 not used
AMD_Fanboy1993: well.. used too
spreeuw: is what I have
idletask: spreeuw: from what? The kernel?
AMD_Fanboy1993: brb new boot loader
DanaG: oh yeah, kernel dailies are still failing to build.
nanonyme: idletask: Which chip?
DanaG: ={
idletask: nanonyme: rv370
nanonyme: DanaG: Should that be surprising? :)
DanaG: nope, I suppose not.
nha: zhasha: that looks neat; now add translation of those hex values to named constants, and it could be really quite neat :)
zhasha: nha: that's what I meant by "next step is reading the damn xml spec file"
zhasha: the right pane will show state
zhasha: and everything will be translated
zhasha: it will also have a compare view to compare a CS from 2 drivers
suokko1: What is that tool for? Reading IBs from KMS?
spreeuw: idletask: yep dmesg
adamk_: Off-topic, I know, but are the mach64 2D specs available anywhere?
spreeuw: with current git drm/mesa dri1
zhasha: it's for debugging CS' from different radeon drivers
zhasha: so that we may track r300g bugs easier
idletask: spreeuw: the DRM/mesa version seems unrelated in my case, I've had this message for aeons
ajax: adamk_: not that i know of. why on earth would you want them?
spreeuw: idletask: lookup general mtrr setup then
spreeuw: the mplayer docs have a section on it
spreeuw: could also just be normal
spreeuw: in your hardware setup
adamk_: ajax, Someone on #ati was asking about them, working on 2D drivers for some OS he's working on.
spreeuw: idletask: cat /proc/mtrr
idletask: spreeuw: done that, and the aforementioned region is indeed reported as write-back by the kernel
essial: I heard someone over here was aware of the location of open Mach64 chipset specs
essial: (at least the 2D accelerated information)
rnoland: idletask: you are not allowed to overlap anything except uncached on WV
rnoland: WB
idletask: But then why does the X server insist on it being write combining at all? Or is that the radeon driver, or something else?
adamk_: essial, Now, now... I didn't say that anyone here was aware of their location :-)
kcodyjr: that's a symptom of a broken boot-time mtrr table, since the default behavior for an unspecified range is uncached
adamk_: Oh wait, I did.
essial: :p
kcodyjr: there should be options for fixing up the mtrr table on boot
adamk_: essial, Sorry, I forget the negative.
adamk_: "not aware" :-)
rnoland: idletask: kcodyjr all of my current machines set a variable mtrr of WB across all of memory...
kcodyjr: rnoland, that's incorrect behavior
rnoland: it is really annoying... PAT is the way...
idletask: kcodyjr: and why would the mtrr table be broken on boot?
rnoland: kcodyjr: tell that to bios folks...
kcodyjr: pat's and mtrr's combine to get "least-cached" behavior between them
kcodyjr: so a wb mtrr + wc pat == wb accesses
essial: ah well
essial: I'll keep digging
essial: you wouldn't happen to know what kind of tag line ati ususallyputs on their first page for device specs would ya?
kcodyjr: you need there to -not- be an mtrr range covering the i/o range
rnoland: kcodyjr: i would have to review the intel docs... but i think that combo is WC
kcodyjr: rnoland, someone must have tried and failed, because the kernel has fixup code
kcodyjr: i just reread them last weekend
nha: zhasha: add a feature to compare the register state at given points in the command stream; i.e. to compare to CS, state might be emitted in a different order, so what we're really interested in is differences in the registers at the time a draw call is issued
AMD_Fanboy1993: im trying to compile -ati on my *BACKUP* fedora computer and erm.. i get a xinerama configure.ac error (syntax error)
spreeuw: hmm
rnoland: at least intel and asus both do this...
AMD_Fanboy1993: xinerama commmand not found
spreeuw: openarena.i386: radeon_common.c:1257: rcommonEnsureCmdBufSpace: Assertion `rmesa->cmdbuf.cs->cdw' failed.
kcodyjr: xinerrific. don't use xinerama.
spreeuw: Received signal 6, exiting...
nanonyme: AMD_Fanboy1993: Maybe mising some build deps?
AMD_Fanboy1993: nope
zhasha: nha: again, that was the plan :P
AMD_Fanboy1993: i have it installed my fedora computer
nanonyme: What's the actual error message?
nha: zhasha: okay, I shut up now ;)
zhasha: nha: the red dots indicate the current position in the CS
rnoland: kcodyjr: 0x0/0x100000000 BIOS write-back set-by-firmware active
Terman: I have a small "bug" report (performance regression with kms)
kcodyjr: rnoland, incorrect behavior set by the firmware. enable the kernel fixups.
rnoland: kcodyjr: i'm on freebsd first of all....
nanonyme: Terman: Hmm, regression with non-KMS->KMS or KMS->KMS?
zhasha: no you're welcome to come with input, but right no I have a translation module to write (and the translation is in an XML file)
idletask: Gah, the causes of this message are way over my head
kcodyjr: rnoland, ouch. no fixups for you.
kcodyjr: you could fall back to a /sbin/init.wrap script hack to fix them up manually
rnoland: kcodyjr: actually attempting to rewrite them has generally proved to lock up the machine...
AMD_Fanboy1993: ./configure line 12446 syntax error near expected token 'XINERAMA.'
Terman: 2.6.31-44-desktop, kms: 4502 frames in 5.0 seconds = 900.340 FPS
rnoland: but that is after it is up...
kcodyjr: which is why you have to do it as early in the boot as you possibly can
nanonyme: AMD_Fanboy1993: Yeah, sounds like a missing build dep... Maybe xorg macros?
rnoland: never tried to cause it to modify early or in the loader.
Terman: 2.6.31-44-desktop, nokms, vga: 9315 frames in 5.0 seconds = 1862.982 FPS
AMD_Fanboy1993: ./configure line 12446 XORG_DRIVER_CHECK_EXTENSION, xineramaproto')
zhasha: nha: do you by any chance know for sure whether packet1 ADDR{1,2} fields should be shifted like packet0's ADDR field (<<2)
AMD_Fanboy1993: maybe i dont have macros brb
kcodyjr: i've never tried it with freebsd, but linux was happy with doing it in-kernel, or doing it between the kernel and the userspace init
rnoland: kcodyjr: yes, it would probably work before any real mappings take place.
AMD_Fanboy1993: its installed
kcodyjr: i do know the only time mtrr's are allowed to overlap is when you have an uncached sitting within a writecombining range. you will have to screw with them.
nha: zhasha: I'd have to look it up, it's been too long
nanonyme: Terman: If those are glxgears fps', just ignore them...
idletask: feels like an idiot
idletask: I don't understand anything :/
rnoland: kcodyjr: yes, WC can overlap UC, and UC can overlap anything iirc.
nanonyme: idletask: Hey, I've felt like that about every day for the past four years. :3
Terman: nanonyme: of course they were done with the best-of-all-benchmarks :-)
AMD_Fanboy1993: nanonyme: nah you seem to know your stuff
kcodyjr: glxgears is not a benchmark. it's not even a skidmark.
AMD_Fanboy1993: see this is why i hate package managers..
Terman: nanonyme: but all that changed are the radeon kernel module (with/without kms compiled in) and the ttm module (only present if kms-radeon module is loaded)
suokko1: essial: Have you looked at code in mach64 driver in freedesktop git?
Terman: nanonyme: so why is the code half as fast as before?
cohn: < kcodyjr> glxgears is not a benchmark. it's not even a skidmark. <--- xD
adamk: Terman: Use a real test of the drivers, then get back to us :-)
AMD_Fanboy1993: on my distro, not a problem. and since package managers always *RENAME* the original packages with something even dumber than its original name, nothing ever works right
spreeuw: hey cool the remaining Neverball corruption is gone
spreeuw: the ball's shader
spreeuw: gleam shader
spreeuw: openarena is crashing after launch though
spreeuw: wow excellent
spreeuw: spring Unit textures are visible now
AMD_Fanboy1993: any fedora users online?
airlied: suokko1: I'm not 100% sure currently I think it requires random access.
airlied: but I might be able to fix that
AMD_Fanboy1993: oh yay airlied!! i cant compile -ati on my fedora back up box
AMD_Fanboy1993: ./configure line 12446 XORG_DRIVER_CHECK_EXTENSION, xineramaproto')
suokko1: airlied: I did post to mailing list alternative get value function that might work better for parser
suokko1: If parser was designed around that idea
nanonyme: AMD_Fanboy1993: Being in Tech Uni for four years is enough to make quite a few people feel like idiots. :p
suokko1: AMD_Fanboy1993: Too old xorg-macros
agd5f: essial: the mach64 driver source is your best bet
AMD_Fanboy1993: thanks suokko1 :)
essial: greatI guess so
agd5f: essial: there were specs at one time, but that chip is so old, I'm not sure where they are at this point
agd5f: essial: they were nda anyway
essial: I'm sure, but you'd think with them being old, they'd dump the docs in with the rest of the opened specs
kcodyjr: but that does require an ip review of the docs, and it may well be that mach64 is so damn old it isn't worth the trouble
essial: sighs
essial: Hey that machine plays starcraft like a champ
essial: well
adamk_: essial, They'd have to go through the same review that the current specs are going through, I'm sure.
essial: somewhat
kcodyjr: otoh, i don't know what ip is left from back then, that isn't already all over the intarwebs
adamk_: Oh, kcodyjr already said that.
essial: kcodyjr: from my research, seems like none of it is on the internet :p
agd5f: essial: like I said, can't find them. probably been moved to tape
kcodyjr: you won't find 0-day sploits with a google search either
nanonyme: X)
nanonyme: Ah, good old tape archives?
kcodyjr: never underestimate the storage capacity of a footlocker full of tapes.
AMD_Fanboy1993: hahah xorgisbroken
xorgisbroken: X)
kdekorte: hey dinoshade it working right now... great!
idletask: I kind of agree... Why, for instance, is OpenGL implemented by Mesa and not within X itself? What is the purpose, today, of having the OpenGL library out of the graphics display engine?
nanonyme: Eek. :)
idletask: Or any 3D API
nha: idletask: I hope you're joking
idletask: nha: I'm not
airlied: suokko1: yeah I think I'd have to check all the callers
airlied: the packet3 ones being the main ones
rnoland: idletask: there are other consumers of 3d besides X
adamk_: So any further thoughts on this bug: https://bugs.freedesktop.org/show_bug.cgi?id=23901
airlied: I suppose I could keep track of last idx and assert if it geos backwards
suokko1: seriously? Why would you want to have everything in one single huge library?
idletask: rnoland: which ones?
airlied: agd5f: I think I have the nda ones locally somewhere, but I suspect the driver makes more sense
nha: idletask: ever heard of this newfangled thing called "direct rendering"?
AMD_Fanboy1993: idletask: because
idletask: suokko1: why would you want 5+ different components that need to be in sync just to have basic 3D effects? The argument goes the other way around... I don't know much about 2D/3D tech, but it seems very complicated
Terman: adamk_: same result with neverball: with kms compiled in and activated: 15-17 fps, without kms: 35-40 typical, seldom down to 30 fps
AMD_Fanboy1993: idletask: and the code is a bit messy too in my opinion
idletask: nha:well, ultimately, you need a display
nha: idletask: I agree that having to sync all those components is daunting, but X is not the right place for the hardware-dependent stuff
AMD_Fanboy1993: not to be insulting
adamk_: Terman, Now *that* is more likely to get a response from the developers.
adamk_: Terman, Having said that, last I heard there were known performance issues with KMS, though I don't know if those have been resolved.
nha: Terman: ouch, that sounds bad :(
airlied: its not perf issues is vsync
adamk_: Ahhh.
airlied: you either want tearing or don't want tearing
AMD_Fanboy1993: how do you toggle on and off vsync?
nha: still, performance shouldn't drop from 35 to 17 because of vsync :/
suokko1: airlied: except tearfree code only affects max 10% real applications and 50% for gears
stikonas: idletask: X hardware drivers is slowly moving to kernel and mesa out of X
idletask: nha: then, what would be the route to take to reduce that number of components? There have been several efforts over the years... Berlin, DirectFB, and now Wayland...
suokko1: So there is others bottlenecks too
agd5f: adamk: does a force dpms cycle bring both monitors up?
agd5f: *forced
airlied: we should add an option to the driver to disable it for etsting
nha: airlied: that's a performance drop from kind of bearable to horribly slow, and vsync is really not an excuse for that :/
AMD_Fanboy1993: anybody know what source file the vsync code is in?
stikonas: idletask: so we can get rid of DDX driver -- 1 component less
AMD_Fanboy1993: for r600?
adamk_: agd5f, I'll tell you in a minute, as soon as I reboot again with KMS enabled.
Terman: airlied: ah, thanks! that sounds like an explanation
nha: idletask: Wayland is not a route to reduce that number of components; in a way, it's actually the opposite
airlied: Terman: what gpu is it btw? also agp or not?
idletask: stikonas: what does DDX stand for? In this channel, it refers to xf86-video-ati... What is its exact purpose? For instance, as opposed to DRI
Terman: x1400 mobility
lwithers: airlied: a few days ago you helped me with zaphod, and provided a patch -- I've found the patch does work and zaphod is (so far at least!) stable, so thank you
stikonas: idletask: Device Dependant X
stikonas: it is another name for X drivers
airlied: lwithers: must push that patch.
idletask: stikonas: OK, thanks for the information
stikonas: xf86-video-atiis DDX
lwithers: I initially reported a crash but it turns out X just crashes if I ever restart it -- nothing specific to zaphod since it happens whether it's enabled or not
nha: idletask: in fact, we're already moving in a direction where the DDX could potentially be removed in the future; not sure if it'll really happen, and if it happens it will definitely take a lot more time
adamk_: agd5f, 'xset dpms force off' simply causes the CRT that's working to blank for a second before coming back...
adamk_: agd5f, Here we go.. . force suspend blanks the CRT till I hit a key... Even then, though, the LCD stays off.
agd5f: adamk_: ok
rnoland: hrm, whatever was going on with the lighting in engine is fixed now...
idletask: nha: which means, all hw handling would be... Where? In Mesa? In the kernel?
suokko1: idletask: Mesa/Gallium
nha: idletask: those two, yes
adamk_: I'm about to open another bug report for some serious flickering with this CRT at 1600x1200 with KMS enabled.
idletask: looks up Gallium
osiris_: for someone that one day complained about WoW being rendered upside down - turning the full screen glow effect off fixes it
nha: WoW renders upside down? Now that's a useful bug
kcodyjr: stand the monitor upside down?
nha: get all those addicts back to being productive ;P
nanonyme: nha: Are you sure they wouldn't just turn the monitor upside down?
osiris_: nha: I think it's the problem with texture coordinations in FBOs
nanonyme: Addicts can be surprisingly resourceful. :p
nha: osiris_: oh, that makes a lot of sense
idletask: http://en.wikipedia.org/wiki/Gallium3D <-- is that what Gallium refers to?
nanonyme: Probably.
kcodyjr: no worse than working the mouse upside down because the ball cracked, and they can't replace it because they're jonesing by the time they're 10 feet away from it...
nanonyme: Yeah, it is.
osiris_: nha: maybe that's the reason why all fbo tests are failing
nha: if it is, that would be a nice and easy fix
nha: though I'm fairly certain it's not the solution to all of them
nha: there's one test that fails depending on the pixel format (i.e. it succeeds for rgba, but fails for stranger formats like RGB5 and such)
nanonyme: Well, isn't the best you can do to just fix bug after another and hope fixing one will fix others instead of create more... ;)
MrCooper: otaylor: I think there were other cases where apps actually broke because they tried using GLX 1.3 APIs, maybe that's what motivated idr
stikonas: it's high time to change the topic to "No 2D/3D for R800" :)
chithead: not that you can buy r800 cards anywhere
stikonas: yeah, even Phoronix has not managed to get that card
chithead: heh yeah, the article was some sort of hidden complaint
agd5f: adamk_: does force off work any better?
adamk_: agd5f, "force work" just caused the CRT to go blank for a second and then come back immediately.
adamk_: The LCD didn't do anything.
idletask: BTW, about 3D... Wine has a Direct3D layer now, what does it use as low level APIs?
adamk_: Is there any reason why force work wouldn't work at all?
adamk_: Wait...
adamk_: I just tried force off again, and it did the same as force suspend (ie. blank the CRT, reenable the CRT on key press, but does nothing to the LCD).
stikonas: idletask: ir does D3D->OpenGL conversion
kcodyjr: how about "no pci support for hercules graphics devices"
idletask: stikonas: that was my guess, but I wasn't sure
rnoland: agd5f: um, that last commit looks like it horribly broke vdrift...
stikonas: idletask: I think that wine requires Frameboffer Objects, which requires kernel modesetting
stikonas: s/Frameboffer/Framebuffer/
agd5f: rnoland: the draw prims stuff still needs some sorting out
kcodyjr: frameboffer objects? that a new adults-only api?
rnoland: agd5f: the textures are horribly broken now...
kdekorte: I think the lighting is wrong in the projtex demo. The textures are finally in the right spot, but they are not lit right as compared to when running in software mode
rnoland: agd5f: to the point that i can barely find the buttons to exit the game
spreeuw: rnoland: what game?
rnoland: vdrift
spreeuw: oh
spreeuw: here current mesa crtashes openarena
spreeuw: but it fixes neverball
spreeuw: and springrts unit textures
agd5f: richard's working on sorting out the draw prims stuff now
rnoland: agd5f: cool... nexuiz is also borked...
rnoland: agd5f: is this a new extension that was enabled?
rnoland: i don't see it in that last commit...
agd5f: rnoland: hw support for index buffers
rnoland: ah, ok... well it was working with that original commit earlier...
kdekorte: vdrift crashes on me with the Assertion bo->space_accounted faile in radeon_cs_gem:121 cs_gem_write_reloc
rnoland: i just pulled in your last commit and it went nuts...
spreeuw: oh naother commit
spreeuw: 3 tonight
spreeuw: atleast
spreeuw: ah yes
kdekorte: quake3, menu screen is black with a rainbow quake3 logo
kdekorte: with latest mesa
spreeuw: openarena has some problem like thta too
spreeuw: it no longer crashes with 30second old git
spreeuw: but the menu sceen is only half visible
agd5f: spreeuw, rnoland: you can force the non-ib path by commenting out line 1134 of r700_render.c
rnoland: agd5f: not a big deal for me... i'll wait for richard to sort it out...
spreeuw: me neither I'm happy with the progres as is
idletask: When you use KMS as I do, is there any reason left why you cannot just use Alt+Fx to switch to a VT? Is the X server programmed so that you need Ctrl+Alt?
airlied: yes, since alt is used by lots of things
airlied: it has nothing to do with kms
nanonyme: Doesn't X put the keyboard into some different mode altogether?
idletask: airlied: OK, thanks for the information
spreeuw: ctrl alt Fkey always has been the way to switch
idletask: nanonyme: yes, and that troubles me too... I don't see why it would be any different from the console
spreeuw: guess they had to pick one
spreeuw: idletask: when you're in a kvm concole
spreeuw: doesnt alt -> or alt <- work?
idletask: spreeuw: well, what with KVM? X acting its own with the keyboard predates KVM by far
spreeuw: yes I know
kdekorte: agd5f, still getting lockups on my rv635 in KMS/DRI2 mode. I have drm-next, mesa (git) and libdrm and ddx from fedora rawhide. Any recommendations?
spreeuw: just wondered how kvm consoles are treated
spreeuw: are they under X now?
spreeuw: or am I mixing up things?
idletask: spreeuw: it's qemu that provides the console, really, and it's "just another X app"
spreeuw: is the tty framebuffer still seperate?
nanonyme: idletask: Err, don't get me wrong. It doesn't trouble me at all that X sets keyboard into a different mode. :)
spreeuw: oh sry for the confusion I mixed up some acronyms
idletask: nanonyme: it does me
spreeuw: KMS and kvm
idletask: spreeuw: I kind of wondered indeed
idletask: But yes, alt+arrows still work with kms consoles
idletask: And no, kms consoles don't need X
spreeuw: so kms unifies kernel consoles ddx and 3d ?
idletask: As far as I understand, no
spreeuw: ok
idletask: In fact, I don't know what kms does really, except that it seems a huge step forward for the state of Linux graphics
idletask: I don't really know what the "mode' stands for in "kernel mode setting"
idletask: s,really ,,
spreeuw: it does the 2d driver with the 3d engine as far as I understood
spreeuw: more extensively so than before
Neo_The_User: if i come across any compiling errors on gcc 4.5 for xf86-video-ati, should i report the bugs to gcc or to you guys?
airlied: you'd send patches to fix them
Neo_The_User: hahh
Neo_The_User: alrighty then. brb :)
nanonyme: idletask: When people talk of KMS, they actually mean both the modesetting and memory manager parts, usually.
nanonyme: The modesetting memory management afaik being the more interesting (and more troublesome part) of it.
nanonyme: s/modesetting //
nanonyme: (or at least reading airlied's blog the initial development process sounded pretty painful ;)
Neo_The_User: how can the founder of most things think his own project is painful, if you're the one who wrote it?
nanonyme: Well, the implementation apparently was somewhat untrivial...
idletask: Neo_The_User: because you need to account for the legacy?
Neo_The_User: good point
kcodyjr: it's actually a bastard of a thing to try and do and preserve kernel portability
idletask: Even though the kernel help entry explicitly says that enabling kms with a userspace that has no support for it "will cause pain"
Neo_The_User: ok i have kms on by default and i dont have the 1920x1200 buffer thingy
Neo_The_User: and i put in like 3,000 kilobytes into the kernel frame buffer console support thing
idletask: kcodyjr: when I though "legacy", I actually thought "userspace", I kind of forgot the fact that Linux ran on x CPUs (x > 10)
nanonyme: I recall memory fragmentation being one of the tricky problems mentioned in the blog.
idletask: Neo_The_User: you must not enable any card specific frame buffer if you use kms
Neo_The_User: what does that mean?
Neo_The_User: wait nvm
Neo_The_User: i dont
idletask: Don't use atyfb if you have an ATI, don't use intelfb if you have an Intel chip and so on
Neo_The_User: all i have in FB support is the EDID stuff
Neo_The_User: and in frame buffer console, i put in around 3,000 kb
idletask: And fbcon?
Neo_The_User: yup
adamk_: Neo_The_User, What does 'cat /proc/fb' show?
idletask: 3000 kb what? I didn't have to set any amount of memory whatsoever to get it to work...
stikonas: will atyfb be removed from the kernel?
Neo_The_User: nothing at all
idletask: Not in the kernel config nor in the BIOS
Neo_The_User: its ati fb
Neo_The_User: not aty lol
kcodyjr: nanonyme, i'm actively working on taking a whack at the fragmentation problem
Neo_The_User: actually RADEON_FB to be more precise
Neo_The_User: or FB_RADEON
Neo_The_User: forgets
nanonyme: kcodyjr: Oh, it didn't get a good solution yet? Well, it's been a problem for quite some time then. :/
kcodyjr: i just read the code a few days ago, it's using a heap allocator
nanonyme: Right.
idletask: Neo_The_User: it is actually aty (CONFIG_FB_ATY)
nanonyme: idletask: It's for Mach64, seems.
idletask: nanonyme: it is, yes
idletask: I used to use that, a long, long time ago
Neo_The_User: i dont see any ATY stuff in my kernel
nanonyme: http://kernel.xc.net/html/linux-2.6.30/x86/FB_ATY
idletask: Neo_The_User: git grep FB_ATY in the kernel git
Neo_The_User: nothing
chithead: grep FB_ATY /usr/src/linux/.config
Neo_The_User: its my custom kernel anyways
idletask: kcodyjr: fragmentation of the video RAM?
nanonyme: But no, I suspect fb's won't be removed very fast. Possibly marked deprecated though.
kcodyjr: fragmentation period, i'm writing an implementation of the buddy algorithm that can be instantiated as many times as you like
nanonyme: (or rather the non-KMS fb drivers)
Neo_The_User: ok soo...
Neo_The_User: /proc/fb is empty.
Neo_The_User: is that bad?
idletask: nanonyme: especially since kms only really covers intel and ati chips right now
nanonyme: idletask: And new nVidia.
nanonyme: Iirc Nouveau implemented it first for new cards.
chithead: there probably won't be kms replacement for all fbs. for mach64 there is not even drm in the kernel, only in the now defunct drm.git
idletask: nanonyme: yes, that too, but not as advanced as ati and especially intel as far as I can see
nanonyme: chithead: Good point...
Neo_The_User: is there some special setting i need to set in my kernel that nobody knows about?
nanonyme: So FB ATY probably stays then.
idletask: Neo_The_User: well, the strange thing is that I didn't have to set any amount of memory at all with my current config, and I have a full resolution fbcon... Can you pastebin your .config?
nanonyme: idletask: I wouldn't know, I don't run an Intel machine.
nanonyme: Nor an nVidia one.
Neo_The_User: idletask ill give you the name of the config with my numbers in it hold on
idletask: nanonyme: I have an ati (at home) and an intel (at work)
idletask: Both with KMS and DRI
nanonyme: I could toss my old nVidia card in but I suspect the dual-boot Windows would crap its pants if it found both an ATi and an nVidia card in the same machine.
Neo_The_User: CONFIG_VGACON_SOFT_SCROLLBACK_SIZE
idletask: The Intel is much smoother
nanonyme: Define smoother. :p
Neo_The_User: better
Neo_The_User: faster
idletask: # CONFIG_VGACON_SOFT_SCROLLBACK is not set <-- in my .config
nanonyme: I get plenty smooth behaviour out of radeon KMS.
adamk_: Neo_The_User, Did you enable KMS in the radeon DRM driver by default in the Staging section of the kernel config?
Neo_The_User: yes
idletask: nanonyme: in general... I use kwin's cube, when I rotate it, the rotation is smooth... Also, when I use fancy task switching, the video playback is displayed on the intel, not on the ati
idletask: Things like that
bridgman: in case it helps, on rv620 I'm seeing openarena fail with a gaudy coloured title with direct rendering, runs ok with indirect rendering
bridgman: latest mesa and drm from git
idletask: The Intel is a 82Q965, the ATI is an RV370, I don't even know which one is supposed to performe better
idletask: perform, sorry=
idletask: But the Intel works far better
Neo_The_User: http://neo-technical.wikispaces.com/file/view/myconfig.config (my old config used with vanilla kernel)
kdekorte: bridgman, known issue think it from the draw_prims stuff
Neo_The_User: see if there is anything wrong with that ancient config of mine
bridgman: thanks, that's what I figured but just checking
bridgman: presumably indirect rendering prevents the use of draw_prims somehow ?
suokko1: draw_prims~=VBOs
Neo_The_User: the only major differece is that i have DRM and radeon drm into the kernel rather than modules
idletask: Neo_The_User: you use config_vga_soft_scrollback, I don't... Have you tried deactivating this option?
Neo_The_User: that shouldn't matter.
idletask: Well...
idletask: That's the only difference I see, really
Neo_The_User: btw i have vga 16 color graphics off in my current kernel too
idletask: I never use scrollback in RAM anyway since I use screen
idletask: I let screen handle it :p
Neo_The_User: ill see if anybody else agrees with your suggestion
Neo_The_User: should map to primary display device be on?
Neo_The_User: for fbcon? i have it off
idletask: CONFIG_CC_OPTIMIZE_FOR_SIZE=y <-- I don't have that either, but it seems even more unrelated to your problem
idletask: Neo_The_User: I have it off too
Neo_The_User: any fb devices such as vesafb and vgafb?
idletask: No, only fbcon
Neo_The_User: wonders about turning AGP off
Neo_The_User: since he has a erm.. pci e 2.0
idletask: AGP is not only a bus type
idletask: It's a transfer mode
Neo_The_User: i dont think i need it though
idletask: You need AGP for DRI, but don't ask me why
Neo_The_User: oh ok
kcodyjr: that's probably a misnomer for 'gart'
idletask: kcodyjr: indeed, I saw many times "agp" and "gart" mentioned together
bridgman: I believe you can force AGP devices into PCI mode, so they run more slowly but possibly more reliably
Neo_The_User: ill upload my current config in just a sec
idletask: bridgman: were there ever other types of AGP devices than graphics adapters though?
Neo_The_User: that config is really old
kcodyjr: bridgman: http://www.sharpened.net/helpcenter/answer.php?57
kcodyjr: sounds like it's turning off pipelining that makes it more reliable
bridgman: I don't think so... someone probably made an AGP mouse or something, but really just used for graphics ;)
bridgman: slowing down the transfers as well
kcodyjr: bus clocks and such, yes, that too
kcodyjr: though it seems to me that it's the access to system memory that drm would care about. but that article is slightly off; pci devices can access system memory in the dma32 zone
Neo_The_User: http://neo-technical.wikispaces.com/file/view/current.config (ported to the vanilla kernel)
bridgman: I'm a bit fuzzy on the history there; my recollection is that before AGP (and GART) was introduced the PCI cards could not access system memory; the driver had to transfer everything up to video memory first
kcodyjr: that's got more to do with cpu-side memory architecture than with the bus or the card
bridgman: yes and no - the CPU-side design is what responds to requests from cards/chips but the GPU needs the ability to redirect VRAM accesses through the bus down to the system memory
kcodyjr: unless you take great pains, the buffers aren't likely to be within the dma32 zone
Neo_The_User: kcodyjr: was that comment to me?
bridgman: I think it was that capability which was new with the introduction of AGP; the ability for the GPU to texture out of system memory, for example
kcodyjr: neo, no
kcodyjr: with agp came the ability to remap the gpu's view of the bus address space
kcodyjr: so a buffer allocated arbitrarily, even in high memory, could be mapped into the gpu's view
kcodyjr: but absent an iommu that requires programming, it's always been possible for bus-mastering pci devices to access the lower 32 bits of physical ram
bridgman: yep... prior to that I don't think the GPU *had* a view of the bus address space other than using a separate DMA controller
kcodyjr: pci itself gave it one
Neo_The_User: idletask: see anything unusual? thats my latest config but it has all the custom zen features out and many other things left out (make it easier to read)
kcodyjr: needing separate dma controllers to enable bus mastering, was an isa problem
bridgman: what I'm saying is that I don't think GPU engine memory requests could even be mapped to the bus before AGP
bridgman: yes the PCI bus could handle a request, but the GPU couldn't make 'em
bridgman: except using the DMA controller
kcodyjr: that would be chip-specific
bridgman: probably
kcodyjr: but if the gpu has the ability to assert address lines, it doesn't need a dma controller, and if it doesn't, it can't access one
kcodyjr: i can see an interface being made one-way in hardware; that is, the vram maps into bus space but the gpu can't see the bus on its own initiative
bridgman: right; I don't think our pre-AGP GPUs could bus master at all except using the on-chip DMA controller
bridgman: you couldn't access system memory using the drawing engines
bridgman: at least not the 3D engine
idletask: Neo_The_User: well, as I said earlier, the only real difference to me is that you use vgacon_soft_scrollback
kcodyjr: but you could cause the card to perform a copy into itself? that's interesting
Neo_The_User: alright ill try turning it off as everybody is idle or busy
bridgman: yeah, you used one block to copy data into vram then the 3D engine accessed it from there
kcodyjr: that would actually be a thing of the card more than the gpu, since the card sits between the gpu and its vram. i wonder if any of the old pci firegl's took the trouble to wire up to the bus
bridgman: agd5f and airlied might remember the details; not sure if it was the 2D engine doing the transfer or a dedicated DMA controller
bridgman: everything is wired to the GPU; vram, bus, eprom, displays
bridgman: ie GPU is connected directly to the vram, nothing in between
bridgman: thinks we should have stopped after AGP 2x
kcodyjr: got it. once again, design-specific. actually i think the pci configuration space is supposed to reliably say whether the card can bus-master
airlied: the card can busmaster
airlied: just not all parts of the gpu can initiate it
bridgman: yes, but the info in the config space is supposed to reflect what the card/gpu can do, not the other way round
bridgman: comment was to kcodyjr of course
kcodyjr: sounds to me like about 1 card in 5 might be workable, and i'm considering all vendors, not just ati
bridgman: yeah, it really depended on GPU + card layout + mobo layout + chipset + chipset driver / SBIOS
bridgman: as long as all the entrails lined up everything worked great
airlied: I think we can 3D from the PCI GART though on r100 and greater
airlied: its the mach64/r128 ear cards than can only do VRAM
airlied: ^ear^era
airlied: and I think r128 has PCIGART so maybe it was mach64 only
bridgman: sounds right; once AGP made GART standard it started being used with PCI as well
airlied: granted r100 has only one TLB entry so not so fast
kcodyjr: i do remember running early dri on an r128
Neo_The_User: idletask: i switched kernels via kexec and still no kms
idletask: Neo_The_Use: no KMS or no full res console?
Neo_The_User: no full res console
idletask: Neo_The_User: and I don't use kexec either :p
Neo_The_User: im getting 1280x1024
Neo_The_User: i want 1920x1200 >:O this is so frusterating
airlied: Neo_The_User: I'm going to guess the problem is between the keyboard and the chair.
Neo_The_User: airlied: http://neo-technical.wikispaces.com/file/view/current.config (ported to the vanilla kernel)
Neo_The_User: please please i beg you to look over that config
airlied: Neo_The_User: you know those bars they have at carnivals? you must be this high to go on this ride?
airlied: I'm guessing you are failing that test wrt compiling your own distro
Neo_The_User: ok if i switch to fedora, will u help me plz??
idletask: Off, have fun
airlied: fedora has working kms already I don't need to help
Neo_The_User: bye
Neo_The_User: oh
airlied: Neo_The_User: you aren't building the firmware into the kernel, because you didn't listen when peopl told you to
Neo_The_User: i did make firmware && make firmware_install
Neo_The_User: maybe i need to turn off "only compile firmware when this is that" or whatever
airlied: Neo_The_User: CONFIG_FIRMWARE_IN_KERNEL the hint is in the name
Neo_The_User: oh
Neo_The_User: thank you!!!!!! you saved me for the billionth time
soreau: is lhao
kdekorte: airlied, any chance you can clear vram when you init KMS, it is creepy seeing what was one screen when you crashed prior to GDM loading all the way
kcodyjr: creepy?
Neo_The_User: soreau: whats funny?
kdekorte: yeah, makes it look like you're logged in for a sec
airlied: kdekorte: we used to I wonder where I lost that patch
kcodyjr: suppose it depends what you were browsing right before it crashed, and who came into the room during the reboot.
kdekorte: kcodyjr, ha... but if you reboot it doesn't do it, only on a crash
hbbs: airlied, Hi there. Is there a chance to have proper AGP KMS/GEM support on kernel 2.6.32?
airlied: hbbs: whats wrong with it now?
airlied: apart from r600 doing something wrong
hbbs: airlied, I asked you one month ago about it you probably don't remember. I even filled a bug report about it. I own a AGP X1600pro, it can't properly boot using KMS, during boot time my monitor goes black and the system hangs.
airlied: hbbs: did you test with the drm-next tree since?
hbbs: airlied, No, I didn't. I tested back then with the fedora 12 alpha. That was my last test.
hbbs: Right now I'm using Karmic with the very latest updates.
Neo_The_User: is going to leave before he starts yelling
kcodyjr: i'd say he owes you some code monkey work, but i'm not sure if he's ready for it
hbbs: airlied, Is there drm-next code on Fedora Rawhide Nightly live builds?
dileX: hbbs:
airlied: hbbs: its not nightly I have to push code to the kernel when I think its ready
hbbs: airlied, fair enough. So, where can I pull this drm-next code and dependencies?
hbbs: dileX, thx
soreau: In the case of drm-next, should I do 'make oldconfig' for any reason after pulling latest from git?
dileX: hbbs: see topic for build-wiki URL
soreau: Y'ellow
soreau: When using drm-next, do you have to do 'make oldconfig' after pulling latest from git? or just make make modules_install and make install?
airlied: make should be fine
soreau: That's what I figured.. just didn't know if any options were being moved around or what
soreau: airlied: Did you ever get a chance to look at xrandr svideo load detection issue?
airlied: soreau: no I don't have a tv-out r300 handy
airlied: or at least not near a tv out
soreau: I am updating the kernel now and if it's still broke, I'll file the bug then
agd5f: soreau: you should be able to force it on in the meantime
soreau: agd5f: I added the underscore for load_detection in the kernel and now 'xrandr --output S-video --set load_detection 1' at least does not give and error but xrandr still says S-video disconnected (normal left inverted right x axis y axis)
soreau: s/and/an
soreau: agd5f: How can I force it on?
soreau: The only thing is.. libX11 has been failing to build for the past week or so and I've pretty much been ignoring it
soreau: I am using latest everything including drm-next and X server components
soreau: Could this be the problem? (X master oddity)
airlied: never builds client side libs
soreau: still wonders how to force it on
soreau: Is there anything else I can do to test why this is failing before I go and file a bug?
airlied: xrandr --addmode S-video 800x600
soreau: airlied: http://pastebin.com/m1f17f7b1
airlied: now do xrandr --output S-video --auto
airlied: or maybe xrandr --output S-video --mode 800x600
soreau: http://pastebin.com/m41dbac29
adamk: airlied: I just updated my bug regarding the LCD turning off with KMS activated on a dualhead setup. The same monitors work fine with KMS enabled on an HD3450.
adamk: Actually, two of my annoying bugs with this particular setup don't exist with the HD3450, just the x850.
adamk: I was going to try an x1900 tomorrow, but I'm not sure there's any real reason now.
airlied: sounds like something x850 specific alrighty
soreau: airlied: So what should I file the bug against?
airlied: soreau: nothing appears after the last one?
adamk: I'm off... If you think of anything you want me to check/test regarding either bug, just let me know.
soreau: airlied: Did you see that last pastebin? http://pastebin.com/m41dbac29
airlied: soreau: I'm not expecting it to say connected
soreau: orly?
soreau: was..
airlied: the little * means it set the mode,
airlied: which I would expect something on the tv after
soreau: No there is nothing, not even a gltich like it's trying
soreau: glitch*
soreau: But works on bios screen when booting and a half second into kernel load until kms kicks in
airlied: soreau: hmm probably need to do some register dumps maybe file an fd.o bug with all the info
airlied: I'll put it on the list
soreau: On ums, it works until X starts, then I just have to set load detection and then --auto works
airlied: tv-out isn't really my main focus so it might be a while
soreau: Yea I know.
soreau: I see some similar bugs with rv350... from 2007
soreau: I might try to see if I can find a good ddx commit.. but hmm
soreau: airlied: What is the most likely faulty component? so I might try reverting, finding something that works and bisecting?
airlied: soreau: it never worked under kms
soreau: nah
airlied: so there is nothing under kms to revert to
soreau: You are certainly correct
airlied: comparing the kernel tv out code and userspace tv-out code is probably the first thing I'd do
soreau: Where might that be?
soreau: recalls seeing tv detection stuff when looking for 'load detection'
airlied: radeon_legacy_tv.c in kernel and radeon_tv.c in kernel
airlied: oops second one in userspace
airlied: I believe there might have been some r300 regs I didn't handle properly
soreau: airlied: Ok, I'll see if I turn up anything
airlied: you can use radeontool to examin individual registers
soreau: Yea, I've used radeontool and radeondump before
soreau: But I never really got comfortable with them at all
airlied: its probably only one of about 5-10 regs that are wrong
airlied: CRTC_*_CNTL, DISPLAY*_CNTL
airlied: or ones like that
soreau: How would I get a good dump though? ums?
airlied: yup or at console
soreau: I went and compiled all the stuff in kernel
soreau: And even if I identified reg differences, I wouldn't know where to start on how to fix them
airlied: soreau: if you identify them I can fix em quicker :)
soreau: heh, ok :)
airlied: RADEON_DISP_TV_OUT_CNTL, RADEON_TV_DAC_CNTL, RADEON_DISP_OUTPUT_CNTL,RADEON_DAC_MACRO_CNTL,
airlied: RADEON_DAC_CNTL2,
airlied: I'd start somewhere around thoser
soreau: I'm trying downgrade of ddx blindly to see if it might be a few commits back
soreau: Since it's the quickest thing I can try first
airlied: the ddx won't help kms
airlied: it doesn't do anything
soreau: reinstalls -9999
soreau: looks at radeontool
soreau: airlied: I seem to not have made notes about how to use radeontool. Best I can recall it'd be something like # ./radeontool reg CRTC_*_CNTL or something
soreau: And TBH, I'm a bit confused how to check where it's not working. I guess I need xrandr to have the '*' for 800x600 and then check the regs?
airlied: you might need to look up the registers in the reg file to get the hex
airlied: then radeontool regmatch hex
airlied: suokko1: hmm linearising the reads is quite messy
airlied: we need to get the reloc index which is ahead of us in the stream and add it too where we are
suokko1: So you would have to save the relocation index somewhere in parser structure
airlied: its okay for the simpler packets
airlied: very messy for the vertex buffer ones
airlied: there is a relocation index per reloc
airlied: we can't store it in advance since thats is instantly non-linear
suokko1: I tough relocations were always writen jsut before the data that required relocation
airlied: no packet after it
airlied: you can't put nops into the middle of the packet3
airlied: the hw still has to understand it
suokko1: That hurts any parsing stream like parsing then :/
airlied: pretty much
airlied: I think keeping two pages might be enough for most cases we'll see
airlied: so we can fetch across a page boundary
airlied: like yes someone might submit a 4k single packet3 but they deserve pain
suokko1: That just sounds way too complex :(
airlied: well what we have now is just broken
airlied: so its fast but it fails the works test
airlied: so I've no problems pushing something that slows us down at this point
airlied: it just would be nice to have it less pathalogical
suokko1: Can we somehow make user-space submit first relocation packet and the use it in next packet?
airlied: not really
suokko1: yes. That would add complexity in userspace
airlied: the DDX/mesa is pretty much designed to emit the relocs in-stream
suokko1: Maybe we could have relocations pushed in end of stream with pointer to start of relocations stream and then we read both same time. libdrm could begin writing relocations to end of command buffer
airlied: what do you mean the end? we don't have an end until we flush
airlied: we don't always transfer all 64k into the kernel
suokko1: airlied: I mean that we have fixed length buffer and we start writing relocations to the last element
airlied: at the moment thats 64k and we don't want to push it all if we don't use it all
airlied: if you only send 1k of commands we only copy 1k
suokko1: We don't have to push the middle
suokko1: If we give sizes for end and begin streams both
airlied: I'm missing where this is less insane than two pages
airlied: also how you match the relocs back to the place you are relocting
suokko1: Then parser could read 2 streams same time and relocations would be there always when you need them
airlied: we can just pass another chunk in
airlied: no need to go mad on reusing the end of the ib
suokko1: That is possible too
airlied: but then you'd have to start adding offsets to the reloc
suokko1: and probably better
airlied: and then we end up with what we used to have
airlied: the reason we use the packet0 nops is we know where they apply to
soreau: airlied: I just dumped them all :P KMS: http://sprunge.us/HFDC UMS: http://sprunge.us/fhHE
suokko1: I have to think that a bit more
airlied: soreau: all of them might not include all of them
airlied: not all regs are in radeontool
airlied: and if we have another stream of relocs we also have to page cache them as well
soreau: I think I have a hunch what the problem might be (or at least.. *tries his suspicion*)
soreau: Nah, that didn't work
soreau: airlied: The thing is, I never understood what you were saying about looking them up and getting the hex values
airlied: soreau: see the numbers in brackets?
soreau: yes
airlied: grep the reg name in radeon_reg.h
airlied: hmm I gget page crossing at least playing OA
suokko1: How then does EmitAOS work? It looks like the relocations are written to middle of LOAD_VBPNTR packe
airlied: suokko1: there is a kms path
airlied: in non-kms we do relocs different
suokko1: yes. I noticed
suokko1: What was problem with old style insertion of data to middle of packets?
airlied: suokko1: we didn't do that ever.
airlied: suokko1: the old relocs built up a second list
airlied: of offsets into the IB
airlied: it was fine for Intel where they don't parse the IB just shove relocs into it
suokko1: ok. But what if we insert the relocations in middle of packet and then in copy to IB we just modify order of data
airlied: since we had to pasre the IB anyways we didn't think it was worth doing two parses
airlied: suokko1: glisse liked having the packets look the same for saniy reasons
airlied: sanity even
airlied: at the moment we don't rewrite the IB
suokko1: I understand that
airlied: we copy it in one go, and fill in the relocs while we parse the original
suokko1: But here is too many problems for every solution
airlied: I suspect if we started again, we'd do it different and we'd be solving the other set of issues
suokko1: I know. There is always issues
airlied: really for PCI(E) we can do this a lot better
airlied: its only for AGP where that sucks
airlied: but I'd like to avoid having two paths because it'll get broken
suokko1: So for PCIE we can just copy everything to allocated IB and modify there
airlied: the main thing is reading back
airlied: we can readback from the alloced IB on PCI(E)
airlied: on AGP not so much
airlied: not without cache flushing overheads
suokko1: Maybe inserting relocations to middle of packet is least evil solution
suokko1: Then data would come in stream like fashion which would simplify parsing it
suokko1: Now we would only have extra work in copy phase to get data to GPU order
airlied: it also sounds like a major rewrite I'm not really up for at this point
soreau: airlied: http://sprunge.us/TBBP
airlied: perfect being the enemy of good enough
soreau: gah, formatting got messed up
airlied: soreau: DISP_OUTPUT_CNTL looks suspect then at least
airlied: tries the two page solution to see how much it sucks
suokko1: 2 pages solution sounds scary and possible buggy solution
airlied: suokko1: why buggy?
airlied: I supsect rewriting the kernel/ddx/mesa will introduce more bugs at this point
suokko1: If you ever get the large packet you are in trouble
airlied: why?
airlied: it'll be slower granted but I can't see why it won't work
suokko1: You won't find the info from 2 pages that you are looking
airlied: it'll bounce
suokko1: Unless you have one page pointing relocations and another the actual data then it might work
airlied: sucks to be sending 4k packet
airlied: it'll end up reading pages twice, its possibly suboptimal but I don't think optimising for the uncomon case is worth it
airlied: the only thing that can get that big is something like an inline indices
airlied: which doesn't contain relocs
airlied: checks shitty r100 packet
suokko1: Someone invents way to EXA do asynchronous DFS/UTS and send BLITBLT_MULTI with a lot of entries ;)
airlied: we don't use BITBLT_MULTI now
airlied: we do the blits with packet0
airlied: DDX inlines vertices but again doesn't have relocs
airlied: I think 3D_RNDR_GEN_INDX_PRIM
airlied: is the only one that really could suck and its r100 only
agd5f: soreau: if you are trying to figure out why tv load detection doesn't work for you in kms, compare radeon_detect_tv() in radeon_output.c to what's in the drm
agd5f: radeon_detect_tv() calls r300_detect_tv() for r3xx, although as I recall both functions worked on my r300
Neo_The_User: is it possible to set KMS at a fixed resolution in console so when i boot up into my kernel, i can see the entire boot start up?
Neo_The_User: ^so
airlied: Neo_The_User: not sure what you are asking for there
airlied: the entire boot startup is 100s of lines
airlied: I'm not sure how fbcon picks the font size
Neo_The_User: ok erm... KMS takes forever to find the correct display mode so i miss the first 3 secs of my start up and mine is around 6 seconds.
Neo_The_User: well not forever. wrong word. not fast enough as i want it to
airlied: dmesg?
airlied: as in you can see kernel msgs after it boots
Neo_The_User: oh wow! with kernel debugging on, my dmesg is so much larger i can see everything!!
airlied: but no we can't redraw the msgs that are on vgacon on fbcon after switching from what I know
Neo_The_User: oh ok
Neo_The_User: thats what i was looking for. thanks for the info!
Neo_The_User: sometimes when the console goes blank after about 30 mins, when i wake it back up again, i see red dots all over the edges
Neo_The_User: might be my video card though cuz i c it with windows 7 64 too
Neo_The_User: i recall you saying that erm.. you had every single radeon card or something. do you have any issues with the 4650?
airlied: I don't run them all at once
soreau: agd5f: I found radeon_detect_tv() in legacy_output.c but not finding it in the drm
airlied: soreau: radeon_legacy_encoders.c
Neo_The_User: http://neo-technical.wikispaces.com/file/view/dmesg.current.txt see anything wrong? perhaps why microcode takes forever to load or anything drm related?
airlied: no
Neo_The_User: hmm... ok then. not like im in a hurry trying to get my comp to boot up as fast as possible
soreau: I guess I'm supposed to be looking at radeon_legacy_tv_detect ?
airlied: soreau: or the r300 one
airlied: r300_legcy_tv_detect
Neo_The_User: starts X for the first time with KMS
soreau: airlied: Not finding r300_legcy_tv_detect () anywhere
soreau: grr, typo
soreau: stares blankly at the function
soreau: airlied: What am I looking for here? :/
airlied: soreau: differences between that and the ddx one
agd5f: looks the same to me
soreau: So between that and r300_detect_tv ()?
soreau: (in ddx)
soreau: begins to wonder how code gets accepted into the kernel tree
agd5f: soreau: r300_legacy_tv_detect() in kernel should be the same as r300_detect_tv() in ddx
soreau: I added rumble support to the gamecon module for N64 controllers and it works with my homebrew interface ;)
airlied: agd5f: me too since I wrote it ;-)
agd5f: also, it looks like it's always enabled with kms, so no need to enable it via xrandr
airlied: agd5f: I decided to see who cimplains ;-)
soreau: heh
soreau: Would that mean it should choose S-video over DVI-0 if both are connected?
airlied: no
airlied: it would enable both
soreau: I know it took me forever to figure out why with fglrx, X would never start. Turned out it was because I had both s-video and a second monitor plugged in (way back in the day)
soreau: With the radeon driver, it always worked with all three connected
soreau: I still haven't figured out why kms incorrectly reports 4096x4096 max while ums correctly reports 2048x2048
soreau: (viz xrandr)
soreau: via*
soreau: Which was my earlier suspicion. With kms, I was previously trying with the main monitor @ 1280x1024 and was thinking it was silently failing because it thought maybe 1280(x1024)+800(x600) was in the range of 4096 (but failing because in reality max is 2048)
soreau: With ums it throws a warning about requested size too large and I have to use >1280x1024 for the main monitor to get it to work
soreau: But I tested with 1152x768 and still failed so that wasn't it
soreau: Here is the reg dumps more legible if it helps http://pastebin.com/m7fa4e224
soreau: But unfortunately, I'm not sure how they correlate with the code or what I can change in attempt to test anything :p
soreau: After looking at those two functions, I don't see any real difference either
soreau: Well I tried everything I know how to do and I still can't get it working. Guess I'll just have to file a bug report
airlied: soreau: my r300 laptop is upgrading
soreau: airlied :D
soreau: puts another log on the fire
soreau: and cracks another beer =)
airlied: soreau: it hasn't crashed yet, this is the longest its stayed on for ages
soreau: airlied: Give it some love and it will work just enough ;)
soreau: I just fixed my ancient stinkpad earlier today, Thought the battery was dead but turned out to be loose leads. Tweaked them and it works now
airlied: this one has a loose backlight power cable
EruditeHermit: RV870 looks amazing
kepstin: hmm. Does HDMI audio work on r7xx with the radeon driver yet, or is that still radeonhd only?
airlied: on some r7xx neither supports it
kepstin: huh. well, i guess i'll just have to try and see then, when i get an hdmi cable :)
soreau: gives airlied's lappy extra connectivity powers
airlied: its also got a really old hdd in it
simplexe: hi all
soreau: airlied: I have thinkpad 600e with a whopping 6gb hdd
EruditeHermit: airlied, you might want to add RV8xx not supported yet to topic
airlied: EruditeHermit: not until someone has bought one
soreau: EruditeHermit: They're coming out of the bushes with that, aren't they
simplexe: today i update mesa, GL apps works, in glxgears +5-10%, openarena menu don't appear
AMD_Fanboy1993: might be in the wrong channel but i cant compile agd5f's 3d code
AMD_Fanboy1993: its trying to compile agp support which i have ON in the kernel but it cant do it. should i post error?
soreau: It also might help to say what exactly it is you're trying to accomplish
airlied: apart from being stupid
AMD_Fanboy1993: to get 3d working with ermm kms
DanaG: hmm, I'll be glad whenever a kernel image next builds, successfully.
DanaG: /home/kernel-ppa/mainline/build/drivers/staging/go7007/s2250-board.c:670: error: implicit declaration of function 's2250loader_init'
DanaG: yeah, that's the thing that was broken last time, too.
airlied: hehe staging drivers
airlied: just turn that driver off
DanaG: that's an automated build by the ubuntu kernel team.
DanaG: I was hoping not to have to build my own kernel.
airlied: ah fail
DanaG: http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-09-23/BUILD.LOG
DanaG: It's the same one that's been failing since after the 12th.
airlied: you'd think someone would be watching that
DanaG: I hope they fix it to at least compile.
DanaG: =þ
DanaG: Upstream, I mean.
DanaG: Either that, or have it spit out a "screw you, this driver is broken; I'm ignoring its failure." =þ
airlied: you'd think the ubuntu guys would fix it and send the patch
DanaG: s/think/hope/