Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2008-11-01

Search This Log:

kakarlus: do you guys know the channel for gamers?
kakarlus: im having a problem with my crysis warhead
terracon: would the real spstarr please step forward!
spstarr_coding: ?
terracon: hey there he is. hi
terracon: how goes coding
spstarr_desk: kms on r100...
spstarr_desk: let's try it forcefully...
spstarr_desk: well, kms works sorta on r1xx
spstarr_desk: plymouth crashes on exit, cannot vt switch invalid video mode. EDID from this old CRT is 'invalid' and defaults to 640x480 (maximum is 1024x768 normally i use 800x600)
spstarr_desk: but im in X
icewaterman: i have some texture problem with my radeon cards
icewaterman: some textures are displayed weired
icewaterman: http://home.arcor.de/irc-stuff/pics/texture_issue_radeon_linux.png
icewaterman: looks like a regression
icewaterman: because this was not defective before
hifi: you play cs, please die
icewaterman: hifi: it is just a demo, it happens with other games as well
icewaterman: i chose cs for the screenshot because it is old and should not make use of too many opengl features
MrCooper: icewaterman: is that on Fedora?
MrCooper: otherwise git bisect is useful for tracking down regressions
icewaterman: MrCooper: no, it is ubuntu
icewaterman: 6.9.0+git20081003
MrCooper: icewaterman: libgl1-mesa-dri is more likely to matter
icewaterman: 7.2-1ubuntu2
MrCooper: icewaterman: and the last working version(s)?
icewaterman: dunno, the last working one was that from hardy
icewaterman: 7.0.3
icewaterman: MrCooper:
icewaterman: if it is mesa that is responsible
dmb: i'm wondering if it possible to upgrade an ati x1400 in my dell inspiron
dmb: to a better ati card :P
chithead: dmb: unlikely. also the x1400 is well supported by the open source drivers, while newer ones are not
cl: hi guys! i just installed intrepid and now i get random lockups. the screen freezes, only the mouse pointer is movable. sometimes when this happens, the mouse moves very jerky too. killing xorg won't work, shuting down the system via the C E I S U B key sequence doenst work either - i have to hard reset. i have an ati x700 card. is this a known problem?
cl: oh, and adding "EXA" to xorg.conf doesnt solve it either
cl: ..and i'm using compiz
cl: on hardy everything was working fine
icewaterman: cl, remove all Option x y from the xorg.conf that refer to radeon
icewaterman: then it should work.
cl: icewaterman: currently it refers to "ati"
icewaterman: cl: change that to radeon
icewaterman: Option "AccelDFS" "on"
icewaterman: Option "AccelMethod" "EXA"
cl: icewaterman: after the installation there was only:
cl: Section "Device"
cl: Identifier "Configured Video Device"
cl: EndSection
cl: and this was crashing too
cl: icewaterman: is this a known problem?
icewaterman: then try to set driver to radeon and the options above
icewaterman: worked fine with an x850xt
icewaterman: or lets say it worked, fine is not exactly true :)
icewaterman: but the driver is still under development
cl: icewaterman: i thought ati refers to radeon?
icewaterman: cl: it used to but it may assume some default settings that result in a crash
icewaterman: i cannot test it
cl: icewaterman: did you experience the same problem, and what you just suggested fixed the problem?
cl: i can't use fglrx, it performs horribly with compiz..
icewaterman: no, i played with some options and it crashed, so i didnt use them
cl: ok, i'll try you suggestions
cl: thanks!
icewaterman: cl: every linux driver performs horribly with compiz
icewaterman: you will have to wait until dri2 is finished
cl: icewaterman: in hardy radeon was performing nicely
tlp: compiz is the one thing the radeon driver seems to be doing flawlessly for me with my r5xx card :)
icewaterman: cl: ah i thought you meant compiz & gaming
cl: for me to, that is before intrepid :-)
cl: when running games,i use a script that temporarily disables compiz
cl: no big deal
cl: but crashing the whole system is not acceptable ;-)
tlp: the RadeonProgram list says WoW renders mostly correctly with r5xx, but I'm having trouble getting the actual game to start without it taking my system down with it.
tlp: ah, it just steals my keyboard input and kills X
icewaterman: try logging in via ssh
tlp: yup, that's what I did. Xorg refuses to die with a kill -9 :)
tlp: finally got it to reboot
icewaterman: cl what script do you use?
icewaterman: because in that case i would also try compiz
cl: icewaterman: wrote up something myself
MostAwesomeDude: cl: Which version of radeon, kernel, Xserver, compiz?
cl: the script is called in a bash starter before the actual game
cl: MostAwesomeDude: the radeon package comming with ubunut intrpepid, its a git checkout from 2008-10-03, kernel 2.6.27-7, compiz 0.7.8, xorg 7.4
MostAwesomeDude: Hm.
icewaterman: cl: how do you disable compiz?
cl: icewaterman: via run_without_compiz
cl: i posted the bash script here: http://pastebin.com/m490be92e
icewaterman: why is compiz by default started with --indirect-rendering?
MostAwesomeDude: icewaterman: Because radeon doesn't do direct-rendered compiz?
icewaterman: MostAwesomeDude: it doesnt?
icewaterman: but it should
MostAwesomeDude: No, it doesn't. No free driver does.
MostAwesomeDude: And no, it shouldn't.
icewaterman: hm
MostAwesomeDude: AIGLX stands for Accelerated Indirect GLX.
icewaterman: why is that?
MostAwesomeDude: The core of compiz is tfp.
icewaterman: hm, that explains why compiz is so slow on my box
MostAwesomeDude: Which means GLX commands *need* to go through Xserver.
owen__: icewaterman: No, doesn't. Should be perfectly fast with indirect rendering
MostAwesomeDude: And, no, you're not getting it. AIGLX means that it's still accelerated!
icewaterman: MostAwesomeDude: but it is still slow
MostAwesomeDude: icewaterman: How slow?
MostAwesomeDude: 30fps is pretty reasonable for compiz.
owen__: (I've seen krh demo direct-rendering compiz with DRI2)
icewaterman: uhm, how can i find out how many fps?
icewaterman: looks like 15 to me but i am not very accurate at estimating
MostAwesomeDude: Use the benchmark plugin,.
icewaterman: ok, i'll try to find how to activate that one
icewaterman: ok, seems like i need to press F12
icewaterman: whatever the super key is
cl: hmm ~40 mins ago i installed a git20081030 package, changed the driver name ro "radeon" and commented out AccelDFS in xorg.conf
cl: no lockups so far
MostAwesomeDude: accelDFS can cause lockups for some people; that's why there's a switch to disable it. :3
cl: MostAwesomeDude: ok, i'll let you know if it crashes again, until then you can consider this changes as a fix, if someone reports the same problem. :-D
MostAwesomeDude: cl: AFAIK there's no reason to replace the accelerated DFS with something more stable, because it already *should* be stable.
MostAwesomeDude: Radeon hardware, to borrow marcheu's terms, is "fragile and unreliable." :3
MostAwesomeDude: At least compared to nVidia.
MostAwesomeDude: (Of course, I've never had Radeon hangs, but I've had dozens of GeForce hangs...)
RTFM_FTW: all hardware is fragile and unreliable
icewaterman: cl: acceldfs works fine here
cl: ok, maybe it is the new driver then
icewaterman: cl: where did you obtain the new driver?
cl: https://launchpad.net/~tormodvolden/+archive
cl: gotta repoot
icewaterman: however my problem seems to be a mesa problem anyway, so it will not matter whether i install those or not
tlp: wow, the RadeonProgram wiki is tricky to edit
airlied: I do wonder if some of the stabilty patches that went into the kernel actually had the ooposite effect.
soreau: Hi
soreau: Would anyone happen to know how to set a mode correctly with xrandr using the radeon drivers? So far, I have tried the xrandr man page example command and it fails with this: http://pastebin.com/m1258c4d1
airlied: soreau: tv-out is hardcoded to 800x600 AFAIK.
soreau: Currently I have LCD 1024x768 and tv-out (S-video) at 800x600, but I just want the tv-out to be 1024x768 as well, but I cannot set that mode as it reports as being unavailable
airlied: but you might need to give the mode a different name
soreau: Hard coded, eh? That would suck..
soreau: These small quirks are what keep making me trudge back to fglrx *sigh*
soreau: airlied: How should I write that command differently?
soreau: I mean it came straight from the man page and fails right away
airlied: soreau: change the mode name
airlied: there is already a amode called "1024x768" somewhere.
soreau: Oh ok, let's see
soreau: Hey, I think that worked, testing further...
soreau: Well it added a mode successfully, but I cannot switch to or use it
airlied: xrandr --addmode S-video "1024x768X"
soreau: Well I called it 'mymode' for testing, but now I cannot delete it with rmmode
soreau: airlied: Would you mind helping me a bit more with this?
soreau: I am completely lost here
airlied: did the addmode help?
soreau: This is what I am doing http://pastebin.com/m3678d327
soreau: here's what happens when I try add and rmmode http://pastebin.com/m4b09e77f
airlied: why rmmode it? you want to set the mode.
soreau: Well just for testing purposes
soreau: To learn how to actually use xrandr
airlied: oh wierd.
airlied: try xranndr --admode S-vidoe "mymode"
soreau: bash: xranndr: command not found
soreau: j/k ;)
soreau: airlied: http://pastebin.com/m3d3bc07e
soreau: How should I find out if this is actually hard coded? Because if this is the case, these efforts would be futile
airlied: soreau: its hardcoded alright.
airlied: 800x600
soreau: So there is nothing I can do for this then I guess
soreau: I assume there is some reason for this, so even if I compiled whatever component to get it for 1024x768, this wont work?
soreau: Where is it hard coded?
soreau: (and why)
airlied: I think the TV scaling programming isn't complete.
airlied: most people are quite happy with 800x600 on TVs considering you can't see much better than that.
airlied: without it looking really crapp.
benh: well
soreau: Right, That is understandable, but the point is for it matching the res of the monitor
benh: that would piss me off too :-)
airlied: soreau: ah you are using tv-out into a monitor...
benh: with TV out I want to be able to use the proper number of lines
soreau: Because all hw here is fully capable under fglrx for instance
benh: which 480 or 576
soreau: airlied: No, but I could be :)
benh: visible
benh: so that interlaced stuff looks good
benh: anything else crap :-)
benh: and thus you want to proper number of columns too in order to get the right aspect ratio
soreau: But it still should be configurable and not hard coded
benh: 720x576 for example would be nice for PAL
benh: 800x600 is a stupid default imho
airlied: benh: its the cloest useable resolution. the scaler scales to PAL/NTSC
benh: airlied: right but you don't want that
soreau: Well if I grabbed the source and compiled my own would there be problems simply changing from 800x600 to 1024x768?
benh: airlied: you don't want scaling for interlaced media that is natively of the right resolution
benh: airlied: ie, if I play a DVD I want unscaled true 720x576
benh: airlied: to get the interlacing right
airlied: benh: true... ah well I care little for tv-out, everyone should hve HDMI :)
benh: :-)
airlied: granted someday we'll get around to it, its just further down the list.
benh: I only care to the extent that I wasted some years of my life, a long time ago, doing driver for high end video cards used in TV post-production :-)
benh: no big deal
soreau: I guess it's just principal to me.. I just think it should have option of 800x600 and 1024x768, not to be hard coded
benh: in fact, I wonder what my Mac Mini does for TV Out, I might hack on it one day
benh: it's a non-mobility rv280 and an external dongle
benh: that does composite and s-video
benh: dunno if that involves the chip's TV stuff or not
benh: soreau: sure, patches welcome :-)
soreau: Yea, this is a radeon 9600 with composite and s-video out
soreau: It only auto detects with svideo though
benh: ah, the apple stuff auto-detects fine with composite
benh: I need to run that through ndrver one day
benh: I -think- they have an EEPROM in the dongle tho
benh: so they can detect its presence
soreau: benh: Sorry for the ignorance, but would it just be the radeon driver I would have to compile? I mean, where's this hard coded?
benh: and so they know something is plugged, no need to do load detection
airlied: soreau: just the radeon.
airlied: code is all in radeon_tv.c
airlied: but I can't claim to understand it.
airlied: tv timings just piss me off.
benh: but yeah, with ndrver I can get all the programming they do
soreau: Ok, where can I grab the source, preferably the same version as has come with my distro?
benh: which could be useful to get some of the voodoo values needed for some modes
benh: airlied: me too :-)
airlied: git://git.freedesktop.org/git/xorg/driver/xf86-video-ati
airlied: or just grab a release.
soreau: airlied: Thanks
benh: airlied: back then I got the HW guy to give me tables, I wouldn't bother calculating myself
airlied: benh: we have tables hardcoded :)
benh: airlied: and with ndrver I should be able to snapshot all the values written by the MacOS driver easily
airlied: from gatos.
benh: airlied: we have tables for all the useful timings or only 800x600 ?
airlied: benh: the ntsc/pal stuff looks to be timings from setting up the chip at 80xx0600
benh: airlied: ie, there's weird dependencies betwee nthe actual TV timings and the scaled mode no ?
benh: yeah
airlied: benh: yeah I don't totally understand it all.
benh: me neither last time I looked
soreau: airlied: I think I'm grabbing the latest from git here though, how should I grab a snapshot?
benh: oh well, as I said, if agd5f can't get us the data
benh: I probably can snoops them easily from the macos driver
airlied: soreau: depends on what distro, but the latest should work fine on most distros.
benh: easy enough with ndrver to do a little program that sets all TV modes & snapshots all the right registers
spstarr: hello airlied
soreau: airlied: Ok, I just didn't want some version mismatch somewhere
tlp: I don't suppose regular builds/snapshots of the radeon driver are done for Ubuntu?
soreau: Well even ./autogen.sh failed right off the bat with http://pastebin.com/m363f291f
airlied: soreau: missing devel package.
soreau: I have x11proto-xinerama-dev installed
soreau: And yes, this is embarrassingly enough, ubuntu Intrepid
soreau: Ok, installing libxinerama-dev and libxcb-xinerama0-dev now
soreau: But fails with the same sytax error
soreau: Where's the README or the deplist in here?
airlied: I think xorrg-utils-dev or something
soreau: Ok, I installed xserver-xorg-dev and libxinerama-dev now it's past that point
soreau: Alright, now that the configure succeeds, time to hack on this a bit
soreau: And now it's compiled. So, will I have to install this to get it to work or can I just load the module where it lies.. but I don't see radeon.ko hmm
soreau: And here goes nuthin
soreau: So I need to know, where should these libraries be installed? By a default ./autogen.sh alone, it has installed into /usr/local/lib/xorg/modules/multimedia
soreau: Everything is working, except just as if I had made no changes
soreau: The prefix should be /usr I guess..
agd5f: benh, airlied: I never had any success with any modes other than 800x600
agd5f: on tv-out
agd5f: the beos radeon driver had support for arbitrary modes on tv-out (at least according to the code), but I was never able to get it to light up anything other than 800x600
agd5f: IIRC, the tv encoder is a accumlator of sorts and you had to get the timing such that the end of the incoming frame matched the end of the tv encoders frame or something like that
agd5f: soreau: the driver is hardcoded to 800x600 since I never had the time to get any other modes working
agd5f: the tv scaler should support just about any mode however
soreau: agd5f: I'm looking at it now, and I see the fixmes.. I changed to 1024x768 in TVModeConstants but it doesn't work (obviously)
agd5f: soreau: you'd need to calculate a new table of values for 1024x768 or figure out an algorithm to calculate them based on the mode
soreau: So basically, it's a complicated timing issue?
agd5f: soreau: yeah
EruditeHermit: spstarr: do you still get those wait times?
soreau: agd5f: How would I go about calculating these other values?
agd5f: soreau: you have to match to crtc timing to the tv encoder timing within certain constraints
spstarr: EruditeHermit: I get some instabilities still
soreau: (This is exactly my speculation upon initial review)
soreau: agd5f: Is there any place I might be able to read more about this, docs or anything?
EruditeHermit: spstarr: I get them in the normal non-kms drivers too
spstarr: EruditeHermit: We will have to wait til people look at AGP again, for now i am more or less stable, but im not in kms for now
agd5f: soreau: probably the easiest way to to get the bios to set 1024x768 on the tv using vbe and dump the regsiter values
EruditeHermit: spstarr: do you only get it in kms?
spstarr: I am not getting busy waits in non-kms with composite enabled
agd5f: soreau: not that I know of
EruditeHermit: spstarr: are you using XAA or EXA?
spstarr: EXA
EruditeHermit: hm
soreau: agd5f: Well thanks for the reply and further information. But this is probably way over my head.
agd5f: soreau: it's mostly black magic :)
soreau: agd5f: I see.. I'll hack around on it and see if I can't come up with a spell ;)
EruditeHermit: spstarr: I periodically get 100% CPU usage and unresponsive cursor. The only way to unset that is to switch to a VT and it automatically switches me back to X and the problem goes away
EruditeHermit: by unresponsive I mean that I can move it, but clicking on stuff doesn't work
EruditeHermit: no input
EruditeHermit: I can even bring up windows, but buttons, text input don't work
spstarr: if i switch VT and back it will lockup
spstarr: frankly, im going to help test gallium when glisse and other have code that sorta works
spstarr: cut my loss and just go with that
spstarr: now that said, where does DRI2 fit into Gallium? or its something parallel to Gallium?
EruditeHermit: spstarr: but isn't close to being testable is it?
EruditeHermit: spstarr: something different
spstarr: if so, I want nothing to do with DRI anymore (because it seems to be a dead design)
EruditeHermit: spstarr: gallium is 3D driver framework
spstarr: EruditeHermit: not even close, glisse is only just startin to look at a radeon gallium driver
EruditeHermit: spstarr: DRI2 is a better structure to handle things like more than 1 3D app running at once etc
spstarr: EruditeHermit: yes its a framework, unless that includes DRI2
spstarr: EruditeHermit: I'm not convinced DRI is the right path for the graphics stack
spstarr: kernel drm <--> gallium done.
EruditeHermit: DRI2 is independent of gallium and vice-versa
spstarr: EruditeHermit: then I see no real future working on DRI when we want to move to something that will radically make drivers easier to write
EruditeHermit: spstarr: no one is really working on it now
EruditeHermit: spstarr: what do you mean?
soreau: spstarr: http://wiki.x.org/wiki/DRI2
spstarr: with the DDX being phased out, slowly (kernel drm drivers) we'll get a point where you write a kernel driver and a gallium driver (i think) and that's it.
spstarr: but im speculating
EruditeHermit: spstarr: I thought airlied is doing memory manager + kms, agd5f is doing 3D support for R600/700
spstarr: EruditeHermit: well, they are
spstarr: EruditeHermit: Gallium isn't ready for them to move to yet
EruditeHermit: yes
spstarr: EruditeHermit: and people need 'something' now
spstarr: but the work agd5f is doing on 3D can be reused for Gallium (the programming of the card etc)
EruditeHermit: yes
EruditeHermit: so no wasted work is being done really
EruditeHermit: apart from 3D will have to be redone for gallium
EruditeHermit: but there will be a fallback I think
EruditeHermit: it'll be an interesting 6 months
spstarr: its expected
spstarr: nobody said ramming graphics into 20 year old X code is easy
spstarr: EruditeHermit: from what the Xorg people told me there's a 5% overhead from the GLX <-> DRI conversion
spstarr: and now I understand what Glucose is
spstarr: it is the ability to render X onto 'something' like cairo, or ps or pdf representation i dont know
spstarr: but my guess is that would add overhead converting X11 representation to whatever renderer
spstarr: Glucose is sorta like what Mac OS X would be for their conversion to renderer
airlied: spstarr: I don't think one thing you've said in that past conversation makes any sense.
airlied: I suspect you are randomly picking buzzwords and making up sentences again.
airlied: you will always need a DDX.
airlied: we are a long way from gallium X render state machine replacing EXA.
airlied: in fact it may not ever happen, nobody is bothered with it so far.
airlied: DRI isn't a dead design, you need to stop taking one problem you have with something and assuming things will fix it.
tlp: Aside from being a bit sluggish, I've been able to play through the first four chapters of Max Payne with the radeon driver. It's a Direct3D game too.
rmh3093: airlied, ping
spstarr: we are a long way from gallium X render state machine replacing EXA. -- But we should, if it makes sense drop what we have that sorta works and just go that route.
spstarr: airlied: note i said speculating
SilentK: hello
spstarr: DRI is a problem, 5% overhead from GLX <-> DRI is not very good
SilentK: I downloaded my hp pavilion dv8110us graphics driver from hp.com
SilentK: From thier release date on the file it looks a bit out dated..
SilentK: If I go to the graphics control panel its not catalyst.
rmh3093: my X keep restarting with kms
spstarr: I openly support whatever it takes to move X11's network transport out
spstarr: we *dont* need it anymore
rmh3093: i think there is a nice memory leak in the driver
spstarr: we have NX, VNC, it makes no sense anymore for network transport
glisse: spstarr: X network transport never have been the problem
glisse: nobody ever come up with number showing that
spstarr: glisse: so what is it? the pixmap structures?
glisse: in fact people who looked at it showed that this was not where the overhead were
glisse: xlib
glisse: and acceleration infrastructure of X
spstarr: so then what is xcb?
owen__: spstarr: if the developers weren't spending all their time trying to get hardware programmed and make things not crash, there's a ton of stuff that could be done on performance
SilentK: Should I download catalyst and just install or do I need to remove my graphics card drivers from hp?
glisse: which was designed 10 years ago (i am simplufying here)
spstarr: owen__: hmm, well it just seems there's too much stuff but no one focus
spstarr: glucose makes sense
glisse: in theory it does
glisse: but theory never fit the reality
spstarr: why theory? we see Mac OS X's rendring their display makes sense, and fast
glisse: they are no using somethings like glucose :)
owen__: spstarr: more developers + constrained hardware
glisse: and OSX isn't really an example at least from the low infos and small knowledge i have of it
spstarr: owen__: well we have keithp off in his own world with intel and it seems he totally is neglecting Xorg, and is busy on intel this intel that, yes he works for them but, unless his stuff filters back to Xorg its not very helpful
owen__: spstarr: if keithp cna get the intel drivers working well, that's good enough for me
spstarr: if DRi2 isn't part of Gallium what focus of resources is that useful for? if we all know Gallium is the right direction to go
glisse: dri2 and gallium are orthogonal
spstarr: glisse: right, but it gets us two separate things
spstarr: I think one thing the distros of all stripes dont understand or fail to realize is, even if you have GNOME or KDE and lots of developers hired for those
spstarr: its USELESS if your desktop/graphics stack is broken
glisse: well despite it's letter X is not sexy :)
spstarr: if it's not, then why do we continue to beat ourselves over and over
glisse: what i mean is that we fail big time at making it look sexy...
glisse: the hw is hard to understand and program
spstarr: I understand that aspect, no doubt i see what you're going though from my testing
spstarr: but sometimes you have to cut your losses and start over given what you already know in some things
spstarr: kms and moving most of the DDX to the kernel is a good thing
spstarr: glisse: really I'd like to see the X server go away 'Xorg' and xlib/xcb become compatibility for X apps making it transparent that we dont really have an X server running anymore
agd5f: spstarr: what are you talking about? what would you replace X with?
glisse: well i don't see this happening any time soon
onestone: X12 ;-)
spstarr: agd5f: X doesnt go away, the X server itself goes away or becomes something different
spstarr: agd5f: but I can't see how what we're doing what we have is a good thing or not. We cant get rid of X apps, but maybe we can move them into a compatibility with a new display system
spstarr: I think more people would help graphics in Linux if we had a more consistent direction, if Gallium is that direction great, but let's make the call one way or another
glisse: spstarr: we have to move smoothly
glisse: we have a working mesa driver which is shipped for long times
spstarr: yes
glisse: we are not going to ship gallium before a year or so
glisse: at bes
glisse: at best
spstarr: but if everyone is still trying to refine the existing code, gallium will slip more
spstarr: im fine not using composite on r3xx if it means more resources can go to gallium or something to help the stack
spstarr: glisse: given theres only so many people working on graphics, the scope is so huge, pick your battles
benh: agd5f: I can get MacOS to set any mode and dump the result
benh: agd5f: I still have this thing I wrote to run the macos driver in a shell in linux and spy all it's IOs in fact
benh: agd5f: something to do one day of boredom
spstarr: glisse: I will be happy to test your gallium work
spstarr: more than happy to help whatever I can
glisse: well i first need to get around with dri2 on old stack
glisse: this is my roadmap :)
spstarr: why?
spstarr: see, i don't understand why
spstarr: if DRI2 isn't fitting into gallium, why bother?
glisse: because i want to be able to test memory manager with current stack
spstarr: but wouldn't a gallium driver use the same memory manager ?
glisse: before doing gallium and being unable to know if it's my gallium code or the memory manager stack which is broken
spstarr: fair enough
spstarr: to me that just seems like more pain on your part :)
spstarr: glisse: then I will test your DRI2 work
spstarr: my programming skills are userspace based, maybe if I spent some time reading code more and some books online, might be able to help on the code side of things
spstarr: but with so much going on, maybe I should wait until the mm is solidified and the drm bits are complete
spstarr: then i can break down driver writing into the drm bits and gallium 3D side of things once that api is declared frozen
spstarr: glisse: it would be nice to have techbase.kde.org for Xorg in terms of projects, drivers, whats needed etc so people can get a better understanding to things
spstarr: thats one of the major reasons why i joined KDE, it was easy to do, the APIs were there, examples there, not just real code
jcristau: it would be nice if i had a pony
glisse: well we are lacking so much people that we don't have time for doing webstuff ;)
spstarr: glisse: its a vicious cycle yes:(
spstarr: glisse: my major worry (and it continues) is when will we have a graphics stack that will be good enough that people can just write more nifty stuff for userspace to utilize the stack
spstarr: so gone will be the days we worry about so much as we do now
spstarr: 3 years? 5 years from now?
glisse: i think in 1 year from now we will be a lot better world
glisse: with kms & memory manager upstream and many other ground work done
spstarr: agreed on those
spstarr: that's one side of the puzzle
spstarr: glisse: i guess im sad that it took so long for us to get kms/mm :/
spstarr: glisse: I will guess however when gallium does become reality, there will be an explosion of development, for new drivers
spstarr: if what I see is true and gallium makes it easier to write drivers
spstarr: I guess thats why im excited about it so much
spstarr: it corrects many wrongs
glisse: doesn't correct anythings it's just way better design to program driver for today hw
spstarr: well, but the fact the design is better, would indicate what we have now isn't so good, even as it is possible to do
spstarr: but i guess all of this has been a learning experience
jcristau: 'explosion of development', really?
spstarr: jcristau: if the design is that clean, it might make it easier for me to understand a graphics stack
spstarr: it depends on how different it is from what we have now
tlp: Working drivers would be nice before the shift to gallium, IMO.
spstarr: tlp: not if its duplicate work,that wastes time
tlp: I don't mind waiting if I have something that mostly works in the meantime, whereas waiting for gallium to get here with nothing at all available would suck.
owen__: spstarr: if you are so worried about wasting time, why aren't you working on a gallium-based ddx?
jcristau: owen__: because talk is cheap
spstarr: owen__: I thought most of the DDX moves to the drm driver now?
owen__: spstarr: well, you'd still need *a* ddx. It might be a lot smaller. And someone would have to write it. You?
spstarr: well, if I can understand whats needed for the stripped down DDX perhaps, sure
spstarr: I know C
owen__: spstarr: Well, the first thing would be to check out the xorg sources, change into the exa/ directory, and start trying to figure out how some simple things happen.
owen__: spstarr: then you would want to spend some time on the other end looking at how existing gallium state trackers do stuff
owen__: spstarr: It probably would be a few weekends of code reading before it starts to make sense, but there's actually nothing all that hard about this stuff. It's just bookkeeping and passing commands around. It's not threaded filesystem code or something.
spstarr: so the DDX now just becomes what the EXA does?
owen__: exa is a ddx ... it's a "meta ddx" ... originally there was one ddx per hardware, but exa handles all the different hardware for Xorg, with different loadable modules
spstarr: ok so the common elements like DownloadFromScreen etc are a wrapped API for doing certain operations
owen__: spstarr: exa translates the X level operations like "GetImage" into lower level primitives like DownLoadFromScreen
spstarr: i will have to look at that
spstarr: owen__: I thought we want to marriage 2D and 3D as one, and have no more distinctions between them?
spstarr: or a Gallium DDX would be just that
owen__: spstarr: a gallium ddx would mean that there was no xf86-video-ati chunk of code writing out ati-specific commands, the hardware would be programmed using the same low level driver for 2d and 3d
spstarr: im confused by that, I thought you needed to still do this per GPU (type)
owen__: spstarr: the GPU type is handled inside gallium (of course, there is also modesetting, handled now by kms)
spstarr: so one would have to still write that part in gallium
owen__: yep
spstarr: so its broken up in two, im logging this so i can reread it
spstarr: owen__: I do feel this will be a huge learning curve,for me at least
owen__: well, yes, I'm not exactly expecting you to show up with something next week ... but the nice thing about learning curves is that you learn on them :-)
tlp: What is involved in, say, implementing more OpenGL extensions?
airlied: spstarr: gallium won't cause any explosin in anything.
airlied: graphics driver programming his hard.
spstarr: absolutely!
owen__: tlp: for the interesting ones, it's mostly going to be debugging and extending the memory manager work
spstarr: but i do agree that spreading the knowledge would help people learn more, brain dumps
airlied: spstarr: we do spread the knowledge we get one or two people every year who seem to figure it out.
spstarr: but if you have to repeat the questions over and over doesn't it make sense to document it somewhere?
airlied: spstarr: its not like MostAwesomeDude ever new anything about graphics drivers last yeart
spstarr: (the channel is logged)
spstarr: I'd love to see your conversation(s) with him over the year from beginning
airlied: he arrived in the channel said I want to make r500 FP works, I told him roughly what needed to be done.
airlied: spstarr: they are all in the logs.
airlied: the thing was he took the ball and ran with it.
tlp: FP?
airlied: he didn't keep coming in here asking the same questions.
airlied: he wrote some code, it broke, he rebootted 5000 times.
z3ro: tlp: fragment program
spstarr: airlied: thats usually how it goes :)
airlied: I wrote some code to help him, he rebooted lots more, and it finally worked.
airlied: the thing is you have a really basic problem in userspace with your card.
spstarr: oh i dont care about that anymore, i just want to help graphics kick ass
airlied: the fact that you have given up trying to fix it means you aren't that interested in fixing it.
airlied: we all started fixing a small problem.
z3ro: spstarr: also, if you want to get a feel for how the hardware works, just sit down with the docs, and dump fglrx.
airlied: fixing the whole system is best left up to the people who spent the time understanding the full system.
airlied: and not speculating the things like gallium are more thatn they are.
z3ro: eg if you want to work out an extension, write a test for revenge, see the packets that fglrx generates, cross reference with the docs, and implement it from there.
airlied: or will solve all the problems ever.
spstarr: z3ro: that is an option, then translate the registers into what the docs say
airlied: spstarr: also z3ro did the same, came in asked some questions found something to hack on in a corner nobody was doing anything.
z3ro: yep. you also get a good idea of how the card is programmed after looking at dumps.
spstarr: maybe my education didnt teach me enough about how hardware interaction works, maybe it did
hypnotic: hi there, anybody know if avivo works under linux?
jcristau: airlied: you mean gallium won't solve world hunger? i'm so disappointed
airlied: jcristau: it did already, just TG haven't released the source.
airlied: I gotta run, SIGGF..
spstarr: z3ro: ok, what did you do? maybe document what you did to get started?
jcristau: spstarr: it looks like it failed to teach you how to learn stuff..
z3ro: spstarr: well, this was before we had docs, so if I had to learn again I'd do it a bit differently...
spstarr: well,i learned KDE from example and failure
spstarr: but thats a lot less complex :)
z3ro: personally I'd start with reading the docs... esp the r500 programming guide.
spstarr: i have an r6xx thats the best I could help from
z3ro: this gives lots of ground work that you need to know (eg the CP, ring buffer, indirect buffers, etc)
z3ro: you still need to know all this stuff for r6xx.
spstarr: r3xx is not documented anywhere (i dont know where the real spec is, or if its released or not)
spstarr: right
spstarr: the ground work is what i want to know
z3ro: r3xx is documented.
spstarr: z3ro: the programming guide for that is on the Xorg amd directory? I saw some pdfs in there
z3ro: right now r6xx is a bit tricky because we don't have full docs yet (just the ISA)
spstarr: ugh
z3ro: if you want to work on r6xx you could still do a lot there.
spstarr: z3ro: i want to know the ground work as to how a graphics card works, how you manage it, as above, CP, ring buffer, etc
spstarr: the r500 guide has that?
spstarr: it goes into enough detail?
z3ro: yeah
z3ro: http://www.x.org/docs/AMD/R5xx_Acceleration_v1.3.pdf
spstarr: gets
z3ro: I know it says r5xx everywhere, but this stuff applies almost identically to r3xx.
spstarr: understood on that aspect
spstarr: oh nice
RTFM_FTW: heh I'd recommend starting on the user-space aspects if you are new :D
RTFM_FTW: it helps if you can avoid having to reboot every ~10 minutes :P
spstarr: but that is so blurred
z3ro: RTFM_FTW: sure, but you still need to know about the CP and packets etc for userspace work...
RTFM_FTW: on a properly structured device driver it shouldn't be
RTFM_FTW: z3ro well of course
tlp: owen__: ah. That's the kind of thing I'd be interested in doing, but it doesn't sound like a likely place to jump in.
spstarr: As such, much of this guide is
spstarr: applicable to R3xx and R4xx chips as well with some caveats. Where applicable, generational differences are noted.
spstarr: :)
owen__: tlp: there are certainly possibly some easier stuff ... people have been working on fog recently, etc.
hypnotic: hi there, how is ati doing on linux these days?
z3ro: spstarr: iirc agd5f wrote some nice guides on his blog, too, which would be worth reading.
spstarr: he started i thought, but he got busy :)
owen__: tlp: other people (glisse, MostAwesomeDude, etc) would be better at giving specific suggestions
RTFM_FTW: so is ARB_fragment_program fully implemented in the R5xx driver?
z3ro: and I would look at some revenge dumps on r3xx-r5xx hardware... don't try r6xx - revenge does work here, but r6xx is vastly different to previous generations in programming style.
RTFM_FTW: if so, have you guys implemented ARB_fragment_program_shadow yet?
owen__: tlp: Or for jumping in, trawling bugzilla is not a bad place ... bug fixes are often fairly easy
z3ro: RTFM_FTW: I believe all the instructions are implemented for r5xx fp now.
z3ro: but work could still be done on optimization.
RTFM_FTW: ah cool
RTFM_FTW: so how about shadow program support?
z3ro: spstarr: also knowing something about opengl would be helpful, too. I'd say at least enough to know how to draw some triangles with opengl.
spstarr: z3ro: does this guide explain 'what' scissoring is basically explain what render operations (ROP) do?
spstarr: z3ro: that wouldn't be too difficult, since thats a userspace API to do the drawing
z3ro: yeah. having some opengl knowledge is really a prerequisite.
spstarr: now, i haven't used OpenGL before
z3ro: RTFM_FTW: not sure about shadow program. (actually I haven't used this extension before)
spstarr: i know what blit is
z3ro: for learning opengl nehe has some good tutorials: http://nehe.gamedev.net/ and the red/blue books are good too: http://www.opengl.org/documentation/red_book/
spstarr: z3ro: so many acronyms.. head spins... Vec3.. VS... TS MRT..
spstarr: and you wonder why people are scared :)
tlp: you eat an elephant one bite at a time :p
spstarr: hehehehehe
z3ro: exactly. :)
spstarr: it would be nice if we had this on a wiki explaining them
RTFM_FTW: ah well ARB_fragment_program_shadow effectively exposes the functionality in ARB_shadow through ARB_fragment_program (i.e. R => Dt comparison via GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE)
RTFM_FTW: and a relevant (GL_TEXTURE_COMPARE_FUNC) comparison function
RTFM_FTW: so its definitely a handy extension to have
z3ro: just checked, ARB_fragment_program_shadow isn't implemented yet.
spstarr: some terminology in this doc comes from basic computer class
spstarr: LSB (least Significant bit)
spstarr: boggles
spstarr: Surface formats
spstarr: z3ro: the problem reading this is it doesnt go into the very basics
spstarr: it assumes the reader has knowledge of what these things are
z3ro: spstarr: there is always google, and if that doesn't help, you can ask here.
spstarr: thats a lot of questions ;)
spstarr: google yes
z3ro: some of the acronyms might be a bit hard to figure out (eg I'm not sure if google would tell you RBBM = Register Back Bone Manager (or Management))
spstarr: well the initial part is explaining how memory can be represented linear or tiled
spstarr: typically tiled memory is faster to access than linear
RTFM_FTW: correct... when you have a GPU with multiple IMCs
agd5f: benh: feel free to fill in the other tv-out modes :)
spstarr: Interchangeable Master Channels
spstarr: RTFM_FTW: perhaps I should create a wiki on x.org for these terms as i get tothem
RTFM_FTW: no actually "integrated memory controller"
spstarr: beh
RTFM_FTW: and N banks of very high bandwidth DRAM
RTFM_FTW: tiling is all about trading latency for bandwidth
RTFM_FTW: which is what RT CG requires
RTFM_FTW: *real-time computer graphics
spstarr: I figured that one :)
agd5f: spstarr: http://wiki.x.org/wiki/Development/Documentation/HowVideoCardsWork
spstarr: agd5f: how far is that ?
agd5f: tiling is mostly about better cache utilization
owen_: airlied: yes, still some stability issues on R300+agp :-)
spstarr: owen:)
agd5f: spstarr: it's pretty basic
spstarr: agd5f: i noticed
spstarr: there is a commonality to all graphics cards
spstarr: agd5f: if there are books out there, i'd go even look for a torrent to download one
spstarr: i don't mind reading a book if it gives me a background to go from
z3ro: spstarr: you won't find any kind of "Writing GPU drivers" book, but I would recommend reading the opengl bluebook at least.
z3ro: then reading the amd docs
spstarr: goes to url
z3ro: and knowing a bit of 3d math can be helpful, too, although probably not strictly required.
agd5f: the amd r5xx doc is pretty good if I do say so myself ;)
z3ro: yeah, I agree. :)
z3ro: so it's not just agd5f pimping his work. ;)
spstarr: my trig used to be good... years ago
spstarr: i still have my old notes on trig too
agd5f: spstarr: for 3D you'll generally need linear algebra
spstarr: thats ok then
z3ro: spstarr: "Mathematics for 3D Game Programming & Computer Graphics" and "3D Math Primer for Graphics and Game Development" are good starting points.
agd5f: it's a lot of vector stuff
spstarr: z3ro: will look for those, should be able to find those books online (if i can't find them in stores here)
z3ro: yeah, amazon has them.
z3ro: I mean, you probably won't need those books if you just want to fix some bugs in the drivers, or add an extension, but it's good to have a solid background.
z3ro: you will need some opengl knowledge though.
z3ro: at least enough to know about vertices/indices/colors etc.
z3ro: normals
spstarr: so then i should start with the red/blue books from OpenGL
z3ro: yeah, or even just some of the nehe opengl tutorials.
z3ro: then I'd just pick some extension you want to implement, and figure out how to do that.
z3ro: start with figuring out how to use the extension (what it does, etc), then look at fglrx dumps and the docs to figure out how you translate the opengl state (mesa state) into hardware commands.
spstarr: and we are missing some GL extensions :)
spstarr: oh nice tutorials
z3ro: yeah, there are a few... but the tricky thing is don't pick something thats too complex to start with. eg don't decide to do FBO or something.
z3ro: because that requires a memory manager, and thats still kind of in flux at this point... though I think it's getting there now. :)
spstarr: the red/blue books are online too
spstarr: just bookmarked both
z3ro: GL_EXT_rescale_normal might be a good extension to start on... it would probably be quite simple (eg just flipping a bit on some register)
z3ro: but it will show you how to figure out which register, and which bit (look at dumps and docs) and how to look it up into the driver.
spstarr: so a GL extension is a 'render' operation for GL?
z3ro: hmm actually I'm not sure whether the older hardware could support that extension.. I'm looking at the extension list on fglrx on r6xx, so ymmv...
z3ro: nope, basically a gl extension adds some new feature to the base GL spec.
spstarr: ok
spstarr: I know that when you have z, the object is 3D
hypnotic: hi there, anyone experience with the 4850 on linux?
z3ro: hypnotic: you won't get 3d with the open source drivers, but it should work with radeon or radeonhd.
spstarr: heh
spstarr: "fragment is drawn into the appropriate buffer, where it has finally advanced to be a pixel and achieved its final resting place."
hypnotic: you mean prop drivers?
hypnotic: sorry never used ati, only nvidia
z3ro: radeon/radeonhd are open source drivers, and fglrx is amd's proprietary driver.
z3ro: you can get 3d with fglrx
z3ro: but not (yet) with radeon/radeonhd.
hypnotic: i know 2d rendering on nvidia is not the best, but how is on ati?
hypnotic: aha ok
hypnotic: open source drivers are promising but i am wondering how fglrx are doing compared to nvidia
spstarr: z3ro: something doesnt make sense to me, isn't textures themselves pixels? the image the texture represents is pixels
hypnotic: i dont mind fps in 3d, 2d, (hd) video and compiz are most important
z3ro: well, technically a sample from a texture is a texel, but I guess you can think of it as a pixel.
z3ro: you can also think of a fragment as a pixel on the screen, but again, this isn't technically correct because of aspect ratios etc.
hypnotic: i read 4850 now uses xv for video under linux
z3ro: so a single fragment might actually map to more than one pixel.
z3ro: hypnotic: I don't have any idea comparing fglrx to nvidia's driver.
hypnotic: ok i have to read some reviews then
hypnotic: want to order a new card tomorrow and am really hesitating between ati and nvidia at the moment
hypnotic: half year ago choice was easy
hypnotic: thanx for the insight, i am gonna read some more tomorrow
hypnotic: bye bye
z3ro: bye
spstarr: hmm
spstarr: so a fragment stores (x,y and z planes)?
spstarr: its a pixel but with a z plane
z3ro: iirc there is an explanation of fragments somewhere in the begining of the blue book.
z3ro: probably in the section explaining the opengl pipeline.
spstarr: I notice GL requires you to set a program then end the operation
spstarr: glBegin() glEnd()
spstarr: like a stack
RTFM_FTW: in the immediate mode case yes
spstarr: oh a fragment stores more
z3ro: yep. you can also use vertex/index arrays.
spstarr: but what is a stipple
spstarr: googles
spstarr: so its like a dithering
spstarr: but its more
rmh3093: god this memory leak is horrid