Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-6-09

Search This Log:


agd5f: ssieb: if you are having connector problems file a bug
DanaG: hmm:
DanaG: Failed to initialize radeon; disabling IOCTL
embraceunity: Ok, here is what my kernel panic says after downloading the KMS-Radeon repo for Kubuntu Karmic
embraceunity: http://ubuntuforums.org/showpost.php?p=7425498&postcount=14
cheetopet: glisse: in drm-next-merge branch, if you set CONFIG_DRM_RADEON=y it won't compile
dmb: is there a way to set what resolution kms starts at?
hgb: has a very shaky radeon setup with Fedora 11
hgb: I have two monitors, and when I switched them around, not even having started X, the box froze.
hgb: If I exit X (either killing the server or C-M-F[16]), it freezes.
hgb: And I have a two screen setup (:0.0, :0.1), where I can go from the left screen (:0.0) to the right, but not back.
ssieb: agd5f: I already filed it: https://bugzilla.redhat.com/show_bug.cgi?id=493243
hgb: When the box freezes, there's nothing in the logs.
hgb: airlied: Are you by any chance here today?
hgb: Should 'driver' be "radeon" or "ati"?
MostAwesomeDude: Whichever. ati will autoload radeon.
hgb: Is there much difference between radeon and randeonhd?
MostAwesomeDude: Not anymore, no.
mjr: ati will refer to radeon when applicable
hgb: I suppose dual-head with two screens is not very well tested...
TCW: hgb, used here
hgb: TCW: I can't get it to work. I can only move from screen 0 to screen 1 (the cursor), not back, and when I exit X, the box freezes.
TCW: hgb, what chip?
hgb: TCW: RV730 PRO [Radeon HD 4650]
hgb: TCW: http://pastebin.com/m516e4188 <- xorg.conf
TCW: hgb, too new to be supported well at all
glisse: airlied: it goes into stagin driver
TCW: hgb, at least imho, I am not a dev
glisse: cheetopet: kms is a staging driver
glisse: airlied: i will memtest my agp box
TCW: hgb, try "radeonhd" as driver in xorg.conf, maybe it has better rv7xx support
TCW: just a guess
hgb: TCW: I'll do that. Cheers.
hgb: Round-trip time is long, though. I need to reboot for each attempt, as the box crashes.
hgb: crashes/freezes
TCW: hgb, is it a complete freeze or does just X hang?
hgb: TCW: Not entirely certain. Yesterday, I couldn't even ping it, but today I haven'
hgb: t had another box to test from.
hgb: It seems like a complete freeze, actually.
TCW: hgb, ok, no ping reply means most certainly... completeley frozen :)
TCW: -e
hgb: reboots again
glisse: airlied: still as i got no problem when in pci mode i don't think it's memory
glisse: maybe agp driver
glisse: it's a sis
glisse: bridge
glisse: MostAwesomeDude: please don't split const btw immediate/and const
yangman: hgb: any particular reason to have multi-screen dualhead insteand of RandR?
glisse: MostAwesomeDude: it sounds like adding an artificial limitation
hgb: TCW: It certainly hangs. I typed reboot from an xterm, and it never rebooted.
hgb: yangman: I haven't really tried xrandr a lot, but I was under the impression you only got one (large) screen, and that fvwm would place windows between the monitors, etc. I don't like that
hgb: yangman: But perhaps that's not the case?
yangman: hgb: randr is the recommended method. it's really up to the window manager to act sanely in regards to display boundaries
MostAwesomeDude: glisse: What should I do instead?
MostAwesomeDude: I'm very open to suggestions.
hgb: yangman: I'll give it a shot.
MostAwesomeDude: (Mostly because my efforts to hack up the const/imm split haven't worked so far.)
hgb: tries with only one (X) screen now.
hgb: At least that works nicely.
hgb: That was the radeonhd driver, though...
yangman: hgb: http://wiki.debian.org/XStrikeForce/HowToRandR12
hgb: yangman: It doesn't work all that well with my regular methods. I like to have separate virtual desktops on each monitor, for example.
glisse: MostAwesomeDude: just allocate from the same stack
hgb: My right monitor normally has gnus, irc, a browser for the automatic testing system, etc.
hgb: While my left has xterms, emacsen, galeon
hgb: This seems to be hard with xrandr
TCW: .oO( Browsers, mail on one the left, irc, xterms on the right display here... works nice )
hgb: TCW: But you had two proper screens, right?
TCW: hgb, proper?
hgb: TCW: As in screens in xorg.conf, not xrandr
MostAwesomeDude: glisse: But constants are separate from the shaders.
glisse: MostAwesomeDude: i don't see a problem here, you have to record where const endup beside it could be very easy, allocate constant first so they always use first few slots and allocate immediates after
hgb: decides that the simple 'xrandr --output DVI_1 --left-of DVI_2
hgb: ' didn't work
MostAwesomeDude: glisse: That's what I'm already doing.
hgb: At least not out of the box.
hgb: It completely confuses fvwm
TCW: http://paste.debian.net/38459/ <- hgb, no special DualHead setup in xorg.conf, xrandr --output DVI-0 --left-of VGA-0, done
MostAwesomeDude: The catch is that I have to rebuild shaders each time the constants change.
hgb: TCW: What kind of window manager do you have?
glisse: MostAwesomeDude: no you don't
TCW: hgb, but fvwm may be too old... I use xfce and gnome
yangman: hgb: stuff like that's basically relegated to window managers
glisse: the number of constant is constant :) right ?
MostAwesomeDude: glisse: Sometimes. :3
glisse: MostAwesomeDude: well if the number of constant change obviously the shader changes too
MostAwesomeDude: if (old_count != new_count && shader->uses_immediates) rebuild_shader();
MostAwesomeDude: And apparently that path is getting hit a lot.
glisse: well somethings is wrong i don't see how/why the number of constant changes
MostAwesomeDude: It has something to do with the fact that the state tracker keeps unbinding and rebinding shaders.
glisse: MostAwesomeDude: yeah you have to associate constant/immd with shader
MostAwesomeDude: glisse: I think that I'm going to add the number of declared constants to the shader, and test that too.
glisse: MostAwesomeDude: in gallium spirit when gallium ask you to build a context you save the compiled shader and associated info
MostAwesomeDude: glisse: Yes. But we don't want to save the consts.
glisse: MostAwesomeDude: save the const too
MostAwesomeDude: But they'll change.
MostAwesomeDude: The constants are not very constant. :T
glisse: gallium should give you contextid + const
TCW: what is needed to get DRI2?
glisse: so in your context you got the saved shader to which you append the constant
hgb: TCW: Do you have 'virtual' stuff in xorg.conf?
TCW: rv530, kernel 2.6.29, xorg 1.6 here
TCW: hgb, sure
glisse: MostAwesomeDude: gallium is supposed to make this easy :)
MostAwesomeDude: glisse: I see what you're saying. I'll see what I can do.
TCW: hgb, it is quiete essential for dualhead, as noted in the xrandr docs and wiki
glisse: i will take a look at code later but i am pretty sure i915 did it that way back in the day
MostAwesomeDude: But the state tracker should *not be doing bind_shader(); draw(); unbind_shader();
MostAwesomeDude: Over and over again.
glisse: MostAwesomeDude: this is a typical 3d usage pattern :)
MostAwesomeDude: glisse: But it's glxgears!
glisse: glxgears is the most advanced 3d application ever made !
glisse: :)
buggs: for many ati users it's the only app they use
yangman: chuckles
buggs: after that they know somethings broken
hgb: I suppose the question now is if I can get fvwm to treat the two xrandr screens as separate.
glisse: MostAwesomeDude: i got to pickup mail brb
hgb: All I need is two pagers, possibly.
buggs: hgb, tried e17?
buggs: only wm i think that does independant desktops on more than one display
hgb: buggs: No, I haven't. I've been using fvwm for more than 10 years, and my accelerators and the way windows are placed, etc, is very much in my fingers, so I'm not very keen to switch.
airlied: glisse: I made an F11 -ati package that should run on both kenels
airlied: kernels even
airlied: MrCooper, agd5f: btw the EDID parser is busted on big-endian in kms
airlied: I've been meaning to fix it :)
glisse: airlied: so sis agp seems to support user memory and it doesn't seems i have memory problem on my computer
airlied: I can try on my sis box as well
airlied: send me your .config maybe
airlied: I might be missing something
airlied: what triggers it for you?
glisse: anythings once kms is loaded if i load fbcon it will take few second to happen
airlied: okay I definitely don't see that
glisse: launching X is even quicker
DanaG: Oh yeah, I tried the PPA of Radeon KMS; I got "failed to initialize radeon; disabling IOCTL"
glisse: DanaG: the log likely tell you why & where it failed
glisse: airlied: http://people.freedesktop.org/~glisse/glisse-sisconfig
DanaG: [ 3.159661] [drm] radeon: Initializing kernel modesetting. [ 3.162820] [drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling IOCTL [ 3.164889] radeon 0000:01:00.0: PCI INT A disabled
glisse: DanaG: pastebin your log the problem is printed before that message
glisse: airlied: also rawhide seems to work fine on this sis box
glisse: in agpmode
DanaG: what is agpmode supposed to be? -1, or unset?
DanaG: Card is PCIe; RV635.
glisse: DanaG: only matter if you have agp
DanaG: http://pastebin.com/f3b64b840
bschindler: Hi - I connected an external screen to the my laptop using old vga connector... the problem I have is that the image is a bit blurred the left side of the screen while its basically fine on the right side. The laptop screen is fine though
bschindler: I've got this issue with different screens too, so it is most likely a HW/Driver issue
airlied: glisse: nothing majorly different in the configs
DanaG: oh, and what does the "benchmark" parameter do?
hgb: airlied: When I try what you suggested yesterday with two screens in xorg.conf, the box freezes hard when I exit X. Additionally, I can only move from the left to the right screen, and not vice versa.
hgb: airlied: IT's a RV730/Radeon HD 4650 card.
airlied: hgb: what X server you got?
hgb: airlied: xorg-x11-server-common-1.6.1.901-1.fc11.i586
hgb: airlied: Also xorg-x11-drv-ati-6.12.2-14.fc11.i586
airlied: hgb: try adding Option "VGAAccess" "false" to the second device section
airlied: might solve the cras on X exit
airlied: the mouse ptr stuff I'm not so sure about, I'll have to setup a test box for that one
glisse: DanaG: which GPU ?
hgb: airlied: Could radeonhd vs radeon make a difference?
hgb: airlied: I haven'
hgb: t really tried radeonhd yet.
hgb: Testing is a bit painful, as I need a reboot all the time...
DanaG: RV635.
DanaG: Mobility HD3650.
glisse: DanaG: not supported
airlied: hgb: not sure I don't reall use radeonhd
glisse: yet
DanaG: ah. Perhaps add a "not supported" message for now?
DanaG: Rather than "failed". =þ
hgb: airlied: Ok, cheers. I'll try with the VGAAccess stuff first.
glisse: will add message
DanaG: Cool.
yangman: hgb: radeonhd most likely won't be any better. it was all about randr from the get-go
DanaG: What's odd is that I've had KMS working on my radeon once; I don't remember when that was, though.
MostAwesomeDude: glisse: Will work on vertprogs later. Sleep now.
glisse: DanaG: it works with rawhide
DanaG: I see... just that package is the one that doesn't have it -- wrong branch?
hgb: yangman: radeonhd wouldn't even let me set up two screens with the same device (two device sections, but same BusID)
hgb: airlied: VGAAccess didn't really help
hgb: ponders installing a second video card instead.
airlied: hmm I'm not on SMP
airlied: glisse: ^ maybe that?
glisse: maybe
glisse: will try single
airlied: hmm my config has SMP in it aleight
glisse: well it's single cpu no dual core
glisse: so it's not that
airlied: I had flatmem you had sparsemem
airlied: not sure what the diff there is :)
airlied: just rebuilding the other way here
glisse: hey i can only pick sparsemem here
DanaG: I was reading that as "sparsemen" and "flatmen". =þ
Kaapa: hey there
Kaapa: any tips on how to make hibernate work?
hgb: fails to get his setup working with one nvidia and one radeon card as well
hgb: reverts to one screen for the time being
hgb: Does xinerama work with radeon?
airlied: hgb: mulit-card is busted in X at the moment
airlied: though if you set the nvidia to the primary
airlied: it might work
Kaapa: airlied: you know of any documentation about hibernation/suspension support?
airlied: Kaapa: for what? it works for me in Fedora
hifi: I had a working multi-card system with X, nvidia and radeon
hifi: the radeon one was the secondary head with no DRI
airlied: hifi: yup that might work as radeon can post without int10
hgb: gets a feeling that things are regressing
airlied: hgb: actually it might be NoInt10 option
dileX: is it today where F11 will be released?
airlied: yes in 8 hrs or so I think
Kaapa: airlied: I can't make it resume
airlied: maybe 4-5
hgb: airlied: Didn't quite follow, there.
dileX: airlied: thx
airlied: hgb: you might try adding option "int10" "false"
hgb: airlied: And make the radeon device secondary?
airlied: (this was for the single radeon card case)
dileX: must refresh rpm know-how (so long ago)
airlied: but shouldn't harm anything else
hgb: airlied: Ah, to avoid hanging on X exit?
airlied: yeah I'm not sure what causes it
hgb: airlied: I'll give it a shot when I get the time. Guess my employer won't like me to fiddle with this all day :)
hgb: airlied: Still, dual-screen setup isn't very interesting if I can't move between both screens... Guess it needs some investigation.
Kaapa: ah!
Kaapa: just found out that suspension to disk works
Kaapa: it's suspension to mem that's screwed
Kaapa: much better news
Kaapa: but still, if someone has suggestions on how to make it work, they'd be appreciated
glisse: Kaapa: kms ?
glisse: distrib,gpu,config...
Kaapa: slackware (-current), 01:00.0 VGA compatible controller: ATI Technologies Inc M76 [Radeon Mobility HD 2600 Series],
Kaapa: xorg.conf: http://kaapa.pastebin.mozilla.org/656356
Kaapa: its a toshiba laptop and I use the pm-utils scripts to handle the suspension
glisse: Kaapa: is this with lastest software (ddx) ?
glisse: if not try with ddx from git and with 2.6.30 kernel, it should work with that i think
Kaapa: This is version 1.2.3
Kaapa: kernel 2.6.29-4
Kaapa: how outdated is this?
glisse: i think r6xx were merge in 2.6.30
glisse: ddx is also important
glisse: lastest ddx version is 6.12.2 iirc
Kaapa: I don't even have ddx installed (to be hones, it s the first time I hear about it)
Kaapa: may be a dumb question, but what do you mean when you say r6xx is merged in 2.6.30? That I won't need xf86-video-ati anymore?
glisse: xf86-video-ati is ddx
glisse: and no you still need ddx with newer kernel and you will for next few years
Kaapa: is it worthwhile to test the latest version w/o upgrading kernel?
Kaapa: or do I really need .30?
glisse: yeah could help
Kaapa: do you recognize this behavior?
Kaapa: is it a known issue?
glisse: dunno
glisse: it's just that we don't have resource to support all version of ddx/kernel
glisse: so the rules is test with lastest and report bug if it doesn't work
Kaapa: totally understandable
dileX_: glisse: cool, you put FB and FRAMEBUFFER_CONSOLE in drivers/gpu/drm/Kconfig.
airlied: osiris_: hey, fixed mipmap_limits
airlied: osiris_: but dri1 crashes for me using mesa master also
airlied: with makeCurrent
osiris_: airlied: oh, cool.
osiris_: then the makeCurrent is probably Xserver regression
airlied: osiris_: yes I suspect mesa/xserver somewhere
Kaapa: With the latest git code I still have problems suspending
Kaapa: but I don't have the latest kernel, so it's still not a good test case
Kaapa: I'm getting this lines on dmesg, are they normal?
Kaapa: http://kaapa.pastebin.mozilla.org/656379
hifi: probably
Kaapa: (I assume the duplicate symbols are caused by me not using .30)
arkascha: I am using the radeon on an ATI R505 board under X.org-7.4-8. Is there a way to get hardware 3d support so that KDE/compiz wont eat all my cpu ressources ?
arkascha: As driver I specified radeon, that works, while radeon-hd freezes reproduceably.
[Enrico]: arkascha: what version of xf86-video-ati and mesa?
arkascha: Mesa-7.2
arkascha: xorg-x11-driver-video-7.4
[Enrico]: xorg-x11-driver-video-7.4 <--- this is not what i've asked :D
arkascha: [Enrico]: sorry, newbie problem :-) I do not seem to have installed a package called "xf86-video-ati". One minute, I'll check that...
[Enrico]: arkascha: that package can be included in xorg-x11-driver-video
[Enrico]: arkascha: which distro are you using?
arkascha: [Enrico]: opensuse-11.1 @ x86-64
[Enrico]: arkascha: mhm ok give me a minute to boot a vm
arkascha: [Enrico]: Indeed I cannot find any packages matching video-ati.
[Enrico]: arkascha: opensuse devs pack all video driver in one package
[Enrico]: arkascha: can you paste your /var/log/Xorg.0.log (use nopaste or similar pls) ?
arkascha: [Enrico]: package "xorg-x11-driver-video" contains a file "/usr/lib64/xorg/modules/drivers/ati_drv.so". Guess thats what I need ?
arkascha: [Enrico]: sure, log comes in a minute.
Zajec: arekm: vm? what are you trying to achieve? acceleration on some guest machine?
[Enrico]: arkascha: btw you need /usr/lib64/xorg/modules/drivers/radeon_drv.so which is included in the same package
arkascha: [Enrico]: http://portal.imageware.de/pastebin/p67ewt/Xorg.0.log
Zajec: hm, is this some kind of ancient radeon?!
Zajec: (II) Module radeon: vendor="X.Org Foundation"
Zajec: compiled for 1.5.2, module version = 4.3.0
[Enrico]: arkascha: can you see this linbe in the log "R500 support is under development" your radeon driver is old, you should add the X11 repo and install the newer version
arkascha: [Enrico]: oops, though I DO use the official X11 repo and an up to date version.
Zajec: arkascha: it doesn't seem so
arkascha: We are talking about this repository: http://download.opensuse.org/repositories/X11:/Drivers:/Video/openSUSE_11.1/ ??
Zajec: yes... this should conain much newer radeon_drv.so
Zajec: er, moment..
Zajec: X11:/Drivers?
[Enrico]: arkascha: no not that repo
arkascha: Just saw myself.
[Enrico]: arkascha: that repo doesn't contain the radeon driver (and btw avoid radeonhd)
Zajec: http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.1/
arkascha: I do not use radeonhd, it keeps freezing for me.
arkascha: I'll upgrade, one minute,
Zajec: arkascha: be sure to update everything from this repo... one missed package may stop you from starting X
Zajec: if you will update xorg-server but miss -video, you will have ABI conflict
arkascha: right, I remember having trouble with that repository month ago. But I am willing to give it another try :-)
Zajec: using this right now (with radeonhd) works nice
arkascha: Zajec: Is there a real advantage in the radeonhd driver compared to radeon ?
arkascha: Zajec: I though I read about the new features from radeonhd being "backported" to radeon ?
Zajec: arkascha: i get HDMI support which is very important for me
Zajec: plus scaled mode... I can display 1920x1080 scaled down to native 1600x900
Zajec: great if you use second monitor with higher res
Zajec: so some pluses, no minuses... decided to radeonhd ;)
[Enrico]: arkascha: radeon is less experimental and "more official"
scarabeus: MostAwesomeDude: nice, working gears, and nice log for it ;]
arkascha: [Enrico]: that's what I tought. Zajec: since being at work here I dont use HDMI :-)
Zajec: [Enrico]: i think radeonhd is quite stable already... and for sure not less official than radeon :)
Zajec: still belive to see one of drivers dead somewhere in future :) probably after implementing KMS
libv: heh, the radeonhd versus radeon story is a really nasty one
Zajec: libv: :)
libv: one day i'll tell what happened in great detail and with a lot of facts to back it too
[Enrico]: Zajec: no i don't think so, radeonhd experiments some new features and if they works they are also backported, the 2 project are very near
Zajec: libv: what about today? :) such a things meant to be done later... usuall finish abonded ;)
libv: [Enrico]: radeonhd was the project that brought up r5xx and up hardware from scratch, for amd, while ATI for some reason was unable or unwilling to do so for its new mother company
libv: [Enrico]: radeon then, as a reaction against an actually successful radeonhd (done by suse and amd), by redhat and ati.
libv: this is the very core of the story
[Enrico]: lol
Zajec: as always... money or ombitions :P
libv: [Enrico]: how bad is that huh.
libv: free software? linux desktop? technical superiority? all that went out of the window for politics
mjg59: libv: Wow. It's astonishing how quickly you go back to paranoid mode.
mjg59: How many companies is this working against you now?
libv: mjg59: ah, the same old counterattack
arkascha: Ok, packages downloaded, upgrade in progress. Hope to be back in a few minutes. If not, thanks for now ! Great to get friendly and helpful replies on IRC !!
arkascha: holds his breath...
libv: mjg59: aren't you working for the company that claims that atombios is the greatest thing ever, but you still spend your time doing bullshit talks in which you say how great you are for speeding up powermanagement by bypassing atombios code?
libv: hrm... this only weeks after bashing me for being anti-atombios.
mjg59: The moral here is "under some circumstances you can gain better results by driving hardware outside its designed specifications", not "defined interfaces are bad"
mjg59: Where atom doesn't get in your way, it's the right way to do things
libv: ah... but when it does get in your way, now or 5 years from now, what do you do then?
mjg59: I'd rather not care about the specifics of the memory controller
libv: aha, ASICInit.
mjg59: libv: Use atom where it works, don't use it where it doesn't
mjg59: Memory reclocking seems sufficiently fast on r600 via atom
libv: mjg59: at one point the barrier for bypassing it becomes too high, and broken state is then kept.
mjg59: Well, yeah, maybe in 5 years I'll have a different view
libv: this is what will probably only be clear to you several years from now, if by then you still bother to care.
libv: and then there is no way back.
mjg59: Yet we're utterly tied to ACPI on x86
mjg59: And even most of the people who argued for ignoring ACPI 10 years ago accept it now
libv: with acpi having become an industry wide thing, not something limited to a specific subset of graphics hardware, and not with a massively changing api every time something changes to the modesetting layout.
mjg59: So what's the supposition? That atom will end up insufficiently functional?
mjg59: It's not supposed to be some sort of universal panacea that avoids ever having to update a driver to support new hardware
libv: it is, in any case. ati had no docs whatsoever, and atombios was part of the reason and part of the way of dealing with that.
libv: this makes the very existence of atom questionable.
mjg59: It's not like atom contains secrets
libv: from a company pov yes
libv: from a graphics driver developer, it does already.
libv: when did you last see documentation on modesetting?
mjg59: Well, there's the atom tables you can call
mjg59: And if you actually care about register contents then you can trace the atom writes and it'll probably make more sense than the average vendor documentation
libv: 14:57 < mjg59> libv: Use atom where it works, don't use it where it doesn't
libv: this then undermines the whole point of these things
mjg59: Nonsense
libv: without vendor documentation it becomes a lot lot harder to make sense out of these things
MrCooper: libv: ATOM would exist even if Linux or free software or whatever didn't, so I'm not sure what your point is there
mjg59: If I only have to care about one special case, that's a much easier task than caring about ten special cases
libv: MrCooper: yes, and that matters how?
Zajec: ACTION probably know nothing comparable to you... but
Zajec: WTF: And you can trace the atom writes and it'll probably make more sense than the average vendor documentation
libv: Zajec: free software, right?
libv: mjg59: having register dumps replay puts you in nv driver mode.
arkascha: :-)
libv: mjg59: thanks for aiding progress.
mjg59: Zajec: For example, having complete register documentation on the memory controller doesn't actually tell you how to program the memory controller
arkascha: [Enrico] & Zajec: Thanks for the assistance. I have a) a working X again, b) a much _faster_ X and c) no problems, as far as I can see.
libv: so nouveau is good, radeonhd is bad... from a non-political/corporational pov, why?
arkascha: switching desktops is so much fun now !
[Enrico]: arkascha: np enjoy :D
mjg59: libv: You realise nouveau's now concentrating on modesetting through the nvidia bios tables, right?
libv: mjg59: yes, i am aware of this, and i seriously dislike it
libv: but unlike with ati, there was and there is no chance to change that.
mjg59: And asic bringup is always likely to involve using bios code
Zajec: mjg59: maybe company should change docs writers then... what is wrong about documenting register plus sample, super simple, abstract code
libv: mjg59: you realise that this is what radeonhd has done all along right?
mjg59: Zajec: companies write documents for their own benefit
libv: mjg59: ASICInit has always been run by radeonhd from even before radeon had r5xx and up support
libv: mjg59: the reasoning there was, it is better than running full int10 and the people who really want to can go and look at the code.
mjg59: Zajec: Yes, it would be wonderful if released documentation also told you how to drive every aspect of the hardware. But that documentation doesn't exist, and it would cost a ridiculous amount to cause it to.
mjg59: libv: So you're already dependent on atom
libv: for modesetting, which is 99% generation specific.
libv: it is better to not depend on atom
libv: only board specific things.
mjg59: It's more work and it's generally unnecessary
libv: mjg59: of course we are, we at least need board information
libv: mjg59: another general statement discounting what you even agreed to earlier.
Zajec: starts to think we should use fglrx... closed driver / closed instructions... quite near :P (read as little irony)
mjg59: Mm?
Zajec: afk 4 mom
mjg59: Like I said, I think atom's the right choice except for a very small number of cases where you want to do something that's not possible with atom
mjg59: Would it be nice to have more docs? Yes.
mjg59: But I'd prefer that the finite amount of time available for documentation was concentrated on the things that aren't possible with atom
mjg59: That way we get a more functional driver
libv: this whole thing boils down to "where do you want to have the pain". You either realise you were wrong all along, when it is impossible to change, or you take a bit more pain early on, when docs, access to more information and momentum are available?
mjg59: I've no idea where this "impossible to change" thing comes from
mjg59: Code that works doesn't stop working
mjg59: It seems unlikely that we're suddenly going to realise that r500 never worked at all
libv: mjg59: intels vbe driver.
mjg59: So, yeah, it turned out that vbe didn't actually let you drive the chip
mjg59: But at that point the choice was between a vbe driver and no driver
libv: mjg59: are you so certain that the atombios abstraction matches the hardware underneath?
mjg59: For the current generations? It seems close enough
libv: if so, take a closer look at it.
mjg59: The question isn't whether atom prevents you from doing things. The question is whether atom prevents you from doing *useful* things.
mjg59: Intel's VBE interface did
libv: aha, but they said "close enough" and "it does useful things" with vbe
mjg59: Which was true, in 1992
libv: but what is the point of this discussion anyway, you stepped in by discounting it all as paranoia and it is clear which side of the political/corporation divide (the only one that is clear in this whole story) you are.
mjg59: I had no corporate affiliation when I started looking at atom
libv: you will not admit to my face that i have a point.
mjg59: I won't admit it behind your back, either
libv: but times will change.
libv: that _i_ have a point, that you will indeed never admit directly
libv: but this is also a common story.
mjg59: If the atom abstraction remains constant as hardware demands change, then yes, I think there would be a problem
mjg59: The functional issue with VBE was that it didn't gain any functionality while the hardware did
libv: mjg59: but then why not try to implement as much as possible in C code when the hardware changes?
libv: you're going to have to rewrite things anyway when hw changes.
libv: and at least this way you can work around issues more easily
mjg59: By generating more issues?
libv: and there is a much better chance that you then know what you are doing and what you are supposed to be touching, as you then would've received the docs
mjg59: You're conflating issues
mjg59: Your first argument seems to be "Atom exists and so we weren't given adequate docs"
libv: but they are attached.
libv: no.
mjg59: And your second argument seems to be "Atom should not be used"
libv: we were given part of the docs
libv: and now we are not even given that any more.
libv: when we still were allowed to have the docs, we were easily able to implement proper modesetting.
libv: the docs issue is heavily intertwined with the atombios issue.
libv: for ATI, atom is both a way to deal with the lack of documentation and the cause of a further lack of documentation (as now the political wind to force people to use atombios also stops ati from giving out register level modesetting ifnormation)
Zajec: heh... i've just asked Matthias about part of code he pushed into radeonhd... it's AtomBIOS based part of power management... everyone should read: http://lists.opensuse.org/radeonhd/2009-06/msg00154.html
Zajec: it sums up importance of docs
mjg59: Zajec: Not really
mjg59: Zajec: No hardware docs are likely to tell you how clock gating works
mjg59: That's a silicon level issue
mjg59: It's only relevant to hardware design people, not anyone writing software
libv: mjg59: a really cute example of how atombios influences our (and others) ability to use the available hw is HPD. HPD is available with the unbelievably nicely designed R5xx modesetting hw, but it was not provided in the atombios connector table. Board makers then didn't test hpd functionality (even though it is a required part of the DVI standard), and therefor, on about 1/50 r5xx boards out there, the functionality is broken, and on 1/
mjg59: libv: You were cut off after ", and on 1/"
libv: this is just board specific information in a table, but this explains how the bios can limit the use of available hardware
libv: "50 r5xx
libv: boards out there, the functionality is broken, and on 1/20 or so,
libv: the hpd pins are swapped around compared to a logical layout.
libv: hrm... irrsi silently cut that then.
mjg59: Again, this seems to be "The existence of atom is bad"
jcristau: libv: /script load splitlong.pl
mjg59: Rather than "Using atom is bad"
mjg59: Zajec: But yes, the extent to which we don't have documentation for certain aspects of radeon power management is frustrating. But which would you rather have? Docs that tell you how to do something that you can already do, or docs that tell you how to do something new?
Zajec: mjg59: it is not only about silicion's part... we have no idea what EnableASIC_StaticPwrMgt does... do we need that for executing other commands? does it enable something? downclock something?
libv: mjg59: the whole existence of atom isn't bad, the way it is used and the oft "trivial" bits it is used for exclusively is bad.
Zajec: dinner
mjg59: Zajec: Static power management will typically do things like consolidate clock domains, meaning that you don't have to run as many clocks.
mjg59: libv: Again, that's not a factor when considering whether or not to use it
mjg59: Zajec: At the cost of some performance.
libv: mjg59: have you been listening? radeonhd implemented ASICInit iirc from the day we were allowed to make it public
libv: ASICInit versus int10 is an easy choice to make.
libv: even though the only time we got to talk to ATI hw engineers, we got told that they use int10 anyway
libv: for their fglrx driver
mjg59: libv: However, refusing to use atom doesn't magically fix cards that are broken by design
libv: mjg59: it doesn't, but it makes it easier to mitigate the problems, but as said, after slightly more initial pain
mjg59: So, yeah, obviously you may hit cases where you want to drive the hardware directly. I've given an example o that.
libv: technically, especially when looking forward, taking into account the witnessed lifespan of graphic driver code, it makes sense to implement basic modesetting in C code instead of depending on atombios. ATI doesn't like that, as it exposes their internal issues, and that's where the politics start.
mjg59: The question is what level of work are you willing to put in to have a perfect driver, against the level of work required to implement functionality with a small amount of ugly special casing?
libv: mjg59: intel driver.
mjg59: There was no way to write a functional intel driver using VBE
libv: small doesn't stay small.
libv: mjg59: well, it was vbe plus some things on top
libv: mjg59: until the whole thing became rather unmanagavle
mjg59: Nothing useful
mjg59: You weren't intended to drive the card via VBE
mjg59: That was the fundamental issue
mjg59: You got no sensible control over individual outputs, for instance
mjg59: The BIOS code was mostly there for the benefit of the system BIOS
mjg59: Not for the benefit of the OS
mjg59: This isn't the case with atom
libv: mjg59: ah, but this was all before people considered this output stuff useful. And the intel driver, with its dependance on the vbe (lack of) abstraction, was the really sore spot there.
libv: modesetting paradigms changed
libv: how certain are you today that modesetting paradigms will not change on atom?
libv: how certain are you that some in-the-middle abstraction does not limit what the driver can achieve with the actual hardware underneath?
mjg59: This is well after people wanted to be able to run external monitors at different resolutions
libv: you said earlier... if the atombios abstraction doesn't match the underlying hw, then we have to implement things properly. Then the question becomes; will you then find ati willing to go along with this? What will you have to do to then convince ati to help with this?
libv: will there still be this possibility then?
libv: or maybe it was better to do things properly from the start
mjg59: Will anyone with old hardware care at that point?
libv: mjg59: depends on how the code is handled, i cannot say that keeping old hw going is a strong point of several drivers.
mjg59: Like I said, the functional issue with VBE was that it never matched hardware functionality
mjg59: It seems less likely that atom will have this problem
libv: it has this problem already, it is only a less extreme problem.
Tatsh: where can i report bugs?
stikonas: Tatsh: http://bugs.freedesktop.org, you may also mention you problem here
stikonas: maybe it is the known one
Tatsh: what is 'the known one'?
stikonas: your bug can be already known
Kaapa: there's only one bug? wow :)
Tatsh: i have an ati radeon xpress 200m (yes i know it sucks); i use xorg 1.5, blah blah, custom cflags as one would expect with gentoo but everything is normal except this
Tatsh: i use an external monitor and if i disconnect and do xrandr --auto, i can switch back to my laptop screen fine
Tatsh: my external monitor uses 1440x900, while my laptop does 1280x800; when i try xrandr --auto when reconnecting the screen, it corrupts the bottom part of the screen
Tatsh: i have a pic of the action, since it's not screen capturable
Tatsh: http://imagebin.org/51943
Tatsh: notice the bottom of the screen, all garbled
Tatsh: that's after using xrandr --auto when reconnecting the external lcd
MostAwesomeDude: I ran xf86-video-avivo for a few months.
Tatsh: how to reproduce: start X with LCD connected, everything is fine, start a terminal, disconnect monitor, type xrandr --auto, reconnect monitor, type xrandr --auto again
Tatsh: does this sound familiar to anyone with a laptop connected to an external LCD?
Tatsh: my other issue is this
Tatsh: if you look closely into that picture, you can see that KDE's Kicker only stretches to 1280 pixels, when it should stretch to the full-width of the monitor (the proprietary drivers did this); when I go to desktop options to change the resolution, maximum resolution reported is the laptop's: 1280x800
MostAwesomeDude: Tatsh: If the resolution is the same as in fglrx, then it's a KDE problem.
Tatsh: it's not
Tatsh: fglrx reported the correct resolutions to wherever KDE is getting the info from
Tatsh: 1440x900 and below
Tatsh: if i didn't have my external LCD connected, 1280x800 and below
Tatsh: https://bugs.freedesktop.org/show_bug.cgi?id=22175
Tatsh: posted my bug and i hope it explains well
Tatsh: gotta love it https://bugs.freedesktop.org/attachment.cgi?id=26586
osiris_: glisse: gpu reset doesn't work on my rv380 and rv535. it works only on rs690. maybe you're missing pcie gart setup while resetting gpu?
Kaapa: is there any kind of performance tests we can do to measure the driver?
Kaapa: glxgears returns a good number, but while switching virtual desktops this "feels" slow
MostAwesomeDude: Kaapa: Gears Is
MostAwesomeDude: Not A Benchmark
Kaapa: what can I use?
Kaapa: just to have a rough idea
osiris_: Kaapa: http://dri.freedesktop.org/wiki/Benchmarking
Kaapa: thank you
Kaapa: osiris_: ping
dmb: i know this may sound extremely weird, and is most likely not related
dmb: but it seems whenever I use a KMS enabled kernel, wifi doesn't work correctly
Kaapa: osiris_: I installed q3 demo, but when I execute it I get no output from cd /q3 && ./q3demo +exec demo 2>&1 | egrep -e '[0-9]+ frames'
Kaapa: do I need to let the demo run till the end?
dmb: with the kms stuff, it works fine
osiris_: Kaapa: yes
Kaapa: osiris_: does it take long?
osiris_: don't know. I always run openarena
Kaapa: oh, btw, do I need to install the opengl stuff?
osiris_: no, there's one env variable but I forgot the name
Kaapa: I can't get any output of fps
Kaapa: but I'd say about 10 fps :S
Kaapa: and cpu is 100%
osiris_: what gpu?
Kaapa: Radeon Mobility HD 2600 Series
agd5f: Kaapa: 3d driver isn't ready yet for your chip
Kaapa: oh, so it is normal then?
Kaapa: the worst part here is that on regular use, switching screens, opening windows, etc, seems slow
agd5f: Kaapa: 2d and video accel are available with the drm in 2.6.30 and some newer distros
samosa: is there much of a difference from catalyst 9.2 --> 9.5? (went from 8.6->9.2 and only difference I saw was, more ram needed for start-up process, seems all newer versions of software are doing only improvements to crossfire or latest games...and not improving anything else...)
MostAwesomeDude: samosa: Wrong channel for Catalyst/fglrx; try #ati instead.
samosa: your so awesome, MostAwesomeDude. :-)
MostAwesomeDude: Yeah, I know. :3
airlied: can't wait for libv's expose of radeon vs radeonhd history
|mr: Hi, I
|mr: m curious about this page: http://www.x.org/wiki/RadeonFeature
|mr: I'm very interested in updates, as the last update to the page was a month ago
|mr: If there were any changes I would be quite interested to know.
MostAwesomeDude: Nope, that page is pretty up-to-date.
stikonas: |mr: most of the changes are done now in Kernel modesetting, maybe code will be merged into kernel 2.6.31
|mr: stikonas: That's good to know. .30 should be out this week, right?
|mr: radeon KMS would be great for .31 for Ubuntu 9.10
stikonas: |mr: yes, if Torvalds won't find any grave regressions
|mr: But the radeon KMS you speak of... is it only r100-r500?
stikonas: r600-r700 will go to next kernel
stikonas: probably 32
|mr: Cool...
stikonas: but it still has some bugs left, but I have used KMS for over a month and it is really usable
|mr: So OpenGL compliance in radeon with r200 through r500 is all lower than what the hardware supports?
|mr: What is the point of working hard on that if we are moving away from mesa OpenGL and towards Gallium3d?
Curan: |mr: you might find http://tirdc.livejournal.com/ interesting as well then, not much updates, but you can't miss important things :)
stikonas: |mr
stikonas: |mr: some distros (mostly enterprise) won't ship gallium3d for some time
scarabeus: that wiki page is funny, unknown state for r400 based cards, i am suspending for 4 years with that card, and only crashes i had were due to bugs in tuxonice ;]
osiris__: |mr: experience. once we learn how to implement one feature in classic mesa should be pretty easy to implement it in gallium. also gallium driver won't be probably finished before next year, so ...
Curan: |mr: tirdc=The irregular Radeon Development Companion
osiris__: and by finished I mean the state of features/speed that classic mesa driver is in now
nanonyme: osiris__: Yeah, isn't the core still quite unfinished too?
osiris__: core of what?
nanonyme: Gallium core.
osiris__: no, I think it's finished
nanonyme: Oh, nice.
nanonyme: I was under the impression it was under construction too.
|mr: Mesa 7.5 RC3 is out so
|mr: almost stable
stikonas: glxgears should be enough for any user :P
|mr: Even though 7.5 is testing branch of Mesa I think
|mr: mesa 7.6 will really bring gallium3d
stikonas: and r300-gallium renders glxgears
osiris__: soon users should be able to run most of the dx9 games that wine can handle
nanonyme: stikonas: Softpipe or hardware rendering? :)
MostAwesomeDude: nanonyme: Yes.
stikonas: hardware, but only with hybrid kernels
MostAwesomeDude: And with both SW and HW TCL.
nanonyme: Neato.
MostAwesomeDude: stikonas: If glisse's kernel still doesn't work, you should give me dmesg dumps and I'll fix it.
stikonas: I was not able to workaround problem with 0x4010 (MOSPOS0) register on newttm
stikonas: MostAwesomeDude: "Forbidden register 0x4010 in cs at" \n "[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !"
nanonyme: Ah.
MostAwesomeDude: stikonas: 'k, I'll get it later.
stikonas: I tried commenting this out in radeon_state_invariant.c but driver still prints this message
nanonyme: MostAwesomeDude: Probably glisse's security stuff you were noting you had trouble with earlier too?
nanonyme: "Forbidden register" sounds pretty dubious.
stikonas: s/Forbidden register 0x4010 in cs at/Forbidden register 0x4010 in cs at 3/
agd5f: stikonas: driver shouldn't be writing that register
agd5f: drm sets it
agd5f: now
stikonas: I know, we discussed this earlier
stikonas: when I first reported this issue to MOD
stikonas: s/MOD/MAD/
agd5f: stikonas: should be able to just remove the code in the driver that tries to set that reg
DanaG: r600 KMS only in 32? Bummer.
airlied: stikonas: you using the write DDX?
cbmuser: airlied: I tested radeon-kms on my IBM T43 with X300 today, works like a charm
cbmuser: thanks alot
cbmuser: hope can use it on Debian soon
glisse: osiris__: hhhmm what happen when it didn't work ?
glisse: computer hang ? or just cp failure ?
osiris__: glisse: complete hang, even SAK doesn't work - maybe kernel oopses
glisse: airlied: btw sadly i don't see any good explanation to my page structure corruption on agp none of the affected page are allocated by ttm
glisse: osiris__: strange last time it played with that it worked here for r5xx reliably and lot less reliably for r3xx
osiris__: glisse: PCIE cards?
glisse: osiris__: yeah i am mostly pcie, i hate agp enough to not use it as a default ;)
osiris__: hehe
glisse: anyway i will finish polishing radeon kms patch i am adding gpu reset back to my check list
glisse: zzzZZZzzz
spstarr: glisse: get a Fedora account! :)
spstarr: F12 is open for business
Rossyfox: Hello! :3
MostAwesomeDude: :3
Rossyfox: I have a quick question
MostAwesomeDude: 'k.
Rossyfox: My desktop has a Radeon 9600 in it and I'm running Xubuntu 9.04
Rossyfox: The proprietary Radeon drivers are a no-go. Freezes the system on startup.
MostAwesomeDude: Go with the open drivers. fglrx isn't officially supported anymore for that card.
Rossyfox: Is there an older version of fglrx that is?
MostAwesomeDude: Probably.
Rossyfox: Or will that not work with a newer kernel?
MostAwesomeDude: Probably not.
soreau: Rossyfox: What do you have plugged into the card?
MostAwesomeDude: What do you need from fglrx, exactly?
chithead: #ati would be the correct channel, don't expect anything newer than kernel 2.6.28 and xserver 1.5 to work with fglrx and 9600
Rossyfox: soreau: One 15 inch CRT monitor
soreau: Rossyfox: Then chithead is correct ;)
Rossyfox: Alright. Which open drivers would be the best for 3D?
soreau: Rossyfox: I have the same card and would definitely recommend not using fglrx, but the open radeon driver that is installed by default on Jaunty
MostAwesomeDude: There's only one open driver for that card.
soreau: indeed
osiris__: airlied: could you confirm my account request #22120 ?
Rossyfox: fff. If only fglrx were open it would be relatively trivial to get it working on a newer kernel.
MostAwesomeDude: Rossyfox: Kill the fglrx with fire. Stuff should work.
MostAwesomeDude: And we don't want fglrx; it's icky and big.
Rossyfox: So there's no way for me to get 3D, then?
Rossyfox: Is this not a different driver than the one that comes with Jaunty? http://wiki.x.org/wiki/radeon
MostAwesomeDude: Rossyfox: We *do* have 3D.
soreau: Rossyfox: Are you in X now?
mjt: hmm. Is there a way to get r6xx accel (r6xx-r7xx-support drm branch) to work on 2.6.30-tobe?
Rossyfox: soreau: Yes. Though I'm on IRC via my laptop.
soreau: Rossyfox: Which graphics driver are you currently using on the ati machine?
Rossyfox: The one that comes with Jaunty
MostAwesomeDude: And your 3D isn't working? fglrx hosed libGL, probably.
soreau: Rossyfox: And what does the output of 'glxinfo|grep renderer' say?
Rossyfox: It says that glxinfo isn't installed :P
TCW: Rossyfox, apt-get install mesa-utils
soreau: wow
soreau: mesa-utils is installed by default on ubuntu
soreau: Rossyfox: Is this an upgrade or a clean install?
TCW: soreau, I thought you are already used to ubuntu users? :-P
TCW: soreau, it is? Ok... wow then :)
Rossyfox: soreau: Clean install
Rossyfox: It might not be default with Xubuntu though
Rossyfox: Xubuntu has a different package set
soreau: ah
soreau: yes
Rossyfox: What I am wondering is: when I added Tormod Volden's apt repository, I got offered a bunch of new drivers, are any of them useful at all to me?
soreau: What drivers? For what?
MostAwesomeDude: No.
TCW: Rossyfox, you do not need *anything* additional
Rossyfox: Well, this isn't really meant to be a gaming computer anyway
Rossyfox: It only has 1GB of RAM.
Rossyfox: I upgraded it from WinMe to WinXP a while back, and it was too slow for it. That's why I put Xubuntu on it.
TCW: Rossyfox, uninstall fglrx (if still on your system), reinstall all packages that have dri or mesa in its name, put "radeon" as driver in xorg.conf (or omit that line completely) restart X and you should be fine
TCW: the reinstall is just to make sure fglrx did not break some essential mesa / dri files (which are needed for 3D / performance)
soreau: TCW: How
soreau: 's your r5xx?
Rossyfox: Some of these packages want to remove other mesa packages
soreau: Rossyfox: What are 'these packages'
soreau: ?
Rossyfox: libgl1-mesa-swx11
TCW: soreau, how?
TCW: Rossyfox, a reinstall wants to remove some packages?
Rossyfox: It wants to remove libgl1-mesa-dri, libgl1-mesa-glx and xubuntu-desktop...
TCW: o_O
soreau: Rossyfox: All's you need to remove is packages with 'fglrx' in the name
Rossyfox: should I just let it remove them and then reinstall them?
TCW: Rossyfox, what exact syntax did you use?
Rossyfox: I'm using Synaptic
TCW: soreau, you are sure fglrx does not break some files?
soreau: TCW: Jaunty has their package management.. pretty well managed afaik
TCW: soreau, "just to make sure" you know :) and it does not hurt either
agd5f: mjt: 2.6.30 already has r6xx/r7xx support in the drm
mjt: ohhh
mjt: lol so I tried to replace working drivers with non-working ones :)
Rossyfox: I think it's because swx11 is a software renderer
Rossyfox: so it removes the hardware rendering drivers
TCW: Rossyfox, soreau thinks you can ignore the reinstall suggestion I made... so it doesn't matter
DanaG: swx11 contrasts with dri and glx/
DanaG: you'll want to reinstall libgl1-mesa-dri and libgl1-mesa-glx
TCW: TCW: How's your r5xx? <- soreau, was that your question above? :)
Rossyfox: Are there any things I could add to xorg.conf to help my performance?
MostAwesomeDude: Rossyfox: Not really.
MostAwesomeDude: We have this policy of enabling all the "hidden tweaks" by default. :3
[Enrico]: and that's a very good policy MostAwesomeDude :D
Rossyfox: I think adding that other apt has given me a newer version than comes with Jaunty anyway
Rossyfox: so I'll see what that does
TCW: Rossyfox, newer version of what?
osiris__: airlied: could you take a look at the hang in ut2004? I'm almost sure it's related to OOM condition
Rossyfox: X.Org's Radeon driver
airlied: osiris__: that would suppose I have ut2004 somewhere, DRI1 or DRI2?
Rossyfox: I know graphics are one of the worst things to be bleeding edge with but
Rossyfox: my curiosity is just too great
airlied: my main work PC died and I suspect I had it on it. hopefully fixed this morning
MostAwesomeDude: Rossyfox: Very little is bleeding-edge for your chipset.
osiris__: airlied: dri1. there's freely available linux demo on net
TCW: Rossyfox, you have such an ancient ati card there... think about that :)
Rossyfox: MostAwesomeDude: So it's the newer ones that ATI are being more reasonable about supporting?
MostAwesomeDude: Rossyfox: Well, it's not a matter of reason.
MostAwesomeDude: See, *we* are the officially endorsed driver now.
Rossyfox: Is that since the AMD takeover?
MostAwesomeDude: Yeah, AMD likes open source a lot.
Rossyfox: good ol' AMD
Rossyfox: I'm sorry to say I went with an Intel in this notebook though
Rossyfox: I go with whoever's got the best processor for the price I want at the time I buy
Rossyfox: How do I find out what driver is in use again?
TCW: it is since AMD realised how crappy fglrx is... and as support for older chips was a lot better with free drivers...
radiomark: Hi everyone, I just installed a radeon card in my machine, graphics output is working great -- good work
radiomark: But I have one question re: xinerama, to get it to work alongside another graphics card
radiomark: Is Xinerama supported? At the moment it crashes when I enable it, I found only old posts referring to this. Does it work in more recent drivers?
spstarr: with the r6xx-r7xx rewrite branch in mesa do we have primitive 3D triangles?
Rossyfox: So is it the case that contrary to what seems to be popular perception, newer hardware is actually better supported by Linux now?
airlied: osiris__: is it a full gpu hang?
TCW: Rossyfox, depends.... but in general no
airlied: I don't want to crash my laptop at the moment.
TCW: Rossyfox, how do you come to that conclusion?
osiris__: airlied: yeah, and wait one moment. I going to send a patch that prevents some earlier hang in the game
Rossyfox: Increasing manufacturer support?
airlied: osiris__: you got useVBO seT?
spstarr: looks at git
airlied: or whatever the secret ut2004 hack is
osiris__: airlied: I didn't know about any ut2004 hacks
osiris__: what does it do?
Wizzup: Quick question - is there a list of every card that is supported by the radeon driver?
TCW: Rossyfox, I don't get it... the newest Ati chips for instance, don't work well (because fglrx sucks like hell), old ones like the one you have works very well (because radeon does not suck as hell)
airlied: osiris__: http://dri.freedesktop.org/wiki/Benchmarking
airlied: see the ut2004 section
Wizzup: I found a list on Ubuntu.com, nevermind
osiris__: airlied: FYI with your latest mipmap fix, we have only 2 failed wine d3d9 tests!
spstarr: unless Ubuntu is using Fedora bits... Wizzup ...
airlied: osiris__: are they big problems?
Wizzup: spstarr, I was planning to use it on my Gentoo, but I was just checking if radeon supported 3650 HD. :-)
raevol: airlied: you're a wined3d dev? :o
spstarr: Wizzup: I have 2 of those.. and no only 2D EXA XVideo accel
airlied: raevol: no way, though I did clone it the other day for some reason
spstarr: Wizzup: laptop has one and full desktop card one
raevol: haha i see
osiris__: airlied: nope, point isn't clamped to specified min/max size
Wizzup: Ok, so no 3D as of yet? :)
osiris__: minor problem
spstarr: Wizzup: no 3D yet, even though the 2D is using 3D
osiris__: airlied: hmm. it looks like it just to give some perf boost, but since we don't really implement VBOs it's no win
Wizzup: Ok, no biggie. :-) I'm using the radeon driver on an old laptop of mine and it works flawlessly. Much better than fglrx
Rossyfox: TCW: But from what I've been told, X.Org's driver doesn't even have good 3D support for my chip...
Rossyfox: but better support for the R3xx/R4xx/R5xx series
TCW: Rossyfox, as good as the chip can be
raevol: TCW it's still on the way though isn't it?
TCW: raevol, hm?
raevol: 3d for r6/700?
Rossyfox: TCW: Then the 3D acceleration must not have been running because I know I got better OpenGL performance on Windows on this machine
TCW: Rossyfox, don't compare apples with oranges
Rossyfox: Wouldn't OpenGL vs DirectX be comparing apples with oranges?
spstarr: Rossyfox: there has been massive work done on the r3/4/5 support but its not merged yet
TCW: Rossyfox, I don't own a ati r2xx chiped card, I only know some folks who do and they are fairly happy with its 3D performance, when they acknowledge how old the chip is. But true, the Windows driver may be faster...
TCW: raevol, I don't get you
raevol: sorry i thought you were talking about a different card
airlied: osiris__: you send that patch for fix the eralier crash?
airlied: or am I just waiting on good old sf.net
osiris__: airlied: not yet, I'm doing last tests. I will let you know
airlied: cool my Pc is getting repaired now so I can crash laptop in a while :)
airlied: did you try under DRI2?
osiris__: hmm, I think I did and the app crashed during startup
airlied: so much for not crashing that laptop.
airlied: under DRI2 I see a too many elts warning
airlied: then I get some death
osiris__: airlied: I've sent the patches
osiris__: death as the machine hanged?
airlied: no just the gpu
osiris__: rs690?
airlied: no this was on my r500
airlied: I'm in DRi1 now so I'll play a bit
airlied: ut2004 is annoying as it grabs the keyboard
osiris__: when does it hanged? right after level start?
airlied: yeah once I tried to play a game
osiris__: did you see a few first frames?
airlied: I got a bit of the level intro pu
osiris__: so it's the same as here
osiris__: regarding the too many elts warning - it can be easily fixed by calling vbo_rebase_prims in r300DrawPrims if elt buffer is too big
airlied: sounds like a good idea
osiris__: we should also call vbo_rebase_prims if vertex buffer is too big (IIRC max is 64kB)
osiris__: *(64kB x vertex_size)
osiris__: airlied: here's another miptree related crash (wine d3d9 test on sw tcl), t->mt->bo expression causes the segfault (mt is null) while emitting textures' offsets
osiris__: airlied: to force swtcl on TCL cards I use tcl_mode=0 env var - it goes the same path as for non tcl hw
osiris__: airlied: bt of the crash http://pastebin.com/m1b0ef64b
airlied: osiris__: any instructions on building the d3d9 test suite?
osiris__: airlied: just compile the wine and in wine/dlls/d3d9/tests run make test
DanaG: heh, with fglrx, wine tests just segfault.
osiris_: how's the debugging going?
osiris_: airlied ^^
airlied: osiris_: I needed my laptop back :(, dell pc guy failed to fix it
airlied: osiris_: those patches on mesa3d-dev contain the initial ut2004 fix?
airlied: I'm trying to track down the makecurrent crash
airlied: which involves writing down how drawables and contexts work
DanaG: I tried ut2k4 for Linux... and the audio was rather broken.
osiris_: airlied: no, it's a fix for another bug that I think I've been hitting with ut2004 too
osiris_: airlied: oh, good. I hate that stuff ;)
DanaG: seems to be down: http://www.botchco.com/agd5f/
Rossyfox: Alien Arena just froze for me :<
zhasha: airlied: have you fixed that IRQ issue yet? (kind of tired of all the skipping)
Rossyfox: Should I remove pulseaudio if I don't need it?
Rossyfox: I'll tell you what is good for Linux 3D though
Rossyfox: the VirtualBox guest driver
spstarr: who controls the IRDC blog?
spstarr: Irregular radeon dev companion blog
spstarr: airlied: welcome to Gallium world :)
TCW: do I see it correctly, that when gallium3d is mature, mesa will be obsolete?
TCW: on the other hand... looks more like... dunno... :)
bridgman: TCW; Gallium3D doesn't replace Mesa itself, it just replaces Mesa's current hardware driver layer
bridgman: all of the higher level code stays (with changes to run over Gallium3D) -- think of Mesa as the OpenGL state tracker
bridgman: or "similar to OpenGL" ;)
bridgman: mesa is maybe a million lines in total, most of that stays
bridgman: spstarr; tirdc is maintained by Christoph (egore on IRC)
spstarr: ahh
bridgman: he is also the guy who makes "bridgman summoning" possible (via the logs)
bridgman: whether that is a good or bad thing is still open to debate
TCW: bridgman, I c
spstarr: bridgman: heh
bridgman: gallium3d is still hugely important though... the current mesa hardware driver layer was designed a decade or so ago and GPUs have changed completely since then
bridgman: if you want a rough idea, look in the mesa tree at src/mesa
bridgman: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa?h=r6xx-rewrite
bridgman: gallium3D + drivers kinda replaces the drivers/dri folder
spstarr: bridgman: when is the AMD folks going to begin porting the dri driver to gallium?
spstarr: or will the r6xx-rewrite work be easy to move to gallium structure
bridgman: when we get classic mesa running at roughly 5xx no-KMS level
spstarr: ok
bridgman: the 6xx-rewrite work should be fairly easy to move but realistically it will either move in a bunch of small pieces or will get rewritten to take advantage of what we learn from the first implementation
bridgman: I'm a big beliver in throwing away the first implementation
bridgman: which tends to make the people doing the first implementation unhappy ;)
bridgman: my guess is that we'll keep half and rewrite half, hopefully we'll rewrite the easy half
MostAwesomeDude: spstarr: r6xx port to Gallium will commence when the kernel parts are ready.
dmb: MostAwesomeDude, is the port of r5xx all ready started?
MostAwesomeDude: Yep.
airlied: MostAwesomeDude: textures next :-P
MostAwesomeDude: airlied: Well, *better* textures.
MostAwesomeDude: Basic 2D works, but mipmaps are wrong, 3D and cubemaps are missing.
MostAwesomeDude: And no texgen, stipple, AA, or point sprites.
DanaG: Biggest 3D thing I use is compiz.
airlied: MostAwesomeDude: you need the mipmap tree stuff or not?
airlied: I assume gallium can't do all of thaty :)
MostAwesomeDude: Probably.
MostAwesomeDude: Gallium provides pipe_texture, which is like the worst-named struct ever.
DanaG: pipe texture? you mean, like metal? because nobody would make a pipe out of wood. =þ
amarsh04: don't laugh, I've seen pictures of pipes made out of wood
DanaG: oh yeah, like in hot springs, as a cliché example.
amarsh04: I meant used as pipelines for drinking water - probably close to 100 years ago
bridgman: http://www.powerhousemuseum.com/collection/database/?irn=88660
bridgman: courtesy of the Australian Wood Pipe company