simplexe: how to enable powersaving mode? only ForceLowPowerMode?
jnoah1984_1: when building mesa, how do I tell the build to only build radeon r600, and winsys drm, etc?
yangman: --with-dri-drivers
jnoah1984_1: Winsys dirs: drm, Winsys drm dirs: intel <-- want to add radeon if possible
yangman: Winsys is gallium-related, iirc. there's no r600 gallium implementation yet
jnoah1984_1: ok
jnoah1984_1: how do I get the mesa build to only build r600 dri?
simplexe: jnoah1984_1: --with-dri-drivers=swrast,r600
jnoah1984_1: And once all is built can I install over what I have or is there a 'safer' method?
simplexe: jnoah1984_1: yeah
jnoah1984_1: lol, ok, what's the safer method
dbbolton: i specified "radeon" in my xorg.xonf, but from the look of things, it's falling back to vesa. how can i check which driver is in use?
MostAwesomeDude: jnoah1984_1: You can use LIBGL_DRIVERS_PATH to specify where *_dri.so are located.
jnoah1984_1: ok
MostAwesomeDude: Also, for Gallium+r600, as soon as airlied/glisse have good stable patches for KMS on those chips, I'll add r600 to the radeon winsys.
jnoah1984_1: on Fedora (rawhide) how do you get/use g++, gmake is asking for it
MostAwesomeDude: I haven't done it yet because the interface isn't finalized. (But it probably won't change.)
MostAwesomeDude: $ sudo yum install gcc-c++
jnoah1984_1: MostAwesomeDude: not doing gallium
MostAwesomeDude: jnoah1984_1: Then you should only need to set LIBGL_DRIVERS_PATH in order to get r600_dri.so picked up.
MostAwesomeDude: You might also want to use LD_LIBRARY_PATH to pick up the libGL.so you just built, but it shouldn't be needed.
jnoah1984_1: and where do I use these lovely little PATH definers?
MostAwesomeDude: They're just environment variables.
MostAwesomeDude: Either export them or use them right before commands.
jnoah1984_1: ok
jnoah1984_1: xf86-video-ati says it needs xorg-marcos, what's the title of the package in fedora?
MostAwesomeDude: $ yum deplist
MostAwesomeDude: Or does that only do binary deps?
MostAwesomeDude: Anyway, ISTR that the name is xorg-x11-util-macros, could be wrong though.
jnoah1984_1: MostAwesomeDude: binary only
jnoah1984_1: that was correct, thanks
jnoah1984_1: all these parts, mesa, drm, xf86-video-ati (git's) are dependent of eachother?
MostAwesomeDude: Kind of.
MostAwesomeDude: DRM and libdrm together provide the actual HW access.
MostAwesomeDude: The DDX has 2D accel and also card modesetting.
MostAwesomeDude: Mesa's completely independent, but it still uses the DRM interface for talking to the card.
jnoah1984_1: I am unable to even configure xf86-video-ati
jnoah1984_1: http://pastebin.com/d2b895b9e
jnoah1984_1: any idea/help?
MostAwesomeDude: You need xineramaproto. Creo que es en xorg-x11-xinerama-proto.
MostAwesomeDude: *I think it's in...
MostAwesomeDude: Talking in another channel in Spanish, sorry.
jnoah1984_1: no worries, I understood anyway.
jnoah1984_1: well that's not it
MostAwesomeDude: Hm. My yum search seems to be broken.
MostAwesomeDude: Find xineramaproto. It'll be one of the few packages with "xinerama" in its name.
MostAwesomeDude: (The other one is libXinerama, which you already probably have.)
jnoah1984_1: libXinerama and it's dev were the only ones
Moobyfr: hi
Moobyfr: I having some errors with my radeon card and modesettings, this is a 2300 (M64) r535
Moobyfr: kernel 2.6.31, xorg 1.6.3.901
Moobyfr: http://pastebin.mandriva.com/14339
jnoah1984_1: airlied, agd5f, can someone help me out with this? I am trying to just build xf86-video-ati git. http://pastebin.com/d2b895b9e
jnoah1984_1: MostAwesomeDude: any luck identifying that package?
MostAwesomeDude: jnoah1984_1: My yum doesn't wanna do yum search.
MostAwesomeDude: As I said before, I'm not convinced from that error that your configure is getting regenerated correctly.
jnoah1984_1: will you trying generating it and seeing what you get?
jnoah1984_1: are you not on rawhide?
MostAwesomeDude: I don't have a working dev box right now.
MostAwesomeDude: F12 decided to go off and die, and I'm still working on shuffling drives around.
jnoah1984_1: lol
jnoah1984_1: that sucks. good luck getting stuff working
jnoah1984_1: I am checking in fedora-qa about the package, but all must be away/asleep
airlied: xorg-utils-macro or somethnig, drunk now.
jnoah1984_1: haha
jnoah1984_1: I have the xorg utils macro
jnoah1984_1: I need the xinerama proto. lol
MostAwesomeDude: airlied: Drunk's good. Sober means having to deal with dead boxes now instead of later.
jnoah1984_1: MostAwesomeDude must get drunk then
MostAwesomeDude: jnoah1984_1: But I has chores to do.
jnoah1984_1: at 1 in the morning...
jnoah1984_1: ?
MostAwesomeDude: Sure, why not.
EruditeHermit: airlied: drunken irc
EruditeHermit: fun
airlied: is going to get drunker, time to go watch fireworks
EruditeHermit: airlied: why are there fireworks?
EruditeHermit: well have fun with them first =p
airlied: EruditeHermit: some city festival in Brisbane, also F111 planes doing dump and burn which is always cool
airlied: gone &
haeger: Can give me someone a hint how i can get kms running with kernel 2.6.31 and the xf86-video-ati driver? (archlinux)
nanonyme: Which card?
haeger: nanonyme: r300 (firegl v3200)
AStorm: haeger: simple: build latest libdrm with --enable-radeon-experimental-api, then xf86-video-ati latest (mesa latest is recommended as well)
nanonyme: Compile libdrm with --enable-radeon-experimental-api, then compile xf86-video-ati and Mesa against it and compile a kernel with kernel modesetting enabled by default from staging options.
AStorm: in the kernel, enable STATING option
AStorm: *STAGING
AStorm: and in that menu find the option to enable KMS.
AStorm: build DRM and RADEON options in
AStorm: enable BUILD_FIRMWARE_IN.
AStorm: build kernel, make install, done.
AStorm: oh, make sure FB and FB_CONSOLE are enabled.
AStorm: :)
AStorm: *FRAMEBUFFER_CONSOLE
haeger: is ati servicing not enabled by default in kernel 2.6.31??
nanonyme: Framebuffer console is only necessary if you want to be able to VT switch.
AStorm: haeger: it is not.
haeger: oh -.-
AStorm: it is enabled by default if you use drm-next branch of kernel drm
AStorm: (only set radeon.modeset=1 there on kernel commandline)
haeger: hmmm i will give that a try ^^
haeger: thanks!
AStorm: nanonyme: who wouldn't want to switch VT? ;p
AStorm: some kind of embedded?
nanonyme: AStorm: Pure desktop user.
AStorm: haeger: also, drop video=... and vga=... options from kernel command line
nanonyme: Someone who probably came in from Windows side.
AStorm: nanonyme: it's a good fallback to have
AStorm: hm, I don't know, maybe video=radeondrmfb will work ;>
AStorm: ah btw, the panic code is next to useless right now
Zajec: agd5f: will you backport r600 changes to mesa 7.6?
AStorm: it drops to text mode *after* the OOPS happens and doesn't reprint it
AStorm: agd5f: ^ re panic code
AStorm: agd5f: add dmesg buffer printk to it
AStorm: that should print the OOPS and final throes fine
AStorm: (It forces a reinit well apparently, vt07 is restored
AStorm: (or maybe a kind of print that doesn't go to dmesg log)
AStorm: hello guys
AStorm: I'm hitting some font corruption bug here
AStorm: who wants a screenshot?
AStorm: (that's w/o composite)
AStorm: nothing special in X log or syslog
AStorm: looks like characters and stuff is replaced by blocks
AStorm: this sounds like a regression in the latest 3 commits in drm-next
Zajec: AStorm: just post it... we always like collecting ideas for screensavers :)
AStorm: hehe
AStorm: I get to install a screenshot tool first
Zajec: import new.screensaver.idea.png
Zajec: import is command
AStorm: wait, maybe I indeed have imagemagick
AStorm: :)
AStorm: Zajec: http://omploader.org/vMmMyOA
Zajec: hm, not much impressive as screensaver
Zajec: maybe as virus? :)
AStorm: heh.
Zajec: will you bisect that?
AStorm: no, I won't run around bisecting 3 commits
AStorm: I'll just test them all
AStorm: and likely 2 are unrelated ;p
AStorm: only one looks like it could cause that
Zajec: heh, probably right :)
dileX: Zajec: hi, the PM patchset is from you?
suokko: AStorm: Sounds like DFS/UTS bug
AStorm: suokko: indeed
AStorm: but I have latest drm-next etc.
Zajec: dileX: yes
AStorm: it must've been introduced right now
suokko: yep. Same beast as I have been trying to tame
AStorm: let me find the likely relevant commit id
dileX: Zajec: which gpu did you test with? and against which kernel (vanilla .31)?
suokko: Sounds like good idea if yo ucna find it :)
Zajec: dileX: it's patch for KMS
Zajec: dileX: so it's for drm-next airlied's tree
Zajec: dileX: this should work with everything with AtomBIOS
nanonyme: This is about r600?
Zajec: dileX: but make sure you read, that it's just a beginning of work
nanonyme: If so, it'd be a patch in ddx that enabled it.
Zajec: dileX: nothing really to be excited about yet
dileX: Zajec: someone has to start testing :-)
Zajec: dileX: :) sure, you're welcome
nanonyme: AStorm: Try the EXANoDownloadFromScreen xorg.conf option?
AStorm: nanonyme: I might.
dileX: Zajec: not this we - thinko will enjoy munich with some other sidux guys
AStorm: I've only hit this once
nanonyme: Yeah, seems pretty random for me too.
suokko:
Zajec: suokko: ;)\
AStorm: or cause fires.
Zajec: suokko: actually i changed my engine clock to sth 10x higher than maximum and it didn't burn :) just locked :)
suokko: AStorm, nanonyme: yes. It is very random to me after I added some protection to DFS/UTS
AStorm: suokko: add some logging instead so we can track it down
suokko: AStorm: You would have to do testing after is font operation in xserver/exaexa_glyph.c to see when it gets corrupted and gie warning
suokko: gie*
suokko: give*
nanonyme: AStorm: You probably want to revert the drm-next blitting commit though if you want to get any useful debugging information out. :P
AStorm: nanonyme: yep
nanonyme: Stock drm-next floods dmesg.
suokko: Then another place that can cause that corruption is kernel side BO move oepration
AStorm: nopes.
AStorm: nanonyme: no it doesn't
suokko: So it is hard to know which is really broken
nanonyme: Does for my rv670.
AStorm: nah, that's been fixed.
AStorm: pull drm-next.
AStorm: drm/radeon/kms/r600: fix blit dword count for non r6xx
AStorm: this.
AStorm: ok, now, how do I add the EXANoDownloadFromScreen to hal-based setup?
AStorm: (no xorg.conf)
jcristau: vim xorg.conf
suokko: AStorm: You have to create the xorg.conf
suokko: dpkg-reconfigure does it in deb systems
suokko: So you get good basic structure there
nanonyme: AStorm: xorg.conf works for overrides normally.
jcristau: AStorm: Section "Device", Identifier "foo", Option "EXANoDownloadFromScreen", EndSection
AStorm: but I'd have to add a whole section, a screen and all foo.
jcristau: no
jcristau: just 4 lines should be fine
AStorm: Identifier "foo"? ;p
AStorm: what's the foo?
nanonyme: Identifier doesn't matter. :3
jcristau: identifier is mandatory, but you can set it to whatever you want
nanonyme: Yeah.
nanonyme: Driver would matter but it, on the other paw, isn't mandatory.
suokko: hmm
rah: I get the feeling that EXANoUploadToScreen causes problems
suokko: too
rah: hmm
rah: Sep 12 12:50:56 myrtle kernel: [drm:radeon_ring_write] *ERROR* radeon: writting more dword to ring than expected !
nha: there's a typo in that message
frej: don't remove... easy googling ;)
rah: more like a thinko I think
frej: all error msg's should have a unique identifier ;)
rah: like a unique number or a code
rah: we could call it an "error code" :-)
frej: in principle it could be a onetime random id whenever the code is added
frej: fun... 2.9GB debug log from radeon_debug=all, Anoyingly reproducing a crash takes longer time when debug is on (maybe because of slower rendering)
nha: yeah, that's a likely culprit
nha: particularly because big debug log = lots of disk activity which can also change system behaviour
suokko: frej: luckily debug log compress well with high compression levels ;)
frej: suokko, less/vim sucks though :/
suokko: frej: Ctrl+C and then G should work well in vi
Zajec: how should I compile Mesa on x86_64 to have both: 32-bit and 64-bit drivers?
Zajec: i want to try run 32bit game in wine
BCMM: what is the status of free AT
BCMM: I drivers?
BCMM: for recent graphics cards
Zajec: BCMM: experimental 3D if you mean that
suokko: Zajec: You have to crosscompile libdrm+mesa
Zajec: BCMM: openarena works great i belive
BCMM: Zajec: so no stable 3d opengl for recent cards?
Zajec: BCMM: however still some thing to fix
suokko: Then install them in somewhere and make sure ld loads them for wine
Zajec: BCMM: not yet stable
Zajec: suokko: should I google for "crosscompilation linux"?
suokko: hates the DFS bug
suokko: Zajec: -m32 is enough ;)
BCMM: i'm deciding whether to get an nvidia or ati card; i've used the closed nvidia drivers for a while with not too many problems, but i've heard of the closed ATI drivers preventing people upgradeing xorg or the kernel
suokko: If you have multilib version of gcc installed
Zajec: suokko: oki, thanks
BCMM: and i'm trying to work out whether the closed nvidia drivers or the open ati ones will give me less trouble
Zajec: BCMM: well, nvidia has quite stable drivers with nice features
BCMM: Zajec: yeah
Zajec: BCMM: however you can expect open source ATI drivers becoming stable this year
GoGi: how can I try kernel modesetting for R700?
suokko: BCMM: open at drivers should be ready for 2.6.32 kernel mostly
Zajec: suokko: i'm not worrying of DRM
suokko: Thatmeans opengl 1.5
Zajec: suokko: that will be for .32 probably, indeed
BCMM: i'm annoyed with them not open-sourcing it, and it has had some problems in the past, but i was impressed with the way nvidia worked with the KDE community when kwin started uncovering up performance bottlenecks
Zajec: suokko: i think about mesa rather
suokko: Zajec: I think mesa side should be ready about same time
BCMM: suokko: what is "ready"? full opengl support?
Zajec: suokko: that's what i said ;)
Zajec: BCMM: full opengl needs gallium
Zajec: r600g driver
Zajec: which's writing was not started yet
chithead: BCMM: if you don't mind being at the mercy of nvidia for giving you updated drivers, you get more value there atm. latest X developments (kms, xrandr 1.2, ...) you will only get with open source drivers however
Zajec: devs want to have stable mesa r600 driver first
chithead: BCMM: maybe you can give more details about your use case
BCMM: i want to run kwin with effects turned on
BCMM: and ideally be able to play opengl games
BCMM: nexuiz and ioquake3
BCMM: at least
chithead: quake based games (nexuiz. ioquake, padman, openarena) work for me on hd3200 igp
suokko: BCMM: ooss ati should do that when 2.6.32 is realsed without major problems. Some extra effects might not work in kwin
suokko: If there is any requiring GLSL
BCMM: what are GLSL?
BCMM: (is)
suokko: Opengl shading language
GoGi: igp?
BCMM: chithead: what are these latest X developements you speak of?
suokko: GoGi: http://xorg.freedesktop.org/wiki/radeonBuildHowTo
chithead: GoGi: integrated graphics processor (ie. onboard shared-memory)
GoGi: thank you
chithead: BCMM: kernel modesetting and dynamic output reconfiguration
BCMM: chithead: does that mean adding screens without restarting X?
BCMM: also, what is the advantage of KMS?
chithead: BCMM: adding/removing screens, configuring custom resolutions, positioning, rotating, etc.
BCMM: does the kernel have release schedules or is it "when it's done"? how long is it likely to be before 2.6.32?
Zajec: BCMM: big res console, faster switching, nice booting, better power management
BCMM: oh, the console could run at for example native resolution of my monitor?
Zajec: BCMM: check how long did it take to release 31since 31-rc1
Zajec: BCMM: and you will know :)
Zajec: BCMM: you should be able to use KMS beginning with 2.6.32-rc1
chithead: BCMM: kms for r500 is included in kernel 2.6.31, r600 3d will come in 2.6.32 (r600 kms possibly not yet)
Zajec: BCMM: no "could". it does :p
BCMM: and therefore no waiting around while the monitor changes res when switching to a console?
Zajec: chithead: .32 will provide r6xx kms
BCMM: are r500 and r600 gpu core revisions?
chithead: oh good
Zajec: chithead: drm-next will me pulled to master, and drm-next contains kms code :)
BCMM: (sorry, i've never owned an ATI card before and don't know much about them)
Zajec: BCMM: yeah
chithead: BCMM: r500 refers to cards up to radeon x1950, r600 refers to radeon hd 2400 and later
Zajec: BCMM: http://en.wikipedia.org/wiki/Comparison_of_ATI_graphics_processing_units
BCMM: would it be offtopic to ask for recommendations about a card to get here?
mjg59: core architecture rather than core revision
Zajec: BCMM: r300-r500 are similar, supported by one driver
Zajec: BCMM: r600-r700 use new driver
Zajec: mjg59++
BCMM: what is R800? does it work?
suokko: BCMM: R800 is HD 5xxx
Zajec: not yet release afaik
suokko: That will be published in 22nd/23rd this month
BCMM: ah i see
BCMM: there seem to be a number of ATI drivers floating around; what is the name of the in-kernel one we're discussing here?
GoGi: are there developers paid by AMD to write the drivers?
suokko: Too bad there won't be any value cards in begin but something hd4xxx series should be cheap and powerful
chithead: GoGi: yes, some are employed by amd, some by linux distributors, others are volunteers
suokko: GoGi: yes. 3 are currently working for open drivers. Redhat has also developers for radeon
BCMM: and is the driver likely to be extended to support R800s?
suokko: yes. I think there is some work done behind closed doors to publish support soon after launch
BCMM: suokko: work done behind closed doors towards the open driver?
chithead: BCMM: yes, they cannot publish the code before the cards are announced
BCMM: oh i see, AMD helping get support ready but not wanting to show the competition the features before release day?
BCMM: with the R800s about to come out, have i picked a bad time to try and obtain an ati graphics card?
chithead: BCMM: the good thing with open source drivers is that support for your card will not become worse than it is now
suokko: BCMM: If you don't want to buy high end card (it sounds you don't need one) then no
BCMM: suokko: i want a decent but not very high end card
suokko: Because value cards for less than 100€/$ are going to come after a few months
BCMM: i also have a windows partition taht i might want to play newer games on (i know i know but it's cheaper and more open than owning a console)
BCMM: suokko: that's what i meant; are thing just about to get a lot cheaper?
suokko: BCMM: Then you should think about waiting for r800 and see if it is what you want
BCMM: i'm balancing expence verses the horrible noise coming from my GeForce 7300 GT with a dodgy fan
suokko: BCMM: Performance/price ratio performance/power ratios should be better in r800 cards than in r700 cards but you have to wait a bit for them
BCMM: bother, i wanted an easy decision :
BCMM: :)
chithead: best bang for the bug you currently get from radeon 3650 (prices starting around 30€) or radeon 4650 (from 40€)
BCMM: chithead: that sounds approximately my range
nha: I'm currently chasing a bug that gives my pretty good bang ;)
chithead: s/bug/buck/ :p
suokko: hates writing test case to kernel :/
nha: [12110.105833] Forbidden register 0x4FD4 in cs at 211
nha: *sigh*
nha: I guess I'll have to update the kernel again at some point
nha: anyway, r300g doesn't seem to use that yet
suokko: Or disable cs checker
nha: nah, that's not the right way to go
BCMM: Zajec: where can i see the dates of kernel releases so i can get an idea of timescales?
Zajec: BCMM: kernel.org ;)
Zajec: http://www.kernel.org/pub/linux/kernel/v2.6/
Zajec: that dir listing includes dates
BCMM: Zajec: not on the front page, and when i looked at pub i couldn't work out which were RCs
suokko: BCMM: About 3 months for each release and we just got 2.6.31 out
BCMM: so if i got a radeon card, i would be able to use it with 2d right away, and 3d in about 6 months?
suokko: 2D now and 3D and KMS in 3 months
BCMM: sorry, meant to type 3
Zajec: so as i said :) this year ;)
BCMM: ok, i undestand now...
BCMM: oh, is there a closed driver that i could also use in the meantime?
Zajec: BCMM: check official site
Zajec: fglrx
BCMM: thanks
Zajec: works more or less
BCMM: so how do you enable the driver? is it CONFIG_DRM_RADEON?
Zajec: you may need to reinstall system after playing with fglrx... but you will some installations anyway if you want to try 2.6.32
suokko: BCMM: There is but it is a bit slow to support the latest distributions. Fedora is out of question if you use AMD driver
BCMM: "you may need to reinstall system after playing with fglrx" ook, why?
Zajec: BCMM: for fglrx you don't need any kernel magic
nha: reinstalling the system is a bit extreme
Zajec: BCMM: you will need to install 2.6.32 and mesa 7.6
BCMM: Zajec: i meant for the driver discussed in this channel
Zajec: well, ok, maybe wrong idea
nha: but I think fglrx still overwrites libGL.so and so on, and it can be hard to track down which files need to be repaired to deinstall fglrx completely
Zajec: anyway reinstalling kernel, libdrm, mesa maybe
nha: afaik some distros provide tools that make it easier
flo|linux: hi
BCMM: suokko: do you mean you need drivers tailored to specific kernel builds for the closed drivers?
Zajec: afk
suokko: Closed drivers have to have wrapper code for kernel/xserver changes
BCMM: suokko: so why is fedora out of the question?
suokko: Fedora has too many patches in kernel and xorg so driver doesn't support Fedora
flo|linux: does the open source radeon driver have any limitations on kernel versions?
flo|linux: with the fglrx, i would have to fiddle around a bit when i don't use a vanilla kernel
flo|linux: do i also have to fiddle with the radeon driver?
[Enrico]: flo|linux: it is better to have a new kernel, but it works with almost all (for old cards almost)
BCMM: so is AMD supporting kernel driver development?
suokko: flo|linux: Latest development foes to the latest kernel of open drivers
flo|linux: but i can recompile my kernel with different settings (but the same version) and my driver will not break?
nha: obviously you'll have to recompile the radeon drm also
nha: but it won't break
flo|linux: "obviously" ^^? I didn't know that ^^
suokko: flo|linux: If it breaks it is a critical bug and should be fixed soon
flo|linux: and, when i need multiple kernels at the same system, and every kernel needs its own drm, is that possible?
suokko: flo|linux: yes. drm is kernel modules so it is installed to /lib/modules/
flo|linux: ok
flo|linux: and when i have two kernels with the same version but different settings... how will this work then?
suokko: btw, bugs only get fixed if they are reported to https://bugs.freedesktop.org
flo|linux: or is kernel version not 2.6.foo, but 2.6.foo-configuration-one ?
suokko: flo|linux: You have to add minor version numbers to them so they have different build numbers
suokko: yes. Like that
nha: flo|linux: you *always* have to recompile kernel modules, or the module loader will complain about ABI mismatch
flo|linux: ok
nha: flo|linux: this is the case for *all* kernel modules
nha: you can force override it in some situations, but it's not recommended and people will kill you if you do it and then complain about problems
flo|linux: ok
nha: oh and yes, you can have several kernels on the same system
nha: look into /lib/modules, there is one subdirectory for each kernel
nha: so the modules for kernels are kept entirely separate to avoid conflicts
flo|linux: afk
nha: Does anybody have an idea why r300g fails at glxgears in master?
nha: I've tried to bisect it, but somehow I'm getting a commit that seems rather unrelated :/
nha: btw, fails = gears are all over the place
suokko: nha: Which commit you get for bisect?
suokko: I have seen that all over place effect in r200 and Ithink it was most of times because something not recompiled correctly
nha: it was your commit that adds more explanatory output to the -22 error ;)
nha: and I always compiled with make clean
nha: perhaps some card state got stuck
gustaf1: just tried vanilla 2.6.31 with staging ATI KMS on r500, and got blank screen (monitors in sleeping state), both on boot and when starting gdm (blindly)
nha: suokko: or is there something more than make clean?
suokko: make -B
suokko: nha: agd5f did report some crashing from my debug logging changes too. So it sounds like I should not change anything debugging related. ;)
nha: weird, because the failing tests also spam debug messages again
nha: perhaps it's some case of bisect doing weird things across a merge?
frej: nice, from 2.9GB to 22mb (7zip though).. :)
suokko: frej: You probably would only need tail -n 10000 from the log
suokko: Or even less
frej: True thought about it, but since it's just 22mb i'd rather avoid a possible roundtrip (if it failed) :/
suokko: But 7zip compression is slow ;)
frej: i know :(
frej: but you don't have to look at it ;)
frej: if you prefer i can do that instead, for later reference
nha: MostAwesomeDude: do you know what's wrong with r300g?
nha: glxgears and other things go majorly crazy, and git bisect appears confused by merges
nha: (in fact, during bisect I get misrendering that looks entirely different from the problem that I have in master)
Zajec: nanonyme: just use atom
nanonyme: As in, format pages to be better readable with a small screen.
nanonyme: I guess I could.
nanonyme: Just have to add the pages as bookmarks, I guess.
nanonyme: Thanks for reminding the obvious, I often overlook the simple ways. :p
suokko: nanonyme: So only thing that should be added would be cgit link to add page to bookmarks ;)
MostAwesomeDude: nha: No idea.
MostAwesomeDude: I have not touched that code in a bit.
MostAwesomeDude: But most of the changes are coming from other parts of gallium.
nanonyme: Only thing needed is I gather the links once to my cell phone's bookmark list. Rest should be there already. :3
nanonyme: MostAwesomeDude: Who's winning, you or shatter? ^^
MostAwesomeDude: nanonyme: Actually, I think my cough's beating both of them.
zhasha: MostAwesomeDude: cooper has been committing to r300g
MostAwesomeDude: zhasha: Well, I assume he's got good reasons for it.
zhasha: yeah he fixed it :P
MostAwesomeDude: He's good people. If his changes are breaking things, you'd better let him know.
zhasha: I'm just saying his changes may be indirectly linked to the bug
zhasha: I've noticed that glxgears draws the window, with borders et al. inside itself
zhasha: and it nests and nests. I think it swallows memory like no other
MostAwesomeDude: Hm.
MostAwesomeDude: nha's change looks good. I'm kind of saddened that cooper didn't fix the indexbuf stuff while he was in there, but that's okay.
MostAwesomeDude: continues to read log
zhasha: MostAwesomeDude: mipmaps are still dead
MostAwesomeDude: zhasha: Oh, I know that. I may be able to fix that.
zhasha: MostAwesomeDude: I've been trying with no luck
MostAwesomeDude: agd5f: Could I get a clarification on e938d4a053 in drm/mesa? I don't know if that should be there.
MostAwesomeDude: zhasha: You've gotta unify texture and sampler emit, because they cross into each other's registers..
MostAwesomeDude: Or did I push that already?
zhasha: I'm not sure
MostAwesomeDude: I did, looks like.
MostAwesomeDude: But I did *not* push the patch directly after it, which adds in mipmap emit.
MostAwesomeDude: But it doesn't matter unless generate_mipmap stuff has become less broken.
MostAwesomeDude: Hm. 8f990f928b1 and 80ea03bd17 are questionable, especially since most of those are not actually going to get regenerated or revalidated, just reemitted.
bridgman: I believe Cooper was going through the redbook tests one-by-one and getting them running, not sure if he was running glxgears as a regression test
bridgman: that seems like the first thing we should find out
bridgman: ie if glxgears is working on his system
malgar: hello Radeon 9600, kernel 2.6.30 , distro debian sid, driver: radeon. 3D is working but it seems to me that 2D is slower than with nv drivers of an older nvidia card... like maximizing/minimizing windows.. drag.. and so on.. could be a driver/card problem=
malgar: ?
kcodyjr: 9600 should be strongly supported with distro drivers, i would think
bridgman: are you running xaa or exa ?
bridgman: there was an X server change in early 2009 that seems to cause bad delays maximizing windows unless you're running exa
malgar: bridgman, are you talking with me?
malgar: i don't know what xaa or exa are
bridgman: malgar... malgar... yep ;)
bridgman: they are acceleration options - xaa is older, exa is newer
bridgman: in the device section of your xorg.conf you can put
malgar: ok.. are they in xorg.conf ?
malgar: ok
bridgman: Option "AccelMethod" "EXA"
bridgman: (or xaa)
bridgman: default was xaa until quite recently
bridgman: so try exa
kcodyjr: bridgman, just as an intellectual curiousity, under what conditions should xaa be faster than exa? i understand the difference was driven by a usage model change.
bridgman: xaa used to be faster when the code in xserver wasn't handling fonts efficiently, although I don't know the details
malgar: bridgman, i have EXA
MostAwesomeDude: Glyphs and traps might still be faster in XAA.
bridgman: as of about 6 months ago exa seemed faster all round
bridgman: malgar, can you pastebin your xorg log ?
suokko: kcodyjr: xaa is faster if exa hist a lot of software fallbacks
suokko: Like with gonme it does :(
bridgman: suokko, I didn't think we were hitting many software fallbacks with current exa drivers
bridgman: is there more than just traps ?
suokko: trapezoids are one which is often called by gnome
MostAwesomeDude: Component alpha might not be handled in all cases.
bridgman: xaa accelerates trapezoids ?
MostAwesomeDude: Traps shouldn't be a problem with that sweet hax that we've got now for using VS to warp things.
MostAwesomeDude: Yeah, I'm pretty sure it does.
kcodyjr: i would think exa and xaa both would require a very high percentage of acceleration coverage, such that the gpu is doing "enough" more of the work to overcome the performance loss of the xserver having to go over the bus to reach the framebuffer
MostAwesomeDude: Generally, yes.
kcodyjr: which leads me to think it's probably benchmarkable, given even a halfway decent profile of the popular desktops' usage, to tell the user when they're better off switching to shadowfb
kcodyjr: there's one other thing that bugs me though - how can exa or xaa function on platforms that don't allow dereferencing a pointer into i/o memory?
MostAwesomeDude: Well, to be fair, x86 is one of those platforms.
kcodyjr: x86 is one of the few platforms you can count on it working
MostAwesomeDude: Ever debugged X? If you accidentally step off into video memory, don't expect things to keep working. :3
MostAwesomeDude: Honestly, I always assumed glibc had some trickery for it.
MostAwesomeDude: Dang it, now I'm thinking on it.
kcodyjr: that's not what i'm getting at; i mean to say that at least x86 lets you linearfb[pixeloffset]=foobar as a simple memory write. on some platform, you can only iowrite32(linearfb+pixeloffset,value)
zhasha: are you proposing accelerating xaa in gallium now?
kcodyjr: i have no idea what if anything i'm proposing, i'm just wondering what the thinking is for platforms that don't allow direct writes into memory mapped i/o space
MostAwesomeDude: zhasha: Jakob was thinking about plugging in at the GC level, so instead of accelerating the five EXA ops, we'd be accelerating the "higher-level" Xcore, Xrender, Xv, DRI ourselves.
MostAwesomeDude: It would be *massively* faster for a few things.
zhasha: what does that entail exactly?
MostAwesomeDude: But it'd be more typin'.
zhasha: I mean, does it include primitive drawing etc.
MostAwesomeDude: kcodyjr: Well, I assume that glibc's memcpy handles it for us.
MostAwesomeDude: zhasha: Yeah, Xcore is fills, polys, and lines. Oh, and glyphs. Xrender is compositing.
zhasha: how are glyphs rendered now?
kcodyjr: MostAwesomeDude, how could glibc possibly intercept what the compiler thinks is a variable assignment?
MostAwesomeDude: kcodyjr: We don't dereference pointers to VRAM.
MostAwesomeDude: In EXA, for example, if we need to migrate a pixmap back to main memory, we memcpy it back.
MostAwesomeDude: And then do all the unaccelerated ops in main memory.
kcodyjr: oh? i saw some of that a while back. that's a good thing. but doesn't the fb pointer (in vram) get handed to the X server itself at device init?
MostAwesomeDude: Sure.
MostAwesomeDude: But I don't think it's ever dereferenced in acceleration code.
MostAwesomeDude: It's just used for memcpy() fallbacks.
kcodyjr: i don't know enough about the server internals to share your confidence that only the acceleration code ever touches it - clearly enough there's code somewhere that lets unaccelerated usage dereference that pointer
MostAwesomeDude: Well, I've been mucking around in there enough, and I haven't seen anything like that.
kcodyjr: then i'll take your word on it until and unless i see otherwise. but, i think it would be worth the exercise for someone to get a name of such an architecture, and see what happens... may not be an issue for the pc-compatible gpu vendors anyway
jcristau: kdekorte: re: 23816, you probably need to vt switch away from X
kdekorte: jcristau, ok let me try that
kdekorte: jcristau, vt switch locked up my machine...
jcristau: win..
kdekorte: jcristau, with drm-next been getting a lot of lockups.. probably 5-10 a day
kdekorte: jcristau, nope vt switching away does not make drmstat work
jcristau: oh well
kdekorte: jcristau, also tried switching it init 3 and running it.. still nothing
zhasha: MostAwesomeDude: how much is Xcore used by say, GTK?
MostAwesomeDude: zhasha: Enough, probably. Glyphs, at least.
zhasha: MostAwesomeDude: and glyphs are currently unaccelerated?
MostAwesomeDude: I'm not sure how much of it's actually just copying things from one spot to another.
MostAwesomeDude: zhasha: Oh, no, glyphs are, but they usually use weird depths like A1 that are tricky to accelerate.
MostAwesomeDude: The glyph cache turns those into A8 so that cards can accel them.
zhasha: huh, how does freetype draw such pretty fonts then?
MostAwesomeDude: AA.
MostAwesomeDude: Although at this point I must admit that I'm kind of sketchy on the entire process.
MostAwesomeDude: I watched a presentation on it last year, but I think things have changed. A lot.
zhasha: how's shatter by the way? I can't find any code :(
nanonyme: thinks everyone should be obliged to buy MAD a drink after he finishes shatter
MostAwesomeDude: nanonyme: Well, as long as we're doing DNF promises, I'd like a pony.
MostAwesomeDude: zhasha: http://cgit.freedesktop.org/~csimpson/xserver/log/?h=shatter is stuff that doesn't suck.
nanonyme: DNF?
MostAwesomeDude: I don't have any rendering redirection code that I seriously trust.
MostAwesomeDude: nanonyme: Duke Nukem Forever.
nanonyme: Ah. :)
mzz: doesn't understand what everyone sees in ponies
zhasha: you don't think you'll ever finish shatter? O_o
bridgman: mzz; it's tradition; in my last company everyone wanted a helicopter
mzz: now that I can understand
nanonyme: Hey bridgman.
MostAwesomeDude: To be honest, if I did get a pony, I'd give it to airlied; he's wanted one forever.
bridgman: but everyone was young once and not everyone wanted a helicopter then, hence the universality of ponies
nanonyme: Cute.
MostAwesomeDude: I better finish; I was going to demo it at XDC.
bridgman: hi nanonyme
bridgman: ;)
zhasha: "What 12 year old kid wants a motorized dirt bike?" - Sheldon Cooper
MostAwesomeDude: But my code's been fail, my comps have been dying, and I'm coughing up various internal body parts.
bridgman: geez, I was racing dirt bikes at 12
bridgman: back when I was short
zhasha: MostAwesomeDude: I wish I could come but it's way over in 'murrica
bridgman: MostAwesomeDude; sounds like one of those cross-platform viruses
nanonyme: seriously did not expect to be running working DRI2 at this point on his r600, still quite shocked that he is ^^
MostAwesomeDude: zhasha: There might be funds for devs, not sure though.
MostAwesomeDude: Not sure who to ask either. :T
zhasha: nanonyme: expressing yourself in the 3rd person, fancy
zhasha: MostAwesomeDude: I'm not technically a dev
MostAwesomeDude: bridgman: Well, if I fix up the comps, then I get better, right?
zhasha: I'd give you my old PC except it's a piece of crap
zhasha: and it only has an r200
nanonyme: zhasha: That's what /me is for?
zhasha: I think...
MostAwesomeDude: Don't worry about it. I've been workin' on it.
zhasha: or is 9100IGP r300?
MostAwesomeDude: The fileserver's back up, and it yielded an extra drive, so next on the agenda is the desktop.
zhasha: I also have an r100 :P
Zajec: bridgman: what is state of your TODO list? sometime ago you put releasing audio engine specs on it...
zhasha: the infamous ATi All-In-Wonder Radeon 7200 w/ TV tuner
kcodyjr: think i have one of those kicking around too, not sure if it still works.
zhasha: oh mine works
zhasha: AGP x4 on a K7
bridgman: 6xx/7xx IRQs are top of the list, then a bit more power management, then audio I guess
zhasha: and a 1.4GHz Athlon XP 1600+
bridgman: I feel like something is missing... oh yeah, evergreen
MostAwesomeDude: I'd request the MC/iDCT blocks, but I don't have time to work on that anyway.
zhasha: Too bad I don't still have that awesome 25/50MHz PC with windows 95
bridgman: agd5f has put together a doc on textures, reviewing that now
MostAwesomeDude: bridgman: Ooh, that would be so nice. There's so many little corner cases on textures.
bridgman: MC is really just 3D engine; we stopped using IDCT in our drivers because anything over about a 300 MHz CPU was faster
bridgman: we keep stumbling across useful internal docs; every time we find something we either write code or make a doclet
bridgman: we = agd5f ;)
bridgman: at least the writing part; I do some of the finding ;)
MostAwesomeDude: bridgman: So I (or any other enterprising youngster, hint hint) have everything needed to do XvMC either in Gallium or in DDX?
bridgman: I believe so; with the obvious qualifier that we will probably find something missing in the process of actually making the code work
bridgman: in principle though MC is just a bunch of little blits
bridgman: Cooper was starting to work on it but I asked him to look into 300g first
MostAwesomeDude: Well, I think that work put into r300g is better, since the MC code is generic.
kcodyjr: i would think it'd be in gallium, since you have to keep some mpeg state between frames
MostAwesomeDude: kcodyjr: XvMC provides for that. It's still kind of a stupid pain though.
MostAwesomeDude: But that's what st is for!
Zajec: bridgman: i was asked on phoronix forums about gpu temperature
Zajec: bridgman: do you know sth about reading it?
Zajec: can this be done by some register?
Zajec: bridgman: ok, that todo doesn't look so scary :)
bridgman: until late 6xx and 7xx temp sensing was always done by an external fan/temp chip connected via i2c
bridgman: agd5f seems to understand the bios tables which show how the devices are connected
bridgman: starting mid 6xx and up some of that capability was moved on chip but we haven't dug up any info on it yet
bridgman: that's the "bit more power management" stuff
bridgman: on the todo list
zhasha: MostAwesomeDude: what are you up to these days btw?
MostAwesomeDude: zhasha: As soon as I get back on my feet, gonna finish shatter, then start acting like the radeon-gallium maintainer.
mmp: hello; anyone wants to spend their free time by debugging resume from S3 on RS690 (so far locks up:)
mmp: (running 2.6.31)
mmp: (or at least to give few hints where to look for errors :)
moeSizlak: what is the best way to go from f11 to rawhide
moeSizlak: preupgrade fails with "failed to download installer metadata"
suokko: mmp: Bug reports are the best way
Zajec: do we use i2c already for communication with anything?
mmp: suokko: usually yes, I think is much better to discuss this with developers than just opening a bugzilla ticket and waiting a year to solve it; I can do sort-of debugging myself, I just need some kick :)
Zajec: what actually can be connected to i2c?
Zajec: gpu, temp control, sth else?
mmp: suokko: and it irritates me for too long to just open a support ticket :)
suokko: Then you should jsut start by running the suspend resume with all the debug stuff on an see what turns out
mmp: suokko: ideally yes, but the problem is that the freeze on resume is too early; I doubt I'll get any useful info stored in some permanent form
mmp: netconsole would be the way, if I had another linux pc here
suokko: mmp: Then you need netconsole or serial console
suokko: No others way to debug it
mmp: serial is no-go here; dell latitude xt is the machine
mmp: (small tablet, don't try to find anything legacy on it)
suokko: So you have to find some way to get info either stored (synchronous partition maybe) or get the debug data out in real time
mmp: suokko: well, sync mount might be proper way...
simplexe: hmmm powersave d'not works?
suokko: Not yet
suokko: Except ForceLowPowerMode in xorg.conf
suokko: If you want that
simplexe: my card always very hot but ForceLowPowerMode enabled
suokko: simplexe: Does xorg.log say anything about it? Maybe you could pastebin your log
simplexe: hmm sure
mmp: going to reboot, bbl
simplexe: suokko: http://pastebin.com/m46f107e1
Zajec: ForceLowPowerMode doesn't work with kms
simplexe: Zajec: i using it without kms
Zajec: yup, see now
suokko: log says that it sohuld make card go low power mode
simplexe: i see
suokko: simplexe: Are you sure card is hot and not just spining the fan?
suokko: aha. DynamicPM
suokko: You want to disable DynamicPM I think
simplexe: suokko: ok, i tested it
suokko: Because it looks like driver is switching power mode quite many times there
Zajec: i think DynamicPM just turns off unused blocks
suokko: I think it changes clocks in DPMS changes
simplexe: (II) RADEON(0): Dynamic Power Management Disabled
simplexe: no change
suokko: But is the problem really that card is hot or do you think it is hot because fan is spinning when it shouldn't?
simplexe: stop
nanonyme: suokko: Is there some way to measure temp?
suokko: We can't read the sensors yet
simplexe: yes, fan is spinning when it shouldn't.
nanonyme: So it's kinda impossible to determine the card is too hot unless you junk your own temperature sensor into it? ;)
simplexe: with full speed
suokko: nanonyme: You can feel the difference from outside airflow with hand
suokko: bridgman: Do you know way to make fan not to spin at max?
nanonyme: suokko: Even if normal temperature for the card feels too hot for your hand?
simplexe: suokko: and can be quieter than the fan in 2D mode?
suokko: seems like fglrx might control fan directly so problem might be in atombios for your card.
simplexe: suokko: with fglrx this is works good
simplexe: wiith fglrx fan is very silent
nanonyme: I thought suokko just said that.
mjg59: We have no thermal or power management control
suokko: yes. because they have fan controlling in driver but we don't have
mjg59: The fan will spin at whatever speed the hardware wants to spin it
mjg59: Nothing you can do will change that
nanonyme: mjg59: Or rather the BIOS wants to spin it.
mjg59: No
simplexe: this is bad
mjg59: There's a hardware monitoring chip that controls it
nanonyme: Oh, so it's different on ATi chips than nVidia then. Okay.
mjg59: We don't execute code from the BIOS for this kind of thing
mjg59: It's the same on nvidia
mjg59: The BIOS contains x86 code. None of that gets run.
nanonyme: Well, on nVidia you might have ended up reflashing the card to change default fan speeds.
mjg59: That's the default values
nanonyme: Yeah, those were what I meant?
mjg59: At runtime it's managed by hardware
simplexe: my card had broken due to constant overheating
nanonyme: Right, we were talking about two different things then.
nanonyme: I just meant the defaults.
nanonyme: (since that doesn't require driver support)
mjg59: Right. They'll be loaded into a microprocessor that then takes care of it from that point on.
mjg59: simplexe: Patches welcome
mjg59: It's not actually a terribly difficult problem - hook up the i2c bus, add support to all the i2c drivers to let them export their temperatures in-kernel rather than just in-sysfs, then hook that up to the thermal class
nanonyme: Imo would be neat if power management and thermal management would cooperate so that performance mode would be detected such that card temperature doesn't rise too high.
mjg59: They're orthogonal
nanonyme: Well, if you push power management down, shouldn't the card emit less heat?
nanonyme: Or rather voltages and so.
mjg59: Yes
kcodyjr: nanonyme's right, power management is generation and thermal management is dissipation. their implementations are orthogonal, but their usage is the two different sides of a single coin
nanonyme: So if you want to do it smart, you pick a voltage at which the fan is able to keep the card at a pre-determined temperature.
mjg59: Oh god I really don't want to have this conersation again
bridgman: power and thermal management do need to be coordinated up to a point; you need to consider both when setting clocks/voltages etc
mjg59: Anyway, yes, it will all work absolutely perfectly once the code is actually written
simplexe: mjg59: and through atombios can not control modes of power?
mjg59: simplexe: Yes, but not usefully at runtime right now
mjg59: The kernel already has support for dealing with all of this - it just needs to be hooked up
nanonyme: Neat.
bridgman: speaking of working together, there's a pretty good symbiotic relationship going on outside my window
mjg59: That's the main reason I moved the thermal algorithms out of ACPI and into the generic layer
bridgman: when I don't cut the grass frequently enough I get high weeds growing up; after I weed-whack them a big ol' groundhog comes out and picks up the dead weeds then takes them away to line his burrow
nanonyme: mjg59: Do we still need to decide the temperatures which the algorithms should use though?
mjg59: With luck there'll be values in the atom tables somewhere
nanonyme: Plus you probably want a different set of temperatures with a laptop than with a desktop system.
nanonyme: Yeah, let's hope there's such luck...
mjg59: But the way it works would just be to register a thermal device
mjg59: The active cooling will be implemented by the fan, so the hardware monitoring and fan control gets hooked up to that
mjg59: We also register a passive trip point that indicates that the gpu should be clocked down
mjg59: And finally a critical trip point where we power down the hardware
mmp: suokko: hello again
mmp: looks like I identified the problem
suokko: good
mmp: well... maybe better than I expected
mmp: radeon driver itself seems to work fine under all conditions
mmp: problematic is Dell ACPI BIOS
mmp: the last message in logs was ACPI resume from S3
mmp: ACPI BIOS on this machine checks for one special variable, which seemed to be linux-specific -- kernel commandline acpi_osi=Linux
mmp: so long time ago I set it, in the belief that it might help at least a bit
mmp: but looks like after removing it, suspend and resume work flawlessly
mmp: so my apologies; radeon handles everything suspend/resume-related correctly
suokko: But good that it works now :)
mmp: yup, it is
mmp: but I'm a bit confused about what Dell wanted to say by checking for ACPI OSI being Linux...
mmp: anyway, having suspend and resume working, it's time to play a bit with KMS, and that one didn't work very well :)
mmp: but that will be standardn bugreport I guess :)
mmp: suokko: thanks for help :)
jnoah1984_1: anyone getting this error "./configure: line 12434: syntax error near unexpected token `XINERAMA,'
jnoah1984_1: anyone getting this error "./configure: line 12434: syntax error near unexpected token `XINERAMA,' " when trying to build xf86-video-ati from git?
soreau: jnoah1984_1: No, why? Do you have xutils development package installed?
mzz: jnoah1984_1: wild guesses include: check if your /bin/sh is something weird, check if autoreconf produced any warnings
nanonyme: Sounds like soreau'd be right though. ;)
riri: glop
riri: problem with my Radeon HD2400 Pro (AGP) : can't use the radeon driver without setting the BusType to PCIE, which make quirks on all transparent items (including the cursor)
riri: tried with the radeonhd, but no acceleration at all (same result as vesa)
suokko: riri: AGP is problematic and you should use PCIE until fix for agp problems is found
riri: the Xorg.0.log : http://pastebin.org/17464
riri: suokko: thanks for the info - any way to make transparent things better (at least the cursor) ?
suokko: riri: Yo ucan try to disable UTS/DFS (man exa for details how to)
riri: \o/ I didn't know this man page, trying to find in the driver man any info :-)
jnoah1984_1: soreau, what is the fedora package?
soreau: jnoah1984_1: I can't say, but it should be something like xutils-dev or similar name
nanonyme: aghs at something taking constant one full core of his CPU
riri: nanonyme: lxde-session-lite? :)
soreau: nanonyme: top?
nanonyme: soreau: Probably this http://lkml.org/lkml/2008/6/6/408
nanonyme: Although that's lower than mine...
nanonyme: Still, same process, same hardware.
nanonyme: (and that looks like fixed, damn)
soreau: nanonyme: Try unloading the potentially offending module?
nanonyme: Fails to rmmod -f. :)
nanonyme: Ah, great. Now it did. Guess this is different then.
jnoah1984_1: soreau, if by xutils you mean xorg-x11-util-macros, then yes, it is installled.
soreau: jnoah1984_1: I'm not sure, but I don't think that's the one
soreau: Maybe someone that uses fedora can give you the exact name for the xutils dev package on fedora
soreau: It's probably something -devel
jnoah1984_1: yeah, I have searched, but cannot find
soreau: nanonyme: Do you happen to know what it's called?
suokko: jnoah1984_1: xorg-macros is the git version
suokko: But you might need xserver-xorg-core-dev
riri: suokko: thanksa lot, disable UTS/DFS works (UTS for the cursors, DFS for clients drawing)
suokko: Which distro are you using?
suokko: jnoah1984_1: with apt you could do apt-get build-deb xserver-xorg-video-radeon while fedora has something similar too
suokko: glisse: I found a way to dead lock kernel because of gpu reset
suokko: At least one way is to hold ring mutex while gpu reset gets called
fat_chris: i just had a hardlock after trying to resize a window... cant ssh in and cant sysrq :|
fat_chris: http://pastebin.com/d703914ba <-- heres the Xorg.0.log
suokko: fat_chris: "space check failed in flush" doesn't look good
fat_chris: indeed
airlied: pp
airlied: nha: so piglit runs on r300g now?
MostAwesomeDude: What.
MostAwesomeDude: will buy nha a drink or five at XDC
nha: airlied: my patches fix basic glReadPixels, which is a first step towards testing with piglit
nha: airlied: but there are *lots* of failures
nha: some of them may be secondary readpixels failures, others may be related to the uber-strange behaviour of glxgears I'm seeing
nha: MostAwesomeDude: I couldn't make it to XDC; meet me at FOSDEM (I assume it's going to have an X dev room again)
nha: belgium is significantly closer to home for me
MostAwesomeDude: nha: A few of Cooper's patches confuse me. One of them just makes viewport and scissors get re-emitted if rasterizer gets changed.
MostAwesomeDude: nha: Sure, not sure if I'll be going, but I'd like to.
airlied: nha: does the read pix sanity test pass?
nha: admittedly, I didn't re-test that particular test
airlied: thats alwayst the first test I try and make work
nha: but with my last push to master plus the two patches I sent to the mailing list, not *everything* fails
nha: good point
nha: read pixels also tests depth and stencil reading, which I didn't test
nha: so yeah, should test readPixSanity, but I'll be gone for a few days (summer school)
MostAwesomeDude: An amazing amount of stuff works considering that the code hasn't gotten a true audit.
MostAwesomeDude: But yeah, if glReadPixels doesn't work, that's a symptom of something much further down the line, 'cause I can't do much about getting the caches to flush.
nha: nono
MostAwesomeDude: All I can do is map the BO.
nha: glReadPixels works now
MostAwesomeDude: Oh, good.
nha: it was a combination of not setting up renderbuffers correctly and getting the stride calculations wrong
nha: so it's all good (depending on what people say to my mesa/st patches)
MostAwesomeDude: Yeah, thanks for that stride stuff, 'cause it was all guesswork on my part.
nha: MostAwesomeDude: note that some of the stuff, e.g. fill surface, may need to be re-audited to work for render-to-mipmapped-texture
nha: also, the handle_from_texture seems to assume that textures are non-mipmapped or something
nha: either way
nha: I believe that for a while I'll just pick random piglit tests to attack
nha: oh, there's also that NV_vertex_program bug
nha: that'll be first once I'm back if nobody else gets to it
nha: probably not that hard to fix
nha: anyway, I'm off
Zajec: i want to compiled mesa for 32bit
Zajec: where should I use -m 32?
Zajec: as argument of autogen? or make?
adamk_: What in the world is r500_drv ?
airlied: adamk_: where?
airlied: we ship radeon in rhel under r500
adamk_: Heh... Some guy on #ati is having problems getting DRI going on the r500 driver. I just looked at this log file... He's using Xorg 7.1.1 :-)
airlied: yeah its RHEL
airlied: we don't ship DRI with RHEL usually
adamk_: Yeah, he just said CentOS.
Zajec: how can I compile 32bit mesa r600 driver?
Zajec: to try some game in wine on x86_64 os
[Enrico]: Zajec: did you use the amd64 multilib profile?
[Enrico]: oh sorry
[Enrico]: i'm used to answer gentoo user
[Enrico]: rofl
[Enrico]: it's late forgive me :D
adamk_: Honestly, I've always found it simple to build my 32 bit drivers on a 32 bit machine and copy them to my amd64 box.
[Enrico]: Zajec: well normally it is done like adamk_ said, you should have a 32 bit install (or a chrooted installation) where you compile the driver and then you package it and install it in your 64 bit OS
Vash63: Any idea yet on the Firefox slowness with KMS? Once that's fixed I'll probably turn KMS on permanently. It's the main thing holding me back.
Vash63: Does it happen on Intel too or is it just a radeon thing?
Zajec: wonders about easier way, without chrooting
[Enrico]: last time i've tried fedora 11 (so with kms) firefox was really quick! strange
Vash63: Really? I'm on Gentoo, libdrm, mesa and radeon from git masters.
Vash63: FF is very, very fast without KMS.
Vash63: But slow as a dog with it.
Vash63: The EXA and OGL performance under DRI1 is great, 2d stuff blows fglrx out of the water.
Vash63: But turn on KMS and it feels like fglrx again.
AStorm: Vash63: it's not really slow
AStorm: it seems it's some weird cairo interaction, happens for some inputs
Vash63: No? Scrolling and resizing are horrible for me.
AStorm: Vash63: not for all pages!
Vash63: And even creating tabs and such seem much slower than without KMS.
AStorm: and there's no specifically high cpu usage either
AStorm: Vash63: that general slowness has been fixed
Vash63: Really? Only thing that's kind of old is my drm-next is a few days old.
Vash63: mesa, libdrm and radeon are all up to date.
AStorm: Vash63: that's old enough
AStorm: devel moves at a frantic pace right now
Vash63: Ah. I'm on the latest version in the zen patchset, but I think that was merged 2-3 days ago.
airlied: KMS isn't quite finished yet
airlied: not sure why people are comparing a work in progress with fglrx
rah: airlied: I've been filing lots of bugs
rah: airlied: for problems with drm-next
rah: airlied: but I haven't had much of a response
rah: airlied: are they of value?
airlied: rah: probably, its the weekend
airlied: and I really don't trawl bugs often, until I fix stuff
rah: that would be a "no" then? :-)
airlied: well we do read them, and they are useful for tracking stuff
airlied: so everytime you ask in here, you can point at the histort
airlied: since I don't track peoples bugs in my head ;-)
soreau: airlied: You don't?? Since When?? :D
boghog: someone needs to builda neural bugzilla interface
EruditeHermit: bugs take time to solve
EruditeHermit: =p
EruditeHermit: i wonder how many are open
EruditeHermit: 100s probably
EruditeHermit: 753 with the term radeon
EruditeHermit: ouch
airlied: has ~1000 bugs on his buglist at one time, so its fail to track em ;-)
soreau: airlied: From how many different users?
soreau: If they're all different that tells at least ten fold that aren't reporting bugs are using
EruditeHermit: airlied: btw you were right about my bug
soreau: isn't apt to report a bug
EruditeHermit: the lvds is probably quirky for my card
EruditeHermit: since I think VGA out gets to a different bug
airlied: soreau: most of them are in Fedora stuff, so from mostly different people across 4-5 distro releases
airlied: I also deal with lots of non-ati
airlied: not to mention enterprise bugs
meoblast001: why are the radeon drivers so unstable?
meoblast001: are they like that for everyone?
airlied: meoblast001: what gpu?
meoblast001: X1300
airlied: what happens machine lockups?
meoblast001: well, with Neverball my screen gets all demented
meoblast001: with Super Tux Kart the screen locks up
meoblast001: only thing that runs is Blender, Tux Racer, and my own GL application
airlied: meoblast001: latest mesa?
meoblast001: not sure