bridgman: hmmm.. it's been taken over by porn spam ;(
airlied: Er1K: generally two screen sections + two deice sections + busids
airlied: you seem to be missing the busids
Er1K: so from lspci of 05:02.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] do I have >> BusID "PCI:5:2:0" << for both, >> BusID "PCI:5:2:1" << for the second?
airlied: 5:2:0 for both
Er1K: Put BusID's for both device stanzas. Same result. In the past, I've never had to use BusID when there is only one physical card.
Er1K: I've also tried turning RenderAccel off, tried manually cutting "VideoRam" way down (google suggestion from an nvidia forum).... same
airlied: I'd try starting wwith an empty xorg.conf, and just adding two screens in serverlayout
airlied: two screen sections, pointing at two device sections
airlied: with screen 0, busid, and screen 1, busid
airlied: It worked for me in the past few months, granted smoe servers out there may have bugs
airlied: and in fact you may be hitting a bug in the driver
airlied: probably a missing pScrn-
airlied: pScrn->pScreen = pScreen line I thought I'd fixed
bridgman: airlied, what is your current thinking re: r1xx-r5xx KMS moving out of staging for 2.6.32 ?
DanaG: I wonder when the first 2.6.32 RC will be released.
airlied: bridgman: I'm all for moving it all out of staging for 2.6.32
airlied: bridgman: its already out of staging sorta, its now a command line option to turn on/off
airlied: bridgman: glisse wanted to change some API but Im not really convinced it will actually be a useful gain
airlied: I think what we have is maintainable going forward, and he can bolt any new APIs on later once he gets to utopia
bridgman: yeah, it's often good not to immediately improve APIs; a couple of months later you usually discover what you *really* should have done, and you used up all your upgrade points ;)
vtokarev: as I understand - r600_dir is part of mesa, I've configured it with radeon dri drivers, do I need to use r600 instead?
airlied: I suspect tuning things rather than redesigning will get us 95% of the way
airlied: and I'd rather we concentrated on making things solid instead of pie in the sky redeigns
airlied: vtokarev: yes for r60
tavl: if I comment L59 and uncomment L60, the system freeze with a 75% wide white screen... http://pastebin.com/d14b55697
tavl: Anyone can help?
spreeuw: vtokarev: yes with drivers is r600
spreeuw: and swrast you need too
spreeuw: thats all
spreeuw: for fallbacks and aiglx
vtokarev: yeah, now I get r600_dri.so
mzz: tavl: white screen can be it trying and failing to launch compiz
tavl: mzz: KDE4
mzz: tavl: not familiar with that, but it might be something similar there
mzz: tavl: what happens if you try to launch just Xorg?
spreeuw: my colleague at work uses kde, what a pos
spreeuw: or maybe its the centos defaults
tavl: mzz: no xorg log at all...
bridgman: or at least make sure you have compositing / desktop effects turned off
bridgman: can you pastebin your dmesg output ?
bridgman: although I guess that won't help on a crash either
mzz: also attempt network access (ssh) if you have that option.
tavl: I dont have my previous dmesg, as i had to hard reboot
mzz: oh, and briefly pressing an (acpi) power button instead of the reset button.
tavl: mzz: i tried the "briefly" thing...
tavl: mzz: no luck
tavl: well, the machine i'm talking about is this one i'm in... no way to ssh it, as it's frozen, when i try that config
tavl: mzz: if i comment "NoAccel", then the frozen screen is a really black-and-fullscreen one... :(
tavl: bridgman: about the desktop effects, as i'm on vesa, right now, everything is disabled...
mzz: sorry, can't really help there, I don't have that hardware
tavl: mzz: no idea of what could be causing this behavior?
mzz: tavl: don't think I've seen it, and can't help with zero logging output.
tavl: mzz: i understand...
tavl: mzz: would my xorg @ vesa help in anyway?
tavl: *xorg @ vesa LOG
mzz: probably not
mzz: (WW) Warning, couldn't open module dri
mzz: that's definitely unusual though.
mzz: tavl: also consider commenting out those explicit HorizSync and VertRefresh lines, they rarely help
tavl: (i just copied the default xorg.conf-vesa)
bridgman: I really think all you need is the device section
bridgman: the X server spat out most of the other lines
tavl: trying to restart X...
tavl: ok, only the device section is left in my xorg.conf... still at 800x600... :(
bridgman: running radeon ?
tavl: bridgman: no... still vesa
tavl: mzz: about that dri module warning... anything i could do about it?
mzz: get a less weird xserver
bridgman: if you switch to radeon does it still crash ?
bridgman: with Option NoAccel set ?
mzz: is starting to wonder about slackware, that's the second oddity within 24 hours involving it
tavl: bridgman: i'll need to try it... and probably reboot... but it's ok... just wait a momment...
spstarr: hello bridgman
bridgman: hi spstarr
franjva: third try: has anyone else experienced problems suspending on KMS twice?
franjva: as in, the second time the computer never resumes
franjva: the first time it works perfect
franjva: airlied: yesterday you said that r600 should s/r under kms?
airlied: franjva: mine worked twice, but haven't got it near me now until next week
airlied: franjva: does it s/r okay twice without kms?
airlied: also make sure your OS isn't doing posting on reumse of gpus
franjva: airlied: what do you mean "posting on resume of gpus"?
franjva: how do i check it?
airlied: franjva: not sure its distro specific
airlied: if your distro uses pm-suspend, try pm-suspend --quirk-none
franjva: no, I just echo mem > /sys/power/state
franjva: I'm gonna try without kms
airlied: does you VT switch first?
franjva: let me check
airlied: it might be worth trying that, or just suspending without X running
airlied: and see if it happens twice
franjva: i see the text mode cursor in the left corner (it's more difficult to know now with kms :)
spreeuw: franjva: 1920x1200?
franjva_: airlied: ok, this is weird
spreeuw: nice console ;p
franjva_: if i switch to a vt before suspending, it always works
franjva_: kms and all
franjva_: even though I see the computer switchin to a vt itself when I suspend from X
airlied: franjva_: I mostly tested with pm-suspend which does the VT switch first itself
airlied: so there might be a race condition somewhere
franjva_: I tried with pm suspend too, same results
franjva_: but yeah, it looks like a race condition. maybe the second time it's faster and some necessary previous step is not performed in time
franjva_: (but I definitely see the text mode cursor the second time too)
franjva_: (so it also switches to vt before suspending)
airlied: so pm suspend fails twice as well
airlied: I'll have to try and reproduce it next week then
franjva_: yeah, i used pm suspend before trying with echo mem by hand
franjva_: this is not very annoying. I can make an script that does a chvt before calling pm_suspend
franjva_: it should work
airlied: its wierd since pm suspend should vt switch as its first job ;-)
franjva_: yeah, but I'll put a "sleep 5" in between :P
franjva__: airlied: it wasn't that. it didn't resume from vt after several s/r cycles
franjva__: it seems just a bit more unlikely to run into the race condition from vt
franjva__: but it's there
franjva__: and it definitely never happens the first time I suspend, only from the second on
nanonyme: franjva: Maybe you could do a registry dump before each suspend?
nanonyme: (if that's possible)
nanonyme: As in, compare card state to see how it's different since obviously the actual suspend code doesn't change.
airlied: franjva: cool, I'll try and think about it and track it down next week
franjva: airlied: great. if i can do anything to help (like the registers thingy :P) just ask
franjva: debugging s/r must be a PITA
nanonyme: I don't know anything about it but my guess would be resume code would set the registers in a slightly different state than they originally were before suspend and so another round of suspend fails with the new values but that's just an uneducated guess. ;)
franjva: nanonyme: that could be the best explanation if it always happened the second time
franjva: but from the vts (not X) sometimes it happens the third or fourth time
franjva: i'm more inclined to believe it's a race condition
nanonyme: I don't think it would be very trivial to find out the problem by just reading the registry dump then. :(
gimzo: Hi. Is there a way to use ddccontrol with radeon (radeonfb) driver ? It was once possible but not now
airlied: franjva: if X isn't running at all, can you do it?
airlied: like multiple times from runlevel 3?
franjva: let me try
franjva: before the last batch of changes I could
franjva: I haven't tried since yesterday
franjva: airlied: it just failed to resume
franjva: X wasn't running
franjva: I'll try without kms
franjva: yup, with kms disabled everything seems to work ok
franjva: i've s&r six times from X
osiris_: nha: hi
osiris_: how's the GLSL stuff going?
nha: osiris_: most of the stuff I have is in my public git repository, lately I have been looking more into r300g (it's time that driver comes into good shape)
nha: and there are apparently some compiler regression which should be fixed before the 7.6 release
nha: (of mesa)
airlied: nha: yeah the compiz water report regression was bisected down
airlied: nha: btw I think if you make r300g report GLSL, the other bits might get fixed pretty quick :-P
nha: airlied: yeah, that one and the one about NWN which is apparently really about NV_vertex_program
nha: note that right now, r300g reports OpenGL 1.3 :/
osiris_: that one too #22741
nha: but yeah, just going ahead and saying "YOU CAN HAZ OPENGL 2.0 LOL" could get the ball rolling quickly ;)
airlied: whats causing only 1.3? /me forgets 1.4 requirements
airlied: point params? or fog coord me guesses
osiris_: both I think
nha: osiris_: your patch looks reasonable; obviously it would be better to avoid the running out of texcoords in the first place, but not locking up the system is more important in the short term ;)
osiris_: so what's the status of r300g?
nha: it runs a nice number of things, but has a lot of problems in random places
nha: the foundation seems good though
airlied: I guess most of us can handle fixing the normal type issues, its the compiler that scares us!!
osiris_: any luck with games like q3, sauerbraten?
osiris_: nah, compiler is fun :)
nha: has anybody had any luck with that texsubimage crash/abort bug that people have reported several times?
osiris_: what #?
nha: osiris_: I haven't tried those games on r300g yet
nha: e.g. #22742
nha: actually, that one has a slightly different flavour I think
nha: #22528 is what I was thinking of
nha: I seem to remember another similar bug talking about TF2, which had yet another backtrace
nha: but all these crashes are within some flavour of TexSubImage call
osiris_: aah, IIRC during radeonSpanRenderStart we map textures for all enabled texture units, but some texture has format set to invalid so the bpp is 0, which results in failed assertion in miptree code
tball: Hello, how long are we with radeon r600 3d support?
airlied: tball: its mostly there in git already
airlied: well basic GL support
tball: airlied: Sounds good. Is there some crucial bugs left?
nha: osiris_: ah, that sounds very plausible
airlied: no just lots of small things
tball: So its practical ready for bughunting
tball: Because I consider to try it :-)
chithead: in kms, is there support for edid quirks already? when I start X I see fdo bug 10304 resulting in huge fonts
airlied: chithead: the edid quirks should already be ported over.
chithead: do I need x server / drm from git for edid quirks or are the latest releases enough?
tball: What about r600 and kms?
airlied: chithead: should be enough
airlied: tball: mostly working as well
tball: Wau good job guys
mimikry: airlied: are the R600 3d mesa bits in fedora rawhide already?
muep__: r600 kms worked fine here on Fedora Rawhide, but logging into X causes a freeze
muep__: in a few minutes
tball: If I wan't to test bughunt the driver as a user, would it be best to wait some more?
airlied: mimikry: yup, in a separate package
mimikry: airlied: could you give me a link, please?
airlied: muep__: I'll be pushing new code to rawhdie next week
muep__: airlied: good to hear
airlied: mimikry: dri-drivers-experimental
mimikry: airlied: thanks! :)
airlied: mesa-dri-drivers-experimental even
muep__: tball: maybe, but you could try the Fedora snapshot livecds without modifying your system
muep__: will mesa-dri-drivers-experimental end up on F12 default installations?
airlied: probably migrate it to non-experimental
airlied: it works better than we thought.
tball: muep__: Will that contain latest kms/3d code?
muep__: tball: I don't know if it's the very latest, but I'd guess it's not really old either
tball: muep__: ok :)
airlied: the livecds from the test days are pretty up to date
airlied: I've been fixing suspend/resume since last week so no new code went out
airlied: zzz &
osiris_: nha: ok, looks like during radeonSpanRenderStart we need to add
osiris_: ctx->Texture.Unit[i]._Current->_Complete &&
osiris_: ctx->Texture.Unit[i]._Current->Image->TexFormat != &_mesa_null_texformat
osiris_: to the if condition to make the prey work
osiris_: unfortunately all in game textures are missing
nha: does _Complete not imply that TexFormat != &_mesa_null_texformat?
nha: what sequence of opengl calls can cause such a situation?
nha: TexImage with a NULL data pointer?
osiris_: no idea
nha: would be nice to have a smaller test case than prey for this bug :}
osiris_: MrCooper: what log file do you want for #24304? Xorg.log?
tsiolkovsky: I just upgraded the radeon driver from 6.12.1 (if I remember correctly) to 6.12.3 and now whenever the laptop comes from hibernation it just freezes, is this a known problem?
nanonyme: Hey, is the libdrm_radeon API going to stop being experimental when r1xx-r5xx KMS moves out from staging?
MrCooper: osiris_: does ut2k4 even use the X11 cursor? Doesn't it render any cursors with OpenGL?
osiris_: MrCooper: I don't know. how do I check this?
MrCooper: good question :}
chithead: probably check if hwcursor enable/disable makes a difference
osiris_: chithead: nope, no difference
MrCooper: osiris_: then it's more likely an issue with the 3D driver than with X or KMS
osiris_: MrCooper: how could it be 3D driver issue? there's almost no KMS specific code in r300 driver, and why would it be different in windowed and fullscreen modes?
MrCooper: KMS implies DRI2 etc., so it does make quite a difference for 3D
MrCooper: OTOH windowed or fullscreen makes zero difference for the X11/KMS cursor
osiris_: MrCooper: but how could 3D driver affect mouse movement events?
MrCooper: osiris_: that's probably not the same issue as the cursor being invisible
MrCooper: neither the X driver nor the 3D driver is directly involved with input events
nanonyme: Isn't cursor hardware-accelerated too though somehow?
nanonyme: (at least I recall the term software cursor explicitly being used)
MrCooper: nanonyme: the X/KMS drivers just get the cursor shape and position
MrCooper: nanonyme: see above, osiris_ already tried SWCursor
nanonyme: Oh, right. Didn't fit into my window. Sorry, carry on. ;)
osiris_: MrCooper: maybe the ddx driver reports some resolution values wrong, and the cursor goes crazy when is clipped
nanonyme: Btw, why do KMS and pre-KMS use different maximum values in cliprect maximums? :) The need for those off-by-one fixes seemed strange to me.
nanonyme: Now, that was redundant.
osiris_: MrCooper: cursor being invisible is also possible a bug in ddx - the cursor could be clipped outside of the window viewport
MrCooper: nanonyme: what 'cliprect maximums' are you referring to?
nanonyme: Mmh, the x2 and y2 values in the rectangles.
MrCooper: where are there differences?
MrCooper: osiris_: the X11/KMS cursor wouldn't be clipped at the window border, only at the screen border
MrCooper: CRTC border, strictly speaking
nanonyme: MrCooper: Sorry, it's been too long since the cliprect calculating changes were made which were followed by a series of off-by-one fixes because things didn't work as expected between DRI1 vs DRI2.
MrCooper: nanonyme: please be more specific, still no idea what you mean
nanonyme: I can see if I can find the place. Can't be very specific before that, sadly.
nanonyme: Ah, cliprects in scissors.
nanonyme: radeon_common.c, function radeonUpdateScissors
nanonyme: I mostly never understood where the one-pixel differences between DRI1 and DRI2 come from.
nanonyme: (ignoring the rest of the changes)
MrCooper: not sure, presumably something else subtracts 1 from the bottom right coordinates with DRI1
Wizzup: Hmm, radeon set's my DPI to 96x96, but i really want to a lower number
Wizzup: I tried Option "DPI" "75 x 75" in my Monitor section, but it still sets it to 96x96
mzz: last time I checked 'Option "DPI"' was not a thing that actually exists
mzz: there's an option to set the physical size of the monitor though.
mzz: look for DisplaySize in man xorg.conf
osiris_: nha: here's the gl calls trace that causes the `dstlvl->width == image->base.Width' assertion to fail. http://pastebin.com/m4e10491d
osiris_: has just found MESA_VERBOSE and MESA_DEBUG env vars
nha: I remember seeing a library that proxies all opengl calls and can be used to log stuff, but I forgot its name...
nha: but yeah, analyzing that log might help
nha: it just seems weird to me that I can't see any glTexImage calls
osiris_: _mesa_debug calls are missing there
soreau: Hi nha. Did you see my message? :)
nha: soreau: which message?
soreau: nha: Well I sent you an email..
nha: oh, you're Scott Moreau?
nha: then yes, I got the mail
soreau: ok cool. any idea whats going wrong?
nha: I'll probably look into those compiler bugs tomorrow (or Monday, that's a holiday over here...)
nha: tbh, not yet
nha: it looks like it might be an r300 specific problem, and I've done most of my testing on r500
nha: I'll have to test that
soreau: I think it is r300 specific
nha: in any case, the commit which you found changes the final hardware code representation, so it's likely r300 specific
agd5f: nha: bugle IIRC
nha: agd5f: yep, that's what I was thinking of, thank you
soreau: nha: Thanks for looking into it
nha: thank you for tracking down the offending commit :)
soreau: well these guys helped out a lot ;)
soreau: I narrowed down the problem to the changes in r300_state.c and r300_fragprog_emit.c by hand reverting the patch which eliminates r300_fragprog.c as part of the problem if that helps any
soreau: just had to re-add 4 lines in the header
soreau: couldnt get much further than that really since I have no idea what the code is actually doing
nha: it *should* just be shuffling values around
nha: i.e. computing the values inside the compiler instead of inside the emit routines
nha: it might be a simple stupid copy'n'paste error that could be uncovered by simply logging the state values that are emitted
nha: at least that would be my initial plan for debugging this
nha: it's just that right now I need to do other things, otherwise this might already have been fixed :}
osiris_: nha: here's the log with glTexImage calls http://pastebin.com/m6477e501
nha: soreau: I guess there's one thing I can do already today, namely test whether piglit would have found that regression
nha: goes to get his R300
soreau: nha: just ping me if you want anything tested from this end
soreau: I should be around all day today
osiris_: nha: here's updated log. the printf args were mixed in previous log. http://pastebin.com/m4ac10aa6
nha: k, though I can't promise to look too deeply into this soon
nha: I think I should focus more on the compiler problems, since other people are more afraid of them :}
nha: piglit says COS/SIN in fragment programs fails on R300
nha: that might be related to the compiz problem
nha: although... no
nha: on second thought, it shouldn't be related
nha: needs to be fixed anyway
nha: we'll know tomorrow
taiu: yes, it does copyteximage to texture which had different dimensions previously
taiu: and in the same call spanrender tries to map all things and validate_miptree does it's own magic and thins fall apart when this texture is kinda incomplete
taiu: a variation of that is bug 22372 where it user CopyTexImage not SubImage so mesa clears some teximage fields and it gives slightly different assert
Kano: hi, is there a patch against 2.6.31 for latest drm
spreeuw: Kano: use git
suokko: Kano: http://xorg.freedesktop.org/wiki/radeonBuildHowTo#head-a6271d23a9199673cea21478e0198d772a55fad3
suokko: There is how to do it easily with git. Then just do git diff origin/master HEAD
Kano: even when you use the stable git repo?
Kano: the example uses linux-2.6 git
suokko: It works against any Linux git repo if merge just works
Kano: maybe that would be a better example, dont you think so?
suokko: sure. That why it is wiki so it can be improved easily :)
Kano: is 3d working stable yet?
suokko: There is still some rendering errors and missing features but some games already work
suokko: I think that someone reported that quake live worked with it
hogbog: was surprised that ioquake3 worked almost flawlessly
hogbog: only some decals showing through walls (as if theyre not z tested or something)
hogbog: other than that it was good, played it for a good 15 minutes, performance was solid
suokko: Kano: Thanks for tip. I updated the how to and fixed a error in pull command. It was missing the branch for Airlied's repository. And merge happens without errors to stable tree (I just tested it)
Kano: maybe you could add the command to create a patch
Kano: in order to be a script it would require "cd linux-2.6.31.y" as 2nd command
suokko: yes. It is easy to forget details :)
taiu: and yes, polygon offset is broken on r600, probably it uses different units than r300, or some more registers need setting
spreeuw: hogbog: yeah very cool
spreeuw: jsut played a bit of openarena ;p
spreeuw: pretty speedy
taiu: if anything uses it seems to be set so big that it effectively disables z-test
hogbog: it is kind of like a 'wallhack' the way it is right now :p
hogbog: you can see other player's shadows through the walls
Kano: 2mb diff..
spreeuw: hogbog: yep
spreeuw: marks on walls too
Er0x: cheaters :D
hogbog: i only played against bots!
spreeuw: it's good for my scores
hogbog: no real people got hurt
spreeuw: I think one of the devs is a player too ;p
taiu: Maybe we get away with radeon tex asserts as brianp replaced swrast glCopyTex[Sub]Image with meta fuctions which do things a bit different
suokko: How about using HLT instruction in vblank wait loop? Would that reduce CPU heat?
suokko: Just for minor improvement until Alex gets IRQs done.
mjg59: suokko: How would you wake up from the hlt?
suokko: What If there was some very high frequency timer wakeup?
suokko: I guess that would be stupid and just using some kernel provided wait for high frequency timer would be better.
suokko: That would mean usleep call which is already option with older cards ...
suokko: at least in mesa
agd5f: taiu, hogbog: fixed polygon offset
hogbog: going to check that out in a bit
hogbog: one other thing i noticed was point sizes were off, in quake2, when I shoot the blaster the particles it emits are too big
agd5f: hogbog: probably wrong units in the driver
spreeuw: hogbog: I noticed that too I think
spreeuw: you could try low impact software flalback if that has effect
spreeuw: always used to work for r300
hogbog: yeah I think point size have always been off for me
spreeuw: have you verified it with blender or so?
bridgman: I guess I can make the intros ;)
bridgman: I was talking to majk1578 on #ati; X2300 (5xx) GPU running radeon 6.12.3, kernel 2.6.30, mesa 7.51
bridgman: seems to work ok but crashes hard when launching flightgear
Neo_The_User: is the 4650 an rv770?
bridgman: glxgears runs ok
bridgman: it's an rv730
hogbog: spreeuw, not sure what you meant, but yeah I notice point sizes were off in blender as well when I go into edit-mode
hogbog: the points it draws in edit mode look too big
spreeuw: its critical in blender
Neo_The_User: does anybody know about the whereabouts of the 5870 HD series?
spreeuw: as it uses size for some tools as feedback
spreeuw: hey the openarena texture bug is fixed thanks
chithead: Neo_The_User: nda expires on 2009-09-23 (depending on time zone)
spreeuw: is it possible this took a performance hit?
dileX: latest mesa commit has...
dileX: + //r700->PA_SU_POLY_OFFSET_CLAMP.f32All = constant; //???
dileX: r600: fix polygon offset
Kano: hi bridgman , could you talk to the fglrx crew and tell em to make xv working correctly like in radeon oss?
hogbog: spreeuw, oh you mean selection? I did notice selection is broken in blender
Neo_The_User: Kano: hahaha!!
nanonyme: suspects 3D might be a bit of a more important priority for fglrx than Xv
spreeuw: latest commit fixes the openarena bug for me anyway
Kano: bridgman: gl is a hack as output and way too slow for hd content from bd
spreeuw: but I also switched the engine to sync on vsync
nanonyme: Kano: Why not just use the open drivers? :)
Kano: nanonyme: because the 3d part is too slow
Neo_The_User: Kano: bd as in blu-ray?
nanonyme: Kano: Can't have everything. :3
Kano: also too hard to backport for lenny
nanonyme: Solution: don't use Lenny.
Neo_The_User: sid ftw!
nanonyme: Problem solved.
Neo_The_User: debian sid is like archlinux :)
terracon: Neo_The_User: I dare you to say that in #debian!
Neo_The_User: did it
suokko_: There is at least some similarity ;)
Kano: Neo_The_User: yes
spreeuw: neverball is fixed too now
agd5f: point sizes fixed
spreeuw: only some strange corruption in the ball shiny spot
Kano: nanonyme: i do not support unstable distros anymore
nanonyme: Kano: That's fine, upstream doesn't support distros either. :)
spreeuw: you're on a roll agd5f
Kano: nanonyme: i have got my own distro if you dont know that
VitRuss: Hi! I've got HD550 (rv710), but 3d in xf86-video-ati git isn't working for me. I have OpenGL vendor string: Mesa Project and OpenGL renderer string: Software Rasterizer. Could you help? kernel - 2.6.31-zen2, it should include drm-next...
hogbog: im just going to fire up my testbox right now then
nanonyme: Kano: And?
Kano: nanonyme: well and that is lenny based
nanonyme: Kano: Are you saying you lack the capability and time to maintain it properly or what? ;)
bridgman: VitRuss; you need kernel modules from a separate git tree to get 3d support
bridgman: it will merge into 2.6.32
nanonyme: Or why should that matter?
agd5f: VitRuss: make sure it containst drm-next, also you need to build the 3d driver in mesa
bridgman: jbridgman.livejournal.com/945.html, scroll to the bottom
suokko_: bridgman: There is the wiki how to now ;)
bridgman: or drm-next, that's probably better ;)
suokko_: also in topic
Kano: nanonyme: i do maintain it properly you can be sure
nanonyme: Kano: Why do you complain then? :)
Kano: nanonyme: most users are happy with it when they dont need the absolutely latest xorg/kde4
spreeuw: agd5f: do you know if s3tc is still/already working?
VitRuss: bridgman: agd5f: for person with the same kernel and packets with RV730 it's ok
Neo_The_User: bridgman: not to start talking about fglrx but is the code for fglrx windows and the fglrx linux version different at all, as far as performance code goes?
Kano: nanonyme: because fglrx is crap but needed. it is even too stupid to work when libdrm2 is updated
nanonyme: Kano: I recommend joining #ati to talk about it.
bridgman: VitRuss; I doubt it; 2.6.30 had kernel support for EXA/Xv but not for 3D
bridgman: Neo_The_User; most of the code is the same (OpenGL stack etc.) but it's cut apart and reassembled to fit around the DRI interface
nanonyme: spreeuw: Sounds doubtful since it doesn't work properly with r300 Mesa either.
bridgman: 2D and video is quite different
Neo_The_User: thank you! :)
spreeuw: nanonyme: it always worked for me with r300
spreeuw: mesa supports it
nanonyme: spreeuw: I've heard problems being reported with r300 with it. Iirc corruption and so.
nanonyme: (and that it wouldn't be a very high priority thing since part of the people run into license issues with it)
VitRuss: bridgman: it's zen kernel. it includes lates drm-next
VitRuss: bridgman: I've build it today...
suokko_: VitRuss: Can you upload your dmesg?
VitRuss: suokko: i'll try now
nanonyme: VitRuss: I'd rather use 2.6.31 with drm-next pulled on top of it than zen sources.
nanonyme: Unless there's other stuff too you actually need bleeding-endge.
nanonyme: Just a note. :)
VitRuss: nanonyme: 2 people on zen-sources have the same working with hd4870 and something based on rv730.
VitRuss: suokko: could you give me the address where I can upload?
suokko: VitRuss: http://nopaste.org
VitRuss: suokko: http://nopaste.org/p/a4FRdHh3nb
suokko: VitRuss: Your radeon modules is never loaded
suokko: Wht happens if you modprobe -v radeon?
nanonyme: spreeuw: 0.991606] [drm] Initialized radeon 1.31.0 20080528 for 0000:01:00.0 on minor 0
nanonyme: Egh, suokko even
nanonyme: Yes it is. ;)
nanonyme: According to that nopaste page anyway.
suokko: ok. I missed that
suokko: Everyone should use KMS so eadier to spot
suokko: doesn't remember links2 shortcut for search
nanonyme: Yeah, I think zen kernel might have the staging option disabled.
nanonyme: I think / is the search button there.
nanonyme: It's in most console applications.
suokko: yes. looks like vi keys
VitRuss: suokko: http://nopaste.org/p/aykbUCm4j config. radeon is buildin in kernel. I'l try to rebuild with CONFIG_FIRMWARE_IN_KERNEL=y and then will come back in case it won't work
suokko: yes. It doesn't load firmware to card so it looks somewhat funny what is going on without error message
suokko: xorg.log would be useful also to know what is going wrong
nanonyme: The firmware error cases could have more informative errors outputted, yeah.
suokko: all failures in kernel could have more informative messges
nanonyme: Like, say, "cannot load firmware: file not found" and "cannot load firmware: corrupted file" in dmesg. :3
suokko: Patches are welcome ;)
suokko: like every -E
hogbog: hmm point sizes look correct in blender now, but still too large in quake2 for some reason
nanonyme: suokko: Probably wouldn't slow the initialization that much, aight?
nanonyme: That is, to put a few if clauses that gracefully fallback from radeon init.
hogbog: also ioquake3 now runs without any glitch or issue whatsoever \o/
suokko: There is alreayd the ifs to check for errors but insdie if is no error messages
nanonyme: So adding them would be trivial?
suokko: Tomorrow in phornix: "Quake live works with r600 oss driver"
suokko: nanonyme: yes
suokko: And many others places are missing the error messages when failing something in kernel
suokko: Only problem adding them is to know what is failing in what palce and what numbers would be usefull debug info
nanonyme: Well, imo at least places that require user intervention demand for an error.
nanonyme: Otherwise the user doesn't know what to do next.
nanonyme: (like in the microcode case)
suokko: I agree but that is quite some work to add the error messages. Might even take 2 work days for whole kernel module to review and add the error messages where ever there is need
suokko: for someone who knows the code well
suokko: For me it would take longer :P
suokko: agd5f: Do you know which registers causes AGP flush? Is it some outside card feature?
bridgman: one of the reasons everyone hates AGP is that you have to muck around in the chipset registers, not just the GPU
bridgman: graphics drivers aren't supposed to touch the chipset but it's real hard to make everything run reliably if you don't
bridgman: chipset/mobo vendors used to keep their drivers & bios up to date but they stopped doing that for AGP years ago
bridgman: and then everything started to smell
suokko: It is impossible? How do you synchronice stuff without doing it?
bridgman: it's just different for every single stinkin' chipset
bridgman: at least if you want to use all the features
bridgman: that's why the devs recommend turning stuff off - fast writes, high AGP levels etc...
suokko: If I understand AGP correctly it doesn't guarentee any synchronization and we need some for cpu and gpu changing same data after each other
bridgman: it's more than synchronization; you need to sometimes hit chipset regs just to get reliablity
suokko: fast writes off, agp 4x tried. nothing helps for me
suokko: (8x device)
bridgman: PCIE has cache coherence one way at least, I think that translates to "if GPU writes to system memory then CPU cache knows about it"
suokko: GPU doesn't implement cache coherence then I guess
bridgman: I don't think the GPU caches system memory so don't think we need updates that way
bridgman: there's definitely no attempt to keep CPU and GPU caches coherent
suokko: IT does for some GTT stuff so I think yes
suokko: That why quetion is which cache can hold old data for dma engine
bridgman: in theory dma engine doesn't have cache IIRC
bridgman: but chipsets have small FIFOs
suokko: or is blit just so slow and CP doesn't waith even with wait untill enough that dma engine operates before blit
bridgman: IIRC things sometimes get stuck there
bridgman: blit is pretty fast but CP won't wait for anything automatically AFAIK
suokko: And my test case is only 4 objects 40 bytes each which I copy around and that causes failures
suokko: bridgman: I have 2d cache fulsh and waith idleclean and still dma engine somehow copies old data from somewhere after blit writing to source memory
bridgman: reluctantly invokes Allen's Axiom and reads the manual
suokko: I could of course be doing something evil that is not supposed to work like blit and dma handling same data after each others
suokko: But I jsuttough it would be good test case for dma and 2d engine if they can work together
suokko: bridgman: btw, I have rv280 only but similar symptons are with newer agp cards. So it might hve same problems with newer cards
bridgman: yeah, the 2d engine didn't change all that much from r128 right up to 5xx/rs6xx
bridgman: so the problem is on blits from vram to system memory, right ?
suokko: dma engine didn't either I guess
bridgman: which PM4 packet are you using ?
bridgman: CPDMA or BITBLT etc ?
bridgman: which operation, let's say...
suokko: bridgman: BITBLT first for GTT->VRAM copy and then next DMA fails for VRAM->VRAM copy
suokko: OR it can happen so that BITBLT happens first for VRAM->VRAM and then VRAM->GTT fails with DMA
suokko: I use direct register writes because that is what was already used for BO moves in kernel
suokko: (or direct register writes in ring)
bridgman: just direct register writes in ring ?
bridgman: or a mix ?
suokko: just ring
suokko: But not using PM4. That was what I was trying to say
bridgman: or at least not using type-3 packets
Neo_The_User: does anybody recommend any specific MTRR clean up values in the kernel?
bridgman: you are using PM4 for direct register writes in ring
suokko: type-3 yes
Neo_The_User: i get MTRR errors sometimes and X doesnt start
suokko: yes type-0
bridgman: Neo; I think that's one of those areas where everyone says "it's too damn complicated, stop messing with it" ;)
suokko: bridgman: you can get code from http://people.freedesktop.org/~suokko/radeon_test_patch/ if you have agp system and kernel code around ;)
Neo_The_User: i didn't touch the MTRRs. im using the stock kernel
bridgman: right now my only agp system is the XP box at the office
suokko: typo warning. I don't use X ;)
Neo_The_User: last night on arch64 with the stock drivers and kernel and everything, i had to reboot 6 times and it worked
suokko: Good for you not having agp systems :) I start hating whole idea behind agp
suokko: Neo_The_User: Maybe some slowdown beofre X starts would help if it is some timing issue
Neo_The_User: ah ok
suokko: But I don't know anything about mtrr issues. Just guess if it is random failure so slowing down stuff usually helps
Neo_The_User: slowing down stuff by not compiling 3 different things at the same time and watching dvds in mplayer via frame buffer?
suokko: I mean that some initialization is going too fast because it doesn't wait for hw and so next initialization step tries to use hw before it is ready
Neo_The_User: ah i see. thanks!
suokko: But if it is happennig long after boot then it is probably not that issue because most hw is initialized in boot
Neo_The_User: nah it happens right after boot
Neo_The_User: thank you so so much
Neo_The_User: depends on gedit
arekm: playing with clang http://carme.pld-linux.org/~arekm/clang/ati/2009-09-19-1/
Neo_The_User: wow thanks arekm! clang is pretty cool
[Enrico]: Neo_The_User: but not complete yet. bute sure it is primising :D
suokko: Isn't compiler supposed to optimize all dead assigments and dead initializations?
suokko: So that programmer doesn't have to write special code for every case if some variable is used or not after
Neo_The_User: writing good code is a good habit
suokko: Neo_The_User: Good code initializes all variables and is generic.
suokko: Only 9 last errors are really important ones ;)
Neo_The_User: like a compiling error you mean?
nanonyme: isn't impressed with clang until it can handle inline Assembly properly
Neo_The_User: who... in the world... uses assembly? except 1337 h4x0rs who decompile binaries and call themselves geniuses?
nanonyme: Neo_The_User: Mesa.
suokko: libdrm, kernel
nanonyme: Well, yeah, those too.
suokko: Any more examples?
Neo_The_User: uhh... k then i wasn't thinking of inline
suokko: I think we well never get rid of inline assembly because compilers can't do all the optimizations without taking hours per source file
suokko: And some new instructions are not implemented correctly in compilers and all kind of limitations that slow down code
Neo_The_User: the only bad part about assembly that i hate is that i cant write a bash script that contains super complex ascii art neatly the way i have it in the assembly window thingy
Neo_The_User: changes the format of the art on me, when i dont tell it to
suokko: I hate macros
nanonyme: Well, the icky bith with clang is that it doesn't just have to implement any inline Assembly, it has to implement explicitly *GNU* inline Assembly.
nanonyme: With all the extensions.
nanonyme: Otherwise things aren't gonna compile.
es-web: Hi, I have an Acer 4501 WLMI with an ATI radeon mobile 9700. I'll like to enable tv out on it (Im running CentOS 5.3)
suokko: Yeah. GNU is evil vendor locking ;)
nanonyme: It is... :(
nanonyme: But what can you do, too much depends on it nowadays.
nanonyme: wonders if es-web's card is an AtomBIOS and supports AtomBIOS tv out
suokko: Good part is that more tools are starting to default standar compliant behavior and have switches for extensions
suokko: nanonyme: It isn't
suokko: That one is r300
bridgman: 9700 would be too old for atombios
suokko: Do we have any tv-out for r300 that realy works?
suokko: I think r200 has soem wroknig implementation but I haven't tested it (I don't have S-video)
Neo_The_User: my r300 hs s-video but i use DVI
suokko: es-web: What version of video-ati you have?
Neo_The_User: well.... i DO have an r200 with s video but it has no fan hence it starts on fire
suokko: And how much rhel patches is there? :)
es-web: suokko how do i check that? im a bit rusty is some time since i played around last
suokko: xorg.log should tell the version
nanonyme: bridgman: Is the tv out stuff in those chips done in-house by ATi or third-parties, btw?
bridgman: mostly in house but PLLs used to be third party IIRC
es-web: ATI driver version 6.6.3
suokko: es-web: You should probably try some new livecd if tv-out work with them. That driver is quite old
nanonyme: bridgman: Just wondering if there's anything that *might* prevent from being entirely open about that part of the card architecture. :)
VitRuss: suokko: I've recompiled kernel, but now X hangs when startingwith radeon.modeset=1, if no radeon.modeset - no desktop effects in kde4.
suokko: bridgman: I was just wondering how to do the AGP flush because there is wait for agp flush in wait until register
suokko: VitRuss: Can you paste the dmesg and xorg.log from both cases?
suokko: to nopaste or what ever you like :)
VitRuss: suokko: but with modeset console is looking very good :) I'll try, some problems with dmesg)
suokko: VitRuss: btw, with modesetting you should make sure that radeonfb or uvesafb or vesafb modules aren't loaded or build in and messing up drm modules
VitRuss: suokko: no such modules. everything is disabled in kernel
suokko: good :) They just are known to conflict with modesetting
suokko: VitRuss: magic console command is dmesg | curl -F file=@- nopaste.com/a
spreeuw: another game with texture load problems
spreeuw: true combat elite
spreeuw: enemy territory doenst have the issue
spreeuw: maybe its a texture type or size bug
spreeuw: but almost certianly a s3tc bug
VitRuss: suokko: wow :) thx)
suokko: spreeuw: Can you disable texture compression from the game?
suokko: There should be some config option for it
dileX: suokko: what about adding "LIBGL_DRIVERS_PATH" as alternative to... ModulePath "/opt/xorg/lib/xorg/modules,/usr/lib/xorg/modules" (build-wiki)?
spreeuw: Mesa warning: software DXTn compression/decompression available
spreeuw: ...using GL_S3_s3tc
spreeuw: Initializing OpenGL extensions
suokko: dileX: they are not same thing. Modulepath is for ddx loading and LIBLF_DRIVERS_PATH is for dri driver loading
danau: Where in the radeon driver could I search if I want to diagnose a problem with screen resolutions?
bridgman: nanonyme; you mean like selling the division that developed the TV-out hardware ?
dileX: suokko: right. but it would be fine to mention it as an alternative in section mesa (dri-drivers)
dileX: suokko: "glxinfo | grep nGL" -> "glxinfo | grep OpenGL" (nGL might confuse on first view)?
nanonyme: bridgman: No no, I meant as in perhaps someone in the company being capable of saying just what the heck the open drivers are doing wrong. ;)
suokko: dileX: yes. yo ucan fix it because I'm not running X just now ;)
suokko: It is free wiki
danau: I already added some debug-statements to legacy_output.c, radeon_modes.c and radeon_output.c, but couldn't find a solution there.
bridgman: we sold the division that had the engineers who designed this stuff
dileX: suokko: you are free!!! X-free, hahaha
suokko: danau: xorg.log is the best place
spreeuw: ah got it,
suokko: dileX: You are free to fork ;)
spreeuw: in ~/.drirc works around it
danau: suokko: Yes, I checked the messages from xorg.log and looked where they appeared in the driver.
spreeuw: for games with dual types of textures
bridgman: so that makes things take a little longer
suokko: So texture compression isn't yet working correctly.
nanonyme: bridgman: Ah, too bad.
spreeuw: hmm actually it
spreeuw: one sec
spreeuw: testing vegastrike
bridgman: not a big deal, we just need to spend enough time comparing code with the Catalyst drivers, but it takes time and it's not the highest priority yet
spreeuw: inside the engine it seems to work, just intialisation is failing or something
nanonyme: Yeah, that works too.
suokko: Too much basic feautres are missing :/
nanonyme: Assuming Catalyst drivers actually had a working tv out with the chipsets.
spreeuw: inside the r600 driver s3tc textures seem to be accepted
spreeuw: since vegastrike uses ono other textures
danau: I first checked xorg.log, then tried some configuration changes in xorg.conf, then updated my bios and now I compiled the latest version of the driver.
suokko: So What is your problem? I don't know ddx code well yet
suokko: Also do you happen to have 2.6.31 kernel with KMS?
danau: No, I have kernel version 2.6.28. The problem I'm having is also described here: https://bugs.freedesktop.org/show_bug.cgi?id=19843
suokko: danau: But modesetting stuff works about like: read EDID, Try to add a few more standard modelines, then pick prefered one from EDID or xorg.conf
spreeuw: woops no vegastrike crashes my machine
suokko: It of course adds custom modes from xorg.conf same time as tring to add standard modes
spreeuw: but it showed the loader screens fine this time
spreeuw: when it starts loading textures the machine became gradually unresponsive, as if it wnet swapping
spreeuw: then I had to magic sysrq out
spreeuw: nanonyme: if you want to test check this http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html
spreeuw: and driconfig for options
spreeuw: this used to work on r300 fyi
danau: suokko: Yes, I also searched for mode-lines for this specific screen/setup. But I couldn't find them. Is there a tool that I can use to generate a mode-line for a currently running configuration?
suokko: danau: Did you try it now with 6.12.4 and it was still broken?
VitRuss: suokko: I can't get Xorg.log in fail case. But here are: http://nopaste.com/p/a0syaSj6hb dmesg without modeset, http://nopaste.com/p/aCQMdIv4K dmesg with modeset and http://nopaste.com/p/agr5mvZV3 xorg.0.log without modeset
suokko: danau: new one should output a lot more details about modes than your old 2.6.9 where you had the xorg.logs in bug reports
danau: suokko: the version I now run was checked out with: git checkout -b 6.12-branch origin/6.12-branch
danau: So that is the 6.12 branch I guess.
danau: It still is broken.
suokko: danau: There is no tool to calculate the modes that I know of
suokko: danau: Can you update the bug report with new xorg.log?
spreeuw: wow tce looks awesome in hires ;p
suokko: VitRuss: Does your ddx, libdrm and mesa support modesetting?
suokko: that means libdrm compiled first with --enable-radeon-experimental-api
suokko: and then reconfiguring and recompiling mesa and ddx
suokko: some bleeding edge distriputions have that enabled already
danau: suokko: Yes, I'll update the bug-report. Unfortunately I cannot be online on IRC while restarting X.
stikonas: what does "no rrb" means in mesa/progs/samples/star output
suokko: stikonas: warning wrong radeon state emit
suokko: It is dri driver output
suokko: VitRuss: your ddx at least supports it. It is shown in xorg.log
suokko: so libdrm does too
VitRuss: suokko: ok :) I didn't find it in PKGBUILD, so started recomping))
VitRuss: suokko: http://nopaste.org/p/aSUbM7DTf kernel config just in case for you to check, maybe I've forgot something...
suokko: VitRuss: your dri initialization is failing without detailed error message. That would need a patch to add a few of them
suokko: VitRuss: Now I found the problem. you are missing DRIQueryVersion symbol
suokko: VitRuss: That should be part of dri module for xserver
VitRuss: suokko: so what I need to recompile?))
suokko: libdri.so xorg module
Neo_The_User: agd5f: pingzz
suokko: that means xserver
suokko: VitRuss: It might be enough to make it load but it sohuld be autoloaded from /usr/lib/xorg/modules/extensions/libdri.so
Neo_The_User: wait no.. disregard that agd5f
airlied: suokko: you might look at the PRE_WRITE_TIME stuf in the odcs giving out about AGP cohereny
VitRuss: suokko: do you think it will be enought to create xorg.conf with Load "dri"?
suokko: VitRuss: If you can find that libdri.so file then maybe yes
VitRuss: suokko: the file is in the path written in xorg.log...
nanonyme: spreeuw: Hmm, having read the whole documentation, that library smells a bit like fail. :(
suokko: airlied: Does it affect all wait untill operations?
suokko: yes. I don't have X running to read the pdf docs :/
suokko: Maybe I could find them with google and read from there
suokko: nanonyme: That why we should use the texture tools ;)
nanonyme: suokko: pdf2txt is an awful solution if you're desperate enough.
nanonyme: Or whatever the name was.
airlied: suokko: I'm not sure it'll help in kms case since we dont use writeback
suokko: airlied: But I guess I will get mre info about where the old data is coming with my next patch which makes cpu to write to vram 4 bytes to begin of bo with a known value to see if that affects dma transfers
spreeuw: nanonyme: it works on r300
suokko: But because problem is also affecting situation when previous copy was done by blit from vram to vram it sounds like it might not be agp issue exactly
spreeuw: its also required for usable 3d on a desktop
spreeuw: many games use it
nanonyme: spreeuw: Did you actually read what it can and cannot do?
spreeuw: but its only really problematic for the ones distributing textures precompressed
spreeuw: the games now not working used to work fine with r300
spreeuw: iirc unreal is a major one
spreeuw: and vegastrike
nanonyme: "However, the driver behaviour of not supporting online-compression/decompression, but only precompressed textures, is not OpenGL conformant. "
spreeuw: but there must be a bunch more
nanonyme: It can handle *only* precompressed textures, nothing more.
spreeuw: yes the other case is already covered by the ingame setting
spreeuw: with games that compress on the fly you can just disable it
nanonyme: Hmm, right. But aren't we wanting texture compression/decompression too here? ;)
spreeuw: you dont need it
danau: suokko: I added the latest XOrg.log files as well to the bug-report.
spreeuw: in any case, precompressed texture is broken
nanonyme: spreeuw: Depends on the amount of vram memory available as far as I've understood.
spreeuw: this used to work with r300
spreeuw: could be a general mesa bug too
nanonyme: That is, whether we want full s3tc or not.
suokko: I think r200 has better support for compression ;)
spreeuw: they all use the same mechanism
suokko: I never realy have tested it but never had problems either
nanonyme: suokko: Hmm, which algorithm?
spreeuw: as far as mesa feeding it
nanonyme: Or did you still refer to s3tc? :)
nanonyme: I was already getting hopeful someone wrote their own free compression algorithm. ;)
VitRuss: suokko: yes! It works! I've recompiled xorg and compositing is working now!
suokko: good. Does that help KMS case too? If not whathappens if you disable dir in xorg.conf with KMS?
danau: Should I also test with an unstable branch, or wouldn't that help?
suokko: danau: There isn't much changes between them. unstable only adds kernel modesetting support
danau: Ok. Is there anything else I can do to diagnose the problem?
suokko: sorry. I couldn't find the updated log file to check it too
danau: This is the attachment I just added: https://bugs.freedesktop.org/attachment.cgi?id=29703
danau: It should contain 3 log-files.
suokko: Now I see it. links2 is jstu a bit too aggresive about caching :)
nanonyme: ctrl+r doesn't work for refreshing?
suokko: It does. I had closed links and opened it and it was still oading the page from cache so I couldnt believe ctrl+r would be solution
VitRuss: suokko: what do you mean KMS case? all is working. There are some picture corruptions, but in general is very good!
suokko: VitRuss: to picture corruption disabling downloadFrom/uploadToScreen might help
suokko: They are still not stable in all hw compinations (AGP is the worst)
VitRuss: suokko: what's this?
suokko: VitRuss: man exa
suokko: It is hardware accerlation to enable faster transfer of data between gpu and cpu
VitRuss: i'll try :)
EruditeHermit: soreau, how did fixing the water effect bug go?
soreau: EruditeHermit: nha said he will be looking into it monday since it is a holiday where he is
soreau: apparently piglit has already shown broken sin/cos in the compiler
agd5f: es-web: tv is supported on all radeons except the origina r100 and r200 since they used external theatre chips for tv-out
soreau: agd5f: Ive asked a couple of times but why is enabling svideo broken atm? says something about optcode i/o error iirc
agd5f: soreau: works here. what error are you getting?
soreau: agd5f: http://git.pastebin.com/m6c964d7a
agd5f: soreau: you don't have an s-video output listed
agd5f: only vga and dvi
soreau: agd5f: How can I find out why that is?
agd5f: soreau: using kms?
agd5f: Not sure if dave merged the tv-out stuff yet
agd5f: soreau: what card do you have?
soreau: rv350 (radeon 9600)
agd5f: soreau: need to check why it's not enabled in the drm. in the meantime you can use ums
soreau: agd5f: ums?
airlied: should be all merged
soreau: Does that mean nonkms?
agd5f: soreau: userspace modesetting
soreau: agd5f: Ok thanks
soreau: airlied: Is there anything I can do to check why it's not working here?
airlied: soreau: you running drm-next?
soreau: no, just .31
airlied: ah thats why then
soreau: Alrighty. Time for some drm-next love. What's the link again please? ;)
suokko: soreau: topic ;)
suokko: there is link to the link ;)
soreau: suokko: Thanks ;)
EruditeHermit: soreau, are you on ubuntu?
soreau: EruditeHermit: Nah, this is gentoo
soreau: But I haven't built a kernel without the package manager downloading and patching it for me before
soreau: I don't think it should be that difficult
soreau: I don't understand the portion under "alternatively use drm-next as is". What is actually cloned there?
suokko: drm-next that is some rc kernel
suokko: But you shouldn't realy do it unless you run into merge problem with first variant
soreau: what about making a patch? why does it tell you how to do that?
suokko: soreau: Kano did need that so I though it wouldn't hurt there. Some distribution packanging stuff probably (trying to pathc debian kernel maybe)
soreau: I hope make oldconfig with my old config from .31 is enough
suokko_: soreau: It will ask if there is any changes to config
soreau: suokko_: It just did automagic like it has been doing through the .31 rc's
soreau: No prompts. So I hope it didn't miss anything
jabagawee: how can i keep up with radeon development?
jabagawee: is there any websvn or irc bot or the like to keep me updated?
EruditeHermit: jabagawee, you can look at the commits on http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
EruditeHermit: or http://cgit.freedesktop.org/mesa/mesa/
jabagawee: wondering, what are the major differences between radeon and radeonhd?
jabagawee: read something about atombios, but a friend said that news was outdated
EruditeHermit: jabagawee, radeonhd didn't want to use atombios; they wanted to program the card directly
EruditeHermit: I am not sure, but I think since then, they started using it too
jabagawee: yeah, that's what i've been hearing
jabagawee: both are using atombios, so what would the difference be?
EruditeHermit: less and less now
EruditeHermit: they both use the same 3D driver
EruditeHermit: the only difference is the DDX driver
jabagawee: googles ddx
jabagawee: from what i understand, atombios is basically a wrapper ati provides the oss community to perform method calls on
jabagawee: sort of, no?
EruditeHermit: its an abstraction layer
jabagawee: Pitxyoki, hi
Pitxyoki: I've been searching about ATI cards on linux, and I'd just like to confirm this:
Pitxyoki: Do all supported ATI adapters have 3d acceleration with the closed-source module?
EruditeHermit: well yes and no
Pitxyoki: If it is on this list, http://wiki.cchtml.com/index.php/Hardware , it means that I will have 3d?
Pitxyoki: (with fglrx, at least)
EruditeHermit: Pitxyoki, r6xx and r7xx cards (i.e. Radeon HD2xxx, 3xxx, 4xxx) have ongoing support with fglrx
EruditeHermit: r500 generation and below, i.e Radeon X1xxx X series and things below that do not have monthly released drivers for new kernels and Xservers etc
EruditeHermit: the above is all for fglrx
EruditeHermit: r500 and below has open source 3D support
soreau: agd5f: airlied: http://pastebin.com/m5c6f6f7e
Pitxyoki: That means that maybe, someday, the currently supported cards may stop being supported by ATI, right?
EruditeHermit: Pitxyoki, more than likely
EruditeHermit: Pitxyoki, but, there is open source support for the legacy cards
EruditeHermit: Pitxyoki, what they want to do is support the newest cards with catalyst(fglrx) proprietary driver and then support legacy cards with the open source drivers
Pitxyoki: I'm considering on buying a laptop with an HD 3470, so I'm trying to ensure it won't be a bad choice.
EruditeHermit: Pitxyoki, open source radeon 3D acceleration for that card is just now becoming available
EruditeHermit: as in, its in its early nascent stages
EruditeHermit: but full 3D support is available through Catalyst (fglrx) proprietary driver
Pitxyoki: I don't mind it much if for now it has an open or closed-source driver, as long as I have 3d. Of cource, I'd prefer it was open, but if there is a possibility I'll be happy with it.
Pitxyoki: So I guess I won't be disappointed with an ati, then.
EruditeHermit: well in the future, there will be open source 3D support
EruditeHermit: they have some employees working on the open drivers as well
Pitxyoki: Out of curiosity, do the sources for the old cards' drivers reveal anything that could be essential for that technology at the time?
EruditeHermit: no idea
Pitxyoki: Anything that really justified them being closed?
EruditeHermit: they never released the sources
EruditeHermit: they released documentation on them
Pitxyoki: Then the employees they have working on the open drivers only have access to the docs too?
EruditeHermit: so AMD released specifications about their cards and documentation about how to program them
soreau: Pitxyoki: Everyone has access to the docs now since amd began releasing specs
Pitxyoki: I mean... The reason these companies make the drivers closed is usually because they don't want their competition to know much about the internals of their cards, no?
EruditeHermit: yes and no
soreau: Pitxyoki: The closed source drivers have something to do with licensing issues iirc
EruditeHermit: another important ( maybe more important) reason is fear of being sued
Pitxyoki: If they are working on the open-source driver and eventually will help release full open drivers in the future, those "secrets" will eventually be revealed...
EruditeHermit: well for example they didn't release docs on the video decode block
Pitxyoki: That could explain something.
EruditeHermit: for fear of being sued by companies from whom they license technology
EruditeHermit: and also to stop their HD video decode keys from being revoked
airlied: soreau: try "load detection"
EruditeHermit: for DRM protected content
airlied: for kms, I should probably make it the same as non-kms
kcodyjr: also, to be totally blunt and cynical, proprietary drivers remain closed partly because they don't want anyone to see how bad the code sucks
soreau: airlied: That didn't give an error at least, but it effectively did nothing afaict. xrandr's still showing S-video as being disconnected
EruditeHermit: kcodyjr, there is no way for us to know =p
airlied: soreau: anything in the logs about conflicts?
EruditeHermit: we've never seen it
kcodyjr: precisely, EruditeHermit
airlied: some of us have
airlied: not me but others
soreau: airlied: Sorry, which logs? X log?
airlied: soreau: dmesg
soreau: airlied: Hmmm
airlied: at least two people in this channel have had the displeasure of seeing fglrx internals
kcodyjr: i've seen some companies closed stuff, though nothing from amd or ati. generally their coding discipline sucks.
soreau: airlied: http://pastebin.com/m2f457234
soreau: I've yet to see compiz in dmesg until now ;) *tries with xfwm4*
airlied: soreau: nothign back up when radeon loads?
soreau: airlied: I have radeon built in http://pastebin.com/m3d69e85e
airlied: ah okay its not conflicting then
airlied: wierd the r300 load detect might be broken
soreau: and I don't think xrandr is causing any syslog messages as it doesn't show anything new after I try load detection
Pitxyoki: One more thing: if for some reason I can't install th fglrx drivers, vesa should still work, right?
soreau: airlied: And fwiw, I tested o .31 dri and it works (though it suspiciously failed one time in a similar fashion until I booted again)
soreau: Err.. dri1
EruditeHermit: Pitxyoki, vesa will work and the open source radeon driver will work for 2D with most current distros
soreau: tries a cold boot for kincs
soreau: kicks too
EruditeHermit: Pitxyoki, the next distro refresh will also have 3D working for it
EruditeHermit: open source
EruditeHermit: but limited to OpenGL 1.3
EruditeHermit: Pitxyoki, Ubuntu 9.10
EruditeHermit: next Fedora release
kcodyjr: in the long run i've never been disappointed with ati hardware, Pitxyoki. you may have to live with finicky drivers (fglrx) or a temporarily restricted feature set (open source drivers) but once the oss drivers stabilize, you'll be damn glad you didn't buy the other guys' card.
EruditeHermit: next Mandriva
Pitxyoki: But that's with the proprietary driver, right?
EruditeHermit: even open source
Pitxyoki: I use Debian, I've even been using the experimental drivers for my intel card until recently.
EruditeHermit: Pitxyoki, so radeon6xx/7xx 3d support will be in kernel 2.6.32
Pitxyoki: So i guess that "refresh" might have even have arrived here.
EruditeHermit: Pitxyoki, any distro that uses that kernel and newer will have basic 3D support open source
Pitxyoki: So it's going faster than I thought.
EruditeHermit: so actually it will miss Ubuntu 9.10
EruditeHermit: but it will be in Ubuntu 10.04
Pitxyoki: google seemed to be a little derrotist about ati+linux.
EruditeHermit: well ATI+LInux has sucked until recently
kcodyjr: give me five minutes with google and i'll find you a scientific study that says most people don't like sex. it's google.
EruditeHermit: over the last year and a half it got a LOT better
Pitxyoki: kcodyjr, thing is, maybe now you need 5 or more minutes to find google telling you what I just discovered here.
EruditeHermit: actually even over the last 6 months it got significantly better
EruditeHermit: hardware wise, ati cards seem to last long
kcodyjr: i'm well aware of the nvidia vs ati debates. reality check is: nvidia's closed source drivers behave better than ati's closed source. both of them are a varying degree of a PITA depending on your distro. OSS drivers are not a pain in that regard, and the ATI guys are way the hell ahead of the nouveau guys in that department.
EruditeHermit: nvidia had that melting issue
kcodyjr: and historically, ati hardware has always displayed a higher quality image, testable only during those rare moments of driver equilibrium of course.
EruditeHermit: anyway you cut it though, Linux graphics is doing a lot better than 3-4 years ago
airlied: not sure we way the hell ahead of nouveau either :)
EruditeHermit: you won't be in terrible shape with any vendor
EruditeHermit: airlied, noveau doesn't even boot on all NV cards
EruditeHermit: it chokes on IGPs
airlied: EruditeHermit: it boots all the ones we have here.
EruditeHermit: airlied, do you have an nvidia IGP?
kcodyjr: i respect that kind of humility airlied, but the fact is, you got specs, and the nouveau guys are left doing bus snoops.
airlied: kcodyjr: you'd be surprised how little difference that can make,
airlied: its a lot more of a mindset change
airlied: having specs amkes you wait around for information
EruditeHermit: but if something is not working you have bridgman who can talk to fglrx devs
Pitxyoki: One thing is true: 5 years ago I couldn't get this intel card working with any distro.
airlied: EruditeHermit: rarely does that help over just RE'ing fglrx ourselve ;)
airlied: the thing is the driver architectures are nothing alike
EruditeHermit: well atleast you have a way to figure out how someone else solved a problem
kcodyjr: imo the driver is still expected to do way too much
airlied: and the guys work worked on fglrx for r500 say have long since moved on
EruditeHermit: even if its a bad solution
airlied: EruditeHermit: RE'ing gets that just as quick
airlied: in fact RE'ing means you didn't get lies in the first place from the docs ;-)
soreau: airlied: This might be of interest: Here on .31 ums, load_detection works but "load detection" fails with the same error message as load_detection does on .31-00132-g864aa7a
Pitxyoki: 4.5 years ago, only Ubuntu gave me that pleasure... And only 2 years ago I could install and use debian here.
airlied: soreau: yes the _ needs fixing in kms vs ums
kcodyjr: i've been living on the edge for years (gentoo) so i can't really sympathize with distros being out of date.
soreau: airlied: I guess there's no cheap hack to get around that for now?
airlied: soreau: hack around what? the _ or the fact detect doesn't work
EruditeHermit: airlied, you'd know I guess, but I talked to the nouveau people and they don't have 3D on any card and no 2D on IGPs. Radeon is a lot further along than that
soreau: airlied: I don't know what's b0rken exactly ;) (just to get it to work some way proving the breakage is in one place or the other)
kcodyjr: airlied, i'm still a little fuzzy on how the gart interacts with the rest of the physical address space as seen by the card
airlied: EruditeHermit: well I hired Ben and he sits next to me ;-)
airlied: pool &
kcodyjr: is the card actually blind to anything not programmed through the gart? or does the gart merely occupy some arbitrary space, overriding the card's view of physical within that aperture, but that aperture can now be pointed anywhere including high memory?
airlied: kcodyjr: its just a window in a 32-bit address space
EruditeHermit: airlied, according to their website, it says IGPs don't work. Can you ask him?
EruditeHermit: am I wrong about that?
EruditeHermit: if they do, that would be awesome and I could buy the laptop I wanted =p
kcodyjr: i mean, in the case of a straight pci device, it can see the bottom 32bits of physical, straight through to the chips. can a chip behind a gart still see (directly) whatever isn't being occluded by the gart aperture?
kcodyjr: behind a full blown iommu i'd say no, that's what an iommu is for, but i'm not clear how much a gart is iommu and how much it's hack
Pitxyoki: Oh, by the way...
kcodyjr: just when i was thinking there was an undetected netsplit.
Pitxyoki: Do the fn keys on laptops generally "work" when a card is supported or is that something that's out of the ati's driver scope?
[Enrico]: Pitxyoki: do you mean the bright up and down keys for example?
chithead: or the enable/disable external monitor
[Enrico]: mhm no idea
Pitxyoki: The brightness and contrast keys.
[Enrico]: but on my laptop it is the asus_laptop module that detects these fn keys
Pitxyoki: Google had shown me this a while ago: http://ubuntuforums.org/showthread.php?t=905111&page=2
Pitxyoki: That's why I'm asking.
chithead: brightness usually works independent of the graphics driver, you need acpi backlight and possibly vendor specific notebook driver
[Enrico]: Pitxyoki: so be sure to have them and also acpid running at default or boot runlevel
Pitxyoki: Thank you all.
Pitxyoki: I'm leaving now. Really, thanks a lot for all your help.
kcodyjr: MostAwesomeDude, maybe you'd know. what does the chip see in the bus address space, outside of its fb, mmio registers, and the gart aperture? will it see the physical ram pages or will it get bus errors?
MostAwesomeDude: kcodyjr: The chip doesn't even see that. It sees VRAM and anything mapped into it.
kcodyjr: ok i thought the video ram was a chunk of actual ram mapped into the bus address space
MostAwesomeDude: No, the VRAM is the RAM that's on the card.
MostAwesomeDude: The CPU can see a bit of VRAM that's mapped into main memory.
MostAwesomeDude: And the GPU can see main memory mapped into VRAM (using the GTT.)
kcodyjr: gtt maps from bus space to gpu space?
MostAwesomeDude: IIUC yes.
kcodyjr: does the gtt have anything to do with the gart
kcodyjr: or will the gtt function even in the absence of a gart, for example on a vanilla pci device
kcodyjr: what i'm getting at is, let's say i want to dynamically map some physical system ram into the gpu's view. for further simplicity let's say i want exactly one page.
kcodyjr: if my understanding is correct, i would need to either a) pick something below 4GB, or even lower if the particular card can't see all of the pci 32 bits, and then program the gtt so the gpu can see it or b) i would need to program the high memory page into the gart, and then move on to gtt setup as in the first case. have i got it right?
MostAwesomeDude: Something along those lines.
kcodyjr: so then, and here's the bottom line, if i wish to get my page of system ram visible to the gpu without involving the gart, the physical page must also not be in that space occluded by the gart aperture, in addition to being within the card's range to begin with
kcodyjr: so a smart gart aperture placement, from the card's point of view, would "cover" areas of physical ram that are tied up with something else
kcodyjr: hm. that makes the gtt effectively a pagetable, giving the gpu a virtual address space much like the cpu sees
kcodyjr: does that mean the gtt has to have an entry for the mmio register range, if you want the cp to be able to set registers?
soreau: airlied: I put an underscore in drivers/gpu/drm/radeon/radeon_display.c line 680 and now load_detection doesn't give an error but it still doesn't work either. S-video simply remains disabled/disconnected
soreau: Took me a minute to realize it installed the new kernel as -dirty ;)
bridgman: kcodyjr; cp has a direct path to the gpu registers; it doesn't have to go through the bus or anything
soreau: Also I would like to know whether or not xrandr is misreporting my max tex size at 4096x4096. This rv350's max is 2048 afaik, reported by glxinfo -l
soreau: Wherever I can get s-video out working, it is reported as 2048x2048 by xrandr
soreau: With drm-next kernel, do I need libdrm?
soreau: and when using drm-next kernel, does any component need to be compiled against it?
soreau: (like.. libdrm)
soreau: or do all the nonkernel components only need be compiled against each other
mwu: I think you just need to compile libdrm from git and turn on the experimental radeon api stuff
soreau: mwk: thanks
mwk: soreau: no problem.
EruditeHermit: hey, anyone have thoughts on whether the 785 chipsets are better than the 790 chipsets?
airlied: kcodyjr: it depends on the GPU setup, radeons can passthrough the non-gtt/fb address space straight to PCI or they can have it generate an error