StR|Sangreal: hello
StR|Sangreal: pls i need help with configuration of my video card
StR|Sangreal: i have my kubuntu intrepid amd64 installed on defaults, i dont get proper acceleration and cant play video
StR|Sangreal: my video card is ATI radeon mobility x1450
StR|Sangreal: and my cpu architecture is centrino duo (asus notebook)
hifi: what does glxinfo say about direct rendering
chithead: and are you running a 2.6.28 kernel?
StR|Sangreal: http://pastie.org/383126
StR|Sangreal: glxinfo output
StR|Sangreal: and i run latest updates hence i think the kernel is the latest stable
hifi: so yes, you have direct rendering enabled
hifi: whats the problem?
StR|Sangreal: all the desktop flitters, some window freeze on launch, i cannot play video
StR|Sangreal: and generally the performance is much much worse than with fglrx driver
chithead: StR|Sangreal: check for video acceleration using "xvinfo" also be aware that desktop effects may not work properly with the drivers in kubuntu 8.10
StR|Sangreal: (although i know that catalyst driver isnt the proper solution since it cannot accelerate my card by definition, only with some universal acceleration, and it doesnt support xorg 1.5... :-/ )
chithead: ubuntu 8.10 shipped some prerelease special edition fglrx which works with x server 1.5
hifi: StR|Sangreal: bottomline is, you have acceleration but it's not as fast and feature rich fglrx can be
adamk: And newer versions of fglrx support 1.5.* as well.
StR|Sangreal: well installing fglrx didnt solve my video problem and disabled me from solving it in a different way
StR|Sangreal: (although the system performance improved significantly)
StR|Sangreal: so now i have my sys on defaults and hoping that sb helps me to configure radeon driver
StR|Sangreal: i have just installed, updated from officially supported repositories and upgraded (and added some user sw)
hifi: why you can't play video?
hifi: any error messages
StR|Sangreal: no, it simply closes (in vlc) or plays only sound (mplayer) or only sound and subtitles (kaffeine)
hifi: mplayer -vo xv
hifi: you should see at least some warnings/errors on console
hifi: and you could try the radeon driver 6.10.0 backport for intrepid
StR|Sangreal: http://pastie.org/383141
StR|Sangreal: mplayer output
adamk: Sounds like you are using XAA.
adamk: Make sure you add this line to the Device section of your xorg.conf file:
adamk: Option "AccelMethod" "EXA"
StR|Sangreal: well i dont have any such line in my xorg
StR|Sangreal: i need to extend my brief xorg.conf given by default, but i cant do it
StR|Sangreal: i will paste you my xorg log and my xorg file
StR|Sangreal: Section "Device"
StR|Sangreal: Identifier "Configured Video Device"
StR|Sangreal: EndSection
StR|Sangreal: Section "Monitor"
StR|Sangreal: Identifier "Configured Monitor"
StR|Sangreal: EndSection
StR|Sangreal: Section "Screen"
StR|Sangreal: Identifier "Default Screen"
StR|Sangreal: Monitor "Configured Monitor"
StR|Sangreal: Device "Configured Video Device"
StR|Sangreal: EndSection
chithead: StR|Sangreal: stop it, use a pastebin
StR|Sangreal: thats all relevant in my xorg file
adamk: StR|Sangreal, In the future, use a service like http://pastebin.com/
adamk: You have a Device section.
adamk: So add the line.
StR|Sangreal: if you were so kind to provide me with a new config file.... :-$
adamk: You shouldn't need a new config file.
adamk: The one you have is apparently fine. Just add that one line.
adamk: Then restart X and see if mplayer works.
StR|Sangreal: well my config actually doesnt state anything
adamk: Again, it's fine.,
adamk: Xorg autodetects nearly everything these days.
adamk: Just add that one line to the Device section.
StR|Sangreal: well however my log file is full of errors :/
adamk: Listen to what I am saying... Xorg is working just fine for you.
adamk: You have 2D and 3D acceleration.
adamk: You are not using EXA, and that is causing the problem you are seeing.
adamk: So switch to EXA and be happy.'
StR|Sangreal: ok i will try thanks
StR|Sangreal: ok i try to reboot
StR|Sangreal: in case it disables my compiz?
adamk: There is really no need to reboot.
adamk: Just restart X.
StR|Sangreal: ok
StR|Sangreal: well it did solve many of my problems :)
StR|Sangreal: the flickering remains, but isnt as markable as before
StR|Sangreal: and video works now :)
adamk: flickering when playing videos?
StR|Sangreal: no, its more a desktop issue
StR|Sangreal: any new opened window flickers some while
deelnemer: anyone else has trouble using external display like beamer with radeon 9000?
StR|Sangreal: but i think i am satisfied with the current state :) thanks for help
adamk: StR|Sangreal, Glad to be of assistance.
chithead: deelnemer: works great with radeon x700 mobility
deelnemer: ok, so its just that my resources are limited? i also run compiz at the same time...
chithead: compiz does not have to do anything with it
deelnemer: im trying to host this workshop but i can only run the external display at 800 x 600 max
chithead: "xrandr" should list available video modes for the VGA output
deelnemer: thanks, ill have a look see
chithead: it could also be that the external display does not report edid data properly
deelnemer: i wouldnt know about that
deelnemer: its a mitshubishi projector running at 75hz
deelnemer: still the support for the ati card in my thinkpad is superb on intrepid
chithead: well connect some other display. you could also try xrandr --addmode VGA-0 1024x768 or similar
deelnemer: ill try, normally when i do that with the display options it crashes
deelnemer: but also when i stress the video output too much i get jagged lines across my screen, card could just be old or something
deelnemer: thanks for the tips chithead xrandr works perfectly, i just ran xrandr --output VGA-0 --mode 1024x768 and im all set up
nha: hmm, I seem to have a problem with kernel modesetting; I'm using the drm-rawhide branch from airlied's kernel repository
nha: The bug is this: After booting, X initially gets the correct screen resolution of 1280x1024; however, when I restart X it configures 1024x768 after the restart, and xrandr displays that as the largest possible resolution for this output
nha: hmm, curiously, the Xorg.0.log says something about 1280x1024
nha: http://pastebin.com/d1ca06270
nha: I forgot: xf86-video-ati is from the radeon-gem-cs2 branch
nha: Is it normal that both the DRI2 and the XFree86-DRI extensions would be present?
nha: Somehow, both of these extensions are present on the first start of the X server, which confuses glxinfo into picking a software rasterizer
nha: On subsequent starts of the xserver, only the DRI2 extension is present, which causes glxinfo to do the right thing apparently, except that now all GL apps I've tried so far fail with a message like
nha: GLUT: Fatal Error in shadowtex: visual with necessary capabilities not found.
nha: glxinfo reports only one GLX visual and 16 GLXFBConfigs
osiris_: nha: it's because of recent glx visuals rewrite
osiris_: nha: revert 5100d829a4d71ce4a9fbc2b81694a1fb90066ccf from xserver and it should work
osiris_: nha: I got shadowtex almost working, first frame is not correct, changing light position fixes it (also it works when started under valgrind)
nha: osiris_: in what context? shadowtex used to work just fine
nha: I'll try that revert later
osiris_: nha: yeah, sorry. tri-depth* didn't work earlier
osiris_: (at least not on non hw tcl)
osiris_: nha: what are you planning to work on?
nha: nothing yet
nha: I want to get up to speed with kms + mm
nha: then, if I find the time, I want to help fix 3D bugs in that area
nha: it's really ridiculous how long it's taking us to get that stuff into the respective mainlines
osiris_: we just need more devs to get involved
nha: yay, I'm getting a visual now - and also a lookup :}
nha: fun, fun
nha: at least it's a 100% reproducible insta-lookup
ossman: agd5f, ping
Kollapse: Hi. I have a problem with wine and radeon. It's reporting that my video card or driver doesn't support a certain vertex or technology. This doesn'
Kollapse: this doesn't happen in fglrx
Kollapse: Any hints ?
nha: the open source driver doesn't support all the opengl features that fglrx supports
Kollapse: well with fglrx I get spikey mysterious models that shouldn't exist and 1-2 fps
Kollapse: and the guys over at #winehq recommended radeon/radeonhd
Kollapse: the thing it's asking about is UBYTE4N
nha: huh
nha: that's quite cryptic
nha: it might refer to some vertex array format
Kollapse: it's an error message that occurs with both radeon and radeonhd when running call of duty 4
nha: but in general, if native OpenGL apps work for you and you get such an error message, there's probably nothing you can do about it (unless you're able to implement such a feature yourself, that is)
nha: because then it just means that this particular feature just isn't supported by our gl driver
nha: ... and given our lack of developer manpower, it's unlikely that it's just going to be supported over night, I'm afraid
Kollapse: it happens with both radeon and radeonhd
nha: they use the same gl driver
Kollapse: Should I try to install the git versions of libdrm / mesa ?
nha: you could try, sure, but no promises
nha: which version of Mesa are you using?
nha: (it's part of the output of glxinfo)
Kollapse: mesa-7.3
Kollapse: Mesa DRI R300 20060815 TCL
nha: then I believe it's unlikely that installing something from git helps, since there haven't been so many changes in terms of new features since then
nha: (and the date of 2006 is completely misleading, btw)
Kollapse: argh! well I will not go back to fglrcrap
Kollapse: I also have a problem with Radeon and Composite/Compiz I have flickering horizontal lines on the right of the screen when moving wobbly windows
Kollapse: also happens with the cube
nha: hmm, difficult to tell what this might be
nha: I remember some problem in KDE 4 which was caused by incorrect clip calculation; the fix involved both a change to the kernel module and to Mesa, but I don't remember which respective versions have that fix
nha: but it could just as well be tearing caused by a lack of vsync, or something else
Pyru: Hello, do you provide Windows support for ati radeon cards here at all?
yangman: Pyru: no
Pyru: Do you happen to know where I can get some support, google is coming up with nothing =(
yangman: I don't unfortunately
Pyru: ok, thanks anyways.
bridgman: Pryu; driverheaven and rage3d forums are probably best for Windows support; that's where the Windows guys hang out
agd5f: ossman: I don't know how the filter4 regs are supposed to programmed either
bridgman: ossman; guess we're going to have to talk to the hardware guys on Monday
spstarr: hey bridgman
bridgman: hi spstarr
spstarr: I found my dishes!
spstarr: those Aspen / maple shaped dishes
bridgman: neat
spstarr: i bought $250 dollars worth but im missing 10 more bowls i'll buy this week (i bought so much i ended up selling them out on some of them until they get new shipments)
spstarr: :)
assumedalive: hello
spstarr: they are resistant to high temperatures so since my family had them for 10+ years never one broke due to heat
spstarr: i wanted a set for myself in my new place
assumedalive: im wondering if vsynced xvideo is supported when compiz is enabled in the radeon driver
bridgman: don't think vsync works in compiz, and compiz does it's drawing *after* Xv so that would muck up the syncing again
assumedalive: bridgman: so at least in the near future its actually impossible?
bridgman: AFAIK impossible in the sense that there is no combination of options that work with the currently shipping code (disclaimer; this is what I have heard, I haven't spent time with it myself)
assumedalive: is it a fundamental architectural problem?
assumedalive: with xv and compiz?
bridgman: I think so, but even so it's not a big one; if the compositor is doing sync-to-vblank it needs a way to "push back" on Xv and I don't *think* that exists right now
bridgman: you need the ability to occasionally double-up or skip frames since the video frame rate won't exactly match the display frame rate, even if they're both nominally 60 Hz
assumedalive: is that how vista and osx do it?
bridgman: AFAIK, yes
assumedalive: i take it this problem isn't very high on the priority list at the moment then
bridgman: I don't think it's going to be a big deal to solve, it's just that there are still some "foundation" tasks that need to be finished first
assumedalive: does opengl have the same problem
bridgman: OpenGL through Compiz yes, OpenGL without compiz no
bridgman: the problem just that while you have five compositors, three video acceleration paths, and fourteen players it's not so easy for the Grand Unifying Vision to surface
assumedalive: lol i understand, im not criticising or anything
bridgman: the good news is that there is some consolidation happening
assumedalive: it just surprises me that something as fundamental as properly working video is still broken when compiz is used
assumedalive: maybe not many people notice tearing?
airlied: assumedalive: you assume its fundamental
airlied: fundamental does not imply easy to fix
assumedalive: i meant important really, not fundamental
assumedalive: and i didn't come here to complain or anything, im just curious about the graphical architecture on linux generally
bridgman: airlied; is video-through-compositor within the scope of the plumbers conferences ?
airlied: bridgman: its more X hackers.
airlied: there has been a few discussions on it, most involve making compiz vsynced, and some magic for when it pulls offscreen
King_InuYasha: assumedalive, i get tearing in compiz even on normal desktop usage
assumedalive: King_InuYasha: can be fixed sometimes by enabling sync to vblank in the compiz options, i get the feeling that this is a bit of a hack though because it doesn't _quite_ work properly, sometimes there is some small tearing near the top of the screen
King_InuYasha: in fact, on the top left corner of the desktop, the screen flickers and tears a rather noticeble blue square that later causes the whole desktop to shift
assumedalive: also it fails completely for multiple monitors (on nvidia at least, no idea how the open source drivers handle vsync with multiple monitors)
King_InuYasha: its annoying and i was forced to lower the brightness of my monitor to make it more usable
King_InuYasha: i cant turn off compositing because of avant window navigator
King_InuYasha: and Kwin is totally useless because it doesnt work right outside or sometimes in KDE
King_InuYasha: it makes me wonder and hope that the gnome guys will eventually make a full featured compositor for metacity
assumedalive: King_InuYasha: what's the point, compiz works fine
assumedalive: i still dont understand why the kde guys even felt the need for kwin
King_InuYasha: no it doesnt
King_InuYasha: Wine is slow, video is slow, glx is hampered, and 3D gaming is terrible with it
King_InuYasha: with the few times i got to use kwin properly, it fixes most of these issues
King_InuYasha: the fact is, compiz is really a reference and technology preview platform
King_InuYasha: it was really designed to work with Xgl, not AIGLX
King_InuYasha: and with Xgl being phased out (finally), compiz really needs to get in the game or somebody needs to completely redo compiz from scratch, focusing on getting things to work right
assumedalive: from what i understand, aiglx is a bit of a hack that's only necessary because up until recently the open source drivers didnt have a memory manager and so couldnt redirect direct rendered windows properly
bridgman: sure, but that's what RDR is for
King_InuYasha: we have PLENTY of features in compiz, we just need the stability to go with it
bridgman: gives the collaboration-with-X advantages of AIGLX with the speed of direct rendering
King_InuYasha: assumedalive, aiglx is the mesa of compositing
assumedalive: dude, compiz is mostly there, i think a lot of what needs to be done is more on the driver side
King_InuYasha: snorts
assumedalive: i hate to say it in the #radeon channel but you should try it with an nvidia card
King_InuYasha: i have
King_InuYasha: its just as bad on there
King_InuYasha: it has nothing to do with the drivers
King_InuYasha: the drivers have long since been brought up to speed for use with compiz
King_InuYasha: that is what caused this graphics driver boom anyways
kcodyjr: fact is nobody's managed to give me a good reason to run compiz or anything remotely like it, except me-too'ism with mac and vista
assumedalive: kcodyjr: it's a technically better solution, get the graphics rendering out onto the graphics card where it belongs
assumedalive: its just not as easy to implement
King_InuYasha: i like using compositing
King_InuYasha: but i would definitely suggest using kwin as your window manager if you want to
kcodyjr: if you're talking about compositing algorithms in general, yes, good
kcodyjr: if you're talking about spinning cubes and transparent terminal windows, no, bull
King_InuYasha: well, thats not the reason i use it
assumedalive: kcodyjr: good job nobody's forcing you to use it then isnt it ;-)
King_InuYasha: the reason i use it because i have applications and desktop enhancements that require compositing
kcodyjr: yes, quite ;)
King_InuYasha: Awn, among other things
King_InuYasha: while it is true that awn is a dock that looks similar to mac os x's dock
assumedalive: King_InuYasha: if you have a problem with compiz that is driver independent, maybe you should report the bug to the compiz developers?
King_InuYasha: it was already reported
King_InuYasha: the dock is much more in tune with my style of working than having double panels or a single panel for the stuff
King_InuYasha: in my opinion, panels suck
King_InuYasha: i like docks much more because they are more managable and more distinct
King_InuYasha: and i managed to free up a good portion of desktop space too :D
kcodyjr: everyone has different tastes, really
kcodyjr: docks annoy me much less when i can configure them not to visibly bounce up and down when i click on them, for instance
kcodyjr: panels work for me because of the low visual impact on change, nothing to do with rendering crunch required, i just don't like stuff blinking and bouncing
King_InuYasha: its the opposite for me
King_InuYasha: because of my glasses, it is hard to see small objects and the static style of panels makes it far less noticable
kcodyjr: different strokes for different folks, right? same reason that i see compositing's value much more for scrolling windows and such than visual effects
kcodyjr: whereas my visual acuity is at its best at monitor distance ;)
kcodyjr: if you see me in my car, get the hell off the sidewalk ;)
kcodyjr: hey if everybody reckoned desktops the same, we wouldn't have so many projects
King_InuYasha: kcodyjr, which im very thankful that nobody does
airlied: osiris_: patch on r500 bad things happen, only get single triangles for the fog tests and running redbook/fog hangs it
kcodyjr: ok. airlied, agd5f, as expected i've got radeonhd r6xx branch, starting up against the merged kernel, failing on CP_INIT and successfully falling back to unaccelerated
kcodyjr: however, i tried turning on shadowfb, and it managed to crash the -monitor-...
kcodyjr: and yes i know how that sounds but there's no doubt about it; backlight went dark, the lighted Westinghouse logo turned itself on (normally off via onscreen config), and X reported no screen attached. No response on its power button, had to yank the cord. very odd.
airlied: kcodyjr: you are running a kms kernel with a non-kms userspace/
airlied: its not expected to do anything but fail horribly
kcodyjr: at the moment, yes, just to ensure that it fails gracefully
airlied: it can't fail gracefully
kcodyjr: i understand the expected to fail part ;)
kcodyjr: actually at the moment it is, except for the shadowfb thing
kcodyjr: dri init bails sanely
airlied: you can probably make it fail gracefully, but since we have lots of deployed broken userspaces only a time machine can save most people
airlied: you could just put a KMS check in the startup of the driver, and fail if KMS is enabled
kcodyjr: i don't think that's necessary, but perhaps refusing to even attempt any acceleration is a good idea
airlied: the other option we've kicked around is banning mmaps to the device memory.
airlied: kcodyjr: you cna't let userspace set a mode
airlied: or do any card init
airlied: it trashes all the kernel state with direct hw access
kcodyjr: hmm.
kcodyjr: then why am i not getting the kinds of horrible failures that's expected, that's almost as concerning
kcodyjr: kill X, and the fbcon comes back, apparently quite intact
airlied: its called luck
airlied: it happens mostly that userspace will set the card up similiar to how the kernel does in any case
airlied: and when X dies fbcon will try and reset the mode
airlied: however a lot of other stuff could be gone horribly wrong
kcodyjr: hmm. then it does sound like the radeonhd driver wants to refuse startup if it detects kms... kinda goes against the grain
kcodyjr: are we looking at entirely separate trees for all kms ddx'es then?
airlied: no
airlied: the radeon code detects at startup and either uses kms or doesn't
MostAwesomeDude: kcodyjr: Not necessarily.
kcodyjr: this is where having both radeon and radeonhd makes me wanna go cliffjumping without a parachute.
MostAwesomeDude: Ah, airlied is a faster typist than I.
airlied: you might be better off trying to use radeon instead of radeonhd
airlied: alex merged it already
airlied: the r6xx stuff
kcodyjr: watches stars and somehow-still-live- sushi swim through the saline coating my eyes, trying to figure out WTF to make of the two separate driver trees
kcodyjr: at this point, what's in radeonhd that isn't in radeon
airlied: nothing you'd want I'd expect
kcodyjr: really. i won't flame, promise. i don't give a tinker's damn about whatever politics resulted in the split, i just wanna know what think space i ought to be in.
airlied: if you are interested in kms then radeonhd isn't the place to be
airlied: you'd need to merge Alex's radeon r6xx work into my kms tree also
kcodyjr: if you recall, my interest in kms began as a way to avoid dealing with modesetting in my own project (its off-the-wall status notwithstanding) and that still seems like a good idea in general
airlied: as its just been done in paralllel
airlied: kms is the future, just some people liked the 80s a lot
kcodyjr: hey, i liked the 80's ;)
kcodyjr: parts of it anyway.
airlied: well actually I think it was probably the early 90s :)
kcodyjr: yeah back in the 80's i was still writing line numbered basic on my commie
MostAwesomeDude: kcodyjr: In all seriousness, the only thing in rhd but not here is the HDMI audio support for r6xx+.
MostAwesomeDude: (And some legacy modesetting stuff that nobody uses or cares about.)
kcodyjr: and occasionally trying to play a cheesy video game short-circuiting the leads on a pigtail joystick cable because it was more responsive than the damn joystick it came attached to...
kcodyjr: legacy modesetting as in what, pre-randr?
airlied: its not legacy as much as it doesn't use atombios, but since we haven't had major failings using atombios we didn't see the point
airlied: HDMI audio is much nicer when everyone lives in the kernel
kcodyjr: and i couldn't care less about the open source puritan view either
kcodyjr: oh agree, considering the alsa driver needs to know what's at the other end of the hdmi cable
MostAwesomeDude: kcodyjr: "Legacy" here means "non-ATOM", which is rather silly since rhd only covers ATOM cards.
MostAwesomeDude: airlied: Agreed, the HDMI stuff should be in-kernel just like (ideally) the TV hookups, but that's way off in wishlist-land.
kcodyjr: i don't see why the tv hookups couldn't be treated as ordinary but mode-limited outputs... what's so special about them?
MostAwesomeDude: kcodyjr: They can't be reached (easily) without DRM loaded, so DRM and V4L have to work in concert to expose them.
airlied: kcodyjr: tv capture
kcodyjr: afaik this particular 2400 has tv outs, but no in's
kcodyjr: i gave up on the aiw's awhile ago. telling me they're finally becoming viable? ;)
kcodyjr: i think i've still got an r100 aiw agp around, if it hasn't succumbed to esd by now
MostAwesomeDude: kcodyjr: The AIWs actually all use stock chipsets, if you can believe it.
MostAwesomeDude: The problem is only in getting V4L to be able to see/talk to the chips.
kcodyjr: i can believe it. same crap intel pulled with HT, just frying out one important link to disable the feature... or simply not connecting anything to those leads on the chip
kcodyjr: and the other problem is not actually having any inputs on the back of the card ;)
kcodyjr: i did play with the gatos code back then
MostAwesomeDude: Gatos code is still around, although non-functioning, and we should have all the docs and code needed.
kcodyjr: actually it would be nice to have one of the frontends using an aiw; it would make an external game console practical...
MostAwesomeDude: It's just a matter of manpower and interest, I think.
kcodyjr: the aiw design, versus a separate output and input card, is simply latency, but we're talking orders of magnitude...
kcodyjr: even with a hardware mpeg encoder in the same box, the best i was able to get with the discrete configuration was about 3s delay from cable box to monitor
kcodyjr: is amd/ati still making aiw's with the new chipsets?
kcodyjr: one claim that might spark interest in some: an aiw can view and record simultaneously in one pass, and can support an xbox slaved to the pc ;)
kcodyjr: airlied, i dunno if your kernel is doing something right or if that little trip to la-la-land did something to the monitor, but the backlight is being powered down properly
kcodyjr: and i'll be giving radeon a try shortly; i don't recall rebuilding git without curl but it seems i did. are there any other good kms userspaces i should be testing with?
MostAwesomeDude: kcodyjr: Have fun with AIW. I do own one from the X1950 package, but I'm not interested in experimenting; you're on your own. :3
kcodyjr: MostAwesomeDude, the plate is quite full already.
kcodyjr: i'm much more concerned with framebuffer output to component video; there's about a 1/3 chance i'll be getting a top end sony wega xbr whizbang whatsit television in about 4 months ;)
MostAwesomeDude: Cool.
kcodyjr: hand-me-down; actually i'm anticipating my fiance will wheedle it out of her parents when we move in together
kcodyjr: she's good at wheedling. ;)
airlied: kcodyjr: there is a generic kms xorg driver also, but it has no accel without gallium
airlied: even with Alex r6xx code we still need to port it to the new CS codebase and bufmgr stuff
kcodyjr: short version i'm looking at a really big pile of donkey dung before i even see exa
kcodyjr: and if i wanted to attempt that abstraction i've been talking about, maybe it makes more sense to start with the video-modesetting driver, as a more representative skeleton...
kcodyjr: otoh there's sense in just applying my free time wherever you say for the time being
airlied: have a look at seeing if the unaccecl one works, you could do gallium on r600 once someone fills in the rest of the EXA state tracker :)
oga: hasn't gallium changes quite a lot since that was written, anyway?
airlied: oga: I think they've been keeping stuff up to date, at least Dr_Jakob mentioned something
oga: ah. I recalled xf86-vide-modesetting having the exa statetracker built in. I've not seen any commits on xorg-commit.
oga: Can't clai'm i've checked the git repo though.
oga: perhaps my memory's got ass-backwards though.
kcodyjr: now that -really- seems twitchy to me. although i disagree, it's arguably ok to plan on all near-future cards being 100% shaderful, but quite another to say that all non-shaderful cards aren't even going to get 2d...
kcodyjr: it's tantamount to declaring that thou shalt throw out anything older than r299
kcodyjr: unless the video-modesetting driver is really meant more as a sandbox than as the beginnings of a production driver?
MostAwesomeDude: airlied: Would 2D Gallium r300 use the 2D HW just like current EXA, or should it use 3D only?
oga: kcodyjr: IMHO the xf86-video-modesetting idrea was a good one.
oga: it does not stop you having different code written for older chips, but it means that for newer ones all you need write is drm and the gallium driver.
airlied: MostAwesomeDude: I'm not sure what the plan is I would guess it would want to use the 3D hw
airlied: unless they add blit ops to TGSI
oga: marcheu claims that with llvm you could probably do fixed function on gallium too.
kcodyjr: oga, having a bunch of conditionals all over the place will drag performance down in all cases; if pure shader cards want to fly then they don't want the ddx pausing every 20 lines to consider way older cards... would negate whatever performance gain r300 might get from having gone shaderful
kcodyjr: suggests that video-modesetting can become a good common driver for newer cards, but merely a template for kms for older cards
oga: kcodyjr: I means using a modesetting + gallium on shader cards. Other ones can use a "legacy" ddx that does things the right way for them.
airlied: its useful for bringing up new devices, its not going to ever replace current ones
kcodyjr: are they still shipping servers with mach64's? or have they finally got with the times?
airlied: things like Xv sorta mess it up.
airlied: kcodyjr: I think you can still get em, mostly RN50s now though
kcodyjr: RN50 is what, a rage128?
airlied: kcodyjr: rv100 cut-down, no verified 3D
terracon: I think some of those tyan boards had mach64's on them. Not sure of the current models
terracon: let's check tyan's site
kcodyjr: a server kinda will expect good 2d performance, especially if some trained monkey is running it via local gui
kcodyjr: so is the approach with those to skip kms, or to integrate kms into the existing older-chip ddx's?
kcodyjr: thankfully it doesn't have to be my problem, i'm just curious what the roadmap is
terracon: hmm "Integrated video , XGI"
terracon: XGI z9s /w 32m mem!
airlied: kcodyjr: kms in the DDX if someone spends the time
airlied: most server people don't expect fast 2D they expect that refreshing the screen won't shit on the memory bus
MostAwesomeDude: airlied: Just wondering if maybe pursuing 2D would be easier right now. As it is, there's a lot of work left, and it's the tough things. Shaders and vert emit.
airlied: and they want that as cheap as possible
kcodyjr: heh that too, it doesn't have to scream, it just has to be responsive when the cpu is under load
airlied: MostAwesomeDude: I wants my gallium!
airlied: like the latest matrox server chips have 2MB of RAM
kcodyjr: matrox hasn't impressed me since the millennium 2 pci
airlied: they just don't want IGPs.
kcodyjr: and they don't want the cpu to have to do a crapload of memcpy's either
kcodyjr: and often they need to deal with reading long pdf's, but noone's real surprised when the server doesn't like that and they have to walk back and forth to their desks. creates an excuse to screw off talking on the way back and forth, too. ;)
airlied: they don't care what the CPU does when someone is maintaining it.
airlied: its a lot more about what is happening when its running steady state.
airlied: they don't want GPU stealing valuable bandwidth randomly from scsi or sata.
airlied: hence 2MB of VRAM is just enough to scanout something.
airlied: and why we get shit like G200SE, X9s and RN50s
kcodyjr: if it can't drill a pisshole in the snow, it can't hose the bus either
airlied: again nothing to do with speed all to do with not scanning out from main RAM and cheap as possible
airlied: I forgot to mention cheap was the second biggest factor in server chipsets
airlied: don't scanout from main memory + really really cheap
kcodyjr: right
terracon: I think I'm catching on , Cheap. got it
kcodyjr: so, a minimum gpu with discrete vram, preferably carved of wood, but plaster of paris is acceptably cheap as well ;)
airlied: kcodyjr: pretty much.
kcodyjr: fair nuff
kcodyjr: look i don't want you guys thinking i think gallium is any less than way cool
kcodyjr: i'm just not sold on its universality because i never believe vendors when they say this-is-the-way
airlied: nobdy said its universal, they said it covers cards with shader
kcodyjr: true. people are saying 100% shader driven cards are what's going to be universal
kcodyjr: which leads them to the conclusion that purely gallium based drivers are a good way to futureproof
kcodyjr: at least that's how it seems to me
airlied: no a purely gallium based driver for shader driver cards is a good idea, a better idea than any other current idea
airlied: so its worth doing
kcodyjr: for a card that's purely shader based i would not argue that
kcodyjr: for a card that's half and half, i want to see empirical tests, so yeah we have to write it first
kcodyjr: for a family of chips that's some 100%, some mixed, some non-shader... i suppose you have to make an arbitrary split somewhere
airlied: kcodyjr: or do what we do now. and just have a GL driver and a fixed function driver for the other bits
kcodyjr: i dunno. i just foresee it turning into a big mash of ddx stew over time, and the damn things are hard enough to grok already. not that i have any other provable ideas, just unproven ones.
airlied: why would you need more DDXes?
airlied: or just that they would get more complex?
kcodyjr: they'd get ever more complex, yes
kcodyjr: my instinct - and i've tried to fight it in the name of going along with the plans, but the thought keeps nagging - is that specific effort is deserved on reining in the insanity of how many decisions ddx's make and when they make them
MostAwesomeDude: kcodyjr: Gotta be honest here; having xf86-video-modesetting + Gallium sounds nice.
kcodyjr: MostAwesomeDude, indeed it does
kcodyjr: on my r600 it sounds ideal
kcodyjr: optimal even
kcodyjr: on my r300 i wanna play around, try different combinations of assigning parts of the work here and there, see what the hardware can -really- do when optimized for a particular usage pattern or set of usage patterns
kcodyjr: and the principle sort of applies on the r600 as well, but limited to what work should be done on the cpu and what on the gpu, which is a much smaller question of course