JohnDoe_71Rus: alien-arena crash
JohnDoe_71Rus: File radeon_dma.c function radeonReleaseDmaRegions line 348
JohnDoe_71Rus: Leaking dma buffer object!
JohnDoe_71Rus: http://pastebin.com/m5c099e11 console log
cxo: I've noticed glxgears slowly slowly slow down over time, if you just keep it running. I wondered if that too was because of a memory leak
Droste: I'v noticed that my gears stop spinning after 1min
soreau: maybe they need some grease =)
Droste: ^^
cxo: uses RedLine 80W140 Synthetic in the Dana44
cxo: its pretty heavy duty purpose stuff, but keeps the gears going strong, even after 40 years
dmb: cxo, KMS?
Droste: thats a little more than 1min :-)
cxo: dmb, Am I running KMS? Yes
dmb: cxo, i'v had issues of fragmentation (when using kms)
dmb: cxo, r515?
dmb: erm
dmb: r500
cxo: r770
dmb: oh
cxo: no fragmentation
dmb: cxo, how can you tell?
cxo: Thats actually a good question. Saying I could "see" it happening or not looking at something running 18,000FPS would have silly
cxo: I don't really know then :)
cxo: Turning my cub left is like 100000x slower than turning it to its right
cxo: ^cube
JohnDoe_71Rus: RS482 r300
JohnDoe_71Rus: (II) [KMS] drm report modesetting isn't supported.
JohnDoe_71Rus: can fix it?
cxo: update drm, mesa and xf86-video-ati
soreau: cxo: kube or cube?
cxo: compiz cuuuuuuuuube
soreau: huh.. that's strange
JohnDoe_71Rus: how to learn from the console versions of libraries?
soreau: cxo: Did this just start happening or has it always been this way?
soreau: JohnDoe_71Rus: Which distro?
MostAwesomeDude: JohnDoe_71Rus: Your kernel doesn't have KMS.
JohnDoe_71Rus: 9.10 ubuntu
soreau: Actually, it does
soreau: JohnDoe_71Rus: You need to add radeon.modeset=1 to your kernel parameters
MostAwesomeDude: Well, then it didn't get loaded right.
JohnDoe_71Rus: 2.6.31-02063106-generic
soreau: MostAwesomeDude: It's disabled by default
Droste: this time the gears spinned 11min. but there sure is a problem
MostAwesomeDude: soreau: WTF.
soreau: aaaaand he's running custom kernel.
soreau: MostAwesomeDude: They squeezed it in right before the release but default = disabled
soreau: ubuntu does stuff like that
JohnDoe_71Rus: soreau, and compile new kernel?
soreau: JohnDoe_71Rus: No, I was saying it seems you aren't using karmic stock kernel
Droste: ...glxgears only spinned 20sec this time, weird
cxo: soreau, glxgears performance has always been erratic, but i'm noticing the decay only now
soreau: cxo: I'm talking specifically about you reporting
soreau: That should not be happening in any case. If it is, you can try resetting to defaults in ccsm>Preferences
DanaG: hmm, I haven't seen bridgman in a while here, yet he's been active on Phoronix.
soreau: He still dials in every once in awhile ;)
soreau: and he can see our conversations here from the channel logs
k]t: hm, thanks cxo, but even with my 64bit machine, kernel 486 is the only "Working" bit i have...
k]t: this is what im left with... http://tiny.cc/uLf9T
amarks_: completely unrelated, the muppets go viral http://www.youtube.com/user/MuppetsStudio
Ghworg: Ooh a new video, thanks amarks
JohnDoe_71Rus: http://pastebin.com/m446f58 usuali xorg log
JohnDoe_71Rus: http://pastebin.com/m4ec3e293 try enable kms
simplexe: JohnDoe_71Rus: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
simplexe: your libdrm version?
hifi: http://hifi.iki.fi/radeondb/dump_tree.php now thats a device tree
hifi: though it's missing a lot of pci ids
Zajec: how do I force software rasterizer usage?
Zajec: it was some variable...
Zajec: SOFTWARE=1 glxgears
Zajec: sth like that
hifi: and corrections welcome
airlied: Zajec: LIBGL_ALWAYS_SOFTWARE=1
hifi: I wonder why that many pci ids are missing from the ddx...
hifi: is it just that nobody has never used those cards with linux?
hifi: or is ddx grouping them differently
airlied: hifi: what ones are missing?
hifi: well, check the dump of the database I pasted
hifi: it was autogenerated from ati_pciids.csv
gimzo: airlied: my one is missing :) VGA compatible controller [0300]: ATI Technologies Inc RV410 [Radeon X700 Pro (PCIE)] [1002:5e4b]
hifi: series were collected from wikipedia
airlied: hifi: the csv generates the DDX list
hifi: a lot of chips have no pci ids
hifi: yes, I know that
hifi: but doesn't it still need to know all pci ids in order to identify a radeon card
airlied: hifi: it just gets the list from the csv file
hifi: thats what I'm trying to say, is the csv incomplete or not
airlied: not that I know off, but you never know
hifi: for example RV360 has no pci ids in it
airlied: RV360 is RV350 mostly
hifi: and thats a 9600 XT card according to wikipedia
airlied: you salso seem to have RN50 IDs as RV100 in that list
hifi: I autogenerated it from the ddx csv
airlied: we don't have to have exact names i nthe FAMILT
airlied: FAMILY field
airlied: thats now how it works
airlied: we only branch the families where it makes real sense to
airlied: rv350 vs rv360 makes no sense, same for rv370 vs rv380
hifi: then it's incorrect to autogenerate the list from the ddx csv
airlied: I don't think there is a canonical database
hifi: for the radeondb project it's for user convenience that they can type their pci id in order to identify the card family for a test report
hifi: now it would identify them wrong
airlied: yeah that would be a bit of an undertaking
hifi: maybe the pci.ids list will help
airlied: you might find more info in fglrx or windows drivers
hifi: the project is open source radeon specific though
airlied: yeah I don't think anyone can stop you taking the info from those
airlied: if there is any, there may not be
hifi: but would the big pci ids list show exact correct chip names?
hifi: as far as it can be parsed
hnsr: weird, every time my screensaver comes on X seems to crash or something and I end up at the gdm login
glisse: hifi: well dl fglx or windows catalyst and look into it, iirc windows inf files got a list of pciid
glisse: hifi: btw what is radeondb ?
glisse: i ask because i have somethings named that way here
JohnDoe_71Rus: simplexe libdrm2 libdrm-radeon1 2.4.15 git20091125
hifi: glisse: oh, I'm creating a database of test reports
hifi: I'll rename it if it's conflicting
Pallokala: hi guys! keep up the good work. I just upgraded to 2.6.32-rc8 + latest git-stuff and now a lot of the displaycorruptions I were seeing are gone
Pallokala: KMS+compiz + RV630 agp here
spreeuw: Pallokala: yeah for me it works flawless too
spreeuw: but I only have it running for a day
hifi: glisse: ping, should I rename my project?
glisse: hifi: well mine is different it's a debug tools, i will try push my tools today, got a bunch of them and i need to make them public
hifi: ok, I'll just rename it
glisse: plan is to push my radeondb tools into distribution for helping us debug radeon issues
hifi: it can be codename radeondb for now :)
hifi: I parsed the pci ids list as far as I could automagically and got a good result: http://hifi.iki.fi/radeondb/dump_tree.php
hifi: not all series have id's but it's better than before
hifi: and I believe more accurate even
glisse: hifi: x1300 is only rv514
glisse: rv515
glisse: not rv530 or others
glisse: otherwise looks good
hifi: hm, is there a typo
hifi: http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processing_Units#Radeon_R500_.28X1xxx.29_series
hifi: according to that X1300 is RV515
hifi: and it also could be RV350
hifi: er, RV535
glisse: no X1300 is always RV515
hifi: is the wikipedia article incorrect or am I reading it wrong?
glisse: oh the XT report that it should be RV530|RV535
glisse: stupid marketing people
hifi: so my data was good?
glisse: i would like to see pciid of such beast :)
glisse: you used fglrx list ?
hifi: I'll add XT to the series name for RV530|RV535
hifi: actually, no, the linux's pci id list
hifi: it's probably not complete and I parsed only the ones with a sensible "R(V|S)xyz" chip name
hifi: I'll generate a new list with X1300 XT corrected
hifi: there
glisse: X1300XT will likely needs a look at fglrx db
glisse: i don't see it in pciid db
hifi: thats initial list anyway, everything can be fine tuned after launch
hifi: better than a empty database
rlj: i'm having issues with a rs480 (xpress 200m) using sideport memory getting corrupted vram contents after resume from suspend when on kms/dri2
rlj: depending on the amount of time the laptop stays suspended, the degree of memory corruption varies
rlj: apart from the corrupt vram, the system works perfectly after resume and newly allocated graphics show up fine
rlj: and simply restarting X results in working graphics again (as expected)
rlj: the effect is visible in screenshots (i can upload to a pastebin if anyone is interested in tracking down the issue) and as far as i can tell, it looks a lot like the ram memory simply fading from being unpowered
rlj: so i'm led to believe that the vram is either never copied to a safe location before suspension or that it isn't restored properly at resume
soreau: rlj: So it does not happen with suspend to disk?
rlj: soreau, actually i'm not sure about that since suspend to disk somehow doesn't work (haven't tracked down the issue)
rlj: but last time i tried, it would never actually power off the box. (even when doing echo disk > /sys/power/state) which makes me believe it's kernel realted
rlj: *related
rlj: (i'm currently on arch linux. suspend to disk used to work perfectly on ubuntu though so their kernel/userland at least somehow managed to get the knobs turned right)
rlj: does anyone know what functions are involved in the radeon drm suspend/resume code path? (i assume it lives in the card specific drm, right?)
rlj: i guess that could be a first place to look.
glisse: rlj: suspend to disk involve a reboot, on some distrib they are tweaks which will break kms
rlj: glisse, but my issue is with suspend to ram, not suspend to disk really
glisse: rlj: your issue is with sideport memory
glisse: we likely don't support it that well
glisse: try disabling sideport memory in the bios
rlj: glisse, the suspend to disk is another issue (which is a bit weird really since it's concerned with the shutdown phase rather than the wakeup phase)
rlj: glisse, i'll try that (altough it's not preferred since my computer is really low on ram anyway...)
glisse: rlj: well if it works report it here
rlj: i'll have the results in a minute or two
glisse: so we know that we are not handling sideport memory properly
rlj: glisse: with 32MB uma and no sideport configured in bios, suspend seems to work without error so the issue does seem related to sideport, yes
rlj: (another separate issue i'm having though when on kms is xrandr only showing my panel native resolution preventing all other resolutions from working)
rlj: could be some broken edid information though which needs to be worked around, my dmesg seems to point that way
rlj: glisse: what's interesting is that the VTs never show any corruption though after resume using sideport. only X. but possibly they don't use the video card's sideport memory? but then where are the glyphs stored?
glisse: KMS edid parsing is not yet as good as xorg one
rhodan_: KDE 4.4 Beta 1 totally rocks.
glisse: rlj: i think your corruption is caused by us not evicting vram on igp because most igp don't have sideport memory
soreau: rhodan_: How is it better than 4.3?
glisse: thus what happen is that sideport memory is turned off and all if it's content get lost
glisse: but that's a guess from what i can remember of the code
rhodan_: soreau: try it yourself :P
rlj: glisse, what would be the relevant pieces of code to look at?
soreau: rhodan_: I dont use kde, I was just curious what about it was better for you
glisse: radeon_device.c suspend function
rhodan_: soreau: It has feature parity with 3.5 and is much faster, more stable and more polished. http://techbase.kde.org/Schedules/KDE4/4.4_Release_Goals
rlj: glisse, is this in the kernel drm tree or in the dri driver?
glisse: kernel
rlj: (i'm not at all familiar yet with the driver code)
rlj: thanks
soreau: rhodan_: ok
glisse: rlj: ok so we don't evict on igp, edit drivers/gpu/drm/radeon/radeon_object.c and comment line 344
glisse: should fix your issue
glisse: proper fix is for us to detect sideport memory
rlj: that would be on linus's tree i suppose. the conditional return you mean
rlj: i'll need to figure out how the arch linux kernel compile scripts are intended to work though. :) but that workaround seems like a good place to start on my particular box though
pzanoni: MrCooper: you asked me for the logs on #xorg-devel, they are here: https://qa.mandriva.com/show_bug.cgi?id=55880. Do you have any advice on how to debug this? Should I report it on fd.o? thanks
pzanoni: MrCooper: comment #11 might be useful
MrCooper: yeah looks like different maximum virtual resolutions, which can be overridden via the Virtual directive
pzanoni: MrCooper: the newest log doesn't mention what default value it is assuming for Virtual
pzanoni: MrCooper: I'll ask for the user to use a small Virtual
pzanoni: MrCooper: thanks
MrCooper: it's obviously larger, that's what the front/back/depth buffer sizes are calculated from
pzanoni: MrCooper: but the sum of the memory usage on both cases is 32800
MrCooper: pzanoni: the second case doesn't include the depth buffer size
pzanoni: hmmmmm
MrCooper: would be a neat trick otherwise, getting the same result by adding larger numbers :)
pzanoni: MrCooper: but can't this be considered a regression? By default, dri was working, now it's not because the driver assumes a larger Virtual default value
MrCooper: pzanoni: it probably can, but you just can't win on this kind of tradeoff, and it's solved properly with KMS
cxo: brrrr its so cold today
cxo: switches on the radeon
cxo: now someone can shade in the displayport boxes http://www.x.org/wiki/RadeonFeature
stikonas: cxo: this is a wiki, you too can shade it
cxo: I tried, it doesnt work
cxo: it just reverts back to the original colour after the preview
stikonas: cxo: I've just edited it, and everything is working
cxo: Yeah, i don't know. Its never worked for me. Its all good in the preview, but when you actually save it, it reverts
stikonas: maybe you are using some wrong translation of this wiki
stikonas: and pressing cancel instead of save
pzanoni: MrCooper: just for the record, the user reported that using a small Virtual (which is actually 1440x900) worked. thanks for the help
alexex: hello :) i got the following problem: http://omploader.org/vMnY0MA
alexex: i dont know how i got it, but i cant get the thing at the edge away
agd5f: alexex: what hardware?
alexex: any ideas? i have a radeon xpress 200m
alexex: hold on a second, i will post software now
agd5f: alexex: your desktop is larger than 2048x2048
agd5f: which is the max texture size
alexex: it worked before
agd5f: disable compiz if you want it work
alexex: oh :(
alexex: hm, thanks anyway
alexex: explains why it worked on kde though
agd5f: alexex: any gl compositer will exhibit that
alexex: agd5f: so the kde guys are genius
alexex: they did the job
agd5f: alexex: compiz should check the max texture size at startup
alexex: what does that mean to me?
agd5f: alexex: kde may use render, which will fallback to software on surfaces that are too large
alexex: is possible
alexex: dont know
agd5f: alexex: to avoid seeing the problem you are seeing, compiz should check the max texture size. I thought it did
agd5f: but perhaps not
alexex: so im just gonna ask some compiz guys :)
alexex: thanks anyway :)
alexex: are the patches for kms you told me about last time gonna be included in the .32 kernel?
alexex: because i still have the problem with just using my external screen and disabling my laptop panel
alexex: everything just goes black then
cxo: why is 2048x2048 the max texture size?
agd5f: cxo: hw limit on r1xx-r4xx chips
cxo: so how would compiz work around that? do it in pieces and then render it?
agd5f: alexex: 2.6.31 already has kms, so will 2.6.32
agd5f: cxo: shatter
MostAwesomeDude: Shatter won't help with texture sizes, just colorbuffer sizes.
MostAwesomeDude: I am *not* doing texture shatter. So much work for only two apps in the entire world.
agd5f: cxo: separate buffers for each head
cxo: but what if 1 head is bigger than 2048?
MostAwesomeDude: Yeah, compiz could always just do two GL contexts.
alexex: agd5f: as i said already, when i disable internal screen, and enable the external screen on native resolution, both screen go black
agd5f: cxo: buy newer hw
alexex: for whatever reason
MostAwesomeDude: cxo: In that case, you're SOL. Also you'd be going past the bandwidth of single-link DVI, so the card wouldn't even drive it.
cxo: ok
agd5f: alexex: does kms work better?
agd5f: MostAwesomeDude: compiz would have to do somethign like that since with shatter, the desktop would not be contiguous stride
MostAwesomeDude: agd5f: Sure, but I really don't wanna do shattered textures. It'd require per-driver work which I really don't wanna do.
agd5f: MostAwesomeDude: yeah, not for GL
MostAwesomeDude: God, I need to finish stage 1 of shatter. Guess I've got a winter break project. :T
agd5f: MostAwesomeDude: but use for textures fo render would just work since the buffers would be limited to < the hw limit
MostAwesomeDude: Oh, sure.
agd5f: *of textures for render
agd5f: there's no need for GL shatter either. apps should repect the limits
Fjodor: Hi all! I want to run dual-head on an old x300se card, and it works somewhat. Thing is, I'd like my secondary display to be to the left of the main one, and it won't do that. Any ideas or suggestions for troubleshooting?
agd5f: Fjodor: is your virtual desktop large enough to accomodate size by side monitors?
agd5f: Fjodor: http://wiki.debian.org/XStrikeForce/HowToRandR12
Fjodor: I use the gnome display setup tool under ubuntu 9.10, and I can place the display to the left, but then both displays show as the primary (as if mirrored, except that I can go off the display to the right with the mouse)...
Fjodor: agd5f: I should think so, since atm, it seems to work, except that my left display seems to X to be on the right. Somewhat confusing...
tormod: the gnome display setup tool is pretty broken in my experience
Fjodor: agd5f, tormod: Seems so. an xrandr command from the link agd5f provided seemed to do the trick :-D
Fjodor: Btw: Is it possible to run compiz on the radeon driver?
agd5f: Fjodor: yes
Fjodor: agd5f: Any special things I need to do? It didn't seem to work all that well initially
tormod: Fjodor, it should work out of the box on 9.10
coz_: alexex, so did you reduce the resolution of the image?
Fjodor: Must be missing something, then. I get no title bars...
tormod: Fjodor, how much video RAM? AGP?
Fjodor: Xorg.0.log says 131072kb. It's PCI-E
agd5f: Fjodor: start compiz from a terminal and check the startup output
Fjodor: Checking for texture_from_pixmap: not present.
agd5f: Fjodor: check your xorg log and make sure AIGLX is enabled
Fjodor: No mention of AIGLX in the log...
agd5f: Fjodor: pastebin your xorg log
Fjodor: 2 secs
alexex: agd5f: as far as i remember i dont think so
agd5f: alexex: do you have a bug filed?
alexex: ah, no
Fjodor: agd5f:tp://pastebin.org/57504
Fjodor: agd5f: http://pastebin.org/57504
agd5f: Fjodor: you don't have 3d enabled at all
agd5f: #
agd5f: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
agd5f: #
agd5f: [dri] Disabling DRI.
Fjodor: agd5f: Interesting. Any ideas about what to do?
agd5f: Fjodor: check your dmesg and lsmod and see is the radeon drm is loaded
Fjodor: No, it isn't
agd5f: Fjodor: modprobe radeon and restart X
Fjodor: Brb
alexex: i can start compiz with --indirect-rendering only, aswell :(
agd5f: alexex: you have to for non-kms
alexex: hm
alexex: maybe i should have another try with kms
agd5f: only indreit contexts provide texture_from_pixmap
agd5f: alexex: indirect is still accelerated
alexex: hm
alexex: so it actually doesnt make any difference?
Fjodor: agd5f: Well, starting X after loading radeon (which didn't load drm, so I loaded that too in my second attempt), the monitors just lose connection, complaining of no signal...
agd5f: Fjodor: anything in dmesg?
Fjodor: 2 secs
agd5f: Fjodor: do you have fglrx installed?
Fjodor: agd5f: as a matter of fact, I have, even though I found out that it didn't work for my card. That could very well be it, so removing it now :-)
Fjodor: agd5f: Also, does radeon play well with vesafb?
mjg59: Fjodor: Using vesafb is basically always an error
Fjodor: mjg59: Ok, so noted
mjg59: Fjodor: Radeon should be able to restore vesa modes correctly, but it's going to be based on what the BIOS actually did
mjg59: KMS will let you get native modes without having to worry about vesa interactions
Fjodor: Incidentally, I have switched to uvesafb at home, but not on this office machine. I just noticed that now, and wanted to hear if it could be the problem source
MostAwesomeDude: vesafb and uvesafb are mistakes on just about any hardware. I'm really not sure why people pushed them so much.
Fjodor: Well, I can't really seem to get KMS to work at home on nVidia hardware, so I haven't looked into it that much. How would I go about using KMS on this radeon card?
Fjodor: Woa, now compiz seems to be in effect, but all text is upside-down, and secondary display is partially garbled...
Fjodor: Erm, not just text upside-down. Pretty much everything, except the panels are at their right positions...
agd5f: Fjodor: max texture size on your hw is 2048x2048 is your desktop is larger in either direction, you'll get undefined behavior
agd5f: s/is your/if your/
Fjodor: agd5f: Ok, that sucks, but thank you for the explanation. Guess I'll have to ask the tech guys for a better card, then. Strange, though, since the problems stem from the fact that I just replaced my older machine for this old, but newer, one, and don't have much experience with radeon... One should have thought that the graphics card would be more capable of the old one...
agd5f: Fjodor: shatter should fix eventually for mulithead
BioTube: if MAD ever decided he wanted to do it
Fjodor: agd5f: Sounds good, but what does that mean exactly?
BioTube: Fjodor: AFAIK, it's splitting up a texture in-driver
Fjodor: BioTube: Ok, thanks
agd5f: Fjodor: using separate buffers for each head
Fjodor: agd5f: Ok, great
hyc: trying to compile xf86-video-ati from git, getting an error in radeon_driver.c
hyc: /usr/include/X11/extensions/dpms.h:40: error: expected
hyc: ')' before '*' token
cxo: hyc, your x headers are too old to build xf86-video-ati from git
Fjodor: Going home - thanks for your help :-)
hyc: cxo: thanks. bummer
cxo: which version of X do you have?
hyc: this is ubuntu karmic
hyc: with xorg-edgers stuff
cxo: whats karmic? 9.10?
hyc: still 1.6 xserver I think
hyc: yeah
cxo: Ubuntu 9.10 is new enough
cxo: did you follow the wiki?
hyc: not recently. I set up these build trees a few months ago and they were fine
hyc: just did a git pull today
hyc: which wiki?
cxo: the one in the topic
hyc: thx. looking now. it scrolled away when I joined the channel
cxo: you can always type in /topic to get it back
hyc: this doesn't look like the steps have changed lately
hyc: and updating mesa and drm won't fix my X header files
cxo: No they wouldn't have. Check the dependency list
hyc: hmmmm
cxo: I'm using 9.10 x86_64
hyc: yeah, same here
hyc: I also have my own build of 2.6.32-rc7 kernel
cxo: Should work then
hyc: going to rerun autogen.sh and reconfigure...
hyc: hmmm. what version of xserver-xorg-dev do you have installed?
hyc: I have 1.6.5+git20091107+server-1.6
hyc: I can go up to 1.6.99.1+git20090812 that seems to be an old snapshot tho
cxo: 1.6.4-2ubuntu4
hyc: hmm. I can downgrade to that I guess
cxo: Are you not following the regular ubuntu repos?
hyc: I have the xorg-edgers ppa added
cxo: do you have all these dependencies? http://wiki.x.org/wiki/radeonBuildHowTo#head-1d0d38b6fbc11fb69a0676b28184748d6e0d5c87
hyc: bah. same error. wtf, this has to be the same setup the xorg-edgers guys built with...
cxo: dri2proto from git, xorg-macros from git etc..
cxo: libdrm even
hyc: I'll check again
cxo: Its all in the wiki
hyc: I have them, but I haven't refreshed their git in a few months either
cxo: shouldnt be a problem unless you did something stupid like just update the driver and not anything else
cxo: got to run
hyc: well, worked around it. typedef'd Display and #defined Status
hyc: in xorg/vgaHW.h
airlied: glisse: good point on igp sideport
airlied: agd5f: do we have S
airlied: oops sideport detetction yet?
MostAwesomeDude: BioTube: Well, I *have* to do shatter. There's like five different reasons why I need to.
MostAwesomeDude: But it only will work for EXA, so it'll fix core, render, and xv, not GL.
spreeuw: hey how do I enable glsl on r600?
spreeuw: is it an environment option or a compiletime?
airlied: MostAwesomeDude: so what is the status of it ;-)
airlied: like where did it get stuck
MostAwesomeDude: airlied: It properly allocates, and it theoretically shatters a couple ops, although I never actually got it to reproduce things quite right.
MostAwesomeDude: And I haven't restored my xserver tree yet.
MostAwesomeDude: But winter break's coming up, and I should do it during those weeks of downtime.
stikonas: spreeuw: #define in the source (r600_context.c) GLSL is not really usable yet
spreeuw: stikonas: oh ok
spreeuw: and what about TLS for glx, does this offer anything?
spreeuw: or is the configure --help section not cleaned up yet
spreeuw: because my built has TLS enabled
spreeuw: KMS/dri2 build hasnt crashed on me yet since I got it going
spreeuw: but I still have the strange openarena brightness stuck bug
spreeuw: I read somehwere it uses hardware gamma for that
spreeuw: and it worked ok a month or so agao
spreeuw: this still happens when I remove my .openarena cfg
spreeuw: interesting et quakewars look a bit more readable now
spreeuw: but I still cant make out the fonts
spreeuw: of the launcher menu
spreeuw: hey nice a working water surface shader in spring
spreeuw: looks brutal
evil_core: TLS is crypting?
glisse: Thread Local Storage
evil_core: ok, ok, thx
glisse: airlied: btw patch i pushed to xf86-video-ati might also be a good things for fedora 12
glisse: also i can't seems to reproduce firefox crashes with ums
spreeuw: hope flash isnt involved in those ff crashes
spreeuw: that has always crashed my browser on linux
spreeuw: for as long as I've been using it
spstarr: airlied: DRI2+KMS has a speed regression, yeah, ive noticed that quite well also
airlied: glisse: cool, will try and fix my r600 multi-op patch and push a new one today
spstarr: but making it all work is first, yes
evil_core: spstarr: r500 also?
glisse: airlied: also as a benchmark, disable dri2 copy to front might be helpfull to see how much it cost us
glisse: did bench in the past on that
spstarr: evil_core: i only have the r6xx to test and an older rv350
airlied: glisse: just don't copy at all?
glisse: yeah
evil_core: DRI2 doesnt flip buffers?
glisse: we know rendering get done :)
airlied: evil_core: in progress
evil_core: so currently its better to use okd DRI1?
glisse: airlied: it's mostly to know how much the copy is impacting perf
evil_core: old*
soreau: evil_core: better is a subjective term. All depends on what you like to see
airlied: evil_core: DRI1 didn't flip either, unless you turned on pageflip
soreau: more speed or better quality
evil_core: I know, I am always setting that
glisse: if you don't care that much about suspend/resume & dri2, dri1 will bring you more values
airlied: yeah if fps is all you care about then dri1 is good for now
evil_core: I am using laptop
evil_core: and s2ram works
evil_core: s2disk doesnt, because I got crypted SWAP/root
airlied: hopefully as we implement more of GL features and speedups that KMS enables we'll see real speedups
spstarr: secondlife just dies with DRI2+KMS
airlied: in apps that want cool features
spstarr: ya
evil_core: secondlfie sucks
spstarr: evil_core: its good for stressing the graphics stack
spstarr: same for osgrid.org/opensim
glisse: also profiling vram usage didn't endup what i think it would
glisse: need to do more benchmark
airlied: glisse: benchmarks always beat personal feelings ;-)
evil_core: nexuiz isnt betteR?
glisse: yeah :)
glisse: thing here is that the frequency at which i sample vram might impact a lot the results
glisse: i will finish some cleanup on my tools and push them tomorrow
spstarr: gimme tools to test plz
spstarr: I will benchmark
glisse: airlied: did you use your rs480 lately ?
glisse: mine stoped working with 2.6.32-rc8
glisse: well first time i use a 2.6.32 kernel
glisse: also i seem to face a lot of issue with AGP ...
airlied: glisse: I booted latest Fedora on it yesterday but not 2.6.32
glisse: i guess my old AGP budy is trying to stab me in the back
glisse: yeah fedora works
glisse: 2.6.32-rc8 doesn't
glisse: haven't figured out why yet
airlied: whats the AGP issues?
airlied: I should probably go install linus kernel on it, he doesn' thave all my patches yet
glisse: also i have been looking at x200m regression and don't see what patch would be guilty
airlied: do you know its drm?
glisse: agp doesn't work after load kms, unload, reload
legume: Recent ddx changes seem to have lost display for me - RV670 AGP. Only kms, though. Will try and find which later. Any obvious candidate for a revert?
airlied: glisse: oh I don't test that path too often
glisse: neither i, most of the time i boot test, then switch gpu :)
airlied: I did some reloads with 2.6.31-rc9 on my M7/AGP
airlied: but I haven't really been testing linus tree,
airlied: glisse: but you should pull drm-radeon-testing into Linus tree since it has newer patches
glisse: yeah i tested linus tree because i am trying to work a little on ttm patch for 2.6.33 window
ossman: airlied, glisse, what are interesting registers to look at to figure out why CRTC 2 refuses to release the _EN bit?
airlied: glisse: or even drm-next
airlied: ossman: thats wierd, I didn't think it could refuse
ossman: apparently it can
ossman: and I'm suspecting it's related to why the hw locks up when reading the vblank count from CRTC 2
ossman: agd5f speculated about still connected encoders
ossman: or if CRTC control is subject to some fifo
glisse: ossman: did you open a bug for it ?
glisse: it's easier then to gather log & dump
ossman: glisse, yeah, it's my old s-video hang bug :)
ossman: although I haven't filled in the latest findings
ossman: digs up a bug #
ossman: http://bugs.freedesktop.org/show_bug.cgi?id=24611
ossman: updates the bug
glisse: airlied: also the unpin warning shouldn't happen i think we unpin too many time, never bothered to find where this was happening, iirc i did this warning because ttm didn't like to unpin an unpined buffer
glisse: or maybe it was just another ttm bug getting in the way
glisse: my memory is bit blurry on this code
legume: ddx git revert 05551295c5e0946745163f17e5c1d3d41b94bcbf fixes it.
ossman: airlied, glisse, bug updated if you want the short summary of the current state
ossman: RADEON_CRTC2_GEN_CNTL=36800000
ossman: now that does not seem like a sane setting
glisse: no i think it's fine setting
glisse: just disabled
ossman: glisse, but 0x02000000 is RADEON_CRTC2_EN, which is set there if I'm reading things right
ossman: 34800000 would be more expected
MrCooper: ossman: not reading the counter from a disabled CRTC but e.g. just returning the last read value might still be feasible at least as a workaround?
ossman: MrCooper, the problem is that the CRTC looks like it is enabled
MrCooper: ah right
ossman: is the r300 gen CRTC registers covered by any of the docs?
glisse: no, but what is in nda doc isn't much more than what is in the header
ossman: MrCooper, there's no software state on the DRM side of things we can look at to see if a CRTC should be active?
ossman: glisse, bummer
MrCooper: ossman: I think there should be, that's what I meant
ossman: ah. I tried to do the hack on the radeon side of things
MrCooper: that's where it should be, but it should be able to check the CRTC software enabled state
MrCooper: the core vblank code doesn't know how to check itself
ossman: glisse, there's a bit set in RADEON_DISP_OUTPUT_CNTL that isn't in the headers
ossman: RADEON_DISP_OUTPUT_CNTL=10010000
ossman: MrCooper, I think this is doable. give me a few minutes and I should have something
MrCooper: take your time :)
Zajec: where I can read what color tiling is?
Eruditehermit: airlied sorry my laptop died. i am not sure i will be able to get it working again.
soreau: Eruditehermit: Completely died?
airlied: Eruditehermit: ouch
airlied: Zajec: not sure if its mentioned in the r5xx doc
airlied: essentially tiling is just cutting the screen into square tiles that are cache friendly
airlied: so makes the gpu faster to operate on them
Eruditehermit: hard drive died and i think i will get a new comp and not waste money on a new hdd
soreau: Eruditehermit: May be the wisest decision
soreau: At least the gpu's still good! ;D
Eruditehermit: i am on my n800 now
Eruditehermit: we can still use fedora live on a flash drive if u r interested
airlied: What type of hard disk was it?
soreau: Made in Korea
soreau: hides
Vinky: I have problem getting any program using the 3d(maybe others too?) to run, glxgears gives drmRadeonCmdBuffer: -22 and dmesg doesnt give anymore info
Eruditehermit: ata
Eruditehermit: ide
soreau: Vinky: Which card?
airlied: Vinky: probably need a newer mesa
Vinky: HD4850
Vinky: newer than git is hard to find :-)
soreau: What kernel do you have?
airlied: then a newer kernel ;-)
Vinky: .31
soreau: Need newer
soreau: Try 32-rc or preferably drm-next as described in the topic link
soreau: airlied: Did you ever get around to updating the wiki?
Vinky: well it worked before on .31
airlied: soreau: no I still have to figure out what I'm actually doing ;-)
soreau: airlied: hehe ;)
ossman: MrCooper, problem. getting the crtc the proper way involves a mutex
ossman: i.e. might sleep, which is no good here
ossman: any ideas?
Vinky: I have used drm-next for the last 2 weeks or so but it broke yesterday and the git conflicts arising on everyupdate made me switch back
spreeuw: hmm quake4demo sortof runs
spreeuw: with s3tc enabled in driconf
soreau: Vinky: Make sure you have latest kernel, libdrm, mesa and ddx
spreeuw: it starts with corrupted textures
soreau: Vinky: drm-next should pull on top of linus-tree cleanly
airlied: or drm-radeon-testing
airlied: or just run linus
Vinky: soreau, dont know what ddx is called in gentoo, but havent needed it before
soreau: lol
spreeuw: it's xf86-video-ati
soreau: Vinky: I think you have been using it all along
spreeuw: you should use the git version
Vinky: ah :-)
spreeuw: to avoid problems
Vinky: then I have had the git of it
spreeuw: git libdrm, xf86-video-ati,and git mesa
spreeuw: on a 2.6.32rc8 kernel or better
Eruditehermit: ide drives are more expensive thansata go figure
tormod: Eruditehermit, I think I have a good workaround for KMS/gdm race issues, see the wiki page
spreeuw: (easier to use than 31git merged with drm git)
tormod: but if you have no laptop...
MrCooper: ossman: hmm, not sure, also storing the CRTC status in atomic variables elsewhere maybe
soreau: Vinky: In gentoo I use x11 overlay and 9999 versions of libdrm, mesa and ddx (xf86-video-ati) then for drm-radeon-testing I do something like git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git; cd drm-2.6; git checkout --track -b drm-radeon-testing origin/drm-radeon-testing
Eruditehermit: tormod; =(
Eruditehermit: i'll look for a cheap drive
ossman: MrCooper, I'll have to come back to it again during the weekend. but you get any ideas then please throw them my way
Terman: was it really necessary to update the xorg-macros to 1.3? Previously I was able to build the current xf...-ati driver with xorg-7.4, now it seems that I need a newer X than what was released 1 month ago (opensuse 11.2)
spreeuw: a distro release isnt a project release
tormod: Eruditehermit, you can find a 4GB drive in a dumpster near you, enough to use it for testing. Or buy a USB SSD :)
spreeuw: SSD is sweet stuff
spreeuw: but so pricey ;/
spreeuw: just get a nice wetsern digital 2 TB disk for the same money
Vinky: soreau, I have had the git-version of libdrm mesa and ddx(didnt connect ddx with xf86-video-ati) using the guide on the radeon page, will try drm-radeon-testing
spreeuw: Vinky: are you trying to het it running with KMS?
spreeuw: get
Vinky: no
spreeuw: then you shouldnt use the experimental flags with libdrm
spreeuw: at configure time
soreau: Vinky: It should be noted that myself and others have experienced a bug where portage does not update to latest code and stale stuff remains in /usr/portage/distfiles/git-src for the userland trio. Deleting those directorys and re-merging fixes it
spreeuw: in case you did
Eruditehermit: tormod; what kind of dumpsters do u have?
Eruditehermit: =p
tormod: :) I think IDE 4GB disks go for cheap though
Vinky: soreau, ok, good to know
BioTube: i remember seeing huge piles of 80GB hard drives at a scrap yard once
twnqx: has 80gb sata-2 drives around
twnqx: no idea what to do with them :X
tormod: Eruditehermit, but I would have bought an 8 or 16GB USB stick instead, a fast one
spreeuw: letting them run costs you too much in power
spreeuw: per meg
Eruditehermit: i have a usb stick
Eruditehermit: 8gb
spreeuw: dont wear it out
spreeuw: with writes
tormod: spreeuw, it is disputed whether they really wear out much these days
honk: they do, but it takes ages ;)
spreeuw: hope yours doesnt
spreeuw: my old sd card didnt like it ;p
spreeuw: but thats other memory again perhaps
honk: well.. just how much did you write? O.o
honk: even the cheapest flash drives should last a few years if you completely overwrite it once a day
spreeuw: once a day isnt much
honk: errh..
honk: I think it is
spreeuw: for spots
spreeuw: or do you think wear leveing balances it
tormod: yes it does
honk: of course it does
honk: that's why I said "completely"
honk: I really meant that
honk: it might actually be worse on sd cards.. no clue how much space for controllers those have ;P
honk: anyway.. I've used my 512mb usb stick for logging on an openwrt router once writing 1 small entry every 5 minutes.. it worked just fine for years
spreeuw: http://www.bress.net/blog/archives/114-How-Long-Does-a-Flash-Drive-Last.html
honk: (the usb stick is still alive and kickin' btw, I just stopped using the router ;P)
spreeuw: looks good yeah
spreeuw: about 3 years of writes every second
honk: "I'm going to guess that this means I should get somewhere around 30K writes before the device dies."
honk: that's a _lot_
spreeuw: he got 90k
honk: yeah.. well.. his testing method was flawed.. or so he thinks ;)
honk: anyway, how did you get to 3 years of writes? :]
spreeuw: 90k / (3600*24)
spreeuw: talking about radeon, is s3tc high on the priority list yet?
spreeuw: it used to work well in r300
spreeuw: but it no longer babbles with lib_dxtn or something
spreeuw: for r600
honk: spreeuw: yeah well, that's writing the _entire drive_ once a second though
spreeuw: yeah I got it
honk: that's pretty much impossible via usb ;P
Vinky: soreau, spreeuw airlied, its working now using drm-radeon-testing, thanks for your help
soreau: Vinky: No worries, glad you got it working =]
jmho: well, about one year ago I had to work on a device with 4GD flash disc and the disc died after about 6 months with rewriting the firmware several times per day
jmho: nevermind, was reading the backlog
Wizzup: I have a question. I have a 4670 Mobility Radeon HD. And r600_dri.so is loaded. DriConf also tells me my card is R600. AFAIK it is RV730, which is R700, no?
BioTube: they're closely related chip families
BioTube: they share a lot of code
Wizzup: Alright, so I'm not going crazy... :)
BioTube: r500 chips use the r300 driver
ZeZu: all that matters is that the regs match and the driver knows how many ROPS to initialize and send commands to afaik ... i'm still in the midst of decoding some of the docs on the regs.
ZeZu: I wish there was actually a manual that described how to properly do initialization
airlied: goes further down multi operation rabbit hole