Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-6-04

Search This Log:

DanaG: http://anandtech.com/weblog/showpost.aspx?i=606
DanaG: spiffy.
DanaG: funky naming, though... RV620 is HD4200? And an RV635 is an HD3650...
DanaG: There's that generation-faking numbering.
nanonyme: DanaG: Yeah, marketing guys are 'funny'. ^^
DanaG: But at least they only do that with IGPs. =P
DanaG: NV seems to be doing it with lots of things.
DanaG: Renaming GF8 -> GF9 -> GTX-something-or-other
nanonyme: Supposedly they just want to tell us that it's newer => better or something...
hifi: I might go for that
chithead: DanaG: then there were the the radeon x1050 (rv370) and x2300 (rv550)
MrCooper: marketing people just like to come up with inconsistent names for some reason
glisse: MrCooper: btw with dri1 all mode reported by mesa have alpha component
glisse: so tagging than with non conformant sounds bad
MrCooper: glisse: that's not what matters, the visual depth does
MrCooper: the visual with depth 32 used to be marked as non-conformant
glisse: ok so i should tag according to that
glisse: will do
MrCooper: ah, so you're working on that? Cool
glisse: well i got a patch but it ended up tagging everythings a non conformant :)
hifi: glisse: any news on the issues I have?
glisse: right now i am working on making ttm radeon patch for 2.6.31
glisse: hifi: can't remember the detail, does it work when there is only 1 card in the computer ?
MrCooper: glisse: did you look at anholt's GLX visual changes which introduced the problem?
hifi: the drm stuff works when I removed the RV280 PCI id's from the driver so it didn't load for the second card
hifi: but I get the errors when I start X
hifi: in dmesg
glisse: hifi: did you try with physicaly removing one of the card ?
hifi: nope, would that matter?
glisse: yeah
glisse: i likely won't touch multi-card setup issue before next week
glisse: and that only if i find a pci card
glisse: i can't find any of my radeon pci card anymore
hifi: I will miss my second head but if it works it's worth it
glisse: MrCooper: no i didn't looked at the patch
glisse: MrCooper: this was an Xserver patch right ?
MrCooper: yeah, I would have looked at xserver/glx changes
glisse: will look once i get back to that maybe tomorrow
hifi: glisse: though if I can get dual head with separate X screens with the RV570 it would also be cool
hifi: last time I tried it didn't work out so well
glisse: hifi: it should be doable
hifi: I lost DRI completely with that setup
glisse: i don't have anyidea on how to do that thought
hifi: with a second PCI card I had DRI for both screens, though I needed it only for the RV570
hifi: or I could set up my second head as a synergy server
glisse: with kms you will have dri on all card/screen/head
glisse: but i don't know how the multi-master stuff behave with kms
hifi: I only need one DRI capable screen but more is welcome :)
stikonas: can anyone suggest why I get error "/usr/bin/X11/X: symbol lookup error /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: DRI2ScreenInit" after X server upgrade. I recompiled both libdrm and xf86-video-ati
jcristau: that symbol should be in /usr/lib/xorg/modules/extensions/libdri2.so
jcristau: so make sure you have that, and it's loaded
stikonas: thanks
osiris_: MrCooper: I got a question about *ptr++ = . I've always been taught that when one use post(in/de)crementation, the compiler rewrites it to something like this: tmp = ptr; *tmp = ; ++ptr; is this really an issue when gcc optimizations are enabled?
MrCooper: osiris_: what would the issue be?
osiris_: MrCooper: that the compiler allocates temporary variable. it could be written without it: *ptr = ; ++ptr;
MrCooper: not sure why that would make a difference, but I'm not a compiler guy... if you're really concerned about this, can you compare the generated assembly code?
MrCooper: or come up with a test case where it makes a measurable difference
osiris_: I now it won't matter in such a simple case (vertex copying). I'm just wondering if there would be a meaningful difference in speed, when such notations would be used few times in a loop, and the cpu would be spending most of it's time in this loop
osiris_: *know
osiris_: I'm certainly not going to nack your patch because of this notation. it's just some general thought
stikonas: jcristau: radeon is working now, I had dri2proto 2.0 which is too old for git xserver and dri2 was not compiled into xserver, thanks again
jcristau: stikonas: np
MrCooper: osiris_: if it does make a difference, it shouldn't be too hard to come up with a geometry heavy test that shows it? But it's probably easier to compare generated assembly...
MrCooper: but I'd be really surprised if the compiler could only do the former transformation but not the latter
pkt: I have to buy a new laptop and I 'm considering one with an ATI 3670. Will that work with the open-source driver?
adamk: pkt, The open source driver will provide 2D acceleration. There is no usable 3D acceleration.
pkt: I see, thanks :)
erjc: kern.log --> Xorg:5526 conflicting memory type http://erjc.pastebin.ca/1447433
erjc: kms drm ttm radeondrmfb ---> black screen
glisse: erjc: kernel is fine , you likely don't have the proper ddx
nanonyme: glisse: Do you think ddx will require changes to cope with the r6xx/r7xx KMS + memory management?
glisse: likely
nanonyme: *sigh* Sounds yet more branches. :(
glisse: don't see why this would need another branch
airlied: I think alex has done a lot of it already
airlied: he migrated in a branch to an r600 CS code
airlied: anyways we'll have merged kms to master soon.
glisse: airlied: i would like to do kernel security before merging
glisse: this would likely lead to ddx cs being rejected
airlied: why? surely it isn't doing anything illegal?
airlied: glisse: the merge window will open in a week I guess
airlied: glisse: I'm more worried about tiling
airlied: glisse: as I think we need to add relocs for the tiling regs
glisse: airlied: if we are experimental we can break cs userspace right ?
stikonas: Linus mentioned that he wants to release this weekend
airlied: glisse: yes but its not very nice :)
glisse: airlied: for instance some place in the ddx sends cliprect of 4096x4096 while touching 16x16 pixmap
glisse: this would be rejected
airlied: glisse: how much overhead will it be do you think?
airlied: but yeah lets merge what we have and try not to braek it too much :)
glisse: airlied: i want to be able to disable it to compare but so far with the code it's doesn't looks that it's much overhead
airlied: glisse: I'd ike to solve the multi-card before merging, but otherwise I think we should be okay to just mark it experimental
airlied: I might mark it staging so it taints the kernel
airlied: so we can tell from oops if people are using it
glisse: airlied: i can't find my pci radeon to test
glisse: staging sounds good
airlied: glisse: have a look at the globals sutuff,
airlied: patchess went around before
glisse: but i really would like to be able to break current ddx btw now and 2.6.32
glisse: right now i am doing the ttm patch i should sent it soon
airlied: yeah as long as we don't pull the DDX into master until you are finished braeking it :)
glisse: well security was on top of my list but got sidetracked with fixing rewrtie bugs
glisse: btw i need to send patch for f11
airlied: I was going to regen mesa
airlied: after I merge rewrite to master
airlied: its not like we have anyone working on the master driver now
glisse: yeah
airlied: so may as well merge and go for fixing it up in master
glisse: but there is still bugs in rewrite
glisse: for instance in xmoto i have texture corruption but i think it only happens in dri2 mode
glisse: also it seems i am bit by texture glyph corruption on agp :(
airlied: yes but it'll be easier to just fix it on master
airlied: but yeah lets try and get something into drm-next this week or early next week
airlied: I expect we are cutting it close for 2.6.31
airlied: as things need to be in linux-next before the merge window opens
glisse: airlied: i was doing a patch against 2.6.30-rc8
glisse: but was wondering how we would like to sent it
glisse: ie one big ttm patch ?
airlied: send TTM core as one big patch
airlied: its not really splittable too much
airlied: don't bother sending the TTM userspace API
airlied: that can come with a driver that needs it
airlied: you might need to base it on the drm-fixes tree I posted assuming Linus pulls it
airlied: I fixed a bug in radeon ring handling
airlied: but I don't think you'll get any conflicts
airlied: zzzz &
glisse: i am doing the ttm patch but it's hard than i thought, i first need to pick a bunch of core drm patches that i forgot about
airlied: oh thats bit of a pain :(
glisse: things can never be easy ;)
airlied: ah you have the global tracker already
airlied: in your tree
glisse: ?
glisse: oh yes
glisse: that is the things i have cherry picking
glisse: i compiling a tree right now
airlied: cool, this time zzzz.
glisse: if it works i push a branch on fdo and mail Thomas so he can send the patch
hifi: ok glisse, I pulled the PCI card out but no difference
hifi: http://hifi.iki.fi/dmesg.txt
glisse: hifi: a kms enabled userspace won't call radeon_cp_start_kms
glisse: radeon_cp_start_kms
glisse: so either wrong ddx, or way too old X, or no DRI2 X ...
hifi: now you say this? :p
hifi: after I had the pleasure to rip the PCI card out
hifi: so I'm still failing with the legacy stuff on
hifi: I don't see why it would call the old stuff
hifi: my Xorg is 1.6.1
glisse: should be fine
glisse: ddx is maybe not compiled with kms and dri2
hifi: http://hifi.iki.fi/Xorg.0.log
hifi: hmm, that might be
glisse: sadly getting things properly build is trytricky
hifi: I did install libdrm to /usr
hifi: I'm on branch radeon-gem-cs3
hifi: how can I see in the configure output it KMS and DRI2 are detected
glisse: hifi: is X working ?
glisse: ie can you run normal X app
hifi: yeah, I'm on X now
hifi: EXA works
glisse: ok so it works
glisse: you are missing mesa bits
glisse: radeon-rewrite branch
hifi: but when I start X those errors pop up in dmesg
glisse: X fails to load radeon mesa driver so it try to fallback to dri1
glisse: so in your case this is expected
hifi: oh
glisse: if you install properly radeon-rewrite no error will popup in the log
hifi: in Xorg boot?
hifi: so probably this will work after I boot with the clean built kernel and make installed radeon-rewrite
glisse: restarting X is enough
glisse: once you have installed radeon-rewrite
hifi: I built a new kernel with git pull'd updates
hifi: hmm, it might actually work now
hifi: though sadly, no moar fps :(
hifi: does this mesa branch have the FBO thingy dileX told me about
glisse: yeah fbo should work
glisse: try fbo examples in mesa/progs/demos
hifi: how come the half-life engine is so hard on radeon
hifi: fbo demos work nicely
nanonyme: hifi: Hmm, is it ran over Wine?
glisse: hifi: half-life doesn't work ?
hifi: yes
hifi: nanonyme: yes
hifi: glisse: yes, but slowly
nanonyme: I'd rather look into running native Linux programs that use FBO's.
hifi: I have no idea if hl uses FBO's
nanonyme: Wine is usually trouble.
stikonas: FBO's does not work for me at all
glisse: hifi: kms + gl driver are know to be lot slower than without kms
hifi: glisse: actually the speed is the same as the legacy ones
glisse: we are not yet to the stage where we do perf work
hifi: I was hoping to see any improvements
nanonyme: hifi: What did you use for benchmarking?
hifi: I walk in to a spot in one map and look around :)
hifi: not a real benchmark
hifi: but the performance hit there keeps me playing on windows
hifi: 100fps -> ~32fps
nanonyme: But yeah, as glisse noted, the DRI2 is possible to get faster a bit later on. ^^
hifi: it seems to have something to do with water
nanonyme: Egh.
hifi: nah, probably not
hifi: just wide space
nanonyme: No big surprise there if it was, really, I think water has traditionally been one of the hardest things to render...
hifi: tried in a map that has no water
hifi: just looking like inside a house fps drops
hifi: when there are lot of stuff to render
nanonyme: Worst case: needs LLVM to go fluid. :p
hifi: the game is like 10 years old, please :D
hifi: and I can't find anything in the engine to optimize the result
nanonyme: (Plus iirc someone was looking into implementing some optimization architecture that has been in ATi cards for ages but just isn't in open drivers. Sadly don't remember the name of the technology)
hifi: I heard about it here
nanonyme: Same.
hifi: also can't remember what it was
hifi: but from my point of view RV570 shouldn't have any problems rendering something that old without optimizations
hifi: but after all, I don't know anything about writing drivers :)
nanonyme: Maybe or maybe not.
hifi: well, quake 2 runs fine
hifi: so does quake 3
owen_: nanonyme: well, right now, one thing that we don't do with dri2 is tiling, which is just a a little bit important...
nanonyme: Considering with CPU's too the important thing isn't nearly always the raw calculating power but the extensions.
owen_: nanonyme: the memory access patterns that the card does when rasterizing don't work well without tiled buffers
nanonyme: Hmm, right.
nanonyme: owen_: Doesn't necessarily mean it's the only place where you can optimize though, right?
owen_: nanonyme: I'm also not sure if mesa turns on HyperZ (early pixel rejection based on z-range-estimates for tiles of pixels)
nanonyme: Ah, that was it.
nanonyme: Someone said were going to start writing HyperZ for radeon.
hifi: is there any particular thing that could be slow currently
osiris_: it was me, buit I got sidetracked by other stuff
owen_: hifi: well, both of the things I mentioned above will cause huge performance gaps between fglrx and mesa. They certainly aren't the *only* things that mesa will be slow at.
hifi: and there is nothing to be done from the app side to disable things that slow it down?
nanonyme: Probably not that big an impact at least compared to HyperZ (if it does what the explanation makes me think it does).
owen_: hifi: if you have some game that is slow, things you can do to investigate include a) look at top. Is the cpu pegged or not? If the cpu is pegged, use sysprof to figure out why b) see how performance scales with resolution. If dropping to a lower resolution doesn't speed things up significantly, then the slowness has to do with geometry, not texturing
hifi: I'll start with lower resolution
hifi: thats easy to test
nanonyme: owen_: If the game is 10 years old, pretty unlikely to be a resource problem. ^^
hifi: unlikely :)
owen_: If you actually have access ot the engine sources, then there are all sorts of things you can try- you can basically hack out any part of what the game is doing, and see what effect that has
adamk: You can also use a utility like bugle to intercept all opengl calls that the game is making.
owen_: nanonyme: yeah, if the game is actually 10 years old slow and worked on a mach32, then about the only thing that would make it slow on a semi-modern card like a r500 is software fallbacks
hifi: actually the fps doesn't change at all between 1280x1024 and 800x600
adamk: It could be using something that isn't accelerated.
hifi: in that case I'd like to know what
hifi: but I'm really surprised resolution didn't matter at all
owen_: hifi: there's some envvar you can set to have mesa print out software fallbacks it is using, I think?
glisse: owen_: hyperz is more than that it's an optimized/compressed Z buffer which allow to perform z test a lot faster
owen_: hifi: alternatively, sysprof will give you that information as well, since it will be obvious what's at the top of the profile
owen_: glisse: there's some conflation of marketing and tech terms that makes it a bit confusing to know exactly what "HyperZ" is
glisse: we already do early z test ie discard fragment before going through the fragment shader
hifi: owen_: could you guide me trough sysprofiling the game?
glisse: owen_: yeah what hyperz do is bit hidden by marketing :(
owen_: glisse: developer.amd.com/media/gpu_assets/Depth_in-depth.pdf is a pretty neat read
glisse: owen_: mostly hyperz use on chip dedicated memory
glisse: with advanced z value packing
owen_: hifi: Sorry, about to run out.
hifi: np
hifi: can I do something in driconf?
nanonyme: glisse: Hmm, I don't think I figured out your opinion on it: do you think it'll have a big impact on 3D applications?
hifi: omg lol (had to say it out loud)
hifi: the Direct3D renderer is actually faster than OpenGL
glisse: nanonyme: what ?
glisse: nanonyme: tiling will give a boost, hyperz will give another boost\
glisse: but right now the biggest things that needs optimization is how badly we behave with allocating/deallocating bo and also way too small cs batch we ask
phoenix64: okay, this is a call for help, I don't know how to get further really: I have a program here which uses SDL + OpenGL, the code for initialization is simple and mostly copied from 1-2 tutorials, but when I start the program with a r300 in the system and the radeon driver, it jumps to 0 somewhere deep in *my* code (when it is supposed to call a constructor, a place where usually nothing can go wrong)
phoenix64: however, if I enable software rendering, everything works
phoenix64: maybe there is anyone who could maybe help us out? (experiencing this on 2 computers, not on mine, I don't have any r300)
phoenix64: I will of course do as much of the debugging and helping as possible for me, but *to me* this looks like a problem somewhere in the dri driver
phoenix64: the thing is that I don't have any clue on where to start debugging as neither valgrind nor gdb can help with any useful information
phoenix64: ah, wait, on one of the two systems the back trace is slightly different, trying that one now
phoenix64: d'oh, I probably used glew wrongly, sry for annoying you -.-
Zajec: airlied: could you put status of radeon-rewrite somewhere? blog/dri-devel/else? would like to know how near merge we are :)
Adola: Hi! I'm using xorg. And I've got an issue.
Adola: I believe the term is...Artifact? I honestly don't know it's name. But, there are odd parts on gui of programs.
Adola: For example, using konversation, sometimes, over the chatt area, a box of....Color? appears. And To "erase" it. i have to highlight the text that was underneath.
MostAwesomeDude: Adola: I assume you're using radeon...which version?
MostAwesomeDude: Actually, could you just pastebin your Xorg.0.log?
Adola: Um, I don't know?
Adola: Just sudo kate xorg.0.log right?
MostAwesomeDude: Well, go to pastebin.ca, upload /var/log/Xorg.0.log, and paste the link that you get from that, here.
Adola: MostAwesomeDude: http://pastebin.com/d231741f
sannes: Adola: Do you have a screenshot off the artifacts?
Adola: Let me try.
Adola: Where can I send it?
MostAwesomeDude: Everything seems reasonable in the logs, and you're not on AGP.
MostAwesomeDude: imagebin or tinypic.
Adola: Ok, hold on, I'm on dail-up
Adola: Gah, still waiting.
Adola: I gotta go, I'll be back.
Nebukadneza: heho
Nebukadneza: i've got a xrandr problem using a X1550 and the "radeon" driver. i've got everything up and running, with a minimal xorg.conf (as new xrandr stuff suggests), bot monitors (one VGA, one DVI) are in clone mode
Nebukadneza: i just don't manage to get them to be xinerama (aka dvi rightof vga)
Nebukadneza: i tried xrandr --output VGA-0 --auto --output DVI-0 --auto --right-of VGA-0
adamk: Nebukadneza, Welcome... What happens when you try that.
Nebukadneza: both screens blank and still show the same cloned picture
adamk: Did you get an error?
Nebukadneza: nop
Nebukadneza: oh wait
Nebukadneza: i did
Nebukadneza: xrandr: screen cannot be larger than 1440x1440 (desired size 2560x1024)
Nebukadneza: do i need to set some virtual resolution or something?
Nebukadneza: xrandr -q says Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1440 x 1440
adamk: Well that's the problem, then :-)
adamk: That second link I gave you in #ati shows how to set a Virtual screen.
yamato: oh, there is a 4670 AGP card out
yamato: Are there any technical reasons to steer clear of AGP and plan for a new PCI-E system?
Nebukadneza: HELL YEAH
Nebukadneza: works
Nebukadneza: thanks"
Nebukadneza: thanks so much
adamk: No problem.
owen_: yamato: definitely much better to ditch your motherboard and buy a cheap pcie card rather than going for an expensive/obscure agp card
glisse: yeah please don't buy AGP card
glisse: AGP needs to die
yamato: well, the 4670 AGP shouldn't be more expensive by any large margin than it's non-bridged counterpart... its just that I have it in my mind for some reason that AGP would make trouble
owen_: yamato: What I"m actually saying, is that the cheapest ati card you can find + pcie will give you better luck than a fancy new agp card
owen_: yamato: (probably, depends, but anyways, agp is a hacked up technology, that as glisse says, should die)
yamato: well, the 4670 is a very low power card as it is, so if i were to have a PCI-E motherboard, I would probably opt for the 4670 still
raevol: 4670 is a sweet card, that's what i have
raevol: pci-e
yamato: glisse: Thanks, I'll plan for a new machine in that case.
p4ddY`: 4670 is nice
agd5f: glisse: be8d7f4547ba1eb2424376d1f84909ee3f0ed905 is still wrong
legend2440: agd5f: hi. i dont know if you remember me but i was having problems getting my radeon 9600 cards tv out function to work with jaunty. then i got it working with a script but since i rebooted i have not been able to get it to work again. tv picture just keeps flipping as in vertical hold problem.do you think these drivers would be worth trying? https://launchpad.net/~xorg-edgers/+archive/radeon
agd5f: glisse: should be if (pcie) { rv370_pcie_gart_disable(rdev); } else { r100_pci_gart_disable(rdev); }
agd5f: legend2440: you can give them a shot
legend2440: agd5f: ok thanks
agd5f: legend2440: nevermind, that's just mesa
glisse: agd5f: well in fact i think we are both wrong and we could unconditionaly disable pcie & pci
glisse: when in agp
legend2440: agd5f: ok
glisse: disabling pci with pcie shouldn't hurt
agd5f: glisse: but not all cards have pci and pcie gart
agd5f: but different stuff lives at those regs
agd5f: in each case
glisse: agd5f: oh i did though there was no differences, oh i know i missed r5xx :)
glisse: agd5f: thing is flags & PCIE will never be set i think if AGP is set
glisse: need to dive into this
agd5f: glisse: then just check the chip family
agd5f: glisse: I can do a patch
glisse: i should replug a r5xx in my desktop :)
glisse: so i suffer the consequences of my error
agd5f: glisse: if (agp) { if (chip >= rv370) { rv370_pcie_gart_disable(rdev); } else { r100_pci_gart_disable(rdev); } }
glisse: agd5f: yeah that sounds like the proper patch
glisse: got to go will push later
agd5f: glisse: cool
dileX: worth reading: "The irregular Radeon Development Companion"
dileX: glisse: is that new jg@rh?
Adola: Ok, sorry, I'm back now.
Adola: http://yfrog.com/58artifactp Here is a screeny of the artifact.
lynx_abraxas: Hello!
MostAwesomeDude: Adola: Are you using GL or Xrender for your desktop effects?
Adola: MostAwesomeDude: Um.....I don't know? I'm using compiz. How can I check?
MostAwesomeDude: Adola: Ah.
MostAwesomeDude: I thought you were using Kwin4.
MostAwesomeDude: Does the corruption stay when you're, say, spinning the cube?
Adola: Hold on, let me check.
Adola: Yes.
MostAwesomeDude: Is it "stuck to the window" or "stuck to the screen?"
Adola: Stuck to window.
MostAwesomeDude: Woot, not my problem!
MostAwesomeDude: Um.
MostAwesomeDude: You should go ask in #compiz.
dmb: is it possible to set up ubuntu 9.04 to use KMS, or would you have to compiler your own kernel (i'm expecting to git the drm bits mesa etc)
MostAwesomeDude: dmb: Yeah, you almost certainly need to build a custom kernel.
lynx_abraxas: Does "MWM hints" have anything to do with mesa being linked to lesstif?
MostAwesomeDude: That said, yes, people have gotten it working in Ubuntu.
Adola: Hehehe, thanks.
MostAwesomeDude: lynx_abraxas: Well, MWM hints are for the window manager, and neither Mesa nor lesstif are window managers, so probably not.
MostAwesomeDude: That said, I have no idea why Mesa is linked to lesstif.
dmb: MostAwesomeDude, because i have a need to using 2 x servers, and as you know, without kms, the second server has no accel and is so slow its unusable
MostAwesomeDude: dmb: Xnest? Fast user switch?
lynx_abraxas: MostAwesomeDude: Thanks, I couldn't find anything about it on the net. Do You know what is responsible for it in xorg?
MostAwesomeDude: lynx_abraxas: Might have something to do with Xaw.
dmb: MostAwesomeDude, all that fast user switch does is start another x server
dmb: xnest works, but its not good enough
dmb: MostAwesomeDude, interstingly enough, the fglrx used to work with that
nanonyme: *freeze*
lynx_abraxas: MostAwesomeDude: That's a good hint. I will recompile all libs and see if that helps.
dmb: MostAwesomeDude, is there any kind of guide to applying all that patches and setting it up on ubuntu?
dmb: MostAwesomeDude, or, does the ubuntu alpha use kms yet?
MostAwesomeDude: lynx_abraxas: If it helps, neither my libGL, nor libXaw, nor libX11, are linked with lesstif.
MostAwesomeDude: dmb: No idea on guides. I hear that Karmic's got KMS, but no idea how complete it is.
lynx_abraxas: MostAwesomeDude: So I can rule out it has something to do with my radeon driver, is that correct?
dmb: MostAwesomeDude, i should be able to download a plain vanilla kernal and apply patches?
agd5f: dmb: this guide should work: http://jglisse.livejournal.com/1822.html
MostAwesomeDude: lynx_abraxas: I don't think so, no.
dmb: agd5f, so i don't have to compile my own kernel?
agd5f: dmb: you do
dmb: ok, i'll be trying
dmb: agd5f, is it known to be somewhat stable?
agd5f: dmb: yeah
dmb: ok good
dmb: 272MB, quite large
nanonyme: What is? o.O
glisse: agd5f: pushed thanks for spotting this :)
agd5f: glisse: looks good
glisse: checking cmd stream is full of interesting info ddx is try to do the following rendering :
glisse: Jun 4 21:14:00 earl kernel: [drm:r300_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 1296384 have 4096) !
agd5f: glisse: yeah, you find some disturbing things that aren't evident in the code
dmb: glisse, what catagory in the kernel config is ttm in?
mattst88: I don't remember the name, but it's in the same area as framebuffer
glisse: dmb: in driver->graphic driver->drm
mattst88: glisse, you're seeing text corruption too with KMS?
glisse: mattst88: yes but only on agp
mattst88: hmm, I'm getting it on my PCI X1550.
glisse: but alpha ?
mattst88: yes, on Alpha
dmb: glisse, i don't see ttm there
glisse: likely somethings about cache being different
glisse: dmb: it only exist in my tree
dmb: glisse, this is your tree
dmb: git clone git://people.freedesktop.org/~glisse/drm-next
dmb: oh wait
mattst88: glisse, a quote from an Alpha kernel developer might be of use: "There is quite fundamental conflict between the Alpha architecture and x86 AGP implementation - Alpha is entirely cache coherent by design, while x86 AGP is not (I mean native AGP DMA transactions, not a PCI over AGP). There are no such things as non-cacheable mappings or software support for cache flushing/invalidation on Alpha, so x86 AGP code won't work on Nau
mattst88: tilus."
dmb: yup, i am using it
mattst88: of course, in my case the card is still PCI.
dileX: dmb: switched to drm-next-radeon?
dmb: dileX, yes
dmb: i see direct rendering manager
dmb: but i see no ttm
mattst88: search for TTM to verify it exists.
mattst88: / key searches
dmb: when i open the .config
dmb: i ttm is a module
dileX: grep CONFIG_DRM_TTM .config
dmb: is it ok if radeon and ttm are a module?
dmb: or does it have to be y
glisse: dmb: module are better for the moment
dileX: glisse: cool, new commits.
dileX: glisse: hmm, I am missing "[PATCH] drm: fix irq naming for kms drivers.
glisse: dileX: i am working on making patch for inclusion in 2.6.31, so it will be there
glisse: and this patch is cosmetic at this point ;)
glisse: corruption on agp or even pci are more serious
dileX: glisse: OK, n.p. Just GO!
dileX: yeah, drm-next-merge
glisse: airlied: i pushed a start at advanced checking of cs to catch memory access beyond bo size
glisse: it miss 2d blit checking (easy), vertex buffer (more or less easy), texture (harder)
glisse: same code will apply to r5xx
glisse: and same spirit for r1xx/r2xx/r6xx/r7xx
glisse: haven't done much benchmarking but diff with or without checking seems to be non significative
glisse: i also updated my ddx to behave properly :)
glisse: bit tired so i will likely be off, catchup with you latter
agd5f: glisse: in r300_cs_track_check you might want to take tiling into account
agd5f: since that will affect pitch
glisse: agd5f: yeah haven't yet looked at tiling
glisse: agd5f: well pitch programmed in colorpitch should already take tiling into account right ?
agd5f: glisse: yeah, I think so
agd5f: should be ok then
glisse: anyway better reviewing what happen when in tiling rather than guessing from memory :)
glisse: zZz
nanonyme: zZz sounds like an excellent idea. ;)
dmb: stupid question, but why do i get ./configure: line 12312: syntax error near unexpected token `XINERAMA,'
dmb: ./configure: line 12312: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)'
dmb: i have x11proto-xinerama-dev installed
rah: what are you doing?
rah: how do you "get" it?
dmb: building xf86-video-ati
dmb: git
dmb: running configure
rah: do you have the macros package?
dmb: i believe so
dmb: should come with autoconf right?
rah: I mean the xorg macros package
dmb: i would think that would be there all ready
rah: http://cgit.freedesktop.org/xorg/util/macros/
rah: why would you think that?
dmb: should be a package
dmb: in some package
dmb: on debian
dmb: well, installed a bunch of packages, one of them fixed it
rah: xutils-dev: /usr/share/aclocal/xorg-macros.m4
dmb: rah, yup
dmb: that was it
dmb: so when using kms, is the console as fast as the vga console?
spstarr: ponders making sunny side up eggs for dinner
dmb: wow, very very nice 1920x1200 console for me :P
raevol: nice :D
dmb: its only using software rasterizer though
dmb: trying to figure out why
dmb: it says direct rendering=yes, but OpenGL renderer string: Software Rasterizer
nanonyme: Hmm.
nanonyme: dmb: Yes, software rasterizer always implies direct rendering, I think.
nanonyme: (At least without compositing)
dmb: yeh
nanonyme: I doubt it can do DRI2 though.
dmb: well, doesn't dri have to be working if modesetting is working?
nanonyme: Mmh.
dmb: i don't even care about gl stuff, i just want to be able to use EXA
nanonyme: Well, if xvinfo tells you have interfaces, should work.
dmb: in the xlogs, it says
dmb: [dri] radeon.o kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
dmb: [dri] Disabling DRI.
dmb: xvinfo sasy no adapters
nanonyme: Hrm.
nanonyme: Got new enough libdrm?
dmb: that would probably be an xf86-video-ati issue
dmb: hmm
dmb: yes
dmb: i think
dmb: thats
dmb: git clone git://anongit.freedesktop.org/git/mesa/drm right?
nanonyme: And the proper branch.
dmb: yup
dmb: did that also
nanonyme: That very much sounds like a bug that iirc someone said was fixed already.
dmb: looks at glisse
nanonyme: I think he's asleep.
dmb: looks at agd5f :P
nanonyme: Hmm, neat.
agd5f: dmb: pastebin your xorg log
nanonyme: I manage to get "failed to revalidate buffers, failed to revalidate BOs - baddness, Segmentation fault" while resizing redbook hello with r6xx-rewrite. :)
dmb: agd5f, http://pastebin.ca/1448178
nanonyme: agd5f: To be expected?
agd5f: dmb: you aren't running a kms enabled ddx
dmb: agd5f, so that would be xf86-video-ati thats the problem?
agd5f: dmb: yes
dmb: hmm
agd5f: you need the one in glisse guide right now
agd5f: master doesn't have kms support yet
dmb: i used the one he listed on his blog
dmb: http://jglisse.livejournal.com/1822.html
dmb: modesetting-gem
agd5f: dmb: radeon-gem-cs3
agd5f: is the branch
dmb: oh, maybe that post was out of date
agd5f: dmb: the post is fine
dmb: oh oops, i did use that one them
dmb: maybe i didn't make install
dmb: tries
dmb: brbs
spstarr: hullo mad
MostAwesomeDude: Evening.
nanonyme: Moin.
nanonyme: Oh no, I can't post on Phoronix anymore. Reached a pretty binary number of posts. :)
lymeca: count #?
dmb: well
dmb: xvinfo works this time
nanonyme: lymeca: 2^7
dmb: but still shows that it is using software rasterizer
spstarr: dmb: which gpu
dmb: spstarr, r500
dmb: whatever the x1400 is
lymeca: nanonyme: post twice as much? ;-)
spstarr: that's sharing the r3xx code
dmb: agd5f, heres the new xorg
dmb: http://pastebin.ca/1448188
dmb: its definitly using the modesetting driver this time
agd5f: dmb: looks good
spstarr: (EE) AIGLX error: Calling driver entry point failed
spstarr: (EE) AIGLX: reverting to software rendering
spstarr: hmm?
dmb: agd5f, but glxinfo still says its using the software rasterizer
agd5f: dmb: probably missing dri2 stuff or some problem with your 3d driver
spstarr: dmb: what does GL_DEBUG=verbose (if i did the right variable) say when running with glxinfo?
agd5f: LIBGL_DEBUG=verbose glxinfo
spstarr: oh LIBGL
dmb: libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so
dmb: libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
dmb: libGL error: failed to create dri scree
dmb: hmm
dmb: this is r500
nanonyme: Do those files exist?
nanonyme: (Either of them)
spstarr: dmb: r3/4/5 share
dmb: yes, second exists
dmb: ugh oh
nanonyme: It's not really being excessively verbose, is it? :/
dileX: agd5f: I have here with 2.6.30-rc8-git1 on top of drm-next-radeon (and glisse ddx)
dileX: #
dileX: (II) [drm] Could not create SAREA for DRM lock.
dileX: #
dileX: (EE) RADEON(0): [dri] DRIGetVersion failed to open the DRM
dileX: #
dileX: [dri] Disabling DRI.
dileX: modesetting-gem (mesa/drm)
agd5f: dileX: not sure what's up with that
dmb: i don't know if something is wrong with the build system for mesa
dmb: but i copied r300_dri.so manually to where it needed to go
spstarr: dileX: which mesa?
dmb: and it worked
dileX: spstarr: 7.6+radeon~rewrite+git20090528.5dcbcbf-1~dileX+1 + nha's "radeon: Provide a more detailled GL_RENDERER string" (so-to-say latest radeon-rewrite)
spstarr: !
dmb: wow, this is perfect!
dmb: gl is working on 2 servers now!
spstarr: :)
dmb: i know someone just talked about this, but no glsl yet right?
agd5f: dmb: nope. not until gallium probably
dmb: it seems like flash video doesn't use GL or XV yet, is there a reason?
agd5f: dmb: ask adobe
dmb: :(
dmb: thats why i hate closed source things
dmb: especially on linux
zhasha: dmb: it uses GL in version 10
dmb: for some reason, video seems very very very slow
zhasha: but you need to have a few extensions (ARB_fragment_shader and ARB_vertex_shader are just a few)
dmb: does the open source driver have that?
zhasha: no
dmb: so it completely disables gl if it doesn't have that?
zhasha: yes
dmb: thats stupid
zhasha: no?
dmb: zhasha, you know of any way of forcing it on?
dmb: a video shouldn't need those extensions?
zhasha: you can't, it requires we support GLSL
zhasha: working on it in the gallium3d driver, be patient
dmb: oh
dmb: zhasha, would libswf or gnash work you think?
zhasha: perhaps but I doubt the implementations are feature complete
dmb: i'll have to see if i can have swfs use adobe flash, and .flv gnash
dmb: so with KMS, are applications unable to switch to fullscreen?
spstarr: which kind?
spstarr: I use VirtualBox and can switch to full screen inside it
dmb: well, like lets say a wine game
dmb: that sets the monitor to 800x600
mjr: the x server will simply ask the kernel to do the mode change rather than doing it itself
dmb: doesn't seem to work for me
dmb: the ubuntu/gnome Display properties thing doesn't let me change the resolution either
mjr: oh, you were asking a question about the current situation. I have no clue what works ;P
spstarr: dmb: i dont see why not
dmb: ugh oh
dmb: i see this in dmesg
dmb: http://pastebin.ca/1448283
dmb: radeon 0000:01:00.0: LVDS-1: no EDID data
DanaG: hmm, I wonder what kind of performance you'd get from one of these, with an ATI GPU.
DanaG: http://www.xilinx.com/products/devkits/HW-V5-ML510-G-image.htm
DanaG: warning: big big image
DanaG: 2294px × 1882px
dmb: hey spstarr
spstarr: ya
dmb: spstarr, what happens if you are in a console, and you do cat /dev/urandom > /dev/fb
dmb: is it really slow?
dmb: to fill the screen
dmb: or is it instant
spstarr: you mean simple display of text scrolling?
spstarr: i dont know if kms is optimized for text mode yet
dmb: spstarr, that slowness i get when i do that is as slow as any other gl app i use
dmb: spstarr, is gl really really unusably slow for you?
spstarr: im not able to tell you, i have an r6xx right now and in Intel GMA mode
spstarr: my r3xx is 'sleeping'
dmb: oh
dmb: spstarr, do you remember if your exa was also slow on your r3xx?
spstarr: longer time ago yes
dmb: oh
dmb: well, at least xv works very fast
terracon: dmb: yeah exa seems slow compared to f10 and 3d is pretty bust right now (f11)
agd5f: dmb: the kernel code doesn't add non-native panel modes yet IIRC.
agd5f: you'll have to add them manually
DanaG: agd5f: Nice info about power management, on your blog.
spstarr: will hit the freedesktop blog in a bit im on the kde one, then gnome..
DanaG: http://www.botchco.com/agd5f/
DanaG: sorry about the extra ping. =þ