hifi: wat, HyperZ?
DanaG: I'm also getting lack of non-power-of-two texture support.
DanaG: hmm, somebody please tell me what this gives: grep -Ri ntfs /usr/share/hal
DanaG: On Karmic, it gives me these three things, on separate lines:
DanaG: ... all in this file: /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi
DanaG: ah, got help in another channel.
airlied: glisse: how did you generate the bit masks for safe regs?
airlied: it might be nice if you had a decoder script for it :)
airlied: glisse: we need to add the AVIVO and legacy vblank line reg relocs
airlied: so xv works
Vash63: I'm trying to build radeon from source and the latest from git is locking up my PC and forcing me to reboot.
Vash63: Tried it once yesterday too.
Vash63: unknown chip id 0x9441, can't guess.
Vash63: (EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting to software rendering
airlied: sounds like an old mesa install
airlied: but shouldn't cause crashes
Vash63: It is an old mesa install actually, last night I had a newer one.
Vash63: So tonight I forced it not to update to see if that was the problem.
Vash63: Screen goes black as I start up Xorg and then it becomes unresponsive. Good news is my fan does slow down finally.
Vash63: But I even tried putting a && sleep 10 && reboot on the end of starting Xorg.
Vash63: And it enver reboots, so it's totally locked up.
MrCooper: airlied, glisse: it looks like kms-support is trying to use a relocation for the scanout synchronization? Is the idea for the kernel to handle the real CRTC ID, and to NOP it out if the CRTC is off?
airlied: MrCooper: yup, just writing the kernel side for it now
MrCooper: excellent :)
airlied: my old kernel didn't nop it out if the crtc was off but thats a good plan
Vash63: Any advice I should try? Updating mesa?
Vash63: It's on 7.4.4.
Vash63: I think.
airlied: Vash63: looks like its segfaultingin the server somewhere
MrCooper: compiz is looking pretty nice on the T500 without tearing, looking forward to the same on the PowerBook :)
Vash63: Hmm. It's a git build so I'm not complaining really, I'd just hate to see this hit the next release if there's some problem with my card.
MrCooper: airlied: your latest fix seems to have fixed the assertion failure in torcs
glisse: airlied: yup i need to push that
glisse: i will do tgz on fdo
airlied: glisse: what range does it cover btw (the bitmaks?
Vash63: Eh, ok. Well I guess I'll just wait for the next release and hope it doesn't have the same issue though, I'm not really sure where to go from here otherwise.
airlied: Vash63: the AIGLX thing is fine, the backtrace later not so much
airlied: can you run it under gdb and get a better backtrace?
Vash63: Example? It's in Gentoo and that was xdm,t hough if startx is easier I can dot hat... would I want to change my compiler settings to get a better backtrace? And how would I start it up?
airlied: gdb Xorg
airlied: you'll need to login over an ssh connection though
Vash63: Ah. That might take some time, my laptop was stolen and I don't have ssh working on my phone yet.
glisse: airlied: up to 4E00 iirc
airlied: glisse: dang, I'll need regs up in the 0x6xxx range
glisse: basicly range is the last authorized reg
glisse: so it's easy to change
airlied: ah cool so I just need the tools to generate a bigger bm
airlied: is the patch so far, I just need to add the bitmask
airlied: and test it
glisse: airlied: table.tar fdo
glisse: public html
airlied: glisse: missing list.h
glisse: on fdo too
glisse: it's basicly kernel list.h stripped down
Zajec3: airlied, glisse i wanted to ask you about some photo...do you have idea what may cause this: http://estudent.put.poznan.pl/rafal.milecki/dsc00219.jpg ?
Zajec3: it's supposed to be concole: kms+fbcon
Zajec3: one idea I was told is fbcon renders using other resolution/depth than kms set... didn't check that yet
glisse: yeah could be that
glisse: log tell you what fbcon believe to be the resolution
Zajec3: glisse: can I make fbcon be verbose?
glisse: airlied: btw so what do we do with tiling ?
glisse: Zajec3: no need for verbose on its side
glisse: what it prints should be enough to know if he got a wrong resolution
Zajec3: i think it prints Console: switching to colour frame buffer device 200x56 only
Zajec3: don't see anything else
Zajec3: i compiled it into kernel... can that be issue?
glisse: Zajec3: what is the resolution of your screen >
Zajec3: http://estudent.put.poznan.pl/rafal.milecki/dmesg.log scroll to bottom for drm/console actions
glisse: Zajec3: so fbcon res looks good
airlied: glisse: I think for colortiling the front/back/depth my patch should be good enough, and we can ignore texture/pixmap tiling for now :)
airlied: I'll clean up the TTM interfaces though
airlied: had hangover today so didn't want to touch tiling
glisse: airlied: my concern is more with the api
glisse: like shouldn't we add flag to gem map ioctl so userspace can ask for surface backed map and also know if it actualy have one
airlied: for color/depth we probably don't really need it, but we can add it you think it'll be useful
airlied: though I'd like to see a userspace using it
airlied: glisse: btw which table is in r300.c? r300 or r500?
glisse: in r300.c it's r300 :)
airlied: oops I justnoticed rv515 has it :)
glisse: in rv515 it's r500
Zajec3: glisse: can this bug be cause of some bad init for r6xx?
glisse: Zajec3: yup could be surface stuff not cleared
airlied: glisse: we should look at using dotable at kernel build time
airlied: make it generate a .h file
glisse: airlied: oh we have right to do that ?
airlied: glisse: yes there is a hostcc you can use to build something
airlied: it would take some kbuild incantation I'm not sure about but other drivers do it somewhere
glisse: will look at that, would definitly be cleaner to have a human readable list in kernel
glisse: airlied: also with current design there is no way for userspace to know if there is a surface reg active
glisse: when buffer get evicted from vram
glisse: oh and if we want microtiling we need to add 3d blit code to ddx... :(
airlied: yeah I think microtiling on textures from mesa only might be best :)
airlied: if we keep a copy, we can just discard the tiled one instead of trying to blit it back
glisse: texture tiling seems bit useless at least on q3 benchmark
glisse: but maybe q3 isn't a good texture benchmark app
airlied: ask anholt or idr maybe
glisse: micro tiling is still giving a nice boost in perf
airlied: microtiling the front or back buffer would be a mess for blit :(
airlied: glisse: need to modify dotable to take an end reg, as I don't want to have the vline regs set to 0 in the table
airlied: I need them to be checked
glisse: airlied: don't understand what you need
glisse: if you need a reg to be checked add it to the r300packet0 check function
glisse: no need to add it to the table
glisse: except if table is too small
airlied: glisse: table is too small :)
airlied: only way to make it generate a bigger table is to add a register to check at the en
zhasha: airlied, glisse: the performance hits experienced when using KMS/TTM, is that because of the kernel side or radeon-rewrite?
hifi: rewrite was a bit slower than the old master
glisse: zhasha: i think mostly due to kernel
glisse: hifi: sadly no one did benchmark i think :(
hifi: ~10fps slower or so
hifi: in quake 2
hifi: but it was insignificant
glisse: airlied: we got tiling working with dri1 & rewrite right ?
zhasha: I was just wondering if the driver was the perp here
zhasha: the 3D driver that is
airlied: glisse: color tiling works, texture tiling no.
airlied: I needed to figure out how to make it work with bufmgr
airlied: zhasha: rewrite still has a bit of scope for optimisation
airlied: esp around the DMA buffer handling I suspect
glisse: so texture tiling could give 10 slow down
hifi: DanaG mentioned HyperZ some time ago
hifi: does radeon have support for it?
glisse: i don't think it's worth supporting hyperz in classic mesa
glisse: we need selling feature in gallium ;)
hifi: sell me moar fps o/
airlied: glisse: r100/r200 :)
glisse: yeah r100/r200 as they already had it
zhasha: glisse: selling point for gallium: GLSL
zhasha: and possibly also a direct3d state tracker at some point
zhasha: technically speaking, it's also possible to use OpenVG, so accelerated vector graphics
glisse: airlied: so what is thie map_page_into_agp
glisse: and unmap from agp ?
glisse: sounds like a leftover
mcgreg: with the new drm from 2.6.31 will it bring any improvement for r6xx/r7xx cards?
nanonyme: Does improvements here mean new features, bug fixes or both? ;)
nanonyme: (I'd be astonished if it didn't have any bug fixes. There's always bugs to be squished)
mcgreg: well, yes. new features , bug fixes yes. actually, the radeon driver with the current from 2.6.30 is good. only wine makes it crash
nanonyme: Eh, you're running software rendering with r6xx/r7xx on Wine so the end result is probably terrible at best. :)
mcgreg: btw, I recognised the xserver initialisation is quite quick here. it only needs a second from startup console to the xserver. it was a waaay slower some time ago
nanonyme: Might as well forget Wine until r6xx-rewrite gets done...
mcgreg: nanonyme: nah I dont play any 3d games, since it doesnt work. with the currect git mesa , the system thinks I have direct rendering. so it tries to use it and crashes.
nanonyme: mcgreg: Wine uses OpenGL for all rendering, me thinks.
nanonyme: All accel anyway.
mcgreg: I only use startcraft/diablo2 and winuae sometimes
nanonyme: Well, *technically* software rasterizer with direct rendering should work fine with Wine.
mcgreg: as faras I know, you can tell wine to use opengl for everythingt , but that not the default
mcgreg: nanonyme: but I dont have rhe software rasterizer, I have Mesa DRI R600 (unknown 9490) 20090101 TCL which is just not working :)
Vash63: Your OpenGL is done in software.
nanonyme: Vash63: It's not. It's made in fail. ;P
nanonyme: mcgreg: Prevent the r600_dri.so from loading and check if it starts working, neeh?
mcgreg: erm, sry. did you ask me to do it, or did you ask what happens? :) the "neeh?" confuses me :)
nanonyme: mcgreg: Actually both. :)
mcgreg: Vash63: if I start any 3d stuff I get -> drmRadeonCmdBuffer: -22 and it quits. well, it is supposed to be like that, I dont have the correct kernel modules.
mcgreg: nanonyme: and prevent it by ... renaming/moving it away for example?
nanonyme: mcgreg: Or chmod.
nanonyme: Whichever should work.
nanonyme: As long as the initialization fails, you should get software rasterizer and Wine might work.
mcgreg: well, honestly, I really dont use it for anything else. and it works already with the 3 things I told you... so I really dont care :) but I will tets it just for fun
mcgreg: you were right. I renamed it, I get now : OpenGL renderer string: Software Rasterizer
mcgreg: and glxgears works now .. with 355fps ;)
mcgreg: I wish blizz would port those 2 games to linux, so I wouldnt need wine at all :)
nanonyme: mcgreg: Or then someone should write a generic opensource engine that would use the resources in those games like ScummVM.
mcgreg: I have no idea if something liek this is possible for such a big games
nanonyme: Well, Freecraft does it for Warcraft II.
mcgreg: though I remember was was a port of starcraft for "mono" ... it was started
nanonyme: (Though the project might be dead)
mcgreg: nanonyme: is it 100% the same? (freecraft/warcraft)
mcgreg: it was along ago I've heard about it. it is probbaly dead
nanonyme: mcgreg: Requires Warcraft II CD to run.
mcgreg: well.. well, the I meant the game play .. simply everything. if everything is 100% exactly the same, it's okay.
nanonyme: (Or required at one point anyway)
nanonyme: Apparently Blizzard Entertainment complained them that they were violating a trademark on Warcraft.
airlied: glisse: map/unmap agp pagse is the old set_memory interface
airlied: just arch generic (only x86 has set memory
nanonyme: mcgreg: Out of Freecraft were born Wargus (mostly what Freecraft was) and Stratagus (the actual engine).
nanonyme: mcgreg: So someone would just have to write how to use Stratagus with Starcraft resources. ;)
mcgreg: hmm okay. maxbe such engines are possible. but then, I believe it would be quite time consuimg. instead blizz could let the port do my somebody (really, there are enough ppl that would do it) ... and simply do the qquality test. if it is okay, release it, if not, make it disappear
mcgreg: nanonyme: they game would have been 100% compatible, because of battle net and stuff. I suppose this is be extremely dufficult
nanonyme: It would end up with a situation where Blizzard would have to pay developers to write a closed source port under NDA, most likely.
nanonyme: Costly for Blizzard, not so useful for the open source community.
mcgreg: hmmm I bet there are ppl that would do it for free, just to support linux
mcgreg: and yes, it could be closed source even. I dont expect anything else. I didnt ask to make the game open source. just a linux client
glisse: airlied: so we should keep using the agp_map/unmap in non x86 case ?
glisse: btw now on agp bo_open for vertex dma buf is the top function in profiling
glisse: i guess it's the same on non agp
glisse: allmost 50% of the time is spent allocating dma vertex buffer for glxgears
MrCooper: glisse: so we're still not using real VBOs?
glisse: MrCooper: still not
Zajec3: mcgreg, nanonyme: there even in Diablo for Mac, so the have already version using OpenGL, right?
mcgreg: Zajec: the problem is not the possibility and the programming problems but rather just the "will"
mcgreg: and not even a matter of money. blizz does a lots of money
mcgreg: with wow it#s like they're winning lottery every month
Zajec: 2.6.31-rc1 :)
Zajec: it seems Linus didn't pull last changes from Dave :/
glisse: i am trying to keep track of unmerged patch
airlied: glisse: yes need to kepp map/unmap on non-x86
MrCooper: glisse: btw, did you ever succeed in making the 32 bit GLX visual marked as non-conformant for DRI1?
AndrewR: yesterday i tried patch from "drm/radeon/kms: add initial colortiling support." thread, and it gives me many Jun 24 14:49:52 (none) kernel: [drm:radeon_object_create] *ERROR* setting tiling on object 2d0 -847393096 . Probably, i applied it in the wrong way, or this RFC patch sholdn't work on my rv280 yet ... (from me colortiling gives ~3x performance boost in q3, 8fps vs 24 fps with 1024x768x24bpp)
AndrewR: *shouldn't work.
AndrewR: **for me ( cpu = duron 950Mhz, gfx = rv280 with 64 mb vram connected to GPU via 64 bit wise memory bus)
PuffTheMagic_: i am getting:
PuffTheMagic_: i2c-adapter i2c-2: unable to read EDID block.
PuffTheMagic_: in my dmesg
PuffTheMagic_: what am I missing?
mcgreg: will suspend2ram will fine with 7xx?
Zajec: PuffTheMagic_: depends... what is your configuration? what doesn't work?
PuffTheMagic_: idk... everything "seems" to work
PuffTheMagic_: i just get this dmesg spam
PuffTheMagic_: since 31-rc1
PuffTheMagic_: and im not sure what part of my userland it outdated
PuffTheMagic_: im using libdrm and ati from glisses branch
PuffTheMagic_: for kms
PuffTheMagic_: do i need to go back to master now?
Zajec: PuffTheMagic_: this just means there wasn't any monitor with EDID on connector
Zajec: PuffTheMagic_: for PANELs for example EDID is not always needed, you can get native from using alternative method based on AtomBIOS
PuffTheMagic_: ok i can accept that, why though does it have to spam dmesg 6 times about it this is normal behavior
nanonyme: Oh, now the clear code might work?
Zajec: PuffTheMagic: how do you think? maybe to help debug sb's situation when he needs EDID?
PuffTheMagic: well im sure I wont be the only one to bring this up... it looks like an error... debug output should only be displayed if debuging is enabled
nanonyme: mcgreg: That's an interesting sentence.
nha: PuffTheMagic: have you looked into your dmesg after plugging in a USB drive?
nha: that's also quite spammy
mcgreg: nanonyme: you dont know?
mcgreg: I see ... the second will=work :)
nha: bottomline is: it's a trade-off; it seems reasonable to disable that output by default once the driver has matured a bit
mcgreg: will suspend2ram *work* fine with 7xx? (corrcted)
nha: but dmesg is definitely not a place that contains only error messages
PuffTheMagic: ^^^ i dont like seeing any error messages in dmesg ;)
PuffTheMagic: nha: i dont care if its disabled or not now that I know that is not critical... it just seems like an error
PuffTheMagic: so i inquired about it
PuffTheMagic: and i bet you will get more people asking about it
nha: I don't really know how important that message is in debugging potential mode-setting issues; depending on that it could be removed, or perhaps reworded to look less scary ;)
Kano: hi, any news about an official release?
ernstp: This is the right place to file bugs, right? https://bugs.freedesktop.org/show_bug.cgi?id=22397
ernstp: You devs are usually so fast at fixing all problems so I just thought I'd make sure ;-)
ernstp: found a problem with one of the power saving modes now also
ernstp: one or a combination of ClockGating ForceLowPowerMode and DynamicPM is causing my Xserver to crash when it "wakes up" from DPMS
Zajec: ernstp: i suggest filling bug with Xorg.0.log from crash
Zajec: and used options ofc
ernstp: Zajec: right, I'll just have to find some time to triage which option it is
ernstp: shouldn't take more than a couple of crashes to narrow it down
ernstp: hopefully I can do clean reboots through ssh or something...
ernstp: I'm on a 4770 which is still rare I guess, hope the can produce more soon so more people test drivers on it :-)
_Groo_: hi/2 all
_Groo_: airlied: dave are you there?
DanaG: damnit, my text is all screwed up.
DanaG: I'm going back to non-KMS.
groo_: airlied: ping?
egore: just update from 2.6.30-06725-g1d89b30 to 2.6.30-rc1 and now my tft is stuck at 1024x768 ... :-/
egore: hmm, I guess it's this from dmesg "i2c-adapter i2c-3: unable to read EDID block"
Zajec: egore: do you mean 2.6.31-rc1?
Zajec: and KMS, right?
Zajec: dmesg with drm debug=15 would be nice
egore: Zajec, erm, right :-) both
Zajec: don't think I know the code, or fix :)
Zajec: just know what may be helpful for developers :)
egore: Zajec, but you know how to help devs ;-)
Zajec: trying ;)
egore: ok, will try what I can get ...
egore: hmm, looks like my kernels ring buffer is to small. all I get is ioctls
nanonyme: Zajec: Oh, there's already an rc?
Zajec: err, don't understand that, can't help now :/
Zajec: nanonyme: yup
egore: Zajec, that means I need to recompile my kernel with a larger buffer, I guess :-)
Zajec: i didn't know about kernel buffer until now :)
egore: Zajec, iirc CONFIG_LOG_BUF_SHIFT
nanonyme: doesn't even pretend to be aware of where exactly ring buffers are used in kernel
Zajec: nice to know, thanks
nanonyme: egore: The default for your processor type isn't enough then?
egore: nanonyme, not with drm.debug=15
nanonyme: Ahm, right.
egore: until now I had 256KB (18), now I'm trying 2MB (21) ... and also I'm trying to get the dmesg output before X starts
nanonyme: And 256KB is already 16x what is the default for a uniprocessor. ^^
Zajec: dmesg has anything todo with processor? next new thing for me :0
Zajec: i thought it's just place for messages from drivers
zhick: weird... i get a black-screen when the radeon-module is loaded (without modeset=0), with 2.6.31-rc1. anyone else has tried it yet?
nanonyme: Zajec: http://kernel.xc.net/html/linux-2.6.0-test6/i386/LOG_BUF_SHIFT
egore: zhick, did you "modprobe fbcon"?
zhick: uhm... not manually : /
egore: zhick, you need a "client" for the modesetting capable radeon driver
zhick: will try... it used to work without doing so though with glisse 's drm-next-branch
egore: zhick, someone (either X oder fbcon) need to tell it to pick a mode
Zajec: zhick: moment
Zajec: zhick: make sure you load fbcon before radeon
Zajec: zhick: airlied told me that yesterday :)
zhick: yep, brb ;)
egore: here's my dmesg ... http://people.freedesktop.org/~cbrill/dmesg.log
Zajec: eh, as I said.... :/ can't help with that
Zajec: dmesg looks fine for me
Zajec: it tells it choose 1280x1024
Zajec: nothing about forcing up to 1024x768
glisse: http://people.freedesktop.org/~glisse/kms have few patches which are not yet in linus tree
egore: glisse, might these help with the issues I'm seeing?
glisse: egore: likely
egore: glisse, cool. will give them a try :-)
Zajec: glisse: what is problem is egore's case?
Zajec: glisse: dmesg shows everything alright for me
egore: Zajec, dmesg should get a mode for 1440x1050 or so. that one is missing
Zajec: ahh, so it didn't really get native mode? ok, now it explains sth to me
Zajec: anyway it's weird where from drm took that 1280x1024
egore: hmm, still 1024x768
egore: nothing changed in dmesg ... except a few irrelevant lines
zhick: hm... i know tried modprobing fbcon manually before modprobing radeon (had to rebuild kernel because i had compiled fbcon in before) but i still get a black screen : /
zhick: *know = now :>
AStorm: it should load radeon itself
AStorm: did you set any kernel command line options?
AStorm: are you trying KMS, or older driver?
zhick: kms with 2.6.31-rc1
AStorm: can't help you there, I've no idea
Zajec: zhick: probably the sam routing as in egore's case
Zajec: zhick: ssh to your machine, modprobe fbcon and modprobe radeon, then get dmesg output
Zajec: zhick: and set debug... 8 or maybe even 15
egore: Zajec, I think zhick if facing some different problem. I get a picture ... just the wrong resolution
AStorm: I think it does autoload, but yes, dmesg would be best
Zajec: egore: yup, it's just we can get from dmesg info what happens :)
AStorm: if you can't ssh in, then write a script to dump stuff and reboot
Zajec: egore: not the same problem, of course
egore: Zajec, ah, ok. understood now :-)
AStorm: (unless it oopses, this should work)
zhick: yeah, i'll just to modprobe fbcon; modprobe radeon; sleep 3s; dmesg >> dmesg.out
zhick: where do i set debug-level? grub?
Zajec: zhick: if nothing crashes, should be fine :)
AStorm: do you have syslog running?
Zajec: zhick: not sure if drm.debug=15 will work in grub
AStorm: you should
Zajec: zhick: you can use modprobe.conf
AStorm: it will
Zajec: oh, so just add this in booting line :)
AStorm: but modprobe.conf or a file in /etc/modprobe.d should do it
egore: Zajec, drm.debug=15 works
zhick: kk thx, brb again ;)
AStorm: but, why is he grabbing dmesg, when syslog is running?
glisse: egore: the edid patch in my kms rep should help
glisse: edid is completly broken without it
egore: glisse, http://people.freedesktop.org/~glisse/kms/0001-drm-fix-edid-interlaced-bit-position ?
glisse: and all other should help with various others issue
egore: glisse, I definitely applied it ... and I'm pretty sure that I rebuilt the kernel and put it in place
AStorm: and did make modules_install, I hope
AStorm: (or make install)
AStorm: (no, wrong, make install doesn't install modules)
egore: glisse, sigh ... copied it wrong ... brb testing
egore: glisse: once I dit it the right way ... it works :-D
egore: glisse, big thanks
groo_: glisse: any news on modesetting for rs485 (kms) and xf86ati fixes for kms-radeon branch?
gadnio: hello, i am having some troubles with the radeon driver
zhick: dmesg: http://nopaste.info/3a2a890b8e.html
gadnio: i have an hd rv770 card and i get constant hangs during screen refresh
gadnio: like, move mouse fast and i see those delays
gadnio: xorg.0.log: http://pastebin.com/m4592a586
Zajec: gadnio: mention it happens for both: radeon and radeeonhd
gadnio: dmesg: http://pastebin.com/d3e47ba7d
gadnio: Zajec: exactly :(
gadnio: both have the same problem
gadnio: my card is with 512mb ram
Zajec: zhick: actually... this may be the same problem as egore's one
Zajec: zhick: drm doesn't detect right modes for you (broken EDID) and set some complety wrong mode that leads to black screen
Zajec: sound reasonably for me
Zajec: gadnio: I hope not... 512mb means 512 mini bytes... ;)
Zajec: mini bits :)
zhick: weird... it used to work with the drm-next kernel-branch
Zajec: don't know trees histories
Zajec: zhick: it's just weird your dmesg looks so similar to gadnio's one
gadnio: i read here: http://www.nabble.com/-Cooker--Radeon-slow-with-kernel-2.6.29-kernels-td22110800.html it's a dri problem :(
gadnio: thoough i don't know how to fix it
gadnio: back, tried a fix suggested somewhere in the forums and it did not work
gadnio: any hints?
aberres: dudes, struggling now again in the hope to get te external monitor working.
aberres: $ xrandr --output HDMI-0 --auto --right-of LVDS
aberres: xrandr: cannot find crtc for output HDMI-0
aberres: is the current status
aberres: does the error mean anything to anyone? google wasn't to helpful
aberres: here is the output of pure xrandr: http://paste.debian.net/40284/
aberres: with resolutions lower than 1920x1200 and no large vertual screen i could get a signal on the external monitor, but the image was somehow scrambled
yangman: aberres: you can only have 2 unique images being output. LVDS and DVI-0 are both already on
yangman: aberres: turn off DVI-0 and try again
aberres: yangman: hm, interesting. let me try
aberres: yangman: wahahaaa, here we go. a clear signal. any idea where DVI-0 comes from? seems as if is the external minitor and at the same time is not the external monitor (because then there would have been a signal i guess)
yangman: is anything actually connected to the DVI port?
aberres: no. the notebook does not even have on. at least none i can use without a docking station
yangman: probably a bug in the detection code, then
aberres: anything i could do to help debugging it? i will just have some minutes tonight though. then i'm travelling for the next two weeks
aberres: apart from this little startin problem i am very happy how this works now. way better than with fglrx
aberres: once there is better powersaving (everything is about 5° warmer than with fglrx) and maybe compositing for the r600 i will be completely happy. so far i am just 90% happy. but that still is enough :)
marko2: hello everyone
marko2: I have followed the user submitted tip for installing the latest version of radeon
AStorm: aberres, there is compositing
marko2: it worked out fine, but I can't run compiz anymore (Xgl not present). Can anyone help me?
AStorm: there's no 3D
AStorm: powersaving sure could use some work
aberres: AStorm: hm, ok. so it seems to be a problem with kwin then. they changed some code there for 4.3, will have to retry then
AStorm: pity I can't even use fglrx, as one important driver - wifi - was added in 2.6.29 and AMD is slow to update
AStorm: not to mention I've xorg 1.6
AStorm: and downgrade is pain
aberres: i hope i will never ever have to use fglrx again. once it was working it was ok most of the time, but as soon as something (kernel, xorg, driver version) changed it was a real PITA
chithead: AStorm: there exist patches for fglrx and 2.6.29, see the gentoo bug
chithead: xorg-server 1.6 works with latest fglrx too
AStorm: might try
AStorm: will try a head to head performance comparison on fs2_open
zhasha: MostAwesomeDude: glxgears is acting funkay
MostAwesomeDude: zhasha: How so?
zhasha: wait, might just be me
zhasha: doing a complete rebuild now to check
zhasha: if it's funkay still, I'll call it in. Anywho~ what it does is change the clear color in a very pretty fashion, and the gears look like they're inside one another. Again, it might be my own changes doing it
zhasha: nope, it's definitely funkay
zhasha: I can't really screen it for you as it's more like a fluent animation
zhasha: pull, recompile and run. You'll see
zhasha: MostAwesomeDude: http://img514.imageshack.us/img514/2764/glxgears.png
zhasha: before fixing anything, I have a patch I want you to look at
Guest43967: guys, i use a X1200 card on my laptop, i will compile my kernel 2.6.30, what do you suggest? driver radeon or radeonhd? why?
zhasha: Guest43967: no idea, try and see which one you like better. Neither driver is in the kernel itself so it's just compiling it and trying it. Takes approx. 5 minutes total :P
MostAwesomeDude: Ooh, funkygears.
MostAwesomeDude: zhasha: Patch?
zhasha: moving around and renaming some of the fragment shader stuff
zhasha: I applied a stricter and more logical naming scheme (consistent with the overall scheme), and separated r300/r500 fs
zhasha: MostAwesomeDude: www.zhasha.com/uploads/0001-r300-gallium-organize-fragment-vertex-shaders.patch
zhasha: It's quite a mouthful, but overall, I like this better. You're welcome to protest/murder me
MostAwesomeDude: Lemme read it first. :3
MostAwesomeDude: Looks mostly okay.
MostAwesomeDude: Does it compile and run?
zhasha: what don't you like about it?
MostAwesomeDude: You didn't pick a consistent naming in r300_debug.
MostAwesomeDude: Other than that, looks clean and nice.
zhasha: MostAwesomeDude: internet gave out there for a sec. I changed r300_debug as well now
zhasha: MostAwesomeDude: Okay, I replaced it on the server, refresh www.zhasha.com/uploads/0001-r300-gallium-organize-fragment-vertex-shaders.patch
MostAwesomeDude: Looks good.
zhasha: enormous patch for something so small :/
zhasha: MostAwesomeDude: so should I push it?
MostAwesomeDude: zhasha: Go for it.
AStorm: would love r6xx kms
MostAwesomeDude: would like food
MostAwesomeDude: And I think airlied would still like his pony. :3
nanonyme: AStorm: Isn't it mostly that the KMS exists but is mostly useless atm? ^^
nanonyme: MostAwesomeDude: Ponies <3
bkero: OMG PONIES?!?
AStorm: nanonyme, doesn't
AStorm: there's no memory manager yet
nanonyme: Sure it does. It even at one point managed to work with X with no acceleration.
AStorm: oh, probably
AStorm: accel is necessary though
AStorm: I wonder what makes r5xx and r6xx memory management so different
nanonyme: Wouldn't know, haven't read the specs.
airlied: well we have to implement r600 irqs and memory transfer
airlied: for r500 we use the 2D engine which we don't have.
airlied: also r600 command submission is slightly different I think
airlied: since all the registers moved
nanonyme: And the IRQ documentation was something which you don't yet have or did I understand incorrectly?
airlied: I think I have info under NDA on it, I just haven't had time to look at it
airlied: and really we need to finish off the older code to some semi-stable point
airlied: okay vline patch away.
nanonyme: The latest r6xx-rewrite commit quite sneakily enabled the clear code?
nanonyme: Maybe I'll eat a bit and see if it affects rendering.
Batou: How does that work anyway? YOu get the patch done and just can't release it until ATi makes the info public?
nanonyme: Hmm, right. At least with the clear code on the wrongness in the rendering is consistend. :3
nanonyme: (Instead of being different on about every run)
zhasha: "Running synchronized to the vertical refresh. The framerate should be approximately 1/1355810 the monitor refresh rate." -- somehow I get the feeling that's not quite right :P
DanaG: hmm, that behavior of being slow except during "benchmark"... is really odd.
DanaG: oh yeah, and note to self: having gnome squish a really really really really large background image down to a smaller size... for some reason... doesn't save video RAM.
DanaG: It eats CPU, for some odd reason.
DanaG: Interesting things happen when you combine wobbly with xv.
DanaG: The video playback isn't redirected.
airlied: should be unless you are still using overlay
DanaG: It's set to XV.
DanaG: Probably is overlay.
airlied: Xv is fine
airlied: its just textures vs overlay
DanaG: I see... mplayer is probably just using XV adaptor 0 (overlay).
DanaG: That smooth-only-while-benchmark-is-running behavior is the bigger oddity.
DanaG: hmm, textured-video is also only playable with benchmark running.
DanaG: hmm, overlay is always smooth, because it's not redirected.
DanaG: well, not "always", but it's better.
soreau: DanaG: There is some glx call in compiz that is made every frame when Benchmark is enabled
soreau: On nvidia cards with powermizer, benchmark kicks the card into 'high gear'
soreau: There was one guy that made a plugin to make this call every frame with benchmark running of course, but not sure if it's posted anywhere
soreau: DanaG: Take a look in Workarounds and try messing with the glx related settings there