vwbusguy: should I be scared spstarr hasn't made it back here yet?
soreau: vwbusguy: Nah, he'll be back soon enough
soreau: Maybe with a story to tell ;)
vwbusguy: hehe
vwbusguy: claims no responsibility for broken bones and empty checking accounts
DanaG: You know, just saying that sort of thing could be taken as incrimination... as opposed to saying nothing at all. =þ
vwbusguy: lolz
vwbusguy: goes to build the new mesa against the r6xx-r7xx drm module
soreau: vwbusguy: It's not too hard to make a disclaimer. Just use Debians: If it breaks, you get to keep the pieces :)
vwbusguy: hehe
vwbusguy: I put a nice big README on the website
soreau: Not responsible for soggy cornflakes, and all that stuff
vwbusguy: the downside about hardware related testing - can't use a VM
forrestv: what features of opengl does the radeon driver not support? glsl doesn't seem to work, is this fixed or going to change?
vwbusguy: he gone
EruditeHermit: forrestv: hi
forrestv: EruditeHermit, hi.
EruditeHermit: forrestv: it will change but probably nearer to the end of the year
DanaG: Now, having KMS and (at least) Compiz on my R600, would be an awesome gift for by the end of the year.
EruditeHermit: forrestv: but no guarantees
EruditeHermit: DanaG: that will probably happen
EruditeHermit: but again no guarantees I guess
EruditeHermit: but it seems they are making progress
DanaG: Compiz is really about the only 3D thing I do in Linux.
DanaG: I stick to Windows for games -- Wine deals badly with PulseAudio, and doesn't do surround sound, period.
EruditeHermit: DanaG: hmm, Catalyst 9.6 is really good with wine
EruditeHermit: and the new wine 1.1.24 is good
DanaG: I want my surround sound, though. =þ
EruditeHermit: hmm
EruditeHermit: I have it working I think
EruditeHermit: I don't actually know if its surround
ghoti: looks around
EruditeHermit: but its coming fromall my speakers!
DanaG: Not the same thing. 3D positional audio is what I mean.
vwbusguy: freakin compiles
vwbusguy: has Mesa RPMs for r6xx and r7xx, will post in a couple of minutes
spstarr: heh
spstarr: those specs will come in handy when i begin testing
vwbusguy: yup
vwbusguy: got all the kinks out of the mesa specs
vwbusguy: and those RPMs should just work in f11 assume you are using the new radeon driver
vwbusguy: did specific it in Requires
spstarr: new?
spstarr: from koji?
vwbusguy: no
vwbusguy: from http://vwbusguy.fedorapeople.org/radeon-r6xx-r7xx/
ghoti: got an xorg question... I have an RV670, but I don't seem to have full-speed GL. Everything draws, but it's choppy. I'm using the 'radeon' driver because 'radeonhd' was way way worse. How should I investigate what's going on with GL? Or is it just known to suck?
ghoti: OS is FreeBSD 8.0, the card is an HD 3870, in a 2.66GHz i7. I'm upgrading from an old AGP nvidia on a slower i386 machine that nevertheless was much quicker to draw GL.
hifi: theres no 3D acceleration for r600/r700 yet
hifi: see the topic
ghoti: ah, so ... forgive the newbie questions, this is my first major workstation upgrade in years. GL presumably is then being rendered only in software?
vwbusguy: hifi, there is now :-)
ghoti: listens with great interest
vwbusguy: hifi, I've been packaging the r6xx and r7xx support branch for f11 tonight
hifi: whats working
vwbusguy: got the driver packaged and copying over the mesa build against it now
vwbusguy: http://www.x.org/wiki/radeon%3Ar6xx_r7xx_branch
vwbusguy: I got my sources and specs up
vwbusguy: should be an easy rebuild for other distros
ghoti: vmbusguy, any idea if it builds in FreeBSD?
hifi: here is the most important question: does it run quake? :p
vwbusguy: ghoti, no idear
vwbusguy: hifi, no idea
vwbusguy: I've just got i tpackaged
vwbusguy: I haven't put it through WoW or counter strike
vwbusguy: let alone Crysis
hifi: R500 is awfully slow with counter-strike
ghoti: I'd settle for xscreensaver
vwbusguy: has an HD 4650 and -really_ wants FOSS drivers to work for it
vwbusguy: fglrx is working, but it's a decroded piece of crap in the same
ghoti: bought a radeon for lack of amd64 nvidia drivers for FreeBSD.
vwbusguy: bought a radeon because it came with his laptop :-)
hifi: I bought X1950 Pro as it did run quake at the time :p
hifi: with the FOSS driver
hifi: even the crappy quake 2 engine runs fine on it
ghoti: so ... what exactly is Mesa? I'm assuming it's not really a secret research facility? Is it the software rendering we use if direct rendering isn't available?
vwbusguy: spstarr, if you do get around to testing out my new driver, would you mind updating https://bugzilla.redhat.com/show_bug.cgi?id=510829
hax0r1337: bought gtx 260 so he could get ~250fps in ut2004 @ 1920x1200, 16x AA, 16AF
ghoti: hax0r, that would be awesome.
ghoti: loves ut
ghoti: though with that resolution available, I'd be tempted to try out 3D glasses again...
hifi: actually my cs fps dropped during the latest releases
ghoti: I had Elsa glasses that made Descent even more stomach-churning. But they haven't worked in years.
ghoti: And certainly not since I stopped running MS operating systems.
spstarr: vwbusguy: it will be some time before i test right now..
spstarr: im awaiting the amd folks goahead
hifi: waits for optimizations in the driver
vwbusguy: http://vwbusguy.fedorapeople.org/radeon-r6xx-r7xx/f11/
vwbusguy: one loose end to tie on the spec and mesa will be good to go
EruditeHermit: what loose end
vwbusguy: forgot to add mesa-dri-drivers to Obsoletes
vwbusguy: I packaged one mesa package instead of the 6 or so in fedora
EruditeHermit: what is the max temp for a GPU?
vehemens: vwbusguy: does dri2 work with this version?
vwbusguy: vehemens, with the mesa package supposedly. I haven't tested it, just going by what's on xorg. :-)
vwbusguy: use at your own risk
vwbusguy: I'm copying mesa bits over right now
vwbusguy: woot
vwbusguy: new mesa installs just fine
vwbusguy: glxgears is working with new mesa
bridgman: vwbusguy, are you sure you're not rendering in software ?
bridgman: which mesa and drm code are you using ?
bridgman: the r6xx-r7xx branch of drm you linked to is already merged into F11 kernel
bridgman: what you need for work-in-progress 3d on 6xx/7xx is the r6xx-r7xx-3d branch from ~agd5f/drm and the r6xx-rewrite branch from mesa/mesa
bridgman: I don't think drivers/dri/r600 has been merged into mesa 7.6 or master yet
vwbusguy: right that's what i used
vwbusguy: the experimental branch
bridgman: the one listed on that wiki page you linked to, or the ones I just listed ?
bridgman: they're different
vwbusguy: the mesa was on a different page
bridgman: the drm is different too
vwbusguy: http://www.x.org/wiki/radeonhd%3Aexperimental_3D
vwbusguy: yes, I build the drm for it
vwbusguy: *built
bridgman: oh good, those are the right branches ;)
vwbusguy: kewl :-)
bridgman: don't think the drm code will work with the kernel in F11 though... 2.6.28 is about as high as it goes right now
bridgman: nanonyme was looking into what would need to be changed
bridgman: checks to see if the changes for >2.6.28 were already pushed
hax0r1337: isn't ~agd5f/drm already in git linus tree?
bridgman: not the 6xx/7xx 3d stuff AFAIK
bridgman: just the ioctls needed by the x server for EXA and Xv
bridgman: there are different (new) ioctls for mesa
vehemens: hint -> when r6xx mesa/drm with dri2 makes it into the master branches, i'll start buying hw again <-hint
hax0r1337: hmm most of the commits in ~agd5f/drm are dated, seems that most of the activity stopped right around march, I wonder why it didn't get merged yet... or it's not finished yet
bridgman: are you sure you're looking at the r6xx-r7xx-3d branch ?
bridgman: http://cgit.freedesktop.org/~agd5f/drm/log/?h=r6xx-r7xx-3d
vehemens: last update was ~16 hrs ago
hax0r1337: bridgman; yep, most recent commit was 16h ago, but It would be nice to have this merged in 2.6.31, but it's to late already, i do not own a radeon card but might soon :)
bridgman: yeah, but we have to FINISH it first ;)
vehemens: finished code is dead code :]
bridgman: it's not really practical to merge in the kernel code until the accompanying userspace code is working well enough that we think the API is going to be stable
bridgman: so all the focus is on the mesa code right now
hax0r1337: classic mesa I suppose
hax0r1337: btw, with classic mesa and DRI, opengl 2.1 is possible correct?
bridgman: sort of; you need the new memory manager (GEM/TTM) and everyone is using DRI2 with that
bridgman: but classic mesa, DRI2 and mm would certainly support GL 2.x
bridgman: current thinking is not to bother and go straight to gallium3d though
bridgman: on the basis that going the gallium3d route should be faster
hax0r1337: btw whose ahead in 3d support, MAD's r300 on gallium3d or classic mesa/dri2?
zhasha: I don't see much of a reason to continue with DRI and classic Mesa3D
bridgman: depends how you measure
bridgman: oh, sorry, on the same GPU ?
zhasha: that would be mesa3d
hax0r1337: yeah, MAD's code works on r300 only i suppose
zhasha: r300g is nowhere near ready for any kind of use
hax0r1337: oh
zhasha: no, it works best on r500 right now
bridgman: classic mesa is far ahead since it runs more than glxgears, but hopefully the gallium3d code will catch up and pass fairly soon
zhasha: r300g doesn't run glxgears right right now :P
bridgman: "r300" architecture is 3xx-5xx
bridgman: "r600" is 6xx/7xx
bridgman: zhasha; it did a month or so ago, didn't it ?
zhasha: yes, but now something causes funky colors :P
bridgman: pretty sure I remember MAD saying it and tirdc preserving it for posterity
bridgman: ahh, no worries; the 6xx/7xx driver ran gears back in april, the trick is keeping it working ;)
vwbusguy: bridgman, I have my source code, specs and everything at http://vwbusguy.fedorapeople.org/radeon-r6xx-r7xx/f11/
zhasha: the background somehow manages to beautifully transition between various shades of blue
bridgman: nice
zhasha: trivial/tri doesn't work right anymore either
bridgman: ok, so I think we can safely say classic mesa is ahead then ;)
zhasha: never said it wasn't :P
bridgman: agreed, just trying to give hax0r1337 a good answer
EruditeHermit: well I hope more people work on r300g since MAD has shatter to work on
zhasha: I fix bugs occasionally
bridgman: once we get the current 6xx/7xx 3d generally working we're going to switch some of our time to gallium3d
EruditeHermit: what is happening with 6xx btw
EruditeHermit: its been a LONG time in the making
zhasha: it's a completely revamped GPU
bridgman: we're still chasing down a problem in the buffer aging code (which tells us when a buffer can be freed up and re-used); works OK for a while then goes haywire
EruditeHermit: hmm
EruditeHermit: not many commits
zhasha: 3d driver coding isn't exactly easy
bridgman: well, the code's written; until we find what is broken there's nothing to commit ;)
zhasha: at least not when you're unfamiliar with the architecture
EruditeHermit: oh I am aware
bridgman: of course we had the opposite problem; we knew the hardware but didn't know squat about mesa ;)
zhasha: you work for AMD right? :P
EruditeHermit: well doesn't alex know both now?
bridgman: zhasha; yes
EruditeHermit: he knew mesa better than the hardware before right?
zhasha: I wonder when Gallium3D will be API stable
bridgman: EruditeHermit; we're still learning; alex worked mostly on ddx and some drm
EruditeHermit: did you retask some windows guys to Linux or did you hire new guys?
EruditeHermit: was it totally new for them?
zhasha: also, I don't understand why you directed your attention to writing a Mesa3D driver rather than a G3D driver
EruditeHermit: zhasha: for enterprise people
EruditeHermit: who don't want to update kernels
hax0r1337: zhasha: because that's what major companies want, classic mesa support
zhasha: I know it's for compat reasons, but honestly, it seems like you're wasting a lot of time for something that will be tossed in the can soon after completion
bridgman: a bit of each; alex had been working on the open source driver for a long time, cooper had done some mesa work in a previous life, and richard's background was windows
EruditeHermit: thats nice then
EruditeHermit: you have all bases covered
bridgman: zhasha, most linus systems out there will be running non-kms/mm systems for another year
bridgman: they need a solution
zhasha: I once saw a simple Windows driver that would write a single string to a USB port. I shat myself
bridgman: whatever we wrote the first time was going to be throwaway anyways; we just admitted it up front ;)
bridgman: so the plan was classic mesa for dri1, then gallium3d for dri2
zhasha: we get better performance on r300g with glxgears (when it was working right) than you do with r600 in mesa :P
bridgman: most of the knowledge and a good chunk of the code can be carried over
bridgman: I should hope so
bridgman: ;)
EruditeHermit: bridgman: has this bug been stopping progress for months?
EruditeHermit: it seems you were stuck on this for a while
bridgman: no, the code was only written in the last month
zhasha: but when enabling TCL, it drops to like 1/6th of the NO-TCL speed :P
bridgman: driver was mostly finished in April, then we ported it across to the radeon-rewrite code base
zhasha: bridgman: did you code (in part) fglrx?
bridgman: the problem is in some code related to the radeon-rewrite part
bridgman: not me personally
bridgman: we inherited fglrx as part of purchasing FireGL some years back, and we've been gradually replacing pieces over the years
EruditeHermit: a while back you told me you were going to be doing background work for determining if you could release specs for the video decode block of the GPU, what happened to that?
bridgman: it's still on the list, I said it would be after 6xx/7xx 3d
zhasha: so AMD isn't in full responsible for the atrocity?
EruditeHermit: do you help code?
zhasha: that's good news right there :P
bridgman: yeah, I help; I don't code ;)
EruditeHermit: with design?
EruditeHermit: I know you manage the whole project
bridgman: not sure why you call it an atrocity; it's aimed at commercial workstation users on a small, specific set of distros and it does that quite well
bridgman: it's only the last ~18 months or so we have been adding features & distro support for consumer usage
bridgman: and there's still work to be done there
zhasha: except when it causes kernel panics from connecting external monitors and crashes X unexpectedly
bridgman: no, I mean I help by not coding ;)
bridgman: I didn't think we supported hot-plug yet, is that what you're doing ?
zhasha: then you removed support for my card so now I don't really have a choice anymore
zhasha: no, I plug in the monitor and open cccle to turn it on
bridgman: that's hot plug, isn't it ?
zhasha: BOOM! kernel panic at every boot (when X starts)
zhasha: oh, I always thought as hotplug as something automagic
bridgman: oh, sorry, reading while screen was scrolling, thought you said "expect" cccle to turn it on
bridgman: zhasha, I think that kernel panic is fixed
zhasha: doesn't matter. I have an r500
zhasha: and I'm using Xserver 1.6
bridgman: so you want to be using the open source drivers anyways
bridgman: you understand that 3xx-5xx was dropped for all OSes, not just Linux, right ?
zhasha: wow, I thought it was just the linux module
bridgman: nope, we wouldn't do that
EruditeHermit: well its not a fair comparison
bridgman: any time we've dropped old GPUs it has been across all OSes
EruditeHermit: windows is able to use old drivers with vista
bridgman: and it's our fault that Linux is not ?
bridgman: ;)
zhasha: you don't support this laptop under windows anyway so I've been using the omega drivers
bridgman: laptop drivers are distributed through the mfg; we don't do generic drivers for laptops
zhasha: the only reason to use fglrx is opengl 2.1 (shaders, basically), which r300g will provide for my card
EruditeHermit: yeah
EruditeHermit: fglrx was really bad with my r300
EruditeHermit: it didn't have any video outputs
bridgman: was it FireGL ?
EruditeHermit: nope
EruditeHermit: 9600 mobility
EruditeHermit: M10
zhasha: mine as well, M54, X1400 M
bridgman: yeah, the focus back then was almost entirely workstation
EruditeHermit: it works well with my r700
bridgman: good
EruditeHermit: although video playback is slow if I try 1080p
zhasha: I understand -- but that doesn't change the fact that it failed horribly at anything I tried, except for shaders
EruditeHermit: it really could use the XvBA
bridgman: sure, but you weren't trying the things it was designed to do
zhasha: enable UVD
bridgman: or that we spent time on
zhasha: I was using it for regular things like rendering tris and having 2 monitors
zhasha: the second part didn't work out too well
EruditeHermit: rendering tris lol
bridgman: sorry, it was EruditeHermit talking about video outputs
zhasha: I'm not blaming your coders, I'm blaming the higher-ups
EruditeHermit: well its a case of it sucking till AMD bought it
EruditeHermit: =p
EruditeHermit: and AMD is catching up 5 years of neglect in 2 years
bridgman: not really; we started the Linux driver rewrite a year before AMD came along
bridgman: AMD definitely helped on the open source side though
EruditeHermit: well I am sure AMD has placed more emphasis on it
bridgman: actually no
EruditeHermit: well the open source stuff
bridgman: same people, same priorities as before; what happened was that we got workstation to the point we wanted and then were able to start spending time on consumer users
bridgman: open source yes; as ATI it didn't make sense to take the risk of publishing HW info since there was a real risk of losing our ability to sell into our biggest markets for a year or more if something went wrong
bridgman: as a GPU-only business that would kil the company; at least with AMD if something went wrong as a result of supporting open source we could at least continue with CPU sales
EruditeHermit: btw speaking of CPUs
hax0r1337: how could the exposed docs exactly kill ati?
bridgman: anything that puts our DRM support at risk
EruditeHermit: is the Phenom2 X4 8xx series the rejects of the manufacturing process?
bridgman: if publishing info lets someone get around video protection we lose the ability to get WHQL certification, which in turn means we can't sell into >90% of our market
bridgman: it would probably cost us the MacOS business too, so ~99% of our OEM business would go away
hax0r1337: oh wow
bridgman: retail card sales would survive but they aren't enough to stay in business
bridgman: that's why nobody gets into this lightly
bridgman: EruditeHermit; not sure, will go look and see what 8xx's are ;)
EruditeHermit: ah no worries
EruditeHermit: The 800 series have 2 MB of its L3 Cache disabled due to defects.
EruditeHermit: my real question was going to be
EruditeHermit: if a chip has defects, is it a risk to buy it?
EruditeHermit: or do they test them to see everything else works?
hax0r1337: no risk at all
zhasha: most chip manufacturings cause defects
bridgman: yep, mfg defects on a big chip are generally "this spot is broken" not "the whole thing is substandard"
zhasha: the rejects are clocked down or somehow downsized and sold as an older version
bridgman: so you include circuitry to let you disable the area with the bad spot
hax0r1337: it's all about silicon quality /yield and how it gets binned
EruditeHermit: hmm
EruditeHermit: amd mobos are cheaper
EruditeHermit: 790 chipset looks nice
bridgman: it depends a lot on what each block does; if it's something where having less gives you another product you allow pieces to be turned off, but if you need the block to work 100% then you might put in spare rows/columns instead
EruditeHermit: oh
zhasha: take the Cell SPU on the PS3 for example
zhasha: it has 7 cores
bridgman: sometimes we disable portions to "test the market", ie to see if there would be enough market at a certain price/performance point to justify making a smaller chip
EruditeHermit: so there are redundant parts to all CPUs?
zhasha: so they make it with 8, and chances are one of them will come out bad
bridgman: usually, same with GPUs
vehemens: doesn't take much to screw up. look at zilog. if they just come out with a 16 bit z80 instead of going for a 32 with all the trimmings, there would be a lot less i's around.
bridgman: and again, it's a mix of redundancy and the ability to turn blocks off
bridgman: if you have a bunch of blocks doing the same thing you normally just allow bad ones to be turned off
bridgman: vehemens; I thought the Z8000 was 16-bit and it was the 32-bit that never made it out
bridgman: looks like die size & transistor count are the same for 810 and 910 CPUs, so it is likely that one of the L3 cache blocks was disabled from mfg defect
bridgman: from an Anandtech article :
bridgman: When AMD produces a Phenom II die if part of the L3 is bad, it gets disabled and is sold as an 800 series chip. If one of the cores is bad, it gets disabled and is sold as a 700 series chip. If everything is in working order, then we've got a 900.
EruditeHermit: lol
vehemens: bridgman: i forgot about the z8000. the end result was still the same for me anyway as there was no viable upgrade path. http://en.wikipedia.org/wiki/Zilog_Z8000
bridgman: agreed; my recollection was that the 32-bit part was going well until three of the key designers got hit by a truck coming back from lunch
bridgman: that pretty much killed the project
bridgman: you try not to have all your key people on the same plane but nobody thinks about walking across the street for lunch
EruditeHermit: you're kidding right?
EruditeHermit: people hit by a truck ended a company?
EruditeHermit: wow
EruditeHermit: bridgman: btw what temps do 4800 GPUs tolerate?
bridgman: it didn't end the company but it seriously delayed the project IIRC
bridgman: somewhere around 100C, maybe 105C
bridgman: depends on the package and cooling solution IIRC
bridgman: the hotspot on the die isn't at exactly the same temp as the sensor diode so if you're running a ton of power through the chip and cooling well you probably want a slightly lower threshold
bridgman: if you have a wussy cooler and low power you can probably go a bit higher because the hotspot temp won't be much higher than the diode temp
bridgman: I think we try and cut off just under 100C but that's not my area
EruditeHermit: oh
EruditeHermit: ok
EruditeHermit: so 70-80 is within limits?
bridgman: there's a big honkin' application guide I should read one day
bridgman: I hope our customers read it ;)
bridgman: there's maybe 100 pages just for setting fan/temp profiles
bridgman: yep, 70-80 is fine
bridgman: I would still try to get it lower if you're running 24/7 but don't know if that's actually necessary
bridgman: but going to 70-80 during gaming etc.. is not unusual
EruditeHermit: yeah its during gaming
EruditeHermit: normally its around 50-60
EruditeHermit: GPU creates more heat than the CPU
EruditeHermit: and the fan is noisier
bridgman: the GPU probably has 2x the transistors and 20x the processing power ;)
bridgman: I'm guessing on what your system uses but that's about typical
masa-: what kind of processing can the GPU do? is it like some spesific calculations only or what?
bridgman: GPUs are good at crunching big matrices of floating point data
bridgman: if you want to perform the same operation on a billion different elements then GPUs are cool
bridgman: if you want complex branching and different processing for each element then CPUs are better
vehemens: bridgman: after the z80, the symmetric 375 was my next computer. i built a wire wrap version of it using a ti graphics chip hooked to a 20" monitor. never got to porting the xserver to it however. http://jolitz.telemuse.net/william/symmetric
EruditeHermit: gnight
bridgman: basically the shader core of an rv770 is 800 independent floating point ALUs, each capable of one 32-bit MAD per clock
EruditeHermit: bridgman: once again you are very knowledgeable
EruditeHermit: thanks for the insights
bridgman: always a pleasure, goodnight
masa-: bridgman: so do they all have to perform the same calculation on different data sets?
masa-: i guess that's what you just said.
bridgman: that's what they do best; the core of a modern GPU is a big SIMD engine (10 independent SIMD engines on rv770), so doing the same thing on different data is best
bridgman: vehemens; ah yes, the NS processors; I really liked them
bridgman: I thought they were the best of the bunch by a long shot, seems like the timing just wasn't right for them
vehemens: i always felt it was the lack of graphics capability that killed them. dumb terminals only went so far.
bridgman: the first system I got to design from end to end was originally going to be thin clients with 80186s and a server with NS16032 running UNIX
bridgman: I ran across this hole-in-the-wall company with a Unix-lookalike running over a microkernel and figured we could use the same board for client and server
bridgman: I think they had sold about 50 copies of their OS until then, we bought about 50,000
bridgman: that's what became QNX
bridgman: I had been reading about the Sun workstations back when they were being hand-built by students on wirewrap boards and figured a high-volume version of that would be great
bridgman: http://en.wikipedia.org/wiki/QNX
vehemens: never tried qnx, but i still have my bsdi cdrom's.
bridgman: qnx was mostly successful in embedded systems; it was bulletproof and let you make hugely complex realtime systems that stayed reliable
bridgman: never really caught on as a personal OS
bridgman: and it was never targetted for servers
bridgman: but I don't think you can start a modern car without it
bridgman: anyways, sun's coming up, time for zzz
bridgman: bbl
evocallaghan: bridgman: Thanks
luc_: hy
luc_: i made an update for xf86-video-ati from git
luc_: and now i have no more tv out
luc_: i have an hd4850
zhasha: luc_: could you bisect it?
rah: http://pastebin.com/m19995649
rah: is this a radeon bug?
luc_: before update, tv-out "s-video" was wworking
luc_: now is not working
evocallaghan: luc_: Hi
luc_: hi
evocallaghan: Are you able to tell me between exactly what rev this regression happened ?
luc_: no
evocallaghan: luc_: That could be default the isolate the changes that made the regression happen. Your need to do this and log a bug with all the info.
luc_: ok
evocallaghan: luc_: Let us know, and i'll have a look over the diff's :)
Anarky: hi
Anarky: I'm having a Radeon HD 3870 card (should be R600/R700 class if I get it correctly) using radeon driver 6.12.2 and kernel 2.6.30 and can't get xvideo to work
Anarky: could someone help me ?
Anarky: I'm using all those from debian provided packages if it is of any importance
biotube: are you sure you're using the radeon driver? Xorg's autodetection defaults to radeonhd
osiris_: nha: were you able to find a regression in "r300: rewrite FOGC and HPOS attribs handling"?
Anarky: biotube: I explicitely specified it in xorg.conf
biotube: Anarky: just making sure
Anarky: let me look at the line on xorg.log
Anarky: (WW) RADEON(0): Direct rendering disabled
Anarky: (EE) RADEON(0): Acceleration initialization failed
Anarky: this might be the reason of the problem
nha: osiris_: I didn't find any regressions, good job
nha: osiris_: I'm looking over it on a source code level now and I have some comments
nha: I'll summarize them and send them to you
osiris_: nha: the problem is this patch introduces a regresion, but I couldn't find the cause
Anarky: and here's my xorg.conf if it's of any use http://pastebin.ca/1491746
Anarky: what reason could cause that "Direct rendering disabled" warnbing ?
nha: osiris_: what's the regression?\
Anarky: drm & radeon kernel modules are loaded, but lsmod reports no use of the radeon module
osiris_: nha: e.g. run sauerbraten -f1 and walk initial map, when rotating in certain places whole geometry is covered by pink fog
nha: probably related to buggy fog_as_texcoord
nha: I'll test it after looking over the code
osiris_: ok
Anarky: so no idea about that dri / xvideo problem ?
biotube: Anarky: none here :(
Anarky: that's really boring, 3D I can live without, video it's something else
Anarky: and neither radeon nor radeonhd work
Anarky: perhaps I should look on the kernel module side
Anarky: I have really no clue where to look
adamk_: Anarky: pastebin your full log file.
Anarky: ok
MrCooper: and check dmesg|grep drm
evocallaghan: Anyone got a idea why autohell is giving me hell today ? http://pastebin.com/d46d3a827
nanonyme: would also try 2.6.30.1, sounds like a bug fix release to me
Anarky: here's the log http://pastebin.ca/1491749
Anarky: MrCooper: you're right
Anarky: there's an error here
Anarky: failed to load firware
Anarky: I guess I should start looking at that
Anarky: thanks
MrCooper: evocallaghan: looks like libdrm.pc isn't installed properly
MrCooper: Anarky: install the firmware-linux package
Anarky: MrCooper: yep, I just saw that
Anarky: thanks a lot, you're a lifesaver
MrCooper: np
nanonyme: Oh, right, Debian.
evocallaghan: MrCooper: Thanks, lets see. This is a solaris-like box so.
Anarky: let's reboot with this new kernel
nanonyme: evocallaghan: And you have libdrm >= 2.2 and xf86driproto installed?
nanonyme: Oups, it's apparently specifically libdrm it complains about. :)
evocallaghan: bash-3.2$ pfexec find /usr -name libdrm.pc
evocallaghan: bash-3.2$
evocallaghan: :/
nanonyme: Which version do you have installed?
evocallaghan: What do you mean?
nanonyme: Of libdrm.
evocallaghan: Not sure.
evocallaghan: What's the autohell command for that again ?
evocallaghan: pkg-config or something
nha: osiris_: http://radeon.pastebin.com/m69305e30
nanonyme: evocallaghan: You could always check from configure to see how it's calling pkg-config.
nanonyme: But to find out the actual version, can query package manager.
MrCooper: evocallaghan: pkg-config doesn't know anything about libdrm without libdrm.pc
evocallaghan: solaris, package manager..
evocallaghan: hha
Anarky: Yeah, it's definitely solved !
nanonyme: If you do have libdrm >= 2.2 installed, overriding pkg-config in that area should be simple.
Anarky: thank you again !
Anarky: bye
evocallaghan: nanonyme: How do I override it without hardcoding it out?
nanonyme: Which component was this again you're trying to configure?
nanonyme: Oh, it actually does say.
evocallaghan: xf86-video-ati
nanonyme: "Alternatively, you may set the environment variables DRI_CFLAGS and DRI_LIBS to avoid the need to call pkg-config."
evocallaghan: Ah ah, sorry yes
evocallaghan: -_-
nanonyme: Slightly hacky alternative but in case you can't setup the pkg-config detection properly, that should at least work.
evocallaghan: That's fine, thanks
nanonyme: (Assuming your libdrm is new enough)
evocallaghan: Well we will find out what it all goes up in flames ^^
nanonyme: You'll probably get errors on compile time if it isn't. ;)
evocallaghan: Yep
evocallaghan: Does this look ok? export DRI_LIBS="-L/usr/X11/lib/X11/xserver -R/usr/X11/lib/X11/xserver"
nanonyme: I wouldn't know, never had to use -R.
evocallaghan: !!!! what?
evocallaghan: -L / -R are a pair, they should pretty much *always* go together !
nanonyme: *shrug*
evocallaghan: -L links,
evocallaghan: -R is the *runtime* linkage path.
evocallaghan: That's very important, you should not relie on the systems ld.so.conf
adamk_: Which shouldn't be necessary, as I understand it, if the run time library is already in the linker path.
nanonyme: I usually set stuff like -ldrm for the actual linkage.
nanonyme: Never had to touch -R.
nanonyme: Never ever. :)
evocallaghan: adamk_:That's a linux assumption that you shove absolutely everything into /usr/lib
adamk_: evocallaghan: Never had to use -R on FreeBSD, either. So there.
evocallaghan: nanonyme: Have you used LD_LIBRARY_LOAD before then?
adamk_: I'm sure ports use it, but libraries are generally installed where they should be installed :-)
nanonyme: Heard yes, haven't had to use it though.
evocallaghan: What to use LD_LIBRARY_LOAD .... NEVER !
evocallaghan: LD_LIBRARY_LOAD is *only* for vendor binaries that you can't change the runtime path. If you build your software properly you should never set it
nanonyme: And your point was?
nanonyme: I said I haven't had to use it. :)
evocallaghan: I was just amazed that you said you never heard of -R flag
evocallaghan: stunned in fact !
evocallaghan: But ok, now you know
adamk_: He never said he never heard of it.
evocallaghan: (13:51:45) nanonyme: I wouldn't know, never had to use -R.
adamk_: Right... He never had to use it.
adamk_: That's a big difference from never having heard of it. He never said if he heard of it or not.
evocallaghan: Sounds like, he never hard of it so could not verify if my line was correct :/
evocallaghan: ok fair play
nanonyme: I've never had to use it so I haven't tried it so I wouldn't know if the syntax is correct.
adamk_: Oh for crying out load... Can we get back on-topic please.
evocallaghan: :) lol
nanonyme: Anyway...
evocallaghan: gets quite upset when people start setting LD_LIBRARY_LOAD scripts, that is all.
evocallaghan: OK, any way. It does not seem to be finding it.
nanonyme: Did you check config.log to see what it actually doesn't find?
evocallaghan: No, you make a good case. Doing so now :)
evocallaghan: Well its still calling pkg-config even though I exported DRI_CFLAGS and DRI_LIBS
evocallaghan: ac_cv_env_DRI_CFLAGS_set=set
evocallaghan: ac_cv_env_DRI_CFLAGS_value=
evocallaghan: ac_cv_env_DRI_LIBS_set=set
evocallaghan: ac_cv_env_DRI_LIBS_value='-L/usr/X11/lib/X11/xserver -R/usr/X11/lib/X11/xserver'
nanonyme: You didn't set DRI_CFLAGS? :P
nanonyme: That'd be a good reason for why it's using pkg-config, me thinks.
nanonyme: You need to specify where the headers are.
evocallaghan: But its already picking up the headers fine.
evocallaghan: and its set to 'set
evocallaghan: '
evocallaghan: ac_cv_env_DRI_CFLAGS_set=set
evocallaghan: see.
nanonyme: Hrm...
nanonyme: It couldn't be smart enough to do a test program in configure that fails if you don't have new enough libdrm?
nanonyme: Thus never letting you get past configure phase.
evocallaghan: http://pastebin.com/m405e3e13
evocallaghan: No, its clearly trying to run pkg-config and failing at that.
evocallaghan: stopid autohell :(
nanonyme: Is there seriously no way of finding out which package versions you have installed on your operating system?
nanonyme: I was told there's not one but two package management systems on Solaris out of which the first one is getting obsolete.
nha: osiris_: sauerbraten is unbearably slow here
evocallaghan: They are both crap, we are making a new one for AuroraUX
osiris_: nha: what card?
evocallaghan: nanonyme: Well, that's the not the problem here. autohell is not *that* smart to figure out which lib version this is. Its simply calling pkg-config when it should not.
evocallaghan: So this is a autohell config problem in the source.
nanonyme: evocallaghan: Actually it usually is but we're not bumping into that yet.
nanonyme: It often tries to compile test programs inside configure to see what you have.
nha: osiris_: RV530, AGP disabled (either that's the culprit, or some quality setting in sauerbraten?)
nha: I mean, unbearably slow = performance measured in seconds per frame as opposed to the reverse
evocallaghan: nanonyme: In can see in the log I pasted above this is not the case hree.
evocallaghan: s/here
osiris_: nha: try disabling glare effect
nha: hmm, in config.cfg I see: glare 0
osiris_: nha: it's probably disabled AGP because I've checked sauerbraten -f1 on rv535 about two weeks ago and it worked pretty well
nha: eh, no
nha: it was the lines software fallback
nanonyme: evocallaghan: if test -n "$DRI_CFLAGS"; then\n pkg_cv_DRI_CFLAGS="$DRI_CFLAGS"
nanonyme: Override DRI_CFLAGS, see if it stops using pkg-config.
nha: with disable lowimpact fallbacks, it works fine
nha: modulo drmRadeonCmdBuffer: -22
nha: [ 724.708378] [drm:r300_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 369152 have 65536) !
nha: some renderbuffer bug, I presume
nha: in any case, I'm seeing some fog
evocallaghan: anonyme: I did `export DRI_CFLAGS=`
evocallaghan: Did not work :/
nanonyme: evocallaghan: -n means a non-zero string.
nanonyme: It will still detect it as nothing unless you give it -Iheaderpath.
evocallaghan: Ah ok
evocallaghan: sorry yes,
evocallaghan: ah ha, thank you for the help nanonyme:
nanonyme: Np.
osiris_: nha: are you using kms?
nanonyme: It's not like Bourne shell scripts were that hard to read. ^^
nha: osiris_: yes
nanonyme: is half-waiting someone to bring him a result from some "Obfuscated bourne shell script" contest
osiris_: nha: then the drm error is probably because of FBOs
nha: now the really tricky question: how to isolate the fragment program that is responsible for drawing the parts of the world that are affected by the fog bug
nha: osiris_: that's what I thought
soreau: nanonyme: hehe
nha: osiris_: the error occurs with one of the weapons in sauerbraten; just walking around is fine
osiris_: we should probably find simpler testcase
nha: osiris_: I'm going to try to isolate it into a testcase that can be added to piglit
nha: but in the meantime, if you find something simpler, I'd be grateful
osiris_: nha: unfortunately I've tried many mesa/progs but no luck
nha: well, existing piglit test cases also don't catch this, so...
nanonyme: soreau: Well, if one thing I've learned it's that making definitive statements is a challenge for other people to find out why they're not actually true at all. ;)
soreau: nanonyme: Yea.. it's be interesting to see obfuscated bash though ;)
soreau: it'd*
evocallaghan: nanonyme: At the gmake step it says it can't find, xf86drm.h what is that from, the kernel side?
nanonyme: Unsure.
nanonyme: I think it should be in libdrm.
nanonyme: Unsure though.
nanonyme: Yeah.
nanonyme: evocallaghan: Sitting in libdrm directory in my DRM git source tree anyway.
evocallaghan: Ah ok
evocallaghan: hold on, got cout up sorting out python crap (our mailing list)
nanonyme: plays with the idea of refusing software updates until r6xx-rewrite merges into master
evocallaghan: is lost in a sea of branches
nanonyme: Meh, there shouldn't be that many.
nanonyme: What are you trying to do, exactly?
evocallaghan: Oh of course, X server crashes ;(
nanonyme: So, what's it you're trying to do?
nha: osiris_: I have extracted a test case, but I need to run now
nha: and the testcase for some reason fails against software rendering, so I want to check that out first
TCW_: are the foss drivers "tuned" over the time? Will performance get better with new releases in general?
MostAwesomeDude: Yes, that's the idea.
muep___: even entire new features are offered at times
TCW_: Or ist it more like get things done so that they work, and maybe when everything works, try to tune the code?
TCW_: muep___, that's quite obvious ;)
bridgman: TCW; I think the developers try to work on what they feel will help users the most; if missing features are the biggest problem users face, then adding features will be the priority; if features are OK but performance is lacking, then performance would be higher priority
biotube: or whatever bugs them most ;)
bridgman: yep, or what interests them the most
bridgman: but there's no specific policy like 20% of time goes to tuning or anything
spstarr: bridgman: well, maybe not 5am :)
spstarr: bridgman: we're not done though more coming afternoon
bridgman: yeah, thunderstorms always seem to linger over the 'shwa
evocallaghan: Anyone like to review this minor warning cleanup patch please http://junk.auroraux.org/drm.patch
osiris_: nha: are you still here?
evocallaghan: Also, how may I request commit access for our solaris port of the radeon work we are doing?
evocallaghan: There is a team of three of us.
bridgman: evocallaghan; I think access grants are handled by entering a bugzilla ticket, hopefully someone who knows for sure will jump in
evocallaghan: Thanks
evocallaghan: bridgman:Can you review this minor warning cleanup patch please http://junk.auroraux.org/drm.patch
osiris_: evocallaghan: http://www.freedesktop.org/wiki/AccountRequests
zhasha: osiris_: that process takes months
osiris_: it took few days for me
evocallaghan: :'(
evocallaghan: Well um, would someone mind just doing a quick review and commit for me before I just out to dinner ?
evocallaghan: I just wanted to get these tiny things out the way for the other lads when they start this evening or tomorrow
zhasha: osiris_: took 2 months for me
evocallaghan: OK, I will follow that tonight when I get back.
evocallaghan: Looks easy enuff.
vwbusguy: invites the brave-at-heart: http://vwbusguy.wordpress.com/2009/07/11/free-open-source-drivers-for-newer-radeon-hd-cards/
bridgman: evocallaghan; I can take a look but I'm not really close enough to the code to give you any kind of definitive answer
bridgman: best would be to submit to the mailing list, dri-devel IIRC
osiris_: MrCooper: do you know how the VBOs are handled by mesa?
tsamolotoff: Hi there! I'm running an AMD64 Debian testing/squeeze, and git versions of both xserver and xf86-free-ati driver. It runs perfectly (as far as I can say, 'd not seen any segfault or something else yet), unless trying to reboot or power-off. The symptoms are similar to http://bugs.freedesktop.org/show_bug.cgi?id=20954 . Is there something useful to treat the bug?
loops: tsamolotoff: looks like that bug report has a patch attached to it which might solve the problem for you
tsamolotoff: Yeah, I've noticed it
loops: tsamolotoff: would be worth trying out that patch and posting a comment in BZ if it fixes things for you
tsamolotoff: I just wonder why that it hasn't been merged into git yet
loops: tsamolotoff: maybe they were just waiting for you to test it ;o)
tsamolotoff: Thanks for help, mo)
tsamolotoff: A couple of other stupid questions - is there any chance to see s3tc supported ? And what's about glsl, bloom and other fancy stuff?
adamk_: glsl might happen once gallium3d is done, assuming your hardware supports it. It certainly will not happen till gallium3d is available.
bridgman_: s3tc is an IP/licensing issue so hard to say
bridgman_: the rest are all going to be worked on AFAIK
tsamolotoff: IMO, It's a pity that AMD has dropped r500 support until almost all features are implemented (regardless of performance)
tsamolotoff: However, 2d/xv accel on FOSS radeon is amazing
bridgman_: yeah, but it was dropped for all OSes not just Linux, so we lost the free ride on the more heavily used OSes
adamk_: s3tc is available with the libtxc_dxtn library, btw, but doesn't work properly with multitexturing.
tsamolotoff: adamk_ I thought it's software, isn't it?
adamk_: The lack of s3tc makes quake4 completely unplayable (it won't even start) and having that library in place destroys the textures.
adamk_: Not sure how it works, honestly. It's always worked great on r200 hardware.
adamk_: But quite lousily on r300 and higher.
adamk_: Which is a shame. The functionality is present, but no one seems to want to fix it.
adamk_: So it seems there will always be some popular apps that won't be playable with OSS drivers on newer hardware, no matter how good gallium3d gets.
tsamolotoff: BTW, are there some tweaks to make Unreal Tournament 2004 demo work at bearable fps?
adamk_: tsamolotoff, I believe that setting "UseVBO=true" in the OpenGLDrv.OpenGLRenderDevice section is supposed to give a performance gain.
bridgman_: eventually someone is going to have to find a way to license s3tc for use in open source drivers, but so far I don't think that has been successful
adamk_: thinks that someone should be bridgman_ :-)
tsamolotoff: adamk_ Thanks, I'd try that )
adamk_: tsamolotoff, I've always found UT2004 to be playable... I haven't tried the demo, so I don't know if there is a performance difference.
tsamolotoff: However, enabling VBOs in nexuiz made the weapons and some of other objects dissapeared
adamk_: Isn't the decompression of textures handled by the hardware anyway? And wasn't s3tc licensed by the hardware manufacturer?
bridgman_: the problem here is compression not decompression AFAIK
adamk_: I thought games such as quake4 supplied compressed textures, though, that have to be decompressed?
osiris_: adamk_: we have to be able to deal with decompression in CPU because of software fallbacks
bridgman_: most supply compressed textures, but some ask the driver to compress them
bridgman_: not sure about quake4 itself
adamk_: osiris_, Ahhh, that makes sense.
mjr: A half-joking suggestion: code in support for inserting external pre-compressed textures based on uncompressed texture checksum
tsamolotoff: adamk_ Maybe it runs jerky because my gpu is rv535/M56?
adamk_: Hmm... Perhaps...
tsamolotoff: Yours - R400?
adamk_: I've played it on an x1900 and an x800.
adamk_: Though I'm fairly certain it worked fine on a radeon 9550 with slightly reduced settings.
hifi: what was the module parameter to enable kms?
adamk_: kernel module? I thought it was enabled by default unless you used 'nomodeset'
hifi: [ 5.242422] [drm] radeon default to kernel modesetting DISABLED.
hifi: thats configurable from the kernel build I think
adamk_: In that case, I don't know.
hifi: would it be "modeset" if "nomodeset" disables it
nanonyme: Wasn't it that it doesn't *build* the modesetting stuff at all unless you set KMS enabled by default?
hifi: hmm, that would suck big time
nanonyme: (that's at least my impression of it)
nanonyme: hifi: Very much so, especially since nomodeset doesn't seem to work with Linus tree.
hifi: ah, launchpad answered my question
hifi: (Karmic only!) 2.6.31-2 and higher require passing radeon.modeset=1 to grub to use KMS. **
nanonyme: Hmm...
nanonyme: Well, right, that wouldn't be stock sources. :3
spstarr: bridgman_: Cawthra south of QEW, 50 poles down, cars crushed, incredible damage, trees down, I can't type much more now.
spstarr: remains to be seen if we get any nasty cells it is peak time now
hifi: nanonyme: though the implementation choice was nice
Sarvatt: yeah we made the default value for the radeon module modeset=0 instead of -1
Sarvatt: in drivers/gpu/drm/radeon/radeon_drv.c line 85
bridgman_: debates the merits of moving the computer and comfy chair down into the vault
hifi: kms booted fine and gave me a nice native resolution console
hifi: xorg part didn't work so nicely
Sarvatt: was either that or disable it completely but i talked them into just making it 0 so people could still use it :D
Sarvatt: you need https://launchpad.net/~xorg-edgers/+archive/ppa to use it hifi
tsamolotoff: bridgman_: Also, there's "preserve aspect ratio" scaling mode in windows catalyst driver... Maybe it's that's stupid, but I didn't find the option in "man radeon" or on the Internet...
Sarvatt: userland for it isnt in karmic yet
hifi: Sarvatt: what exactly from there is needed
Sarvatt: everything
hifi: I'm pointing at you when my karmic breaks :)
Sarvatt: add it to sources and update, dont pick and choose packages because everything there depends on each other
hifi: I was just wondering
Sarvatt: just remove it from your sources, dpkg -l | grep sarvatt and sudo apt-get install package/karmic for each one to downgrade
hifi: just mesa, libdrm2 and ddx was needed for testing by hand
Sarvatt: you need xserver too
Sarvatt: use the livecd if you dont want to install it all
hifi: if it boots I can fix it (tm)
hifi: lets try the ppa repo then
Sarvatt: dont need radeon.modeset=1 on the livecd since the kernel it uses has it enabled by default
EruditeHermit: MrCooper: hey
hifi: aptitude really needs a option to receive a ppa public key automagically when asked...
Sarvatt: i like it not so i know where crap I dont fully trust is getting installed from :D
Sarvatt: you have a list of everything to revert not adding the key
hifi: Sarvatt: if it asks politely if you want to download the key? :p
Sarvatt: that would be nice :)
EruditeHermit: hey Sarvatt
hifi: I have to always look up how to do it by hand, though the one-liner linked from xorg-edgers if the most compact one I've seen
hifi: ok, rebooting xorg, here goes nothing
Sarvatt: alias keyup='sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com'
hifi: that'd work, sure
Sarvatt: thats whati use, and paste the key after
bridgman_: tsamolotoff; the radeonhd driver might have preserve aspect ratio scaling
hifi: woah, console restore worked
hifi: glxinfo: main/context.c:631: check_context_limits: Assertion `ctx->Const.MaxTextureCoordUnits <= ctx->Const.MaxTextureImageUnits' failed.
hifi: wat
tsamolotoff: bridgman_: But would it be implemented in radeon?
bridgman_: I don't think so, not yet... I remember some discussion of this a week or so ago
Sarvatt: hmm mesa regression? http://cgit.freedesktop.org/mesa/mesa/commit/?id=85957cb512e74c8ddeb5ba2e06df091943ab8400 ?
hifi: I'll try mesa from git
hifi: and btw. I tried LIBGL_ALWAYS_SOFTWARE=1 glxgears, it ran fine
hifi: LIBGL_ALWAYS_INDIRECT=1 froze my X
Sarvatt: that is mesa from git
Sarvatt: only the lastest commit isnt in that mesa
hifi: *now* git
hifi: or is the package so fresh there isn't anything related
Sarvatt: yeah
Sarvatt: i update it every day or multiple times a day if theres alot of commits
Sarvatt: it has everything but http://cgit.freedesktop.org/mesa/mesa/commit/?id=65059606e9a0039fc962869857c5f00a11d6b7cc in it
hifi: doesn't seem to be related
Sarvatt: waiting a bit longer to update it, hate to package it with just one new commit and it ends up having more right after because its a pain to upload new source more than once a day with the way the versioning priorities work
hifi: trying out current mesa now, after that some 7.5ish and bisect
Sarvatt: 7.5 doesnt support dri with KMS though, just a heads up
hifi: /bin/bash: INSTALL@: command not found
hifi: wat
Sarvatt: what card do you have?
hifi: wait, it works
Sarvatt: just apt-get source mesa and add that commit as a patch in debian/patches then add the patch name to debian/patches/series then debuild -uc -us -b from the mesa directory, easiest way
Sarvatt: cd mesa
hifi: eww, debian packaging
hifi: I'll try
moeSizlak: any advantage (in r350) in rawhide as compared to f11
moeSizlak: im thinking of upgrading
Sarvatt: just need to install devscripts first
hifi: why the fsck devscripts wanted postfix
biotube: because prefix is buggy?
Sarvatt: yeah i hate that it makes you install a mta too
Sarvatt: just purge it after :D
hifi: you're a dev, do something about it!
Sarvatt: no i'm not!
hifi: oh :(
Sarvatt: :)
hifi: now it's like building everything
nanonyme: Sarvatt: Nice, admitting nothing sounds good. :3
Sarvatt: indeed! its because some of things in devscripts need a mta though, theres way too much crap in the package not everyone needs. i would be happy with just debdiff debuild and dch in a seperate package :)
hifi: would love to have a -j switch for the make process
biotube: export CONCURRENCY_LEVEL
hifi: maybe next time, thanks for the env
airlied: moeSizlak: don't think there is much adbvantage in rawhide yet
hifi: I'll leave it to build and test in the morning, night
Sarvatt: DEB_BUILD_OPTIONS="parallel=n" debuild -whatever
Sarvatt: it only takes about 45 minutes to compile it all on my atom cpu
Sarvatt: night hifi :)
Sarvatt: it'll probably be updated on the ppa by the time you wake up in that case
EruditeHermit: Sarvatt: does that use multiple cores?
EruditeHermit: Sarvatt: btw would you know how to build i386 packages on amd64?
nanonyme: EruditeHermit: You can semi-trivially install a 32bit (or rather multilib) compiler on amd64.
EruditeHermit: nanonyme: how?
nanonyme: Which distro is this for?
nanonyme: Depends on that.
Sarvatt: it depends on the package, mesa uses the parallel build options
Sarvatt: you can look in debian/rules to see how it works
nanonyme: For Debian there seem to be stuff like gcc-multilib and g++-multilib.
EruditeHermit: ubuntu
EruditeHermit: which has the same stuff as debian
Sarvatt: just do it in virtualbox or something, easiest way :D
evocallaghan: Hi
nanonyme: Sarvatt: chroot is simpler
nanonyme: Imo anyway.
nanonyme: debootstrap + chroot doesn't require any kind of virtualization.
EruditeHermit: hmm
EruditeHermit: it'd be nice if you could pass debuild some parameter for platform
nanonyme: I'd assume you can but as Sarvatt said, a clean 32bit environment is probably simpler.
nanonyme: (probably requires heavy-duty cross-compilers for non-x86-based arch's anyway)
nanonyme: So I'm not sure if the behaviour is useful that often. :)
nanonyme: (even if it exists)
EruditeHermit: ok i'll try chroot and or virtualbox
Sarvatt: EruditeHermit: just make a PPA on launchpad, alot easier :D
Sarvatt: oh here ya go
Sarvatt: https://wiki.ubuntu.com/PbuilderHowto
Sarvatt: sudo pbuilder create --debootstrapopts --arch --debootstrapopts i386
EruditeHermit: Sarvatt: do they hand out PPAs to anyone?
Sarvatt: yup
EruditeHermit: well
EruditeHermit: they are probably backed up a lot
EruditeHermit: and I've use pbuilder before anyway
EruditeHermit: so i'll do that
Sarvatt: nah its just been bad the past few days because they were doing something but its all fixed up now
EruditeHermit: well I might create a PPA for fun too
Sarvatt: https://edge.launchpad.net/builders/
Sarvatt: they had 3 builders for each arch for a few days there
Sarvatt: couple that with 1.5 hour chromium builds building 12 times 4 times a day...
vehemens: mesa r6xx-rewrite branch no longer builds with libdrm master
evocallaghan: vehemens: What's the error?
evocallaghan: I think I *may* of hit the same thing, if so its a simple fix. I have a patch.
vehemens: it appears to be a result of the new space checking code. failing in r200. i haven't tried building r600 only yet.
bridgman_: AFAIK you need to build r6xx-rewrite against the libdrm from ~agd5f/drm r6xx-r7xx-3d branch
nanonyme: vehemens: Could try your idea too just for kinks.
nanonyme: As in, only enable r600.
bridgman_: then again I've never tried building it against drm master
vehemens: ah, i thought that ~agd5f/drm was only for the kernel driver
sgcb: im getting: radeon.h:90:23: error: radeon_bo.h: No such file or directory
sgcb: radeon.h:91:23: error: radeon_cs.h: No such file or directory
bridgman_: I'm still figuring that out; conventional wisdom is kernel driver only but the most common build instructions seem to include libdrm as well
sgcb: in latest git
osiris_: glisse: looks like ddx driver is to blame for performance hit with kms enabled. I disabled emitting cs to GPU for mesa, and when running glxgears I get only 800fps and X is eating 50% cpu time (1 of 2 cores)
nanonyme: bridgman_: agd5f said iirc kernel driver only.
nanonyme: Multiple times.
sgcb: do i need to install/update something?
bridgman_: I asked agd5f for recommended instructions (which worked well), let me check...
nanonyme: That doesn't exclude the possibility of libdrm master from breaking something though.
bridgman_: have to disconnect to get into office lan, brb
nanonyme: vehemens: But yeah, r200 not compiling should not be an issue anyway. Might already be fixed in Mesa master but not r6xx-rewrite, after all.
nanonyme: sgcb: On Fedora?
nanonyme: Sounds like installing a non-kms-aware libdrm over a kms-aware libdrm.
nanonyme: (wait a sec, that shouldn't leave you without headers)
nanonyme: sgcb: I actually think it's the opposite of what I just said.
nanonyme: How'd you install your libdrm?
vehemens: it's too many arguments to radeon_cs_space_check. trying to figure out what airlied added/removed/changed back on the 6th.
nanonyme: Hmm, too many? That's strange.
nanonyme: vehemens: You probably mean this? http://cgit.freedesktop.org/mesa/drm/commit/?id=39970c67b77014caac9a4c3a33765ac7a312b54e
vehemens: nanonyme: that would be it
nanonyme: isn't in front of a Linux machine atm, don't have his git at hand
nanonyme: Ah, right.
nanonyme: radeon_cs_space_check now has only one param. :p
nanonyme: Formerly three. That's probably the thing you were looking for?
vehemens: yea, need to use an old libdrm, or patch the r6xx-rewrite branch.
nanonyme: Hrm.
nanonyme: vehemens: Where is it called in r6xx-rewrite?
nanonyme: Don't have my build system at hand so can't grep or replicate.
vehemens: it's called in radeon_common. going to merge the branches, and see what i get.
nanonyme: Egh
nanonyme: vehemens: Looks like a simple change.
nanonyme: No need to merge.
nanonyme: The single-parameter radeon_cs_space_check that takes cs as param apparently works.
nanonyme: Just drop the latter two params and it looks like it might work...
bridgman: I posted the build instructions I use here :
bridgman: http://jbridgman.livejournal.com/945.html?view=3249
bridgman: http://jbridgman.livejournal.com/945.html try that instead
bridgman: down at the bottom
bridgman: pretty sure that the sudo make install updates libdrm etc...
nanonyme: bridgman: Psst, that's going to fail compiling if the user has a KMS-aware libdrm already installed. ;)
nanonyme: That is, Mesa will.
bridgman: I think that's why the instructions say to build and over-write libdrm first ;)
nanonyme: bridgman: The thing is, it leaves pkg-config behind...
bridgman: agreed
bridgman: this is really for doing development on a nukeable system
bridgman: and there's nothing like doing development to make your system nukeable ;)
nanonyme: Imo r200 not compiling with r6xx-rewrite counts as irrelevant and that latest thing was just an API change in libdrm which is somewhat to be expected on an experimental API. :3
vehemens: read the drm requirement as kernel drm, not libdrm.
bridgman: it probably started as kernel drm and "evolved" ?
bridgman: I imagine once we start adding ioctls etc.. that libdrm needs to change at some point ?
nanonyme: bridgman: Well, the pictures I took on the forums were on libdrm master --enable-experimental-radeon-api.
bridgman: might be interesting to try these instructions to see if you get different results
vehemens: nanonyme: expected yes, also annoying :>
bridgman: or is it kinda working for you now ?
nanonyme: Kinda.
bridgman: I remember, we talked about this, never mind ;)
bridgman: 3870 blah blah...
nanonyme: Yups.
nanonyme: vehemens: Well, the thing here is, keeping r6xx-rewrite up-to-date with an experimental API might be somewhat of a waste of time.
vehemens: the multiple branches makes it a pain (more of anyway) to switch between r300 and r600
vehemens: time is relative
nanonyme: Might as well wait until the libdrm API will get stable, then port r6xx-rewrite over to it.
nanonyme: (unless there's good reasons to do otherwise)
biotube: something I've been wondering: does the r6xx-r7xx-3d branch support KMS?
bridgman: don't think so; afaik it was branched before kms was merged
nanonyme: biotube: It would need kernel memory manager for r6xx/r7xx even if it supported it.
vehemens: nanonyme: kinda takes the challenge out of it to wait
biotube: that's what I thought
nanonyme: bridgman: Actually you said pretty much otherwise in your blog. ;)
biotube: just got an interesting build error on 2.6.30 with the 3D branch
nanonyme: bridgman: "The r6xx-rewrite branch was synced up with mesa master recently" this ended up pulling a lot of generation-generic KMS stuff into r6xx-rewrite.
biotube: "drm/linux-core/drm_sysfs.c:172: error: ‘struct device’ has no member named ‘bus_id’"
vehemens: it's a moving target. blogs are out of date moments after they are written.
nanonyme: Of course it still wouldn't make it support it...
biotube: nanonyme: it says mesa was sinked, not DRM
biotube: s/DRM/libdrm
bridgman: actually no; the *mesa* branch has a lot of support for kms in it... (and 6xx-rewrite is mesa)
bridgman: it's the *drm* branch that doesn't have kms support
nanonyme: Ah, right.
nanonyme: Read wrong then, sorry.
bridgman: biotube; afaik the r6xx-r7xx-3d drm branch only really works up to 2.6.28 right now
bridgman: nanonyme had a patch; still think that's good ?
biotube: bridgman: the interesting part is that I verified the struct did have that member, unless I looked at the wrong file
nanonyme: I've actually got two, one for 2.6.30 and another that'll get it to compile on 2.6.31.
nanonyme: http://koti.kapsi.fi/~nanonyme/public/ located here, testing doesn't probably hurt
biotube: whoops - did look at the wrong file
biotube: explains my confusion
bridgman: miraculously, nanonyme has a patch for you ;)
nanonyme: I couldn't get the DRM in 2.6.31 not to load by default if you set the staging option on though.
bridgman: (I mean miraculous in terms of timing, not that nanonyme has a patch ;))
nanonyme: :P
nanonyme: The patches are incremental.
nanonyme: Need to have both for 2.6.31.
nanonyme: (not that having them both would somehow prevent it from compiling on an earlier kernel version... *sigh*)
Sarvatt: nanonyme try this patch http://sarvatt.com/downloads/radeon_kms_default_off.patch
nanonyme: Looks good. I probably remember it by heart now, will change it when I get back home tomorrow.
nanonyme: (as in, the important parts)
nanonyme: Sarvatt: Thanks.
airlied: osiris_: we do the buffer flips in the DDX now with DRI2
airlied: and cs space check isn't as simple as dropping the parameter.
airlied: it needs actual porting
nanonyme: Egh.
vehemens: i dropped back to a libdrm snapshot of 6/14/09 to build the r6xx-rewrite branch.
nanonyme: airlied: You make it sound much like master branch of Mesa would be of no help for getting r6xx-rewrite to compile. :(
bridgman: nanonyme; do you mean drm ?
airlied: porting r6xx-rewrite to the new api isn't rocket science
airlied: its just not as simple as hacking the prototypes
airlied: like if someone looked at the master commit that changed the API, they could probably fix r6xx in 10 mins
nanonyme: Probably.
vehemens: airlied: it would take you 10 minutes. takes me a bit longer :>
airlied: it would take me 1 minute
airlied: thats why I said 10
EruditeHermit: airlied: we're timing you, go!
airlied: EruditeHermit: I'm not fixing it, if I was I'd have fixed it already :)
nanonyme: bridgman: No, I meant a change in an *experimental* API we've been talking about. :)
EruditeHermit: airlied: you're just scared =p
bridgman: aw crap, I thought we were already lining up with the experimental API stuff
airlied: wonders what is an experimental api
nanonyme: airlied: Usually the one developers add --enable-experimental-api switches for?
bridgman: whatever everyone is saying changed in master that is incompatible with the cs stuff added to 6xx-7xx-3d in alex's repo
nanonyme: 01:23 < vehemens> mesa r6xx-rewrite branch no longer builds with libdrm master
nanonyme: 01:44 < vehemens> it's too many arguments to radeon_cs_space_check. trying to figure out what airlied added/removed/changed back on the 6th.
nanonyme: 02:04 < vehemens> it's called in radeon_common. going to merge the branches, and see what i get.
vehemens: bridgman: last week you were lined up. just not this week.
nanonyme: That's a file in r6xx-rewrite and that's what we were talking about.
bridgman: ahh, no problem
airlied: http://cgit.freedesktop.org/mesa/mesa/commit/?id=c27f21f92d2cf9d23a9edb15d144eceb9ff383bc
airlied: shouldn't be too hard to replicate in r6xx tree
nanonyme: airlied: Yeah, I linked that already.
nanonyme: And you're right, it probably isn't.
nanonyme: I'd probably have tried if I wasn't 15 km's away from my development machine in the middle of the night.
nanonyme: And now I'm off to bed.
bridgman: got it, thanks
vehemens: maybe time for a merge master to r6xx-rewrite again?
airlied: the thing is if you build libdrm without the experimental api
airlied: r600 should work fine
airlied: and since you don't actually needs the experimental api unless you have kms.
megari: ~[5~[5~fgfsds
_moep_: re
vehemens: was hoping to have a shorter list of things to change when switching between r300 and r600 cards. hard part is figuring out what that list is.
airlied: well if you have to switch mesa, you could hack the r6xx mesa to not use libdrm_radeon
airlied: since it really doesn't need it
vehemens: using a older libdrm with r6xx mesa for the moment as it still works with r300.
airlied: if you aren't using kms, a libdrm without experimenal api is fine also
airlied: the experimental api is only useful for kms
vehemens: haven't tried that combination yet
sgcb: nanonyme: alright, fixed it, turns out I needed to follow the first 3 steps of "how to build drm stuff" located here: http://www.x.org/wiki/radeonhd%3Aexperimental_3D
lisandropm: Did any of you had any problems with radeon driver and kernel 2.6.30? I couldn't enable kde effects on it, but I got no error messages in the log
lisandropm: debian stock kernel, by the way
lisandropm: while I can keep 2.6.26, I just wanted to know/let other people know
sgcb: nanonyme: I get errors if I try and build the kernel stuff and FYI, im using debian sid/experimental. :)
pdbogen: (Started in #debian.. I'll try here..) Hi, guys. I have a radeon X1950XT, and I'm using the 'radeon' driver from Debian Sid. glxinfo reports that Direct Rendering is turned on. Running 'sudo glxgears' works fine, and results in omg 1337 FPSs, so DRI is, in fact, working. Running glxgears as non-root returns: "Error: couldn't get an RGB, Double-buffered visual" -- Any ideas?
pdbogen: (I only have one libGL.so, and it's not a permissions issue- strace reports /dev/dri/card0 opened properly)
biotube: su doesn't preserve the environment, sudo does
biotube: you need to install sux to get that sort of thing
pdbogen: ..okay?
pdbogen: Sorry, perhaps there's a miscommunication.
soreau: pdbogen: What does 'glxinfo|grep renderer' say?
biotube: pdbogen: the way sudo works, the started applications get access to your X session
airlied: pdbogen: sounds like a mismatch between X server and mesa amybe
pdbogen: OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL
airlied: or permissions on /dev/dri/card0
Sarvatt: Section "DRI"
Sarvatt: Mode 0666
Sarvatt: EndSection
Sarvatt: maybe?
biotube: pdbogen: su does not perform this connection
pdbogen: Sarvatt: Have that. See above about 'strace'
pdbogen: biotube: What's your point? I'm not using su.
biotube: pdbogen: misread; ignore
pdbogen: nods; no worries.
biotube: uses sudo only to reconnect wireless when it acts up
pdbogen: airlied: I'd agree that a mismatch is possible, but the fact remains that 'sudo glxgears' works flawlessly.
Sarvatt: did you compile libdrm by hand? did you forget to apply 01_default_perms.diff if so?
Sarvatt: is your udev not creating it with the right permissions maybe?
pdbogen: Sarvatt: I did not; everything is packages from Debian Sid, at the moment.
soreau: pdbogen: Maybe your X log will yield some further hint to the problem
pdbogen: Sarvatt: udev created it 0660 root:video, but I'm in the video group, so it's not a problem.
airlied: pdbogen: sudo glxgears may also be running indirect
pdbogen: soreau: I checked, but didn't see anything jump out at me. It's in http://pastebin.com/f12f4b70f, if anybody else would like to take a crack at it.
airlied: does LIBGL_ALWAYS_INDIRECT=1 glxgears work?
pdbogen: airlied: It doesn't.
pdbogen: (Same error)
airlied: otherwise the direct render is getting a different _dri.so than the X server
airlied: sudo glxinfo might help
Sarvatt: whats up with the xf86OpenConsole errors
pdbogen: Sarvatt: No clue, but they don't seem to apply to this issue, so I ignored them.
pdbogen: airlied: sudo glxinfo | grep renderer returns the same Renderer as without sudo.
airlied: don't grep
airlied: put the oputput in pastebin for glxgears and sudo glxgears
airlied: sorry
airlied: glxinfo
pdbogen: Without sudo: http://pastebin.com/f3e880e13
pdbogen: With sudo: http://pastebin.com/f4fed08ba
Sarvatt: heres what udev does for me, hmm http://sarvatt.com/downloads/udev.txt
airlied: wierd you get an extra visual with the sudo one
airlied: best on some stupid env you set onece
airlied: try logging on as a new user
pdbogen: airlied wins.
pdbogen: had export XLIB_SKIP_ARGB_VISUALS=1
pdbogen: .. in my .bashrc.
biotube: needs to get new glasses
pdbogen: Apparently, that was the one visual that glxgears wanted. :P
Sarvatt: looks like you arent the only one http://groups.google.com/group/linux.debian.user/browse_thread/thread/8b4e09876731edd0
Sarvatt: ahh glad it was something silly :D
airlied: sometimes its becaue mesa and X server disagree on something
pdbogen: Yep, me too.
airlied: or no AGILX
pdbogen: nods. I've gone through like half a dozen different "issues" today.
soreau: applauds airlied
pdbogen: Now, if only there was OpenGL 2.0 support, I could play the game that I've been trying to get running all evening.
pdbogen: :|
lisandropm: pdbogen: what kernel do you have now?
pdbogen: 2.6.30. :/
lisandropm: pdbogen: today i had issues with it
nha: osiris_: good news; first of all, I created a regression test for your bug for piglit: http://cgit.freedesktop.org/piglit/commit/?id=527fbeef2213decec2cec49012ea5c0b6c5f411f
lisandropm: get back to 2.6.26 and try again
nha: osiris_: second, I fixed the bug; get this patch: http://cgit.freedesktop.org/~nh/mesa/commit/?h=for-osiris&id=db444bc78c10e5e9f6398d1c78e4cca57bb7bda2
pdbogen: lisandropm: Well, the real problem is that for some reason, my video card fires off spurious MSI messages, so if I have MSI turned on, my system kernel panics every few minutes.
pdbogen: lisandropm: So I built a kernel without MSI. But fglrx needs MSI. :/
lisandropm: pdbogen: well, I don't had that issue :-)
lisandropm: fglrx?
airlied: you can boot with pci=nomsi in theory
airlied: to disable msis
lisandropm: sorry, i was talking about radeon
pdbogen: lisandropm: radeon just doesn't support OpenGL 2.0, AFAIK.
airlied: radoen also doesn't require msi
lisandropm: true
airlied: we don't use msi at all
pdbogen: nods to airlied.
pdbogen: Hence why I'm in here and not just banging my head against a wall. :)
pdbogen: goes to absorb some television. I am spectacularly grateful for all of your help.
ssieb: is the suspend problem well known now? is there any point in filing another bug with my specific chipset?
ssieb: actually, it suspends fine, it's just the resuming that has problems :-)
vwbusguy: airlied, I was going to ask you about the experimental r6xx/r7xx branch
vwbusguy: airlied, has there been much testing on it?
airlied: not on my radar yet, AMD guys mostly
airlied: don't think its ready for much yet
vwbusguy: yeah
airlied: i'm sure when it runs gears it'll be aanounced :-)
vwbusguy: glxgears?
airlied: yeah
vwbusguy: I compiled the mesa against that branch and I've got glxgears working on my specific hardware
ssieb: airlied: any comments on the resuming?
vwbusguy: I put up a bugzilla, but honestly I'm more eager to see how it's working for others
airlied: ssieb: file a bug
airlied: always worth it
airlied: &
ssieb: ok
ssieb: there's just getting to be so many radeon bugs filed, I thought it might be getting a little overwhelming...
EruditeHermit: airlied: I have a question about resuming from kms suspend
EruditeHermit: does it ever require any quirks?
EruditeHermit: i tried pm-suspend --quirk-none in kms but on resume it never brought up the backlight
Sarvatt: you have radeontool installed?
EruditeHermit: hmm yes
EruditeHermit: should I remove it?
Sarvatt: no idea, but that might be screwing with things
EruditeHermit: Sarvatt: what is the order of things on karmic?
EruditeHermit: what does the suspend script call for kms?
Sarvatt: its such a complicated mess i couldnt tell you
EruditeHermit: hmm
Sarvatt: but it is alot different in karmic
EruditeHermit: Sarvatt: did you ever test the kms CD with a USB stick?
EruditeHermit: i'll try again with a different one I guess
Sarvatt: people actually burn things to cds still? :D
EruditeHermit: well it didn't work on my USB stick
EruditeHermit: i always have issues with ISOs on sticks
EruditeHermit: Sarvatt: funny thing is I know the system is back up
EruditeHermit: because I can switch VT and do ctrl+alt+delete
EruditeHermit: and it restarts the machine
EruditeHermit: it just doesn't bring the backlight back up
Sarvatt: try moving /usr/sbin/radeontool out of the way
EruditeHermit: ok
EruditeHermit: brb
Sarvatt: are you using KDE or gnome?
EruditeHermit: Sarvatt: no luck
Sarvatt: pastebin your /var/log/pm-suspend.log?
EruditeHermit: http://pastebin.com/m54ff13f1
ssieb: further research suggests that my resuming issue might actually be a kernel problem
EruditeHermit: Sarvatt: hey
EruditeHermit: even the karmic edgers kms CD 0.16 fails to resume from suspend
Sarvatt: \o/ for the radeondrmfb endianness fix in drm-radeon-kms, no more yellow consoles :D
BubbaT: Hey can someone help me? I'm running lenny kde4.2 with a X1250 chipset5. When I run startx I get an error with AIGLX.
EruditeHermit: Sarvatt: no luck