davem1: w00t 3d is working on sparc64 too
airlied: davem1: nice.
davem1: airlied: you have all the fixes necessary, my library paths were just screwed up :)
davem1: airlied: I can't wait for all those fixes to hit Linus's tree :)
airlied: I'll queue em up in next behind benh I'd be tempted to get push them sooner but Linus would kill me )(
davem1: hehe
davem1: he might not barf as long as his graphics keep working :)
airlied: he's got Intel :)
davem1: yeah and he doesn't use his powerpc box much anymore, so we're safe
airlied: my main worry is actually that < fix, I suspect that might actually berak something :)
davem1: I couldn't believe when I caught that one
davem1: I checked the rest of the headers for similar bugs
benh: davem1: heh
benh: davem1: so you got 3d working ?
benh: while I'd love to see those in .29, let's be a bit realistic :-)
benh: the risk for regression is non-nil, it wouldn't surprise me if some stuff worked on some platforms due to a bug hiding another one
benh: that sort of thing
benh: wouldn't be the first time with radeon
benh: I'll give the patches a go on as much powerpc gear as I can find tomorrow tho
benh: might even solve some of those nasty lockups we had on bimini
airlied: benh: I'll try and get it all into drm-next so you can pull it
benh: airlied: cool, thanks
benh: airlied: I still have some WIP on fixing the domains crap btw
benh: airlied: I'll see if I can finish it tomorrow ... ie, the basic is there as we discussed (bumping interace version to enable proper domain stuff kernel side)
benh: airlied: but it still goes bonkers with 2 cards here so there's something else I need to fix
airlied: davem1: I'm counting 6 drm patches 5 initial series + the surface one
airlied: ah nuts I hope git-fsck saves my ass, reset wrongly.
airlied: benh, davem1 : okay my drm-next branch should have all the bits in it now
davem1: airlied: reflog is a life saver when you do that (bad reset)
davem1: airlied: I'll pull and test it out
davem1: airlied: One bug fix missing, I forwarded another copy to you
davem1: anyways that fix just makes sure we don't run off the end of the GART table when filling it in
davem1: your tree should work for me as-is, so will test as soon as kernel build finishes...
airlied: davem1: pushed thx.
davem1: airlied: just booted up, works
nha: Given that most hardlocks are, according to glisse, due to the card accessing an illegal address on the PCI bus, is there some way the card's memory setup can be changed so that it just won't do that?
nha: i.e. is there some register we can set to make sure that those bogus accesses simply do not appear on the bus but are caught on the card itself?
nha: at least on reasonably standard pc architectures, it should be possible to tell the card that it's only allowed to access one contiguous region, where the system RAM is located, and we know how big the system RAM is...
davem1: IOMMUs do this on some systems
davem1: it does on sparc64 for example
davem1: that's how I found the PCI_DMA_BIDIRECTIONAL bug in the ati_pcigart.c code
davem1: the IOMMU faulted on the write to read-only IOMMU mapping
davem1: there are also some weird controls in the PCI-E GART at least that allow control over what happens to accesses outside of the GART window
davem1: pass-thru, ignore, error, etc.
davem1: the older radeons have very few if any of those controls
glisse: nha: there is setting in gart for that
glisse: actualy we set it up to passthrough
glisse: this is for historical reason linked with writeback (maybe bogus gart on some hw)
glisse: but i think we should set it up to clamp and provide a default safe page to which clamp such access
glisse: hw will then read 0 data (assuming we zero out the failsafe page)
glisse: which i think should be safer and at least provide a chance to debug lockup
glisse: for older radeon the control is in AIC_* regs
glisse: iirc
nha: glisse: yeah, that would be a good idea; I think it's pretty likely that anything that causes a hard lockup without such a safeguard would trigger a soft lockup or rendering corruption instead, so it would still be noticed by people, and we'd have an easier time debugging it
glisse: of course their could still be hard lockup due to others things i have barely explored all lockup situation :)
nha: sure, but anything that has a chance of making lockups easier to debug is a good thing in my book
MostAwesomeDude: glisse: Been out all day and all night too. Built the wrong kernel; waiting for new kernel now.
felipec: agd5f: ping
felipec: or anyone can take a look at http://bugs.freedesktop.org/attachment.cgi?id=22960
nha: airlied: There's still a problem with the build because some of the build system fixes from master are missing
nha: airlied: in particular, make install fails in the glew subdirectory
osiris_: anyone here using fglrx right now on r500 or r300?
MostAwesomeDude: osiris_: Could you link me to your RS fixups?
osiris_: let me find it
osiris_: MostAwesomeDude: http://marc.info/?l=mesa3d-dev&m=123439266102026&q=p3
nha: airlied: when running radeon-gem-cs2 from your xf86-video-ati together with a modeset=0 drm-rawhide kernel, I get the following error message from the X server every time a GL app starts:
nha: (EE) RADEON(0): Unable to reserve offscreen area for back buffer, you might experience screen corruption
nha: any pointers as to what could be the cause?
chemart: hi
chemart: how do i set position and size of image displayed on my lcd display?
osiris_: nha: can you check if mesa/progs/trivial/point-param works for you and whether point size vertex attrib is pushed?
osiris_: nha: when I try to push point size attrib in vertex buffer on my rs690 (no hw tcl) the points are screwed. I'm wondering if there's anything special in sw tcl case
osiris_: chemart: xrandr should have necessary options
MostAwesomeDude: glisse: Your recommended change for pciegart setup did not help.
osiris_: anyone wants to try out point attenuation support on tcl enabled hw?
nha: osiris_: I'll have a look on my RV535
osiris_: here you go: http://pastebin.com/m5de6b248 should apply cleanly on top of current head
osiris_: nha: all you'll probably be interested in is append_point_atten_code function
nha: actually, it doesn't apply cleanly
osiris_: nha: where's the conflict?
nha: patching file src/mesa/drivers/dri/r300/r300_swtcl.c
nha: Reversed (or previously applied) patch detected! Assume -R? [n] n
nha: Apply anyway? [n] y
nha: Hunk #1 FAILED at 136.
nha: Hunk #2 succeeded at 149 with fuzz 1 (offset -26 lines).
nha: Hunk #3 succeeded at 181 (offset -57 lines).
nha: Hunk #4 succeeded at 205 (offset -59 lines).
osiris_: nha: here's updated patch also with fog coords support: http://pastebin.com/m3505c9f3
osiris_: .. should have done point attenuation in seperate branch :/
nha: actually, even with the non-properly applied patch, the point-param looks just like what software mesa creates
osiris_: are you saying that is works?
nha: osiris_: looks like
osiris_: dang :)
nha: osiris_: if you have somewhere to put a git repository (e.g. on fd.o), that might be easier than handling patches manually ;)
nha: osiris_: note I'd be more comfortable with a patch that applies cleanly against master and has one single purpose
osiris_: nha: yeah, I am going to clean them up before sending for commiting
osiris_: it's work in progress
osiris_: so I don't pay that much attention to cleanliness
nha: but cleanliness is next to commitliness...
osiris_: nha: do you know whom I should contact to get git account?
osiris_: could you take a screenshot of point-param?
nha: basically, you have to file a bugreport in the appropriate place
nha: it's documented somewhere on the fd.o wiki
nha: hmm
nha: hold on
rmh3093: is any radeon kms gonna make it in .29 or will that all be in .30
osiris_: rmh3093: certainly not in .29, hope it makes in .30
glisse: even .30 seems to close
glisse: given that iirc merge for 30 will be just couple of weeks after .29 is released
nha: osiris_: http://people.freedesktop.org/~nh/temp/point-param-r500.png
osiris_: nha: I compared it with gimp, and it's the same as with software rendering
osiris_: nha: of course it doesn't work on non tcl hw :/ it has always been troublesome
osiris_: summons bridgman
osiris_: is out of mana, summoning failed
osiris_: nha: could you try demos/pointblast?
nha: what is different there?
osiris_: just wanted to know if it works, if yes will do GL_POINT_FADE_TRESHOLD_SIZE_EXT
bridgman: sorry osiris, time zones and all that..
osiris_: bridgman: I'm fighting ARB_point_parameters right now. could you find out if there's anything in point size parameter handling in non tcl hw? looks like it works already on hw enabled card, but non tcl hw is problematic of course
osiris_: *anything special
nha: osiris_: does fog without fogcoord actually work correctly without your patch?
osiris_: nha: only when EXT_fog_coord extension is disabled
osiris_: nha: when this extension is enabled, mesa does all the fog in shaders (so all the r300FogState and r300FogFv is irrelevant)
nha: hmm
nha: but doesn't the hardware have a dedicated fog unit?
osiris_: nha: yes, but it was real pain to do it that way
nha: odd
osiris_: nha: in the end I found out that the fog coords that were routed through alpha component of one colors were clamped to 0..1 and that's why it didn't work
osiris_: the color clamping can be disabled on r500, but not on r300
osiris_: nha: so to make it work on r300 one would have to scale fog coords first in vertex shader
nha: ah I see
kcodyjr: hey bridgman, what you doing here during daylight ;)
osiris_: nha: I dug some more and looks like the point attenuation vertex program should already be added (look at build_atten_pointsize in main/ffvertex_prog.c). it's weird it doesn't work without my patches
osiris_: nha: about the fog patches. Markus Amsler has been testing it on r300,r400 and r500 and looks like they are almost ready to clean up and commit
osiris_: osiris_: so were almost there with opengl1.4 support
osiris_: talks to himself :/
osiris_: as airlied said with his recent work on radeon-rewrite it should be pretty easy to add occulsion query,pbo and fbo support
osiris_: so only glsl support will be necessary to advertise opengl2.0
bobbens: sounds awesome :)
nha: osiris_: very good
nha: yeah, occlusion query, vbo, fbo, pbo are all pending on cs+mm essentially
nha: so far, I haven't gotten that to work...
MrCooper: osiris_: except for Occlusion queries, you get all that pretty much for free with Gallium
nha: yep
MrCooper: not sure it makes sense to bother with those in the traditional driver
nha: true, though we should aim for a kms+mm-aware traditional driver, just to provide a smoother upgrade path
bridgman: kcodyjr; it's a weekend, I'm not at work
osiris_: I think it makes, because I don't think that distros will jump that quickly to gallium
bridgman: osiris; OK
MrCooper: why not, what's the problem?
nha: personally, I probably won't worry about {v,f,p}bo in the traditional driver model
osiris_: bridgman: thanks in advance
bridgman: you'll probably end up having to thank agd5f again ;)
nha: the only sad thing about that is it leaves ancient cards without support for those features, even though they would be perfectly capable of supporting them
MrCooper: true, but OTOH they tend to lack power for stuff that really needs those features
bridgman: nha; I think the rewrite airlied just finished says "no plan to walk away from the older GPUs"
nha: I suppose
bridgman: osiris; now that gallium3d is in master I think there'll be more jumping going on
bridgman: before that it was a science project
nha: bridgman: well, in the long term, we'll definitely want to use gallium for >=r300, but the whole shader-based model just doesn't fit with those older cards
MrCooper: bridgman: no it wasn't, but it was convenient for excuses like that ;)
osiris_: bridgman: we all should buy you and agd5f big cream cake or crate of beer for the help :)
nha: but at least VBOs make sense for everything that has HW TCL
bridgman: agreed; I think you will see some ongoing development with classic mesa for older cards
bridgman: MrCooper; I agree completely, just talking about perception
bridgman: osiris; nah, this is fun
MrCooper: unless marcheu is right that LLVM will allow translating the FF shaders back to actual fixed-function state :)
bridgman: then again some days it feels like garbage-picking ;(
bridgman: expecially for non-TCL hardware, we're really digging through scraps there; old powerpoint presentations etc...
osiris_: gallium is in master but I suppose that full featured radeon driver will take at least 5 months
bridgman: there was better documentation but no reason to keep it
bridgman: and nobody ever has enough servers, we've already expanded the data center 4 times and moved to denser servers at least three times
osiris_: no wonder, amd + ati made so many products
bridgman: I don't see LLVM doing that kind of shader-to-state translation; maybe something custom & hard-coded but you're really talking about code that trys to guess what the app developer was thinking
bridgman: osiris; yeah, it's been a lot of years too, we've been making GPUs for over 20 years now
bridgman: although I guess the VGA ones don't count ;)
osiris_: bridgman: yeap, and what about the case when the created shader cannot be mapped back to ff hw
osiris_: for me it's just not worth the effort
osiris_: and I really hate to play with agp cards, so I'm not going to touch that old hw anymore
bridgman: yeah, working on agp does seem like a painful way to spend your time
bridgman: is the problem just unreliable data transfer or does the AGP bus actually lock up ?
bridgman: if it's just unreliable data transfer then maybe we just need to (horror) add some checksum-type verification of data going across the bus
bridgman: it would mean you couldn't render with textures in GART space.. and (thinking for a minute) I guess the ring buffer would be a problem...
bridgman: maybe this won't work ;)
osiris_: bridgman: I've got to agp mobos, random crashes on windoze and linux when using 3d apps
osiris_: *two
osiris_: I prefer to play with the fog crashes. at least I know that it was my bad code that caused gpu lock up
bridgman: so it's a "control thing" :D
RTFM_FTW: AGP is a total PITA to work w/ ...the lack of coherency for example :D
nha: I'm a little astonished that I never tried remote debugging with gdb before today
spstarr: fixes some sugar crisp
nha: turns out it is really useful
nha: which should have been obvious from the beginning, but I was always too lazy to figure it out before
MrCooper: bridgman: it's not that bad when you're only dealing with shaders which were generated from fixed-function API in the first place
MrCooper: bridgman: see his FOSDEM LLVM talk from this year
bridgman: MrCooper; those shaders would be generated in the state tracker anyways, wouldn't they ? Are we just talking about either tagging the TGSI code or recognizing specific TGSI sequences as a way to get fixed function through the TGSI pipe ?
MrCooper: bridgman: he was talking about the latter
bridgman: ok, that works; still having trouble convincing myself it's worth doing, but maybe with time...
MrCooper: not sure about that either :) anyway off for tonight, bbl
bridgman: bye
nha: osiris_: why does your fogcoord + point-param patch modify the W_FMT and W_SRC?
nha: osiris_: also, is there a particular reason for the change of radeon_ioctl.c, line 81, in radeonGetAge?
osiris_: nha: ioctl is to shut up valgrind
osiris_: nha: W_FMT - that's what the docs suggest to get best performance
nha: interesting
osiris_: p.130 r500 3d accel guide
nha: I would expect that the Right Thing would still have SRC_RAS thoughf
nha: for the WSRC
osiris_: nha: why? then you would have to wait for RS
nha: ah, I see the comment
osiris_: and that way you don't have to wait at all
nha: maybe you should add a comment there mentioning that accel guide, and page number
osiris_: nha: good point
nha: because it's a little surprising to see without that background info
nha: now that I think about what the hardware actually does, I guess it makes sense, but the comment is a good idea anyway
osiris_: yeap, you're right
osiris__: nha: actually I'm not sure if fgdepthsrc shouldn't be always FG_DEPTH_SRC_SHADER (or maybe it doesn't really matter as long as fog unit is disabled)
nha: osiris_: note when you clean up your patch for final review / commit, it makes sense to put such small changes into a patch of their own, because it seems essentially unrelated to the rest
nha: interesting question
nha: maybe early Z breaks in that case?
osiris__: nha: these were seperate patches at the begining but I've messed it up git rebase :(
nha: who knows how those registers are related exactly
osiris__: nha: see page 135 about early Z. it should be at the top as long as fragment shader doesn't write W pos
osiris_: how to apply a patch generated with git-format-patch and commit it with the description?
jcristau: osiris_: git am
osiris_: jcristau: but there's no email
osiris_: jcristau: I haven't received/send any email, I just generated the patches because I want to split them, and some can be cleanly applied
jcristau: what do you think git format-patch output is?
osiris_: how to show diff between two branches?
jcristau: git diff branch1 branch2
osiris_: heh, didn't think it could be so easy
aneas: i really really miss shader support with this driver. are the any plans to implement those extensions?
osiris_: aneas: r300 already support ARB_vertex_program and ARB_fragment_program
aneas: osiris_, afaik there is a mesa glsl compiler. is it possible to combine these?
osiris_: aneas: I don't think so. e.g. glsl allows for generic vertex attributes which aren't allowed in ARB_v/f_program
aneas: :(
nha: aneas: realistically, it wouldn't be *that* difficult, it's just that we are generally more worried about either things
nha: e.g. getting a working implementation of VBOs would be nice...
aneas: no VBOs yet? oh, i understand :)
nha: currently, we're working on getting proper video memory management in the kernel
nha: once we have that, and it's stable, I expect development on the gallium-based driver to pick up speed
nha: and once that happens, well, glsl is within our grasp ;)
aneas: do you have an estimated timeframe or is all the development community based?
nha: these things are orthogonal ;)
nha: well, kernel memory management will be in mainline kernel 2.6.30 at the earliest...
nha: if your question was whether there is an actual plan and release schedule, then no, there isn't one
aneas: ok, thank you very much :-)
nha: airlied is bashing away at the kernel mode setting + memory management, which is imo the most important piece of the puzzle right now, and I have to say it's looking quite good, but there are no official estimates
nha: anyway, bbl
airlied: bridgman, bridgman, bridgman, candyman?
osiris_: I've rewritten and split the r300 fog coord patches. I'd appreciate any test reports and comments. the mail is on mesa3d-dev list
Renfield: Why is VBO stuff called when disabling GL_TEXTURE_2D, even with a program that doesn't have any vertex arrays?
MostAwesomeDude: glisse, airlied: So the problem's not PCIE GART.
MostAwesomeDude: Even when setting it to discard unmapped access, it still hardlocks.
airlied: the vbo stuff is used internally for normal vertices also.
Renfield: oh
airlied: MostAwesomeDude: does it set any of the PCIE GART error bits?
MostAwesomeDude: airlied: I have no idea, but I think probably not. Any way to check?
airlied: you can read the PCIE_TX_GART_ERROR register 0x18 in the PCIE ind
osiris_: dang. that World of Goo game is better than quake :)
MostAwesomeDude: Hm. Question: For debugging purposes, would it be useful to enumerate registers as they whiz by, and count whether or not everything from r300_demo is written before packet3s start showing up?
MostAwesomeDude: Just wondering whether or not it'd be worth it to spend a half-hour on such a thingy.
airlied: what like read back the regs? not sure it would help.
Renfield: If I see a graphical glitch when using the radeon driver, but not when using software rendering, is this a good indication that the problem is with the driver, and not with the application?
MostAwesomeDude: No, check CS.
MostAwesomeDude: Not readback.
airlied: Renfield: can be yes.
MostAwesomeDude: Renfield: Yep. Actually, that's usually our test. :3
Renfield: Oh!
airlied: MostAwesomeDude: I'm not sure what you mean count everything then.
Renfield: So, should I fill a bug report?
MostAwesomeDude: airlied: Well, AFAICT I'm writing all the right regs. However, I haven't actually sat down with a checklist and ticked each one off. I might have caught the scissors if I did that.
osiris_: Renfield: tell us what's the problem, maybe it's a known bug
MostAwesomeDude: Okay, yeah. Gonna do that first. Not going to waste more time with possible GART errors.
Renfield: Ok, I am trying to run the game d1x-rebirth. When It first shows the main game screen, there is a large texture obstructing the view.
Renfield: I have done some research, thinking that this problem is in the game itself.
Renfield: I have determined that one particular call to disable GL_TEXTURE_2D, done in its routine that draws a rectangle, fixes this graphical problem.
Renfield: Er, I mean causes.
Renfield: When I remove the call to glDisable(GL_TEXTURE_2D) (well, the macro in the program), then it renders the main game screen correctly.
Renfield: I've got a ATI Radeon Mobility M6. I'm currently running Mesa 7.3, xorg-xserver 1.5.3, and xf8x-video-ati 6.10.
osiris_: Renfield: I'll download it and try on my rs690
Renfield: osiris_: Thanks!
Renfield: osiris_: If there is any additional information I can provide, let me know. If it helps also, version 0.52 I believe does not exhibit this problem. The change from 0.52 to 0.53 removes a call to render the game cockpit prior to rendering the weapons display.
Renfield: I can point you to the exact lines that I've changed to clear/cause the behavior if you want.
osiris_: Renfield: actually I won't, looks like the game requires some copyrighted content that I would have to pay for
Renfield: osiris_: No, I don't think you need that.
Renfield: I think you can get the demo levels.
Renfield: Let me find that for you.
Renfield: Because it happens immediately when you enter level 1.
oga: agd5f?
bridgman: airlied; pong
Renfield: osiris_: You can get the free shareware download here: http://www.dfiles.de/download/d1/demo/d1demo_14.zip
Renfield: osiris_: unzip the file, then unarj DESCENT1.SOW. Then you've got descent.hog and descent.pig. Those are all you need.
Renfield: osiris_: Or, alternatively I can give you those directly, I've just done the steps to make sure they work.
osiris_: Renfield: I'm downloading it
airlied: bridgman: ->pm
Renfield: Great! When you get the files, you can run the game with the option -hogdir
osiris_: Renfield:
osiris_: Warning: Unknown size for descent.pigWarning: Unknown size for descent.pig
osiris_: Error: Out of hash slots
Renfield: Hmm.
MostAwesomeDude: pictures a descending pig
osiris_: ;)
soreau: Aren't pigs flying yet?? :)
Renfield: Sorry, I didn't realize how hard it is to get this working without the official files. I'll let you know when I've figured it out myself.
osiris_: Renfield: ok, I the mean time create a bug report
Renfield: osiris_: If you still want to try, I have the correct steps. The same problem happens in d2x-rebirth, so download that game. Then, get the files here: http://www.dxx-rebirth.com/download/dxx/res/d2demo.tar.bz2
Renfield: Turns out that d1x doesn't seem to be friendly to the demo files, but d2x is.
Renfield: I'll file the bug report now.
oga: airlied?
airlied: oga: ?
davem1: it's so dope being able to play quake3 on sparc64, lol
airlied: davem1: whats the cheapest sparc64 with PCIE? :)
davem1: ultra45
davem1: unfortunately not inexpensive
davem1: maybe could get a Niagara box cheaper actually
davem1: and that has PCI-E too but bad for a workstation, too loud :)
airlied: hmm ebay us2.2k, I shuold send it to management :)
davem1: I'll play with current code on my r100 radeon
airlied: I assume no AGP sparcs ever existed.
davem1: it has an rv100 QY
davem1: nope, never had AGP
davem1: that machine is not PCI-E so will test some other paths
airlied: yup PCI will test the GART in main RAM bits
davem1: I'll work on PIPE_SPARC code for the gallium code when I get a chance
MostAwesomeDude: airlied: Speaking of such...
MostAwesomeDude: Do you have an r300-r500 AGP setup?
MostAwesomeDude: I seem to remember that zhasha, who hasn't had a single lockup, is on AGP, not PCIE.
airlied: MostAwesomeDude: I can make such a setup, don't have it currently setup though.
airlied: I've got r100/r200 in my AGP test boxes.
airlied: something working on AGP and not on PCIE would be a firat
MostAwesomeDude: airlied: Well, no rush. I'm currently working on stuff for my uni, but if my guess is right...
MostAwesomeDude: I'm really just stumped as to why things are not working.
benh: airlied: how do you deal with drm.git ?
benh: airlied: you backport things from drm-next (kernel) back to the drm.git on f.d.o ?
benh: airlied: or is the later just stale ?
benh: airlied: (thinking about my and davem fixes)
davem1: he just rebases as far as I can tell
davem1: he moved my fixes to -next because I told them they required your stuff to be useful
benh: davem1: well, drm-next is a linux kernel tree with drm changes
benh: davem1: f.d.o mesa/drm is a out-of-tree variant o f the drm
davem1: drm-2.6 branch next, you mean
benh: davem1: yeah
benh: davem1: I wonder if those "kernel" side fixes are ever expected to make it back into mesa/drm
benh: since some people are least seem to use that :-)
davem1: good question :)
benh: hence me asking it :-)
airlied: benh: I'm ignoring it from now on
airlied: unless it really starts to annoy me
benh: airlied: so the fixes won't go into mesa/drm ?
benh: airlied: no big deal, just need to know...
benh: airlied: there are some stuff that are still being developed there
benh: airlied: which makes it a pain :-)
airlied: benh: I've stopped putting things in there.
benh: ok
airlied: benh: only really nouveau is in there.
bridgman: raises his hand tentatively
airlied: I'm going to push r6xx upstream at some point, and your fixes will need to be checked for r600
airlied: as it doesn't use the same codepaths
davem1: I have no life so I'll start testing kms out on sparc64 too
benh: right, we'll also need to sort out r6xx swappers
benh: (ie, vs. GART etc..)
bridgman: airlied, should we not be working in fdo mesa/drm ?
airlied: bridgman: the fastest path to upstream is to work against Linus kernel
airlied: davem1: it probably needs some of the fixes you've done and benh as well
airlied: I did some power pc work on the kms tree already
airlied: but I haven't gotten back to it.
bridgman: ponders this for a minute
airlied: I need to write userspace swapper support
benh: davem1: last I looked at kms, I think it contained a whole bunch of memory manager crap
benh: davem1: maybe TTM
bridgman: is thinking about bsd and solaris
benh: davem1: which totally conflicted with the drm_map_t fixes, but then, TTM is dead anyway
airlied: bridgman: they are getting better and just copying.
airlied: benh: that TTM code base is, the new one not so much
airlied: I need to port to the new one first though
airlied: so I'd probably layoff kms for now until I get it done.
benh: airlied: new TTM from thomas or GEM stuff ?
benh: airlied: I haven't followed the whole saga :-)
airlied: benh: from Thomas, GEM is kinda useless on anything but Intel
airlied: except for the API.
benh: right
airlied: my only worry for non-x86 arches is the whole MMIO is not memory
airlied: I still haven't sorted out wtf we need to do for that.
bridgman: airlied; oh good, so drm in Linux tree doesn't get GPL'ed or anything ?
airlied: bridgman: the code can be dual-licensed
bridgman: is that something we should be helping with or... ?
airlied: bridgman: it shouldn't be too bad yet, I nearly have r6xx DRM in a patch
benh: airlied: well, powerpc is not going to bite you too badly there
airlied: I'm not against someone maintaining drm.git I'm just against me doing it :)
benh: airlied: but sparc definitely will
benh: airlied: and I suspect mips too :-)
airlied: benh: IA64 does, Altix is worst
benh: heh, but those are broken by design :-)
airlied: davem1: if I mmap MMIO into a user context and they use optimised memcpy on it, what happens?
benh: ok, I'm about to test davem1 fixes on the 440 board
benh: then I'll see if I can spend a bit of time today again on the PCI domain crap
benh: ie, get it working with my 2 card in the machine on different domains
airlied: if the answer isn't the process gets killed then we are in trouble I suspect
benh: and not try to d/l the r100 microcode in the r500 and vice-versa :-)
davem1: aielied: Userland just mmap()'s the memory, it's fine
davem1: airlied: the problem is only kernel side
davem1: airlied: where ioremap() returns physical address cookies, and readl() and friends do direct physical I/O accesses
davem1: airlied: that way we don't waste TLB entries on register mappings on sparc64
airlied: davem1: oh so its fine for VRAM just not registers.
airlied: thats okay as I've no intentions of having any userspace acess to registers anymore
davem1: airlied: no, any PCI resource mapped in the kernel has the issue
benh: airlied: btw, you didn't merge my patch to have the DRM display the card PCI ID ? :-)
davem1: airlied: anything in user side is fine as long as the PCI resource is mmap()'d properly
davem1: the whole "mapping" abstraction in DRM is just asking for bugs
davem1: we have strict types with __iomem etc. attributes for a reason
davem1: because these things aren't normal pointers
airlied: davem1: that abstraction is "legacy" I'm just wondering how much TTM will suck on non-x86 hw.
airlied: benh: oh I shuold shove that in.
airlied: davem1: we don't mmap via the PCI resource
airlied: davem1: we setup a mapping on the drm device node, and it hides GPU object migration
airlied: so if the object is in VRAM the mapping gets torn down and we use PFNs to setup a mapping to the VRAM
davem1: airlied: As long as the VMA mapping implementation for DRM uses the correct physical addresses and PTE attributes you'll be fine
davem1: god what did they break in the xorg input code this time
davem1: every time I git pull I get a keyboard or mouse driver segfault
airlied: davem1: hehe evdev, use the kernel
davem1: and then I just wait for it to get fixed because I have no patience for D. Stone and co.
benh: daniel is a lot better than he used to be :-)
benh: but yeah, just use evdev
davem1: I doubt he's any better
davem1: he probably still thinks it's OK to break half of the input driver builds
davem1: they just remove them from build.sh nowadays
davem1: == FAIL
benh: it's one of those areas where the whole modularisation is a FAIL
davem1: I wish I could ignore half of the ISA networking drivers we have in the kernel
davem1: what a luxury that would be
benh: ie, building the -whole- thing from scratch is a LOT harder than it used to be and takes a lot longer
benh: most of the time being wasted in autoshit
davem1: no shit
airlied: davem1: surprsingly nobody has complained who owned the hardware
davem1: and time wasted on "oh ABI numbers changed, have to rebuild that driver"
davem1: that's what I spend most of my time doing when I git update xserver
davem1: nothing is independant, it is all dependent but clumsily so
benh: airlied: it works fine for people who build everyday and follow what's going on
benh: airlied: it's harder for people like me who toy with it once every few month
davem1: modular tree was just to make binary-only drivers easier
davem1: now that this no longer matters it's a joke
airlied: benh: we aren't optimising for the others :)
benh: airlied: then try to figure out what deps have changed, which new proto package or other bull needs updating, etc...
davem1: yeah it's worse for dist folks, for sure
airlied: dist folks like this way far more, it just upsets the people who don't get distros that work :)
benh: airlied: I find myself being a -lot- more hesitant building a new server if I can avoid it
benh: airlied: while I used to make World all the time
airlied: like I haven't build X from scratch it ages
davem1: they like figuring out which drivers need to be built when an ABI bump happens?
davem1: make World was far superior
davem1: when a header file changed, the appropriate drivers got rebuilt
davem1: END OF STORY
airlied: davem1: when ABI bumps all drivers get rebuilt
airlied: davem1: thats simple for distros.
davem1: I bet those build server cycles could be better spent
davem1: and the dist maintainer has to therefore watch for those bumps
airlied: davem1: unlikely, vs make World
davem1: non-modular took care of it transparently
airlied: davem1: if you have a distro maintainer who doesn't follow the packages then yes you might be worse off.
airlied: I still don't see the problem though.
davem1: it sucks for people trying to contribute
davem1: oh I guess you have enough of those
davem1: nevermind
airlied: davem1: we have way more contributors now.
airlied: like 10x Xfree86 days
airlied: modular made contributions a lot easier.
davem1: that scales to the number of users we have now, so as a ratio I'd say it's about the same as before
airlied: once you get past the fact that there is no need to build it all
davem1: the barrier to entry is higher, especially at the beginning
airlied: davem1: get past building it all as I said.
davem1: YOU CAN'T WORK ON ANYTHING CURRENT WITHOUT REBUILDING EVERYTHING
airlied: the barrier to entry is much lower.
airlied: davem1: yes you can
davem1: NO YOU CAN'T
airlied: davem1: people have written drivers without building servers
airlied: davem1: like full complete drivers
airlied: without once building the server.
davem1: to build current xserver, you need current xrender, xinerama proto
benh: the truth lies in the middle...
davem1: etc.
benh: most video driver work can be done if you have a 1.5.x server
benh: just fine
davem1: you need current MESA, DRM
davem1: the list is endless
benh: it depends how much you depend on the new features
davem1: but nobody should have to know any of this dependency junk
airlied: everyone I know uses a distro built set of packages.
benh: but yeah, as soon as you need to update the server itself, the dependency chain becomes a real pain
airlied: and just works on their own little bit
airlied: if they need a server locally they just run build.sh
davem1: I guess you don't know me :-)
airlied: and it reclones everyone.
davem1: rofl build.sh
davem1: that's another one
airlied: or jhbuild also works.
benh: airlied: sure,, but how long did it take for distros to have the server built with libpciaccess ? :-)
davem1: that works like %5 of the time
airlied: benh: how long did it take libpciaccess maintainer to port the drivers :)
airlied: benh: oh wait :)
airlied: davem1: we have a tinderbox running jhbuild
airlied: so it works 99% of the time
airlied: like how much arch specific code is really left in the server?
airlied: I suspect minimal.
davem1: FB has MMX bits and stuff like that
davem1: then there are the BUS layers
airlied: davem1: not any more
airlied: thats in pixman
davem1: then the loader
airlied: davem1: the bus layers are mostly ignored on Linux now.
davem1: so BUS layers and loader
airlied: the loader is now libdl
davem1: right
davem1: but if you want to test current render etc.
davem1: or make sure there isn't some endian bug in what Keith P. just checked into pixman
davem1: you have to build xserver
davem1: or (cringe) want to see what broke in xkbd today
benh: note that there are endian bugs still lurking around
benh: I noticed that the other day when selectively disabling some HW accel
benh: while tracking some bug
benh: some SW fallback path are broken
benh: could be something with surfaces or PrepareAccess missing tho, not sure
benh: haven't had a chance to dig so far
davem1: that's usually what it turns out to be
benh: davem1: drm-next + xf86-video-ati HEAD work on my 440 board with 4K pages, now about to try 64K
davem1: benh: cool
airlied: I do wish someone would care for endian issues, I try, but it does take a bit of time.
airlied: as it is now, we get a burst of effort, but no maintaining
benh: davem1: DRI fails to init with 64K
benh: davem1: due to the problem with SAREA alignment
benh: davem1: you don't have it think because you are lucky, it's just 8K :-)
benh: davem1: let me try a quick hack to see if that gets past that problem
airlied: davem1: btw if you think the kernel is any better, tell me what SYSFS option to I need to set today to unfuck my bootup :)
airlied: and/or which wirless driver for my iwl3945 isn't going to screw up every 5 mins
benh: airlied: the one in .28 is better for me :-)
benh: (intel wifi crap)
airlied: benh: which one though :) I think there was 3 altogether :)
benh: hehe
airlied: like evdev vs kbd/mouse is nothing compare to some of the shit the kernel pulls.
benh: hrm... tmpfs doesn't like 64k pages
benh: udev causes it to -ENOSPC all over :-)
benh: davem1: 64K seems to be a lot happier than it used to be with a one liner hack
benh: in drm_addmap_core()
benh: /* XXX FUCKTON */
benh: map->size = _ALIGN_UP(map->size, PAGE_SIZE);
benh: I need to dig I suppose to audit all addmap callers and get them to do the right thing, or convince myself that the hack is actually going to not break anything
benh: airlied: what do you think ?
airlied: benh: I'm trying to think where it could screw up.
benh: airlied: this will be needed for ppc64 with 64k pages too btw
airlied: benh: probably most places are easily aligned to 64k.
airlied: benh: RHEL5 runaway :)
benh: airlied: in that case, it's not RHEL5 :-)
benh: airlied: more like an embedded CPU with a small (64 entries) SW loaded TLB
maggot_brain: will it be possible to build the 6.10 Free Radeon X.org driver on Debian Lenny without upgrading the core Xserver / Mesa etc?
benh: airlied: tho the TLB happens to support bigger page sizes
benh: airlied: I think we'll settle for 16K, as 64K pas other disadvantages
benh: airlied: such as totally bloating the memory footprint of some stuff
airlied: maggot_brain: the DDX yes
airlied: 64k pages on ppc sucked for a lot of stuff :)
benh: yup
benh: 16K are a good compromise for that embedded stuff I reckon
maggot_brain: airlied: DDX?
benh: anyway, that fix is needed in a form or another
bridgman: maggot_brain; the driver you want to build is the DDX - Device Dependent X driver
maggot_brain: bridgman: oh right, could you enlighten me? I want to switch my ATI machine to Debian Lenny cos it's low maintenance and I need 6.10 for Xv as I've said before on the channel
maggot_brain: bridgman: as in I've no idea what the DDX is and what its build dependencies are!
bridgman: sorry, what I meant was "the driver which is currently at release 6.10, ie xf86-video-ati, is what airlied is talking about when he says "DDX"
bridgman: ie "no worries, mate"
maggot_brain: bridgman: so it will build with any xserver 1.4 then?
maggot_brain: sorry poor grammar there
bridgman: airlied probably knows that better than me; I'm just explaining what he meant by ddx ;)
maggot_brain: ok, it might be easier to just download the source code and look at the docs in there, but I've no idea where to find it
airlied: maggot_brain: grab the 6.10.0 release tar.gz, untar it, ./configure --prefix=/usr
airlied: make; make install
airlied: in theory will overwrite the Lenny one with 6.10.0reelase
davem1: benh: good to hear you got it working, sorry I was away
davem1: airlied: I've never had a boot failure due to sysfs failures, and if I did I would have gotten it fixed
airlied: davem1: exactly how I work with X then :), however for a person who compiles kernels rarely it would be just as bad an experience.
davem1: airlied: and exactly how I work with X too :)
davem1: like right now how typing any key, even with evdev, gives the xserver a SIG11 with current git
davem1: I'm trying to debug and fix it :)
airlied: is your xkbcomp installed working?
davem1: that shouldn't matter, it worked beforehand without generating keymaps
airlied: davem1: it does matter, if you aren't running a proper setup.
davem1: it really dies and doesn't shutdown radeon correctly, so radeonfb starts to timeout in the kernel :)
davem1: it shouldn't sigsegv
airlied: have you got a backtrace?
davem1: what do you think I'm trying to do right now?
davem1: the sigsegv shutdown path gets a sigbus, that's why the radeon is dead
davem1: so multiple bugs
davem1: good thing I didn't do make install on my main workstation :)
airlied: so gdb can't catch it?
davem1: I don't know the system was hung and am rebooting to try and capture the crash
davem1: be patient ;)
davem1: sigsegv is in PostKbdEvent, let's see where the sigbus happens...
davem1: (I'll save the backtrace and diagnose)
airlied: pastebin the backtrace so I can show input person :)
davem1: let me fix the bug first :) then you can show him
davem1: sigbus is in XkbFreeInfo() rofl
airlied: well he can fix it a lot quicker :)
airlied: the xorg log + backtrace should make it easier.
davem1: http://pastebin.com/m83d0c87
davem1: ->xkbInfo pointer becomes 0x1 for some reason
davem1: this is with xf86-input-keyboard, that needed a build fix on sparc as well
davem1: I'll go with evdev see if that works
airlied: davem1: ah keyboard is on the broken list, try evdev.
airlied: davem1: is that the latest keyboard git?
airlied: davem1: or ping whot on freenode, save him surfing my shoulder :)
davem1: yes, latest git everything
Ivanlul: hello
Ivanlul: I need help with my integrated video chip
Ivanlul: I have an ATI radeon xpress 200
Ivanlul: and when I play videos they tend to be choppy
Ivanlul: can anyone help me?
airlied: Ivanlul: what version of the driver are you using?
Ivanlul: I don't know, how can I check?
airlied: Ivanlul: what distro is it?
Ivanlul: ubuntu
Ivanlul: 8.10
airlied: when you say choppy do you mean it tears or its losing frames?
Ivanlul: losing frames
kcodyjr: airlied, hate to bug not to mention double-post, but i need to know before i can proceed... just how badly does GPL "poison", if i were to use GNU scientific library as a dependency, and leave it open to being replaced with something BSD/MIT later?
airlied: if its GPL (not LGPL) don't touch it
airlied: LGPL you can probably replace later or get some BSDer to write a clean one
kcodyjr: damn
kcodyjr: all i need is a flippin' cubic spline interpolation, and i've found three; two are GPL and the other is in PERL.
kcodyjr: never thought i'd say this but GNU is pissing me off right now
kcodyjr: don't touch it means i can't even read it to learn the algorithm, right?
airlied: use codesearch to find one :)
kcodyjr: read about 25 pages of google results already, i'll try that...
airlied: well I'm sure the algorithm is public? just write one from it
airlied: quantlib seem it might have one in C++
kcodyjr: have to find it, short of taking a math class
airlied: I'm sure porting it to C wouldn't be that hard
kcodyjr: yeah, C++ to C i can deal with
Ivanlul: airlied: do you think there is anything I can do
airlied: Ivanlul: sounds like a lack of CPU, if you want to try the latest -ati release it might be worth it, but you[d have to build it, unless bryce can point out any packages.
airlied: the Jaunty packages might work better.
Ivanlul: Videos seemed to work fine on my other OS, so i don't think it's a cpu problem :\