Sinuvoid: How goes the progress for the r400
Sinuvoid: (post git plz?)
agd5f: Sinuvoid: goes well
Sinuvoid: Yay
Sinuvoid: Improved ut2004 gameplay :D
Sinuvoid: And emulation, woot
Sinuvoid: agd5f, could you post me a link to the svn/git please?
agd5f: Sinuvoid: http://cgit.freedesktop.org/mesa/mesa/
Sinuvoid: Thank you
Sinuvoid: Alright, things are looking up 8)
EruditeHermit: r400?
EruditeHermit: didn't realize anyone was working on r400 specifically
Sinuvoid: I meant r300 or whatever osiris is working on
Sinuvoid: I'm sure I mean r300.
EruditeHermit: ok
EruditeHermit: yeah OQ last week
Sinuvoid: ?
agd5f: Sinuvoid: vbo and oq stuff got committed to master last week
Sinuvoid: What is oq?
Sinuvoid: And yeah, I heard that vbo was added a (week?) ago :P
agd5f: Sinuvoid: occlusion query
Sinuvoid: agd5f, ah ok :p
soreau: thanks for pointing that out EruditeHermit, rc7 seems to be working with even better kms performance! :)
EruditeHermit: soreau: np
airlied: glisse: I've got some things rendering but badly
airlied: glisse: my r6xxcs branch has where I've hacked my way up to
mcgreg: cool, you fixed the random crashes finally :)
simplexe: hmmm... after update to latest mesa, glxinfo shows swrast, although AIGLX use r600_dri in xorg.log. glxgears also using swrast =(
mcgreg: check LIBGL_DEBUG=debug glxinfo
mcgreg: some stuff still is badly broken , ioquake3 has still as textures broen, the texts and gfx even in the menus are broken and bad corruptions everywhere
mcgreg: celestia seems to have no textures at all :)
simplexe: mcgreg: hmm... nothing
mcgreg: sry for the dumb question ..are you sure it says nothing?
mcgreg: ahh openarena==ioquake3==same problems (same corruptions)
simplexe: mcgreg: nothing errors
simplexe: simple render yes and bla-bla-bla...
EruditeHermit: simplexe: you need latest libdrm
simplexe: EruditeHermit: 20090824-1
EruditeHermit: simplexe: try this
EruditeHermit: LIBGL_DEBUG=verbose glxinfo
simplexe: it's installed
EruditeHermit: and paste the output to pastebin
simplexe: EruditeHermit: http://pastebin.org/11569
EruditeHermit: simplexe: did you do LIBGL_DEBUG=verbose glxinfo?
EruditeHermit: or simply glxinfo
simplexe: LIBGL_DEBUG=verbose glxinfo
EruditeHermit: you are missing some of the debug info
glisse: airlied: is it the vbo alignment that fix it ?
glisse: also it's better to not use write domain
glisse: as libdrm-radeon doesn't like a buffer being in write & read domain
glisse: which happen in the copy path
glisse: airlied: also i have the ddx X recycling patch that might need review
glisse: http://people.freedesktop.org/~glisse/radeon-kms-master.patch
Terman: I'm having trouble with X1400 mobility, KMS and suspend/resume (to/from ram)
Terman: the system is rc6 based. After resume, the picture only consists of vertical stripes and I have to reboot to fix that
Terman: there are log messages that indicate problems :-)
Terman: I've uploaded the information I collected to http://www-agrw.informatik.uni-kl.de/home/jmayer/radeon-kms.tar.bz2
Terman: the first indication that something might not be right is [drm:radeon_bo_move] *ERROR* CP is not ready use mem
Terman: cpy.
Zajec2: LIBGL_ALWAYS_INDIRECT=1 makes openarena work :) menu isn't corrupted, and it doesn't crash on starting level!
airlied: glisse: not sure what really fixed it ;-)
airlied: glisse: the vbo realloc seemed to help
airlied: since you never waited for the vbo to be idle
Zajec2: does fixing LIBGL_ALWAYS_INDIRECT=0 sound like big issue?
glisse: given that i was testing with 1 rendering op only this didn't seems like the culprit :)
airlied: glisse: also not doing solid for < 8 bpp
airlied: it still wasn't perfect, I was mainly testing stipple
airlied: and it was only covering part ofthe screen
airlied: glisse: and overlap processing
airlied: glisse: what op werer you tseting with?
airlied: the vb stuff is very messed up since every cs_start resets us to 0
airlied: which would overwrite any vertices we just emitted
MrCooper: Zajec2: what's the problem?
glisse: i was testing solid
glisse: and doing only 1 op
glisse: ie no overwritte
airlied: glisse: my solid was failing due to 1bpp
Zajec2: MrCooper: many ppl report apps work nice with LIBGL_ALWAYS_INDIRECT=1
Zajec2: for me it's openarena i tested
Zajec2: without LIBGL_ALWAYS_INDIRECT=1 it has corruptions and crashes on starting level
Zajec2: MrCooper: http://phoronix.com/forums/showthread.php?p=88589
MrCooper: okay, that's certainly worth fixing, performance should be better in general with direct rendering
glisse: Terman: please open a bug and attach various log of your archive and also lspci -v
glisse: it seems the gpu is not properly restored i guess the nmi comes from the gpu
glisse: airlied: what about the ddx recycling patch ?
glisse: does it looks good ?
glisse: i think it's needed in f12 in order to close a batch of bug with gdm failing
airlied: glisse: yup ddx recycle looks okay MrCooper might want to confirm since he fixed it last
MrCooper: which patch is that?
glisse: http://people.freedesktop.org/~glisse/radeon-kms-master.patch
glisse: airlied: is their a way to know which card issued a nmi on a ssytem ?
airlied: glisse: nope, generally the chipset does it
airlied: I used to get one on my rv370 when i did a read from the BAR afte rvram
Zajec2: glisse: are you working on r67xx KMS with acceleration now? or something else?
osiris_: MostAwesomeDude: hey. how did the GSOC go? have you done everything you planned?
Zajec2: what project?
glisse: airlied: do you know if there is anythings amd use beyond the first 64 bytes of pci config ?
glisse: Zajec2: working on kms stuff changing init path so we can use pcigart to mirror agp and fallback to pci on gpu write to gtt space
airlied: glisse: don't think so, that whole mmconf stuff is messy
airlied: so I'd hope they don't
airlied: the only place they might is on an IGP
glisse: airlied: crap it seems they are usefull reg beyond the first 64bytes
Terman: glisse: as this is a bug in the kernel module: which component/subcomponent should I use?
glisse: radeon or drm
MrCooper: glisse: looks good, only minor comment is that other drivers (intel, Gallium Xorg state tracker) just seem to call EnterVT from ScreenInit to acquire master and stuff
MrCooper: airlied: so does your r6xx solid fix take care of the audacity bug?
airlied: MrCooper: no idea I'm fixing mostly by code inspection ;-)
Zajec2: glisse: does r67xx kms accel need much more work? do you have idea if you manage to do that before .32 merge window?
vehemens: airlied: what type of problem would the texture setup problem cause?
airlied: probably none
airlied: neither of those cases should ever happen
airlied: the solid/copy fixes might do more
vehemens: just going to try them out
osiris_: glisse: radeon cs checker is rejecting textures with TXFORMAT=15 (doc says it's reserved but the driver use it for DXT1)
osiris_: the same problem probably exists for TXFORMAT 16 and 17
osiris_: (DXT3 and DXT5)
glisse: osiris_: you can add them to cs checker just make sure you update size computation
glisse: i guess official doc didn't wanted to give dxt stuff
Terman: glisse: https://bugs.freedesktop.org/show_bug.cgi?id=23479
glisse: Terman: next time dont attach archive but individual files
suokko1: GPU hang with fog use flags :/
Terman: glisse: If you want to, I can add them individually
glisse: Terman: add the output of lspci -v
Terman: glisse: it's in script.log ony for graphics as lspci -vvnnxx
Terman: glisse: only
MrCooper: glisse, osiris_: It's indeed trivial for 16 and 17 - just add them to r300_packet0_check - but 15 is trickier, as it seems to use 0.5 bytes per texel
Terman: glisse: if that really isn't what you want, I'll add it again
glisse: Terman: do you have any script for suspend like the pme one
glisse: i think i got the name wrong
glisse: pm
glisse: make sure there is no pm repost video card enabled
Terman: I use opensuse 11.1, with the components updated to run kms. I run "powersave -u"
glisse: well don't know what powersave might endup doing on suse
osiris_: MrCooper: what's the cpp for DXT3 and DTX5?
glisse: Terman: you need to find out if it tries to report video card on resume
glisse: if so disable that
glisse: repost
MrCooper: osiris_: 1
airlied: glisse: my laptop reposts and it works
glisse: airlied: it repost after kernel reinit ?
airlied: no repost before resume
glisse: so its: vbetool repost, radeon kms resume ?
airlied: glisse: no the BIOS does it itself
airlied: some thinkpads do that
airlied: but we should never have vbetool posting
glisse: airlied: yeah but i saw pm doing vbetool repost which screw kms resume
Terman: glisse: I don't understand what you are talking about: can you please explain a bit what you mean by "make sure there is no pm repost video card enabled"
glisse: don't know how to stop tha
airlied: glisse: its a distro problem
airlied: we fixed it in fedora already
glisse: i guess i need to tell the kernel that when in kms we should disable reg access
airlied: Terman: somethnig might be calling vbetool
airlied: glisse: doesn't matter distro has to fix it
glisse: airlied: could at least help us avoinding having tons of bug due to bad distro :)
airlied: glisse: vbetool doesn't use any kernel interface to access regs
airlied: it does everything direct to hw in int10
Terman: vbetool is not installed on my system (I could add it, it's in the repos)
airlied: no don't install it
Terman: that's what I read from your comments :-)
glisse: airlied: yup but there could be a way to forbid vbetool to work
glisse: like with the vgaarbitrer
airlied: glisse: we do that with a new vbetool
airlied: glisse: my latest vbetool doesn't post kernel driver hw
airlied: its already in Fedora
glisse: i guess we will have to suffer bug until other distro picks it up
glisse: or update their pm stuff
airlied: pm-utils is also fixed in theory
airlied: it shouldn't call vbetool anymore for kms machines
taiu1: osiris_: btw I tried your indexes in VBO work
mjg59: airlied: There was a bug filed that we tracked down to nouveau having /sys/whatever/fb1 rather than /sys/whatever/fb0
mjg59: airlied: Probably want to broaden that check
osiris_: taiu1: any perf improvements? did you encounter any lockups?
taiu1: osiris_: seems to work ok if you fixup the case where offset ends up unaligned
jcristau: mjg59: also /sys/whatever/fb0 can exist without kms
mjg59: jcristau: It checks a bit more than that
taiu1: osiris_: maybe some fps ... fall back to fixup when index type is SHORT and client passes mesa_ind_buf->ptr which ends up being not dword aligned
Terman: glisse: the script sends a dbus message somewhere
jcristau: mjg59: the pm-utils from sid doesn't. did that change recently?
glisse: Terman: also please attach output of cat /sys/kernel/debug/dri/0/r100_rbbm_info
glisse: assuming debugfs is mounted on /sys/kerne/debug
mjg59: jcristau: Oh, hrm. No, you're right.
mjg59: jcristau: We'll really get an fbwhatever under /sys/class/drm/cardblah without KMS?
airlied: mjg59: new vbetool will block it anyways
mjg59: airlied: What does it check?
mjg59: airlied: Also, when was that fixed?
mjg59: airlied: https://bugzilla.redhat.com/show_bug.cgi?id=516694
airlied: mjg59: when I ported to pciaccess I wrote at a pciaccess function
jcristau: mjg59: /sys/class/drm/card0/device is a symlink to the pci device so aiui yes
mjg59: jcristau: Ah, oops.
mjg59: Yes, that'd fail.
mjg59: airlied: That looks like it's still happening after the pciaccess port?
airlied: mjg59: it checks if there is a driver link in the pci device dir
airlied: in sysfs
mjg59: airlied: Well, if it's in 1.2.1 then it's not working
airlied: nouveau needs a fix also for vga handover
airlied: I would guess thats why its failing
airlied: wierd the code has the check in it
airlied: mjg59: see if I can get more info
mjg59: airlied: Cool, thanks
Terman: glisse: it's only the output that's garbled - if I happen to be in a window that accepts the command, I type "shutdown -h" and it is executed
glisse: Terman: i do understand that
glisse: but i need more info
glisse: especialy one which are in the debugfs stuff
Terman: the package seems to be suspend from suspend.sf.net
glisse: Terman: as long as you don't have vbetool installed this is good
Terman: glisse: I've attached the stuff you mentioned to the bug
MrCooper: might wanna try writing to /sys/power/state directly just in case?
vehemens: running the cursor over icons causes similar r600 compiz/gnome menu/font corruption
airlied: does s2ram have a copy of vbetool linked in?
airlied: I remember it doing something silly like that
Terman: airlied: ah, that seems to be the case!
Terman: ok, so next step for me is to find out whether somehting like repost is done and if so, how to disable that
airlied: find whats calling s2ram and what options it passes
MrCooper: Terman: have you tried writing to /sys/power/state directly?
airlied: yeah that probably the best idea
airlied: chvt to a console, echo mem > /sys/power/staet
airlied: state even
airlied: mjg59: I don't draop the state save/restore bits just the full post
airlied: ^draop^trap
mjg59: airlied: Oh - yeah, the state restore probably needs to be trapped as well
mjg59: That'll probably be making assumptions about the gpu state
airlied: I'll have to port those bits to use pciaccess as well
airlied: they just do int10 now
airlied: will do it tomorrow
nanonyme: wonders if there's any simple demo at all left that would give the same corruption on r600 as seen in openarena and folks...
suokko1: Is progs/tests/fog broken for you with swrast?
Terman: ok, I have some results: echo and s2ram work when run in vt, they don't work when run from X. powersave switches to vt1 first, but resume never works for gfx, even if started from vt
MrCooper: MostAwesomeDude: btw, the GEM specific bits should move from src/gallium/drivers/r300 to src/gallium/winsys/drm/radeon/
airlied: Terman: so have you a dmesg from echo at the vt?
Terman: I've created one now and attached it to the bug
airlied: Terman: okay so with X running, can you vt switch, echo, vt siwtch back?
airlied: it sounds like s2ram is the issue
airlied: there is no bad things in that log
osiris_: glisse, MrCooper: does http://pastebin.com/m322345f7 look ok to you?
MrCooper: osiris_: looks okay to me
Terman: airlied: that's what I did
nanonyme: Hmm.
nanonyme: arbvptorus hung with r600. :/
airlied: Terman: and switching back to X failed or worked?
MrCooper: osiris_: technically I guess it needs to take the format block sizes into account...
nanonyme: (was trying to run through all the tests to see if I can find one that replicates the corruption, didn't expect X to hang though)
nanonyme: mental note: add an autokill to the tester script so it can kill the test for me in ten seconds
osiris_: MrCooper: what are the block sizes?
MrCooper: osiris_: the compressed formats aren't defined for single textures but for MxN blocks of a fixed size
MrCooper: so this code might underestimate the needed size
Terman: airlied: everything (including X) works fine, as long as I switch to a vt before echo or s2ram
suokko: grr. I got it hung again :/ evil fog block
airlied: Terman: sounds like distro s2ram messing up then
Terman: airlied: echo and s2ram behave identically, it's the powersave -u command that reliably does not work
Terman: airlied: I'll try to find out whether powersave runs s2ram with some arguments like vbe_post
Terman: airlied: but why does the display break at all when I run echo or s2ram from X instead of a vt?
airlied: Terman: generally something needs to vt switch before we suspend
mjg59: The kernel does
chainsawbike: anyone know if there are drivers for the video-capture on radeon x1950xt's ?
airlied: not sure why having X running would interfere then I should try echo mem with X running on some amchine U sppose
airlied: pm-suspend works fine
MrCooper: with KMS it should in theory work without VT switch?
airlied: yup
airlied: though I'm not sure if we have a possible race if we don't vt switch
airlied: though with full state emit per buffer it shuold be okay
suokko: airlied: I greped for any change in code for "FOG" and there is none so something not state related has broken fogcoord (I compared to "r200 fix broken (by new input handling) fogcoord"
suokko: So I don't have idea where fogcoord data is lost in GPU
airlied: suokko: does it work with 7.5?
suokko: I will test
Terman: s2ram seems to be called without parameters (at least accoring to the log), so it looks like something else is causing problems when using the powersave command
Terman: what I still don't understand is that I need to switch to a vt at all to make it work with echo and s2ram
Lutz_Ifer: what videocard does #radeon recommend for a new desktop computer?
airlied: Terman: have you got a dmesg from an echo inside X?
airlied: or dose it not make it back?
suokko: yes. fogcoord works with 7.5
suokko: I guess I could bisect it in dri1 mode
Terman: airlied: I've just asked my wife to lend me her laptop, so once the windows on that machine "works", I can log in remotely and get whatever is needed
airlied: I start with just before rewrite merged
airlied: suokko: ^
airlied: goes to bed &
airlied: Terman: attach the log from the non-vt echo case
Terman: airlied: sure
suokko: Looks like bisecting radeon_rewrite changes is notpossible :/ but somewhere there fogcoord was broken
suokko: Rendering is broken for r200 when Itry to bisect
rnoland: suokko: it should be bisectable... you just need to bisect before the merge commit...
suokko: rnoland: I know it was broken in that merge and I can't bisect what broke it in radeon_rewrite
suokko: Because r200 has been broken for too long in rewrite branch
rnoland: suokko: hrm....
rnoland: suokko: someone needs to send you an r600 card.....
nanonyme: suokko: Didn't you say binary search is efficient? ;)
suokko: nanonyme: Only if it can determine boolean value from compare result ;)
nanonyme: Hrm, right.
nanonyme: suokko: Maybe you could move to radeon-rewrite branch and bisect there?
nanonyme: Errrrm.
suokko: nanonyme: That is what I did :)
nanonyme: Right.
suokko: It is merged to master so bisect goes automatically in to the merged branch
nanonyme: Hmm, right.
suokko: hmm. What if the problem is that aos is set incorrectly and card doesn't read the vector fog at all :/
tball: Hmm do I need drm r600/r700 branch for the new 3d code to work?
tball: Or is it ok just using the ati-dri branch of r600/r700
Luzipher: hi :) hm, I just tried to get 3d working on my r770 with agd5f's kernel-patch from yesterdays logs and glxinfo and gears give me "IRQ's not enabled, falling back to busy waits: 2 24" ... does somebody have a hint what's the cause of this ?
tball: IT says:
tball: dlopen: /usr/lib/xorg/modules/extensions//libdri.so: cannot open shared object file: No such file or directory
tball: (EE) Failed to load /usr/lib/xorg/modules/extensions//libdri.so
tball: But the libdri.so does exist as a symlink to libdri.xorg which doesn't exist? :S
nanonyme: Which distro is this?
jcristau: sounds like fglrx screwup
suokko: fogcoord changes in old code some states that I couldn't match to new states. They are: R200_VS_FOG_PARAM_ADDR[1-2], R200_VS_MATRIX_0_MV[3], R200_VS_MATRIX_0_MV+1[3], R200_VS_MATRIX_1_INV_MV+3[0], R200_VS_MATRIX_1_INV_MV+3[1], R200_VS_MATRIX_2_MVP[3], R200_VS_MATRIX_2_MVP+1[3]. Which state they belong in new code? old code did output float values so hard to match to new hex only output
osiris_: agd5f: there are a few kms only cursor problems
nomore: hi, for r600 3d which drm version do I need?
osiris_: agd5f: first, when running ut2004 in windowed mode the cursor is going crazy
osiris_: agd5f: in penumbra black plague when running in fullscreen mode the cursor doesn't work at all
simplexe: agd5f: "undefined symbol: radeon_bo_is_busy" - this is drm problem?
osiris_: agd5f: and one non cursor related (but kms only too). in quake3 whole rendering is moved to left by about a half of the resolution width
osiris_: simplexe: you need newer libdrm
suokko: simplexe: You need newer libdrm_radeon or disable it
simplexe: hmm... libdrm from git
osiris_: did you run libdrm configure with --enable-radeon-experimental-api?
simplexe: ok... i reinstall - libdrm, drm from agd5f tree, mesa, xf86-video-ati and it's works
simplexe: Railroad Tycoon 3 after latest update not work
suokko: wine?
simplexe: suokko: yeah
suokko: I think you should forget wine for sometime
simplexe: earlier it's work with windowed mode )
simplexe: suokko: i know
simplexe: this is simple test
osiris_: simplexe: what gpu?
simplexe: osiris_: rv770
agd5f: osiris_: maybe DGA related?
osiris_: agd5f: it all works on non kms
agd5f: we don't init dga on non-kms. although I thought the dga cursor stuff was handled separately
MrCooper: we certainly do, did you mean we don't on KMS?
agd5f: MrCooper: yeah on kms
agd5f: we don't init dga on kms
MrCooper: xdpyinfo shows it here though, and I haven't noticed any cursor problems, but I don't have ut2k4 or penumbra
osiris_: MrCooper: demos of both of the games are available
MrCooper: for powerpc? ;)
agd5f: osiris_: what chip and how much vram?
osiris_: MrCooper: probably not :(
osiris_: agd5f: RV535, 256MB
MrCooper: icculus was actually talking about a powerpc build of ut2k4 a couple of years ago, but I've never seen it
agd5f: osiris_: that should be fine
MrCooper: maybe AVIVO specific issues then
Luzipher: hm, ok, probably I posted the wrong error above ... does anybody have a hint on "drmRadeonCmdBuffer: -22" in glxgears ? (r770, kernel 2.6.31-rc7)
agd5f: Luzipher: you aren't suing the right drm kernel modules
agd5f: *using
Luzipher: hmhm, i patched the kernel with the patch you posted here yesterday ... does it also depend on staging, like kms ?
agd5f: Luzipher: no
agd5f: Luzipher: but it appears to not be using the new modules
Luzipher: ok, strange ... thanks for the hint, I'll investigate what's the problem
loki_666: will 2.6.31 include drm to play with mesa on r600?
Zajec2: loki_666: no
Zajec2: loki_666: it's much too late for such experimental, potentialy not-yet-stable code
Zajec2: maybe 2.6.32, it developers will belive drm api is already stable
loki_666: so what's currently included in 2.6.31? kms for r500?
Zajec2: 2.6.30 is drm for 2d on r67xx
Zajec2: 2.6.31 is kms r1xx-r5xx
Zajec2: maybe glisse will finish r67xx KMS before .32 merge window and then it will hit .32 (as staging probably)
Zajec2: i asked him about this today, but he didn't response
Luzipher: arrgh, complete stupidness ... failed to edit grub.conf correctly and was on an old kernel. Works now, thanks agd5f
agd5f: Luzipher: np
osiris_: MrCooper: what would be proper implementation of glCopyTex(Sub)Image? packet3 BLITBLT?
osiris_: that seems to be major bottleneck for most of the games run under wine
Terman: yangman: you are right - this is a duplicate, although for me (with suspend to ram) the screen is not garbled on suspend, only on resume
yangman: Terman: have you tried suspend-to-disk?
Zajec2: agd5f: could you say something about LIBGL_ALWAYS_INDIRECT?
Terman: yangman: no, because I have an encrypted swapspace and in that case opensuse doesn't seem to support suspend-to-disk
Zajec2: agd5f: when value of LIBGL_ALWAYS_INDIRECT is 0, openarena has corruptions
Zajec2: is this somethign hard to fix?
Terman: yangman: at least not out of the box
Zajec2: (openarena is just my case... other ppl reported that on other apps)
yangman: Terman: try suspend to disk. you can't see it corrupting at suspend time on suspend-to-ram even if it is
loki_666: does radeond driver support audio over hdmi?
Luzipher: hm, quake live looks really interesting, but seems to run quite smooth :)
agd5f: Zajec2: see my comment on this bug: http://bugs.freedesktop.org/show_bug.cgi?id=23469
Zajec2: loki_666: yeah, on most chipsets... but some are still not supported
MrCooper: osiris_: something like that I guess
Zajec2: loki_666: someone tried to port that... but i belive it'll be better to wait for kms
Zajec2: now porting to radeon, next porting to kms... huh
loki_666: Zajec2, i'm on rs780
Zajec2: loki_666: really, don't know, just try
loki_666: k
MrCooper: osiris_: I agree it looks like that would enable lots of things, too bad we can't just use r300g yet :}
osiris_: MrCooper: yeah, with newest changes games like Tomb Raider Legend, Assassins Creed, Prince of Persia are starting to work (although they are painfully slow because of the software implementation of glCopyTexImage)
MrCooper: it might also make the compiz blur plugin usable :)
Zajec2: agd5f: hm, ok... however hard for me to estimate how hard is that to implement :)
Zajec2: agd5f: does it sound like one-day-job for you?
agd5f: Zajec2: probably several days
Zajec2: ops, uh, too bad
Zajec2: agd5f: did you consider "recompile a new vertex shader every time the vertex format changes" as quick workaround? is that one-line-change?
Zajec2: agd5f: or that work around needs to much work to play with that? considering we will second (preferable) solution anyway later
agd5f: Zajec2: I think cooper has a patch to that effect
Zajec2: ah, so it's several-days-job already mostly done? :)
Zajec2: (or completly, just guessing that "mostly")
agd5f: Zajec2: no. the quirk workaround is
Zajec2: ah, ok
agd5f: not sure it works yet anyway
Zajec2: Cooper isn't here, is he?
agd5f: not at the moment
Zajec2: ok, that's for claryfing all that
suokko: agd5f: Do you thing you could test state emit prediction with at r600 http://cgit.freedesktop.org/~suokko/mesa/log/?h=r600_state_predict ?
agd5f: suokko: sure
suokko: It will assert if prediction was too small in end of rendering
agd5f: ok
suokko: That is just for testing so it is easier to find what was not predicted correctly
agd5f: suokko: I hit the assertion
spstarr: agd5f: had to turn off composite, cause sometimes it would start to eat 100% cpu and force me to reboot
suokko: agd5f: Now there is need for debug output to show what was emited more than predicted. Or you might know if you look at predict code
agd5f: suokko: looks like it should be right
suokko: agd5f: http://nopaste.com/p/aUEyFxaGrb If you enable all debug that should help locating where is that extra emit coming from
suokko: I should commit that to my branch too :)
agd5f: suokko: I see the problem. you call r700PredictRenderSize before r700SetupStreams
agd5f: so the don't have the vtx resource count stuff yet
suokko: agd5f: But it has to be called before you emit aos
suokko: And I do count the aos number in begin of predict function
agd5f: ah, ok
suokko: I pushed extra debug output for state prediction
agd5f: I see the problem
suokko: wishes for r100 and r600 cards for testing
DanaG: assumes those must both be AGP.
nanonyme: Egh, they actually make r600 AGP cards? :/
suokko: yes. There is a few
nanonyme: Is it dead with r700 though?
spstarr: those are evil suokko :)
agd5f: nanonyme: sadly they make r7xx agp cards too
nanonyme: Argh.
nanonyme: agd5f: I fail to see much point there anymore, I'd think all motherboards that support AGP only support legacy CPU's anyway.
MrCooper: it won't die as long as there are people crazy enough to buy current cards for their AGP mobos :(
agd5f: suokko: fixed one state size, bug, but it appears more lurk
nanonyme: As in, those people start getting less and less benefit of buying a new card...
DanaG: hmm, and I wonder how the HDMI audio stuff works on AGP.
nanonyme: agd5f: Btw, is it expected that tests/arbvptorus hangs with r600 direct rendering?
nanonyme: Dunno which tests you people have been going over.
agd5f: nanonyme: could be, I haven't tried it in a while
agd5f: DanaG: same as pci or pcie. the sound block is on the gpu
nanonyme: agd5f: As in, mouse moves, nothing else works.
DanaG: Ah, so it's not like the old AIW8500DV with the firewire?
DanaG: That one had a bridge, I believe.
agd5f: DanaG: it shows up as a separate device, but yes, it's on chip unlike the 8500dv
masa-: hm, i have a "Radeon 32MB SDR" on my family PC :p
masa-: i think its some r1xx?
agd5f: masa-: yes. r100
masa-: does some of you have r100 cards for testing or should i steal that one, or is there much point anyway to test r100 cards anymore?
masa-: i also have 9000 pro somewhere, and 9600 non-pro and 9600 pro
spstarr: has an r1xx
suokko: masa-: r100 testing is jsut to make sure we won't break support in changes
agd5f: masa-: I have r1xx cards
masa-: and X600 and HD 4350 and HD 4550 and HD3100 and HD 3200 ;)
spstarr: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500]
suokko: rv200 and 7500?
spstarr: I have Radeon 9700 Pro AGP too but the fan is noisy on it
suokko: I tough r200 started from 8500
agd5f: suokko: rv200 is r1xx based
suokko: ok :)
agd5f: just the name is weird
masa-: all of my radeons are passive except that r100, but i took the stock fan out and taped a 80x80 fan on PCI slots below it :p
spstarr: thats my TV tuner card
suokko: Can someone go to progs/tests/ and run make fog; LIBGL_ALWAYS_SOFTWARE=1 ./fog ?
spstarr: agd5f: is it normal for the GPU to make high pitched 'squeeky' sounds?
agd5f: spstarr: bad bearing in the fan?
spstarr: agd5f: its brand new laptop :)
spstarr: agd5f: but i've noticed this on all of AMD gpus doing this
agd5f: spstarr: fan can still get dusty
spstarr: yes it can
spstarr: easier to clean on this model if i need to
yokto: when i resume from suspend to ram with kms I get all black and white lines and dmesg says ([drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(10).)
MrCooper: it can also be something not related to the fan at all, from some kind of circuitry
nanonyme: suokko: I just did.
nanonyme: What's up?
spstarr: it just 'stopped'
spstarr: weird
simplexe: suokko: where is it?
spstarr: and started
agd5f: suokko: what about it?
spstarr: agd5f: the r6xx has no PM support yet?
agd5f: spstarr: there are some ddx options
spstarr: i guess you want to hook that up later on to sysfs for control?
agd5f: "ForceLowPowerMode" and "DynamicPM"
yangman: yokto: http://bugs.freedesktop.org/show_bug.cgi?id=23290
agd5f: but more dynamic power management will be done in kms
spstarr: makes sense
simplexe: agd5f: kms based on 31 kernel?
agd5f: simplexe: for power management?
yokto: well it seems dublicate of my bug of which no one seems to have taken notice :D #23273
simplexe: agd5f: no, for r600
agd5f: simplexe: kms for r6xx/r7xx will probably be .32
nanonyme: agd5f: Btw, any idea how chip-dependent PM will have to end up being in KMS? Will there be code-share between PM for older cards and r600/r700?
simplexe: agd5f: ok
nanonyme: Just wondering since it seems to me like an important factor in how fast r600/r700 will get PM on KMS.
simplexe: agd5f: current r600_dri support only opengl 1.4?
stikonas: nanonyme: just a guess, maybe 2.6.33
agd5f: nanonyme: common infrasturcure with chip specific hooks
agd5f: simplexe: currently. the hw supports gl 3 however
nanonyme: stikonas: I'm not interested in dates as such. :)
nanonyme: agd5f: Sounds good.
simplexe: agd5f: ok
spstarr: agd5f: heh dont mix DynamicPM with ForceLowPowerMode
spstarr: it doesnt like im using DynamicPM now i think
agd5f: spstarr: should work, but there are likely issues. that's the problem with PM it's really hard to get right for every oem system
nanonyme: stikonas: More like as to whether development in r100-r500 KMS PM will help r600-r700 KMS PM. :)
spstarr: ah
spstarr: (II) RADEON(0): Dynamic Power Management Enabled
nanonyme: Given there's common infrastucture, I deduced the answer to be "to some degree yes".
marvin24: seems that 32bit and KMS does not compute: http://bugs.freedesktop.org/show_bug.cgi?id=22271
MrCooper: s/32bit/32 on 64/
marvin24: all the troubles getting 32bit libs compiled on amd64 where for nothing :-(
marvin24: MrCooper: yep
legume: DanaG: Sapphire don't have Audio on there AGP cards, don't know about others.
marvin24: MrCooper: is there any solution on the horizont?
marvin24: s/horizont/horizon/ :)
MrCooper: marvin24: dunno
marvin24: MrCooper: ok - thanks
nanonyme: notes yet again that he was under the impression /dev/dri/cardX was a legacy node in KMS, not the one that should be normally used
suokko: osiris_: What if we had 2 bos for one vbo if we have to convert data for GPU? Then we would only have to do conversion when data changes.
suokko: hmm. For me swrast of fog test is broken
osiris_: suokko: yeah, that was my first version of vbo implementation.
osiris_: but I've decided not to go that way
MrCooper: osiris_, suokko: I've found that not specifying an initial domain for VBOs helps cut down the conversion overhead
osiris_: the conversion doesn't happen that often to justify increased memory usage
Terman: I have a question/feature request regarding the radeon module (maybe it could even be called a bug report):
MrCooper: osiris_: actually it happens all the time here e.g. with sauerbraten because it uses short and byte indices
suokko: good. Then it should enough to jsut have fall back debug info there in case someone hits it badly
osiris_: MrCooper: byte indices? are you sure?
MrCooper: yes
MrCooper: note that sauerbraten in Debian was a snapshot from about two years ago
osiris_: someone has to tell them it's not a good thing
MrCooper: osiris_: FWIW I think such a scheme could help a lot on big endian machines
legume: suokko: fog sw broken for me also, redbook/plane is also borked.
Terman: - *with* kms, there is a new option called modeset. So if I append a to the kernel boot options something like "radeon.modeset=0", this will disable kms. Unfortunately, if I recompile the kernel or module to no longer support KMS, then this option will *prevent* the radeon module to ever even load
suokko: What if it would be dones so that 2nd bo is allocated only if there is conversion?
suokko: legume: thanks
suokko: So something has broken swrast. maybe time to do bisect
osiris_: MrCooper: for big endian machines we just should use proper BE/LE conversion mechanisms in DMA engine
Terman: I think that the modeset option needs to be accepted even with config-kms disabled.
MrCooper: osiris_: what mechanisms? I'm only aware of the VC swap bits, and those aren't even effective for VRAM and won't help if different BOs have different element sizes
osiris_: darn, forgot about the different size elements in one BO
suokko: So my idea would be have bo with wields radeon_bo *bo; radeon_bo *conveted_bo; boolean dirty; If we hit a vbo thatneeds conversion then we check if it is all ready converted and not dirty
MrCooper: even without that, there could be e.g. a vertex buffer with float elements and an index buffer with shorts?
W0rmDr1nk: hi
suokko: And in conversion code only allocates that 2nd bo
suokko: i mean that only conversion code allocates 2nd bo and if none is required then we just use the original bo
suokko: hmm. But we might need multiple conversions for single vbo?
W0rmDr1nk: I have a few questions
suokko: If there is multiple different data
W0rmDr1nk: I have '01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics] [1002:9612]'
W0rmDr1nk: but when I do lspci -knn it doesnt show any Kernel driver in use: or Kernel modules:
W0rmDr1nk: is this right ?
W0rmDr1nk: also when I do lshw i get: *-display UNCLAIMED
W0rmDr1nk: anybody ?
suokko: W0rmDr1nk: paste your xorg.log, please
W0rmDr1nk: ok
W0rmDr1nk: what pastebin is good
W0rmDr1nk: cos dpaste says too long
suokko: http://nopaste.org
MostAwesomeDude: MrCooper: Agreed.
W0rmDr1nk: http://nopaste.com/p/a45sXroA3
osiris_: suokko: yeah, that's what I've done first time. if you really want it, go ahead and implement it
MrCooper: MostAwesomeDude: btw, your DONTBLOCK changes broke things here, looks like something relies on the constant flushes or so
suokko: And for conversion speed GTT is bad because of caching in agp system
suokko: osiris_: I was just wondering what problems it has :)
W0rmDr1nk: Also, I added radeon manually to /etc/modules.autoload.d/kernel-2.6
osiris_: MrCooper: the initial domain is set during radeon_bo_open, right?
MrCooper: suokko: right, so we probably shouldn't specify GTT already when creating the VBOs
MrCooper: right
osiris_: suokko: IIRC increased memory usage only
suokko: osiris_: But dma regions will increase it too
MostAwesomeDude: MrCooper: I noticed when doing OQ testing that DONTBLOCK did not work right; I think the kernel internally is doing bo_wait regardless of whether I call radeon_bo_wait.
suokko: MostAwesomeDude: I think yo uhave to cann radeon_bo_is_busy
osiris_: suokko: how?
suokko: and if not busy then only ask for value
MrCooper: MostAwesomeDude: that's another issue, I can take care of that :)
suokko: osiris_: dma regions are also allocated and kept until rendering is over
suokko: so we jsutend up allocating space from dma instead of special bo for vbo
W0rmDr1nk: so about lshw and lspci -knn ...
suokko: And I think that dma can even be worse in simple application like gears because we allocate twice the space for conversion
W0rmDr1nk: is it fine if it shows now driver/module loaded ?
suokko: Because previous conversion is still not rendered when we startrendering next
MostAwesomeDude: MrCooper: The bigger issue is that the kernel doesn't appear to correctly understand whether OQ BOs are busy; when testing arbocclude, it just kind of sat there and never returned from bo_wait. Didn't hang, though.
osiris_: MostAwesomeDude: maybe you haven't flushed the CS?
MostAwesomeDude: osiris_: Doesn't it call glFlush() when it's finished? Hm.
W0rmDr1nk: can anybody with a fairly recent ATI using open source radeon (not radeonhd) driver show me their lspci -knn and lshw ?
W0rmDr1nk: if you can do only one then thats fine also
suokko: W0rmDr1nk: I think your xorg.log shows that everything is fine and your kernel module information is just outdated
osiris_: MostAwesomeDude: no, but the first time the app checks if query result is available, driver should flush the CS
W0rmDr1nk: Linux hansolo 2.6.30-gentoo-r4 #1 SMP Wed Aug 19 00:37:04 Local time zone must be set--see zic i686 AMD Turion(tm)X2 Dual Core Mobile RM-70 AuthenticAMD GNU/Linux
W0rmDr1nk: fairly recent kernel
W0rmDr1nk: suokko, so it should show as module/driver in lspci -knn ?
suokko: W0rmDr1nk: I don't know where lspci is looking for module info but that source is outdates
W0rmDr1nk: suokko, does your lspci -knn show module/driver ?
suokko: of course
W0rmDr1nk: can I see ?
suokko: Kernel modules: radeon, radeonf
suokko: b
W0rmDr1nk: radeonfb ?
suokko: Deprecated frame buffer device
W0rmDr1nk: I see
W0rmDr1nk: what kernel version you using ?
suokko: There should be radeomdrmfb
osiris_: darn, BITBLT packet3 requires offsets to be 1K aligned
W0rmDr1nk: and what is your card ?
suokko: 2.6.31-rc6
nanonyme: And there should *not* be radeonfb. :3
suokko: So my database for kernel modules is outdated too
suokko: Evil lspci is not to check module data from modinfo that has pci ids in my kernel :P
W0rmDr1nk: hmm
W0rmDr1nk: can i somehow add alias so that the module is loaded for my card /
W0rmDr1nk: ?
nanonyme: W0rmDr1nk: What's your bootloader kernel line?
W0rmDr1nk: ehrm - dunno - where do i check ?
W0rmDr1nk: oh wait
suokko: W0rmDr1nk: /etc/modules is good place to add modules that has to be loaded in boot
W0rmDr1nk: ill shwo yo
W0rmDr1nk: using genkernel though
nanonyme: Doesn't matter, I'm interested in the parameters.
W0rmDr1nk: nanonyme, you mean: kernel /boot/kernel-genkernel-x86-2.6.30-gentoo-r4 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda7
W0rmDr1nk: initrd /boot/initramfs-genkernel-x86-2.6.30-gentoo-r4
W0rmDr1nk: from grub.conf ?
W0rmDr1nk: suokko, i have it in /etc/modules.autoload.d/kernel-2.6
suokko: and it doesn't load radeon?
osiris_: double darn, we can't emit relocations for only certain bits of dword
W0rmDr1nk: radeon - and lsmod show its loaded - but from what i gather it has to be configured to load radeon for specific device using modprobe alias
suokko: It looks like it is loaded correctly from xorg.log
W0rmDr1nk: ok
nanonyme: Never mind, it's not 2.6.31 so it doesn't have KMS anyway.
W0rmDr1nk: ok well anyway - thats fine then - next question though - I am having problems with dual head
W0rmDr1nk: dual head works nice - except my mouse gets corrupted when i move between screens
suokko: W0rmDr1nk: http://wiki.debian.org/XStrikeForce/HowToRandR12
suokko: oho :)
W0rmDr1nk: no see I have it set up
osiris_: glisse: are there any plans to support relocation for specified bits of dword?
W0rmDr1nk: using xrandr
W0rmDr1nk: set virtual big enough to contain both screens
osiris_: glisse: it's required for hw accelerated glCopyTex(Sub)Image and tiled textures
W0rmDr1nk: but now - my mouse pointer gets coruppted when i move between screens - and after a while (or maybe when i do something funny) my system hangs - cant even get out with ctrl + alt + backspace
suokko: Can you give details for corruption? When it starts when it ends (if at all)? what it looks lie?
W0rmDr1nk: could it be due to evdev ?
suokko: W0rmDr1nk: Is your card using agp?
W0rmDr1nk: suokko, currently it looks like mouse pointer but just cut in two - and pasted wrong way round
W0rmDr1nk: no - its pci express card
nanonyme: suokko: And no, radeonfb isn't technically deprecated in 2.6.30. ;)
suokko: nanonyme: And not even in 2.6.31 :P
nanonyme: Myeah.
W0rmDr1nk: so basicaly - the pointer looks as if it is just like misaligned
suokko: W0rmDr1nk: Can you get a screen capture showing it?
W0rmDr1nk: ok
W0rmDr1nk: i will try
W0rmDr1nk: where do i pastebin images ?
suokko: agd5f: Do you know about r600 corrupting cursor when moving to 2nd screen in dual head?
suokko: W0rmDr1nk:
suokko: http://imageshack.us/
agd5f: suokko: might be dfs related
suokko: W0rmDr1nk: You could try Option "AccelDFS" "no" to device section
agd5f: also, if you are using an old version of the driver there were cursor issues
agd5f: with certain locations on the screen
suokko: 6.12.1
agd5f: probably want 6.12.2, I don't recall when I fixed it exactly
MostAwesomeDude: osiris_: Yeah, probably.
MostAwesomeDude: I haven't finished all the logic.
agd5f: suokko: yeah 6.12.1 is too old
agd5f: need 6.12.2
agd5f: actually so is 6.12.2
agd5f: need 6.12-branch
suokko: hmm. Does that mean gentoo doesn't have updates for it
agd5f: suokko: distros should be tracking the stable branch
W0rmDr1nk: suokko, I cant seem to grab mouse pointer in screenshot
W0rmDr1nk: I select grab mouse pointer but then just nothing shows up
agd5f: W0rmDr1nk: you need to update your ddx
suokko: W0rmDr1nk: It's ok. You need to upgrade your driver
W0rmDr1nk: my what ?
W0rmDr1nk: ddx ?
agd5f: W0rmDr1nk: radeon driver
suokko: xserver-xorg-video-radeon package
osiris_: glisse: actually I think it would be better to create seperate ioctl for the BITBLT packet3
suokko: or xf86-video-radeon
W0rmDr1nk: x11-drivers/xf86-video-ati
W0rmDr1nk: ok
suokko: that one :)
W0rmDr1nk: to which version ?
W0rmDr1nk: cos latest i see is 6.12.2-r1
W0rmDr1nk: is that fine ?
suokko: W0rmDr1nk: I guess it is
W0rmDr1nk: k
W0rmDr1nk: thanks :)
W0rmDr1nk: will try that
osiris_: glisse: the relocation for BITBLT is divided by 1024. creating unified interface for all cases will not be worth it, probably.
W0rmDr1nk: could cursor issues casue the crash though ?
suokko: agd5f: Maybe it would be good idea to tag all then and now new tag in stable branch just to make it easier to know if distro packages are new enough for bug fixes
osiris_: (all cases meaning: standard relocation, relocation for BITBLT and texoffsets with micro/macro tiling)
suokko: W0rmDr1nk: Your driver is quite old so there is a lot fixes in the latest version
W0rmDr1nk: ok - will update
suokko: So it might be already fixed even if notrelated to corruption
W0rmDr1nk: thanks again - nice channel you have here btw
suokko: But if update doesn't help then we would like to get some more info :)
W0rmDr1nk: yeah - will run with new drivers tomorrow and tell you if it helped
Rabenklaue: hi, could someone with radeon drivers from git and installed clutter toolkit please verify this issue? https://bugs.freedesktop.org/show_bug.cgi?id=23487
suokko: Rabenklaue: you card is problematic so might be hw specific
suokko: agd5f: Did you got the prediction to work with r600?
agd5f: suokko: yes. just about to commit the fixes
suokko: ok. I will change it not to assert but warn forall drivers if there is too large emit then
luc__: hy
nanonyme: Hmm, neat.
luc__: any fixex for screen corution when is kwinn enable?
nanonyme: Compiz-gtk seems to be nicer with Xv than Metacity.
nanonyme: (and does a bit different assumptions on window placement; playing with r600 OpenGL)
nanonyme: thinks he'll start using compositing always as soon as we get r600 DRI2 :3
spstarr: me too
luc__: i'am using it now
luc__: :)
spstarr: uhm
luc__: even with screen coruption
spstarr: there is no DRI2 support for r6xx yet?
luc__: with opengl
agd5f: spstarr: not working yet
suokko: yes. Composite is good if just there is no performance hit from it
spstarr: agd5f: ah
agd5f: spstarr: requries kms and probably some mesa fixes
spstarr: well, i saw KMS working on r6xx with Fedora's drm driver
nanonyme: spstarr: With no acceleration? :P
stikonas: spstarr: maybe only radeondrmfb
nanonyme: Sure, KMS itself works. It's the memory manager that's WIP.
kdekorte: Rabenklaue, That is a know issue with the r6xx mesa drivers
masa-: so is r7xx ~the same as r6xx in terms of support?
nanonyme: Roughly.
masa-: i mean if r6xx works does r7xx also?
masa-: ok
nanonyme: It was a bit better earlier but atm probably very close the same.
masa-: what was better?
nanonyme: Well, devs started with r7xx support and went then to r6xx support so r7xx support was better for a time.
nanonyme: They're probably roughly equal nowdays.
nanonyme: (better than r6xx, that is)
masa-: ok
nanonyme: Hmm, something's broken r600 again, seems.
nanonyme: undefined symbol _glapi_SingleThreaded
suokko: sounds like core mesa
nanonyme: It is.
nanonyme: Affected swrast as well.
nanonyme: I'll try cleaning and recompiling.
nanonyme: Apparently the variable is in src/mesa/glapi/glapi.h
agd5f: nanonyme: you have to rebuild the whole mesa tree
nanonyme: agd5f: I did.
nanonyme: Twice.
nanonyme: Oh, there's more commits.
nanonyme: Will try again with those.
agd5f: nanonyme: rebuild and install
nanonyme: I will... Probably was just missing a fix commit.
nanonyme: Assumably it should work now.
nanonyme: Hrm.
nanonyme: Still doesn't work with latest git after make clean, make, make install.
nanonyme: Same error.
nanonyme: Hmm.
nanonyme: Yeah, no go.
suokko: agd5f: I think you want to combine BEGIN_BATCH as much as you can. rcommonBeginBatch is quite expensive and often call function in r300 profile.
agd5f: yeah, I've tried to
suokko: It might even give some performance gains to have it inlined
suokko: just looked at r700Start3d :)
suokko: I was jsut also wondering if that is realy required in begin of each state emit
nanonyme: Trying yet again...
nanonyme: This time with make distclean, maybe make clean isn't clean enough.
nanonyme: Nope.
nanonyme: Still botched.
suokko: nanonyme: Can you bisect the commit that broke it for you?
nanonyme: suokko: I'd be astonished if it wasn't 17090cf3efb0db8fa01b502a9c0df27cbd1a67da
nanonyme: "DRI drivers compiled with this patch applied will not work with existing libGL.so because of the missing new symbol. If this turns out to be a real problem, this patch should be reverted."
nanonyme: Somehow recompiling libGL.so doesn't help though...
suokko: nanonyme: Are you sure that application is loading your compile lbgl?
suokko: and not system one
EruditeHermit: MostAwesomeDude: thanks for helping me earlier
MostAwesomeDude: EruditeHermit: Sure.
nanonyme: suokko: Yes.
nanonyme: suokko: Because they are one and the same.
nanonyme: I install Mesa over system libraries.
nanonyme: suokko: Does it work for you then?
suokko: I can't test. I'm bisecting the swrast bug
nanonyme: Bwah, right.
suokko: nanonyme: Maybe you want to talk in #dri-devel about that problem
nanonyme: If my headache gives up a bit, I just might.
Esmil: Ohh: "Your libdrm or kernel doesn't have support for busy query." Is this some feature of kernels newer than 2.6.31-rc6?
mattst88: Esmil, yes, I think so
mattst88: last few days, it was added
Esmil: Cool. I'll update right away. Thanks
mattst88: it might be in one of airlied's trees, not sure
mattst88: suokko probably knows
suokko: It is in kernel and there iseven pull request to fix a bug in it :)
Esmil: suokko: Ohh, do you have a link to this fix?
Esmil: or git repo
osiris_: airlied: ping
thalunil: anybody is using DynamicClocks with any effect? i am still running around 70°
spstarr: how do you measure temp from FLOSS drivers?
thalunil: spstarr: with ibm-acpi and lmsensors
spstarr: thats for CPU i thought only
thalunil: spstarr: and with my hand which gets pretty hot
spstarr: *dont use lmsensors on thinkpads*
thalunil: spstarr: thinkpads have 10sensors
spstarr: agd5f: it would be nice to expose the GPU temperature in sysfs
spstarr: thalunil: yeah but i thought lm_sensors is dangerous on thinkpads still
thalunil: spstarr: even the battery has 3
thalunil: spstarr, works great
spstarr: its safe? it wont fsck up EEPROM ?
thalunil: spstarr, nope
spstarr: hmm
thalunil: spstarr: /sys/devices/platform/thinkpad_hwmon/temp4_input is GPG
spstarr: oh??
spstarr: looks
thalunil: GPU temp i mean (havent figured out what GPG is
spstarr: mine is 59000 or 59C i guess?
thalunil: is it?
thalunil: 10° colder
thalunil: too bad. with radeonhd its even hoter (but thats what documentation tells me, too)
spstarr: I am using DynamicPM
agd5f: thalunil: DynamicClocks (renamed to ClockGating) doesn't do anything on r6xx
agd5f: thalunil: also you need git master to use any of the pm stuff
thalunil: agd5f, no problem, i can do that
spstarr: agd5f: i note with DynamicPM im hearing a lot less high pitch buzzing
thalunil: spstarr, temp1 is mobo, temp2/3 are the cpu cores, and temp4 is GPU temp
agd5f: spstarr: dynamicPM only lowers the clocks when the displays go to sleep
spstarr: hmm ok
thalunil: agd5f, so, which git repo should i use? radeon or radeonhd?
agd5f: thalunil: radeon
agd5f: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
thalunil: clones
thalunil: error: Unable to find 000000000000000...under $git-repo - bad start :)
thalunil: spstarr: high-pitch noises tend to come from the cpufreq-stuff, too. pretty anoying with these thinkpads, is it?
thalunil: spstarr, had it on several models, too.
mattst88: osiris_, "#define RADEON_QUERY_PAGE_SIZE 4096", what about architectures with page sizes != 4096
osiris_: mattst88: it's the size of ATI gart table page (which always is 4k IIRC)
mattst88: so it shouldn't be a problem for architectures with page size of 8k?
osiris_: nope
airlied: osiris_: bitblt can't do tiled srcs so isn't totally useful
osiris_: airlied: hmm, docs seems to disagree
airlied: osiris_: they lie
airlied: osiris_: at least microtiled
airlied: 2D engine doesn't do microtiled srcs
osiris_: airlied: so how do you suggest implementing glCopyTex(Sub)Image?
airlied: osiris_: using metaops
airlied: wonders if brianp did those
airlied: osiris_: we could ujse the blitter I suppose
airlied: and fallback to 3D engine
osiris_: airlied: anyway, I've got two remarks regarding FBOs
osiris_: airlied: when allocating an BO for FBO, alignment is set to 0, while for color/depth buffer it should be 32 bytes
osiris_: airlied: according to docs the rrb pitch for color buffer should be multiple of 2, and for depth buffer multiple of 4
airlied: osiris_: all buffes align to 4k
airlied: osiris_: we also align the pitch
airlied: in radeon_alloc_renderbuffer_storage
osiris_: airlied: when allocating this bo you align the pitch but size is calculated from unaligned pitch which sometimes result in drm errors like "Buffer too small for z buffer (need 93184 have 90112) "
airlied: ah cool
osiris_: airlied: also the pitch should probably realigned in radeon_update_wrapper
airlied: I'll push the size fix
airlied: osiris_: not sure if the tex image width is aligned already
airlied: if not then we should probably do something like that
osiris_: airlied: currently the pitch is aligned to 64 bytes. won't it result in rendering errors? (docs suggest 2 or 4 bytes align)
airlied: 64 is > 2 or 4
osiris_: I know, but you sure it will work with higher then required value?
suokko: osiris_: if oyu align something to 64 it is also aligned to 4 because 64 is multiple of 4
spstarr_: agd5f: DynamicPM fails to resume when display is shut off
spstarr_: had to reboot
spstarr_: hard reboot
agd5f: spstarr_: try removing the PCIE lane stuff
osiris_: suokko: yeah, but aligning to bigger value may result in rendering errors (try setting texture row align to 64 bytes on r500 and you will get rendering errors - required align is 32 bytes there). not sure if that's the case for color/depth buffer too
suokko: align of begin of data is different to row align. In a row align you have to have exact value unless align can be emitted to GPU.
osiris_: I'm not talking about begin of data alignment
suokko: so it depends on can you tell hw about data alignment. If not it might be hard coded
osiris_: suokko: there are RB3D_COLORPITCH[0-3] regs
osiris_: and one for depth buffer
suokko: bitch can be anything from 2 to 4096. So we could have any multiple of two as pitch for color buffer if I understand it correctly (pitch=2n+0) if I understand correctly
nanonyme: suokko: s/bitch/pitch/ ? :)
suokko: I might mean that ;)
nanonyme: suokko: Hmm, I wonder if I should attempt to fix the problem or wait until people go to shut down computers, go to sleep, wake up, boot up X and curse when OpenGL doesn't work... ^^
suokko: nanonyme: I guess you need to change aiglx to match libGL.so
agd5f: nanonyme: reply to the email on dri-devel
suokko: agd5f: 2x r700_assembler.c:2135: warning: large integer implicitly truncated to unsigned type. You are assigning to one sized bit fiel SQ_SEL_MASK that is 0x07
suokko: Is that correct?
nanonyme: agd5f: I'm not very fluent with mailing lists, I mostly use IRC.
suokko: /fiel/field/
suokko: nanonyme: It is not much different to irc :) good part is that you don't have to search important stuff from idle chat ;)
nanonyme: suokko: /last?
suokko: mailing list to irc :)
frojnd: HEllo there.
nanonyme: Hi.
nanonyme: suokko: Plus I easily read through 8 hours of this channel in 30 mins during peak time if I get access to a computer. An hour if I have to do it with a cell phone. :(
agd5f: suokko: yeah, that should probably be removed, although I don't think you'll ever hit the default case
nanonyme: But yeah, mailing lists: are there some pages for them that I can find where to subscribe and where to send messages?
frojnd: I havea question regarding to xrandr. I have to execute 3 commands to get what I wannt': 1) First Ihave to configure my primary notebooks resolution: xrandr --output LVDS --mode 1440x900 2) than Ihave to rotate my extended one: xrandr --output VGA-0 --rotate left 3) and for the lsast command I have to configure my extended monitor's resoltuion: xrandr --output VGA-0 --right-of LVDS --mode 1280x1024 Is there a way to do this
nanonyme: Silly me, Google said http://dri.freedesktop.org/wiki/MailingLists
suokko: :)
agd5f: frojnd: http://wiki.debian.org/XStrikeForce/HowToRandR12
osiris_: how would like to implement accelerated glCopyTex(Sub)Image?
suokko: osiris_: render quad with texture read from src to dst
suokko: That is what I would think as a solution
osiris_: ... and we have a volunteer :)
suokko: But isn't there meta code for that yet?
suokko: If not maybe it should implemented to common code in driver independent way
osiris_: nope, only framebuffer blit,glBitmap and glCopyPixels
agd5f: seems any of those could be adapted
osiris_: suokko: I don't think it's doable with quad renderings
osiris_: suokko: it copies data from framebuffer to texture object
nanonyme: Hmm. Subscribed. Rest will have to wait, I still have headache and heading to bed.
nanonyme: Hmm, actually I'll try one thing still.
nanonyme: That is, whether explicitly disabling AIGLX is a workaround.
nanonyme: Since direct rendering shouldn't need it anyway.
osiris_: anyway, to enable modern games run at playable speed we need these at least hardware accelerated glCopyPixels
jcristau: even without aiglx you need a working swrast_dri.so
jcristau: by working, i mean one X can load.
osiris_: next speed improvements could come from hyperz and texture tiling
nanonyme: Agh.
suokko: osiris_: And not emitting shaders for every primitive
nanonyme: jcristau: Thank you for preventing me from wasting my time.
nanonyme: Off to bed, night.
osiris_: suokko: proper glCopyTexImage can give over 50x speed improvement. not emitting shaders for every primitive is probably an order of few percents
osiris_: suokko: the games like Prince of Persia, Tomb Raider Legend and Assassins Creed are already working (with minor rendering errors)
suokko: good :)
osiris_: yeah, but the speed is like less then 0.5 FPS
suokko: But for xmoto I saw 20% CPU time going fo state emit so optimizing that should help
suokko: And another problem is that we emit flush and wait too often. Is there any need to emit them in any others palces than in begin of comman buffer?
osiris_: where else do we flush?
suokko: We emit cache flush in pre_emit_state
suokko: And there is also vap flush for every primitive
suokko: also there is wait for idle in pre_emit_state
agd5f: suokko: that's all handled on the GPU
suokko: agd5f: But that is expensive operation in gpu if I understood docs correctly
suokko: So if we flush everything for every primitive we lost a lot of GPU cycles.
agd5f: suokko: some you have to flush since they are input caches
agd5f: like vap and tex
agd5f: at leat if you are changing textures or verts
agd5f: *least
agd5f: and waiting for idle at the end also flushes the output caches
suokko: Why we have to flush every time data changes? Can't gpu jsut load new data to cache all the time while discarding the oldest?
MostAwesomeDude: suokko: That's just the way it goes.
agd5f: suokko: you could be more fine grained about it. you really only need to do it around CPU access to buffers
suokko: So we would need flush only in begin and end of command buffer
agd5f: so input caches need to be flushed before the GPU reads a buffer that was last accessed by the CPU and output caches need to be flushed before the CPU access a buffer last touched by the GPU
suokko: So only emitting flush in begin and end could save thousands GPU cycles per command buffer
agd5f: we could store a bo dirty flag and set it when the CPU maps a bo and if that bo is dirty, add the appropriate caches flushes or something like that
suokko: And we don't even need to do any dirty flags to bo ;)
agd5f: when validating buffers
airlied: does changing CB do an implicit flush?
agd5f: airlied: I don't think so, but it does stall the pipe
airlied: so we have to flush if we change CB
suokko: I think idle does automatic cache flush in r300 but that was removed for r600
airlied: which the DDX does a lot
airlied: suokko: except where it doesn't ;-)
airlied: I think we've hit issues on hw where idle flushing wan't always true
suokko: airlied: Is there always idle package in end of stream? I think that flush happens only after explicit idle command
agd5f: IDLE_CLEAN should flush on pre-r6xx, but probably won't hurt to make it explicit
suokko: So I bet that you get most frames more if you clean up excessive flushing and waiting for engine idle and reducing state emit.
suokko: That way we can get more rendering to single buffer which should speed up things a lot in cpu side
suokko: And we have to do GPU flush anyway in begin of command buffer as long as we use dma rendering. But with pure vbo rendering we could avoid flushing in begin of command buffer
agd5f: suokko: looks like you've got your work cut out for you :)
suokko: But that sounds like minor optimization for complexity that it incolves
agd5f: suokko: yeah, lower hanging fruit to get first
agd5f: like hi-z and tex tiling
suokko: What about openmp threading to parallel stuff? I think there is places where it could be done to improve performance in multi core cpus
MostAwesomeDude: suokko: ORLY?
suokko: ORLY?
osiris_: suokko: you really should listen to agd5f and get interested in hyperz or texture tiling (or glCopyTexSubImage) if you want to make the apps work fast
suokko: I guess you don't really believe that current state emit is wasting a lot of performance. I agree that accelerated copy would help a lot for applications that are using it. Also hyperz would help in gpu side but I think that they won't help much when basic sate emit is broken.
airlied: suokko: its relative
suokko: And my work has been to get r200 to work so far only :)
airlied: suokko: it wastes maybe 0.5 fps vs say 30 fps in certain apps
suokko: It has happened to involve shared code
airlied: there is bigger gains to be made for less effort ;-)
airlied: bringing back hyper-z and tiling on r200 would be good
airlied: osiris_: a blit to a temporary in GTT and a copy for that for CopyTexSubImage would work in theory
suokko: airlied: I wonder how dri1 has lost 15 fps in radeon-rewrite ;) I today benchmarked mesa 7.5 withxmoto and it had 75 fps when dri1 mesa 7.6 can do 63 fps
airlied: suokko: tiling + hyperz?
airlied: suokko: both of those were there.
airlied: granted hyperz might not have been switched no
suokko: and dri2 record is now 53 fps
suokko: So hyperz miht be missing in mesa 7.6 dri1 too
suokko: might*
airlied: radeon-rewrite doesn't support it
suokko: ok
airlied: though it might be tiling
suokko: So that nearly 15 fps would be coming from hiz and tiling
airlied: I suspect hyper-z might still be used in dri1 clear path
suokko: And dri2 should gain from asynchronous buffer swap.
osiris_: suokko: xmoto doesn't stress GPU that much, and use old opengl API IIRC (no VBOs or display lists). so your dma rewrite can make significant improvement there, but for real 3d apps the improvement won't be visible
suokko: So I guess after hiz+tiling+async buffer swap it would be easy to win that mesa 7.5 performance
MostAwesomeDude: suokko: Aim for big improvements, not small optimizations.
suokko: osiris_: I disagree. xmoto is very good benchmark for current radeon driver
suokko: MostAwesomeDude: What about nearly about 4x fps in about all applications?
suokko: for xmoto you just have to find a level that has a lot of geometry so you get stress for driver.
suokko: And if r500 cards can't run with same speed as r200 currently there is something wrong
osiris_: suokko: does it use shaders at all?
MostAwesomeDude: suokko: I'm just saying that HiZ and tiling are probably good targets.
suokko: MostAwesomeDude: I agree
suokko: osiris_: no shaders.
suokko: osiris_: Yo ucan test it for your self from http://people.freedesktop.org/~suokko/ . Yo uhave to first download all xmoto levels and then copy replay_648969.rpl to .xmoto/Replays
suokko: Downloading all levels in nessecery because I don't know how to install single level
suokko: and then i have uploaded script to run the benchmark which supports running it also in callgrind for profiling
osiris_: suokko: so what are the results?
suokko: osiris_: currently 53 fps with my r200 and hifi did get only 38 fps with r570
suokko: I have M9 (rv280)
suokko: and dri1 boosts fps with mesa 7.6 to 63 fps and old code can run at 75 fps
osiris_: and what are the results for unmodified mesa?
airlied: I suspect on r500 the emit size is just larger since shaders
suokko: With dma optimization I got 25 fps while optimizing dma handling I got it up to 53 %
suokko: airlied: yes. But there is a lot of emits that are all same
suokko: /53 %/53 fps/
suokko: That als oincludes soe fps from optimizations to state emit code but I have to have some basic changes to run xmoto at all
suokko: Only application that I have tested and haven't improved is torcs
suokko: Even warzone/nexuiz/sauerbaten got now playable frame rates when the starting situation was less than 10
suokko: btw, Does r300 driver emit shader again for every primitive if game is using shaders?
suokko: I haven't tried to run anything complex with debugging on because that is painfully slow.
airlied: suokko: not every primitive
airlied: ever cs
suokko: So if application uses shaders performance is better than without them
airlied: well generally shaders are used for effects not really performance
airlied: but on a gpu with a shader, converting fixed function to a shader does carry some overhead
suokko: I know that but I wouldn't think that it would take that much penalty
suokko: That you have to emit hundred+ dwords for each primitive to get shaders working
airlied: well just when the shader changes
airlied: the r600 case is just badly coded
suokko: airlied: so is r300
airlied: no its not
osiris_: airlied: yes, it is
airlied: where?
airlied: maybe for fixed function
airlied: no it shouldn't for that either
osiris_: airlied: in r300UpdateShaderState we call SetupPixelShader SetupRSUnit and SetupVertexProgram
suokko: airlied: State emit size per primitive with fixed function is at minimum 200 dwords!
airlied: wow I didn't think that sucked that much
MostAwesomeDude: What.
airlied: lets just move to gallium already ;-0
suokko: MostAwesomeDude: How much r300g does emit per primitive? :)
ernstp: agd5f, airlied: if you want something pretty broken but that doesn't crash to test the r600/r700 code with you can try the world of goo demo
MostAwesomeDude: suokko: State emission isn't per-primitive. :3
ernstp: :-)
MostAwesomeDude: State gets emitted whenever requested by the st.
suokko: MostAwesomeDude: in old code it is ;)
MostAwesomeDude: The exception apparently is OQ.
suokko: But sounds a lot better than old code
airlied: the old code shoudln't do state emission per prim either
airlied: it really shouldn't re-emit VS/FS state unless it actually changes
airlied: I'm just not sure it was always this dumb or if someone dumbed it up
suokko: agd5f: radeonfb with KMS :/
agd5f: r600 only copies the shader once
agd5f: suokko: don't do that
agd5f: don't use radeonfb generally
osiris_: airlied: it have been like that at least since I started messing with shaders (1,5 years)
suokko: That is the problem in mailing list
suokko: There should be cat sized text warning that load that radeonfb is loaded and radeon load is failing ;)
suokko: /that load//
agd5f: osiris_, airlied: look sane? http://www.botchco.com/alex/xorg/0001-r300-add-full-support-for-two-sided-stencil-on-r5xx.patch
agd5f: also http://www.botchco.com/alex/xorg/0002-r300-r4xx-and-rs4xx-also-have-lte-discard-regs.patch
airlied: agd5f: will they need any kernel changes or are those regs safe already?
MostAwesomeDude: LTE/GTE discards might not be kernel-safe.
MostAwesomeDude: note to self: ^^ double-check these on r300g
airlied: they should be okay since r5xx I'm more worried about the STENCIL one
suokko: airlied: is it possible that aos emitted wrong way so vertex fog doesn't read data from correct memory location? Only way could change vertex fog to affect rendering color was when I hacked stride to non-zero value and then it only rendering 2 corners out of 20 with different color.
airlied: suokko: its entirely possible, but the fog emit isn't that much different than the other dma emits
suokko: I looked at state emit from before rewrite and it looks exactly same
airlied: yeah I didn't touch any of that stuff to avoid it breaking
Sinuvoid: Hey guys, what's the git/svn url again?
Sinuvoid: And how to I compile + install?
soreau: Sinuvoid: What are you trying to do?
Sinuvoid: I'm trying to install the latest mesa
suokko: Sinuvoid: and what distro are you using? :)
Sinuvoid: With vbo + oq
Sinuvoid: Fedora
suokko: 11?
Sinuvoid: Yep
suokko: Sinuvoid: http://cgit.freedesktop.org/mesa/mesa/
Sinuvoid: so just type make and how do I install?
suokko: I don't know if it works with libdrm and kernel from fedora 11
Sinuvoid: make && install?
Sinuvoid: suokko, how do I update those
Sinuvoid: I really want this mesa update ;_:
suokko: http://dri.freedesktop.org/wiki/Building
suokko: "1.6. Installing the 3D drivers" has tip also how not to overwrite system mesa
Sinuvoid: hroshi@Jack3I2 ~]$ git checkout git://anongit.freedesktop.org/mesa/mesa
Sinuvoid: fatal: Not a git repository (or any of the parent directories): .git
Sinuvoid: (I'm quite new to this, btw)
suokko: Sinuvoid: http://git.or.cz/course/svn.html
Sinuvoid: -_-
suokko: git has a bit different command names because of different set of operations required for working with it
Sinuvoid: how do I checkout
suokko: git clone url = svn checkout url
suokko: That is first in page that I gave you ;)
Sinuvoid: There is no svn checkout url here
Sinuvoid: Just ssh and git
soreau:
Sinuvoid: ?
suokko: Sinuvoid: Do you see difference there? clone is command in git that replaces svn checkout
suokko: git checkout is same as svn switch
Sinuvoid: oh
Sinuvoid: Okay, I understand now, thanks
suokko: and hit pull is about same as svn update
suokko: git pull
Sinuvoid: Damn, should'a did that
spstarr: looks at today's git changes
spstarr: now that I can track and test r6xx :)
Sinuvoid: It's stuck on this: remote: Counting objects: 259187, done.
Sinuvoid: There, now its working
suokko: May I merge state emit prediction code to master?
airlied: suokko: sounds like its good enough
airlied: and really you'll get bugs quicker if its there
suokko: yes. A lot more testing that way
Sinuvoid: More r300/400 dev plz! :D
Sinuvoid: you guys really are making great progress
[Enrico]: Sinuvoid: you can say that :D
[Enrico]: but i should say just MORE RADEON DEVS
[Enrico]: you are great guys :D
[Enrico]: i have a dream: a radeon driver that outcome fglrx in 3d performance :D
[Enrico]: or at least go near it
[Enrico]: hope llvm can do that
Sinuvoid: I'm running the current driver made from this place, and it IS better than the fglrx
[Enrico]: Sinuvoid: for 3d? really? well i have an r600 so i have to wait :D
Sinuvoid: r300/400 runs pretty much flawlessly
Sinuvoid: With THIS latest upgrade, I should expect it to be perfect :D
[Enrico]: Sinuvoid: well flawlessly doesn't mean faster then fglrx
[Enrico]: but yeah on my old r200 it runs very fast
Sinuvoid: It runs faster than fglrx.
[Enrico]: for 2d this is sure :D
Sinuvoid: ./autogen.sh
Sinuvoid: I typed that in, is that all I do to compile mesa?
Sinuvoid: oh, gmake now
Sinuvoid: prays it works, cause it failed last time
Sinuvoid: So far no errors ._.
agd5f: airlied: yeah, I need to check kernel
agd5f: airlied: lte stuff is in the kernel
Sinuvoid: Error!!
Sinuvoid: radeon_screen.c:1387: error: ‘RADEON_PARAM_NUM_Z_PIPES’ undeclared (first use in this function)
Sinuvoid: deon_screen.c: In function ‘radeonGetParam’:
Sinuvoid: radeon_screen.c:271: error: ‘RADEON_INFO_NUM_Z_PIPES’ undeclared (first use in this function)
agd5f: Sinuvoid: need a newer libdrm
Sinuvoid: git clones that
agd5f: airlied: looks like we need to add the stencil backface reg
airlied: agd5f: in drm-next now I have generators for the kms tables
agd5f: airlied: merged to linus yet? or just your tree?
suokko1: Sinuvoid: You have to configure libdrm with --enable-radeon-experimental-api
Sinuvoid: how how how
Sinuvoid: during the ./autogen ?
airlied: agd5f: its for the next merge
suokko1: Sinuvoid: yes yo ucan pass that to autogen
agd5f: airlied: ok. I'll make a patch against that
suokko1: or you can run configure script later with that parameter
airlied: agd5f: I can probably get a patch in for 2.6.30 final if necessary
Sinuvoid: suokko, ok
Sinuvoid: Here it goes, compiling
Sinuvoid: okay success
Sinuvoid: Now any custom parameters for autogen with mesa?
spstarr: has a cow looking at all the commits in mesa. *so many* !
spstarr: looks at suokko thats a huge merge!
suokko: spstarr: that is merge of master to my branch and not my brach to master :( I guess I did it wrong way when I updated my branch to math the latest development
spstarr: Merge branch 'master' of ssh://git.freedesktop.org/git/mesa/mesa into r600_state_predict
spstarr: 29 hourds ago
spstarr: hours
spstarr: i am 29 hours out of date from mesa master in my build
suokko: 92 min.Merge branch 'master' of ssh://git.freedesktop.org/git/mesa/mesa into r600_st...
suokko: Timzone problems in cgit
airlied: suokko: did you just mess up?
airlied: or is it all okay?
suokko: airlied: code is right but merge commit looks funny
suokko: Because I first erged master to my branch and then merged my branch to master
suokko: And I had merged master already few tiems to my branch causing more merge commits to history
airlied: ah yes that happens with git
airlied: generally its not an issue
suokko: You guys are doing too much development so I have to update my branch all the time ;)
airlied: agd5f: ping, care to exaplain DI_SRC_SEL_AUTO_INDEX?
airlied: ah draw index auto helps
Sinuvoid: Guys! Same error!
Sinuvoid: radeon_screen.c:1179: error: ‘RADEON_PARAM_NUM_Z_PIPES’ undeclared (first use in this function)
Sinuvoid: radeon_screen.c:271: error: ‘RADEON_INFO_NUM_Z_PIPES’ undeclared (first use in this function)
suokko: Sinuvoid: you probably need to run configure for mesa
suokko: so it see find the new libdrm_radeon
suokko: /see find/finds/
Sinuvoid: suokko how
suokko: ./configure in top source directory
Sinuvoid: in /mesa?
suokko: yes
suokko: not in mesa/src/mesa/ but in mesa/
spstarr: suokko: you work for AMD or just a developer?
suokko: spstarr: I'm just cs student :)
spstarr: ah
spstarr: at the rate your going you'll be an AMD folk :)
Sinuvoid: suokko, I still get an error
suokko: Sinuvoid: What error?
spstarr: I think the r6xx/r7xx code will be come a good reference for new developers once its 'done'
spstarr: mesa
spstarr: become
Sinuvoid:
suokko: Sinuvoid: then your mesa can't find the libdrm you jsut installed :/
Sinuvoid: suokko
Sinuvoid: I didn't install it either
suokko: ok. you have to first install lindrm and then configure mesa
waterfoul: I'm having a weird issue with the color filter plugin of compiz. whenever I enable it causes whatever I enabled it on to become a scrambled mess... I can get a screenshot if you need (compiz 0.8.2 with radeon drivers). This is what it does to a gnome terminal: http://img30.imageshack.us/img30/9504/screenshotkts.png. The compiz folks reffered me over here
waterfoul: it also causes the display to become sluggish
waterfoul: lspci | grep -i vga yeilds 01:00.0 VGA compatible controller: ATI Technologies Inc M71 [Mobility Radeon X2100] (Secondary) (rev ce)
waterfoul: glxinfo|grep renderer yeilds OpenGL renderer string: Mesa DRI R300 20060815 TCL
Sinuvoid: It's working o_o
waterfoul: anyone?
suokko: waterfoul: If upgradeing to mesa 7.5 doesn't help then it is bug https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
waterfoul: how do I check my mesa ver
suokko: glxinfo | grep nGL
soreau: suokko: I don't think that's the right link (?)
kmays: I'd be shocked if you said full 3D is working on R600.
kmays: Don't think full GLSL 1.20.8 was implemented yet (compliant-wise).
Sinuvoid: suokko, how do I install?
suokko: Sinuvoid: make install
Sinuvoid: what if I already made
suokko: and then you need to set LD_PRELOAD=/usr/local/lib/libGL.so.1 and LIBGL_DRIVERS_PATH=/usr/local/lib/dri
suokko: You put that to your ~/.profile or ~/.bashrc or what ever is your shell init script
Sinuvoid: suokko, so i do make install LD_PRELOAD=/usr/local/lib/libGL.so.1 LIBGL_DRIVERS_PATH=/usr/local/lib/dri
Sinuvoid: ?
suokko: Sinuvoid:
suokko: you do:
suokko: LD_PRELOAD=/usr/local/lib/libGL.so.1
suokko: export LD_PRELOAD=/usr/local/lib/libGL.so.1
suokko: export LIBGL_DRIVERS_PATH=/usr/local/lib/dri
Sinuvoid: Uh, what?
Sinuvoid: I do the first without export?
suokko: They are runtie parameters to make your system load custom mesa
suokko: first was error
suokko: /runtie/runtime /
Sinuvoid: suokko suokko, so I do make install before all this, right?
suokko: yes
suokko: after you do those export glxinfo |grep nGL should show mesa 7.6
Sinuvoid: OpenGL version string: 1.4 Mesa 7.6-devel
Sinuvoid: ????
Sinuvoid: I just typed in glxinfo
Sinuvoid: Is that right, suokko?
Sinuvoid:
Sinuvoid:
Sinuvoid:
Sinuvoid:
suokko: Sinuvoid: yes. you have the git mesa
mattst88: what more is needed for GL2.0?
suokko: Stupid compiz locked my xserver when I tried to enable color filter plugin and it didn't found support for required fragment shader :/
suokko: mattst88: Mostly GLSL
suokko: wait mesa master should report ogl 1.5
mattst88: airlied, radeon_screen.c:270: error: ‘RADEON_PARAM_NUM_Z_PIPES’ undeclared (first use in this function)
mattst88: and on other lines in that file as well.
mattst88: in mesa, that is.
airlied: new libdrm
mattst88: ahh
airlied: well really new kernel headers
airlied: but new libdrm will do it
wayland76: Hi all. I'm using Fedora 11 and have an ATi FireMV 2400
wayland76: I'm trying to configure xorg for it. I have 2 screens attached to ports 1 and 2 (but not 3 or 4) at the moment
wayland76: My problem is that when it starts up, the screens appear to be clones of each other
wayland76: Also, I'd like the screens to have different resolutions.
wayland76: Is there a way to configure this?
soreau: xrandr
wayland76: Ok, will investigate. Thanks
debio264: I managed to get KMS set up on my laptop a week or so ago, but when I rebooted, it locked
debio264: I had to use my laptop in a few hours, so I pulled it off and now that it's not critical, I'm revisiting it
debio264: should I be trying the kernel from git or 2.6.31-rc7?
debio264: before, everything came from git
agd5f: airlied: DI_SRC_SEL_AUTO_INDEX means the vgt generates the indices for you
agd5f: you just tell it how many
agd5f: otherwise you have to set up an index buffer or send the indicies in the command stream
wayland76: Ok, so I have two screens, but they seem to be stuck the same as each other
wayland76: When I specify left-of, then it seems the mouse cursor can go off the side of the screen, but both screens still display the same thing
wayland76: I note also that xrandr tells me I have one screen, with two DVIs
agd5f: wayland76: randr 1.2 doesn't work multiple gpus yet
wayland76: ok, so how do I get my multiple screens to work?
airlied: I think he might have crtc alloc problems
airlied: I forget he command to try and fix that
wayland76: Command, or xorg option?
airlied: xrandr option
wayland76: Ok
airlied: you may need to play with the --crtc option
agd5f: wayland76: http://wiki.debian.org/XStrikeForce/HowToRandR12
agd5f: wayland76: ah, only using 1 gpu at the moment. I missed that
wayland76: IIUC, this FireMV 2400 has two GPUs, and outputs 1 & 2 are on the same GPU
wayland76: I'm on Fedora, but will read that doco -- thanks :)
agd5f: wayland76: yeah, I saw firemv and though you were trying to use all 4 screens
airlied: wayland76: the gpu applet should also work
airlied: if you are using gnome
wayland76: I'm using Enlightenment :)
agd5f: wayland76: xrandr --verbose will tell you which crtc(s) are driving which outputs
agd5f: for dualhead you need a separate crtc for each output
agd5f: so as airlied said, you may need to force the crtc as older version of xrandr didn't do that for you when you specified dualhead
wayland76: Google won't tell me what CRTC stands for. Help?! :)
airlied: you don't need to know
agd5f: CRT controller
wayland76: Ah, ok
wayland76: I appear to have xrandr 1.3
agd5f: wayland76: yeah, that's fine
spstarr: hmmm
spstarr: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 6
spstarr: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 1
spstarr: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 2
spstarr: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 3
spstarr: corrupt mouse pointer too
spstarr: the machine gets very sluggish briefly then returns to normal but not the mouse pointer (VT switch)
lartza: spstarr: get the xf86-ati-radeon-git to fix the mouse corruption problems
spstarr: pulls today's DDX
lartza: or it fixed it for me
spstarr: hell, i'll pull all 3
wayland76: FinallY! Yay! airlied++ agd5f++ It works! :)
spstarr: libdrm has a header change
Sinuvoid: How do I check what mesa I have?
wayland76: The only problem is, the displays are linked. Is there a way to get it so that I can run separate instances of the Window Manager on each screen?
agd5f: wayland76: you have to set up zaphod mode
MostAwesomeDude: wayland76: With separate input?
soreau: Sinuvoid: glxinfo | grep nGL
MostAwesomeDude: Oh, I forgot about zaphod.
spstarr: libdrm updated, now mesa...
agd5f: wayland76: basically pre-randr 1.2 dualhead
wayland76: Yeah, Zaphod is the one I want.
spstarr: does mesa have any symbol errors right now?
wayland76: So I can't use xrandr and zaphod?
agd5f: wayland76: no
agd5f: wayland76: you'll need to do it all in your config 2 screen sections, 2 device sections, etc.
wayland76: Ok. Well, I know Enlightenment has discussed doing something to deal with that situation, so I'll see what I get
wayland76: agd5f: Yeah, I was trying that before, but the second screen would not be recognised
agd5f: wayland76: also no 3d accel with zaphod
wayland76: Don't care about 3d accel :)
wayland76: I'm not playing games
airlied: you might get really bad 2D experience as well
wayland76: As long as it can handle coding, Seamonkey, Openoffice, and videos (xine), I'm happy
airlied: I'm not sure if you have kms enabled
wayland76: Well, I had it set up in Zaphod mode a couple of years ago, but no longer
wayland76: Anyway, the non-Zaphod mode is something I can live with
wayland76: Before this, I was confined to 800x600, so this is a big improvement :)
agd5f: wayland76: you'll need specify busids and screens in your device sections as well
wayland76: Yeah, I know -- I've still got my old config from my Zaphod days
spstarr: agd5f: I had a weird slowdown when loading OpenOffice with radeon, system gets sluggish
spstarr: in 2D no composite
wayland76: My Zaphod days had two video cards, so basically unless I want to downgrade a long way, I'm stuck with non-Zaphod. At least this way, I can use two physical keyboards with different layouts :)
wayland76: Ooh, according to that link you sent me, E17 can already do separate virtual desktops
wayland76: and that's all I want
wayland76: so I'll investigate that :)
spstarr: fail
soreau: I have been having static/corruption on the right area of my screen when 3D is happening here on my rv350. Especially noticeable when alt+drag wobbling a (large) window around. Looks like little horizontal lines of corruption
spstarr: although i thought i just installed new libdrm-devel
spstarr: radeon_screen.c:270: error: 'RADEON_PARAM_NUM_Z_PIPES' undeclared (first use in this function)
spstarr: heh
spstarr: lemme guess i need to copy this into drm_radeon.h
spstarr: until kernel rpm has it
spstarr: beh
spstarr: airlied: maybe moving drm_radeon.h to libdrm and out of kernel-headers?
agd5f: soreau: try Option "DisplayPriority" "HIGH" without kms
spstarr: airlied: libdrm gets installed anyway w/o X?
soreau: agd5f: But I want kms :)
agd5f: soreau: not implemented yet in kms
soreau: oh ok
agd5f: soreau: relatively easy to port though if you are so inclined
soreau: agd5f: What is happening here?
soreau: I mean what is causing this problem
agd5f: soreau: underflow to the display controller
soreau: I was thinking small timing issue
agd5f: MC isn't giving it enough priority
airlied: soreau: why? its a kernel header
spstarr: airlied: yeah but its still in libdrm
airlied: oops
soreau: heh
airlied: spstarr: not if you configure libdrm properly
agd5f: MC has to split it's time between 2d, 3d, overlay, displays, etc. that option forces the priority of the display controller(s) higher
airlied: oh I probably didn't fix the configure yet
spstarr: airlied: im just using what spec file has
airlied: anyways the kernel exports it
airlied: really libdrm should wrap all those
airlied: and mesa/ddx should use a real api
soreau: agd5f: *nod*
spstarr: i have to clobber the one kernel-headers has with libdrm's
airlied: spstarr: you could update the kernel :-)
soreau: agd5f: Where is this code located specifically?
wayland76: Oh, btw, once I made sure I ran xrandr on the left screen *before* the right one, Enlightenment sort of automagically picked up that there were two screens, and did the right thing
spstarr: airlied: 2.6.31-0.167.rc6.git6.fc12.x86_64 old already (rc7?) :)
wayland76: So now I've got Zaphod-style virtual desktops, and everything just works!
airlied: spstarr: -rc7 should be building I think
wayland76: All of my xorg dreams have come true! :)
spstarr: looks on koji
agd5f: soreau: RADEONInitDispBandwidthLegacy() in legacy_crtc.c in the ddx
agd5f: soreau: see the comment around line 1373
spstarr: airlied: about 2 hours or so left
spstarr: or, I could build it :P
spstarr: pulls cvs kernel
spstarr: chances are i will be done before the builder :)
soreau: agd5f: Pardon my ignorance, but the code would end up in radeon_crtc.c yes? I'm guessing legacy is for dri1 (?)
agd5f: soreau: the modesetting code isn't used at all with kms
agd5f: the legacy refers to the old pre-avivo radeon display engine
soreau: agd5f: That's very confusing considering what kms stands for...
agd5f: soreau: kms moves modesetting to the kernel, so the ddx modesetting code isn't used when kms is active
soreau: oh I see what you're saying now
agd5f: that option needs to be ported to the kernel
MostAwesomeDude: soreau: KMS -> modesetting is done with kernel ioctls, not register poking.
MostAwesomeDude: So the modesetting in the DDX (register poking) isn't used.
MostAwesomeDude: Wow, lag. :C
soreau: MostAwesomeDude: thanks :)
soreau: agd5f: So RADEONInitDispBandwidthLegacy() would need to be implemented in radeon_legacy_crtc.c in the kernel?
airlied: I think we already have some of it in there.
agd5f: soreau: it already is. just the diplaypriority high option needs to be ported
soreau: What is the function called there?
airlied: soreau: r100.c:r100_bandwidth_update
soreau: airlied: I'm using r300
agd5f: soreau: same function
agd5f: used for r1xx-r4xx
soreau: hm