ajami: airlied, I said that -96 had X crashing randomly, but actually I think I spoke too soon. I am actually not sure. However, I am in -96 with nomodeset right now so, I will know for sure soon enough. I think it did, but I honestly am not completly sure.
ajami: I just had my screen freeze, but my mouse moved around. -97 nomodeset. dunno what that means, thought I'd let you know.
happycube: just got etracer running on r300g - psychadelic but you could at least see where tux is!
soreau: far out man! ;)
happycube: added a pipe_flush at the end of r300_swtcl_draw_range_elements - that prolly isn't the cleanest place, but that fixed the prog/redbook/planet problem
happycube: (etracer is still quite foobar, but it's MUCH better than without it)
happycube: i think the flush *should* be at buffer_destroy, but i can't figure out where to hook into that yet
happycube: er, buffer_write
airlied: generally adding flushes is wrong ;-)
airlied: they just paper over the fact that something else is horribly broken
happycube: yeah... i'm not quite up on things to figure out the horrible brokenness yet
happycube: now, textures - *those* are horribly broken
happycube: now... where can a flush go when gallium calls in for buffer_write...?
happycube: (which seems to be a better time to flush)
AndrewR: airlied, this one was good c850cb782626fda78e5e9e5baf18a5bd806a225c (in drm-next)
soreau: AndrewR: A bisect typically boils down to a first bad commit..
AndrewR: soreau, airlied and in my case it points at http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff
AndrewR: airlied, reverting this gives me working radeon driver (with KMS)
ajami: airlied, so far so good. I haven't had a random X crash with -96 nomodeset
ajami: airlied: I don't think -96+nomodeset has X crashing at all.
ajami: just -97+nomodeset
airlied: agd5f: ajami issue seems to point at some of the non-kms patches
airlied: AndrewR: interesting
slavka: hello all!
davem1: airlied: ping
davem1: airlied: Firstly, you were right, sparc64 got bolixed by the 2.6.32 DRM commits with Radeon
davem1: airlied: Debugging now :-)
davem1: airlied: Secondly, in commit 453a7d46dca887 the message says "drop ioctl auth_magic as discussed on mailing list also" but that doesn
davem1: t actually happen in the commit
airlied: davem1: does it work in non-kms mode?
davem1: airlied: no, it reboot my system instantly when I start X, or is KMS mode the default?
davem1: airlied: an instant reboot is always "accessing I/O ports as regular ram" on sparc64
airlied: davem1: no you don't get kms unless you enable it via staging
davem1: airlied: Linus's current tree punts for me
davem1: airlied: anyways, look at that ioctl commit and I'll debug this, don't worry
airlied: davem1: the ioctl commit meant to say drop root requirement on the ioctl
airlied: davem1: so 2.6.31 works okay and something since then broke it?
davem1: airlied: you added that extra text to the commit, it already says it's removing root requirement
davem1: airlied: yes, 2.6.31.5 is OK, double checked today
airlied: davem1: does the firmware load okay?
airlied: that might be a first suspect
airlied: there was very few non-kms changes
davem1: airlied: dunno, will check that out if reading commits doesn't show anything obvious
davem1: airlied: jesus christ you duplicated list.h into mkregtable.c!
davem1: airlied: dude, tools/perf/*.c uses the in-kernel list.h just fine you can too :-)
airlied: davem1: does it? last time I tried to include it in userspace it failed miserabl
airlied: maybe someone fixed it up since then
davem1: perhaps
airlied: the firmware is the only thing I can see that affects non-kms paths for radeon
davem1: are the reg tables used non-KMS? I thought those were used to validate packets?
airlied: no only the kms driver uses the generated onews
airlied: what gpu you using rv370?
davem1: all that CS parsing stuff is only used by KMS?
davem1: RV370 yeah
airlied: yes
airlied: and r600s in non-kms
airlied: we really haven't touched the non-kms driver deliberatly
airlied: so firmware loading is the only think I can think that touched it
airlied: radeon_cp.c and radeon_state.c and r300_cmdbuf.c are the non-kms driver
davem1: I see KMS compiled in unconditionally in Linus's tree
davem1: drivers/gpu/radeon/Makefile
airlied: its built in but not enabled
davem1: ok
airlied: if you modprobe radeon it should say
airlied: davem1: firmware loading works on powerpc but they didn't test it on anything
airlied: anything else
davem1: ok, I'll check that after going over the commits a bit more
airlied: like I expect kms to be busted all to hell, but non-kms shouldn't have broken
davem1: hmmm I wonder about the endianness
davem1: when you do WREG32() it byte swaps on big endian internally
davem1: firmware blog is big endian, and you be32_to_cpup() the values, which is NOP on big endian
davem1: hmmm
davem1: airlied: the other change is that the radeon DRM now registers with the vga arbiter
MrCooper: davem1: there have been no reports of breakage on powerpc, so an endianness issue is unlikely
davem1: MrCooper: wrong
davem1: actually...
davem1: I think VGA is the culprit
davem1: because it's the one bit not tested on sparc64 which is non-trivial and does register accesses
davem1: I bet the I/O accesses in there are busted
MrCooper: what was wrong about what I said?
davem1: I take that back sorry MrCooper
davem1: I'm dyslexic so I read you are saying VGA can't be the culprit, sorry :)
MrCooper: k, cool
davem1: anyways, both possibilities are easy to test, doing that now
MrCooper: btw the Sashimi with benh was delicious the other day, thanks for the tip :)
davem1: :)
davem1: Did you guys go to the fish market or the restaurant by the hotel?
davem1: ok modprobe succeeds... next test...
davem1: Ugh... sorry guys, false alarm on the bug.
davem1: Maybe I had a misbuild, but it works fine now.
MrCooper: a restaurant by the hotel
spreeuw: are you at the japan linux summit?
davem1: we were
MrCooper: no, I'm just on vacation in Japan
davem1: MrCooper: fish market sushi bar was even better
MrCooper: davem1: cool, when we were there it was too early in the morning / busy for Sushi :}
airlied: davem1: it might be different between X loading the module and modprobe loading it
airlied: the VGA arbiter doesn't do anything unless it sees two VGA cards
davem1: airlied: yes let me try that
airlied: for backwards compat reasons
davem1: reboots
davem1: airlied: having X triggering the drm mod load works too, I must have had a shit build
davem1: MrCooper: the sushi places in the fish market open at 4 am and I never went later than 5:45am
MrCooper: yeah it just didn't suit me
davem1: cool
davem1: I'm feeling adventurous, let me try turning KMS on, just a modprobe option right?
airlied: davem1: yeah modprobe radeon modeset=1
airlied: had sushi after noon in fish market still very good ;)
davem1: working so far...
davem1: My X session came up just fine too
airlied: davem1: if you don't have a new X userspace driver, the ums driver will trash the kms driver mostly
davem1: 6.12.99 radeon on this box
davem1: Xorg 1.6.99.1
airlied: if the libdrm is built properly it might work
airlied: not sure what distro have shipped userspace kms bits
davem1: any interesting strings to look for?
davem1: I built completely from GIT
airlied: you shuold have a libdrm_radeon.so somewhere
airlied: if not build git libdrm with --enable-radeon-experimental-api
airlied: then rebuild -ati against that
ajami: airlied, I know I have said this a few times, but now a significant amount of time has passed and I have yet to have any issues (with X failing) with -96 nomodeset.
airlied: ajami: cool I think I'll revert some of the changes that went into -97 then I have a fair idea which ones to kick out
davem1: only have libdrm_radeon, but libdrm_intel is there so yeah I gotta rebuild to test this
airlied: the fact you get fbcon working is quite good
davem1: sorry, I meant "I don't have libdrm_radeon"
davem1: yeah :)
davem1: I haven't pulled in a while, let me play with this, will let you know how it works
airlied: cool, you can rebuild mesa as well against the libdrm to get 3D tested
davem1: wait a second
airlied: it might be slower for your quake gamse until we optimise it a bit more ;-)
davem1: it says using kernel mode setting but I don't get the "Initialized radeon 1.31.0 ..." in the kernel log when modeset=1
airlied: it'll be 2.0.0
airlied: and there should be other spew
airlied: lots of it
davem1: it's 1.31.0 in Linus's tree
airlied: thats the non-kms driver
airlied: the kms driver is an ABI break
davem1: So I have to run staging? I
davem1: m just running Linus's tree
davem1: which builds everything in, all the KMS bits seem to be there
airlied: davem1: well the enable it by deafult option is in staging
davem1: so the code should be the same and I turn it on using modeset=1 so...
davem1: that sucks
airlied: when you modprobe it goes down a very different codepath with the option
davem1: it doesn't say anything in the kernel logs, but the driver load failed
airlied: got dmesg?
davem1: so Xorg can't open the DRM device
davem1: [ 786.071954] [drm] radeon kernel modesetting enabled.
davem1: [
davem1: like I said,
davem1: that;'s all I get
davem1: [ 920.993652] [drm] Module unloaded
davem1: from rmmod
airlied: oh wierd
davem1: yah, error reporting :-)
airlied: I suspect you need to fill out some functions in drm_cache.c for sparc also
airlied: but that shouldn't stop it loading
airlied: oh it might be because radeonfb is loaded
davem1: I can't use radeonfb?
airlied: since you can't have two drivers bound to the pci device
davem1: I can't "not" use radeonfb on sparc
davem1: I'll have no console
airlied: the whole point of kms is to have one driver to control the hw
jcristau: you get radeondrmfb instead
davem1: ok, let me try that, how do I get that modeset option to it when it's built in?
airlied: davem1: staging option
airlied: or on command line should also work
davem1: and a better diagnostic needs to go into the kernel message log
davem1: radeon.modeset=1?
jcristau: radeon.modeset=1 on the command line should work
airlied: yes that shuold work for builtin also
airlied: davem1: so you don't have any offb equiv?
davem1: airlied: no, and vga doesn't work either
airlied: davem1: how do you early debug? serial?
davem1: airlied: OpenFirmware console
airlied: pity it doesn't support offb, I've got a patch to handoff offb to the kms fb handler
chainsawbike: y
chainsawbike: ...wrong place
davem1: here goes nothing...
airlied: expects horrible wrongs
davem1: radeon: No suitable DMA available.
davem1: The machine came up all the way though.
davem1: No console :)
davem1: [ 56.708480] radeon: probe of 0000:09:00.0 failed with error -22
davem1: hmmm, it's probably something stupid, let me track this down
airlied: davem1: I'd expect if it works to see "Architecture has no drm_cache.c support"
airlied: ah dma mask "fun"
davem1: It's fine, sparc64 enforces 32-bit only
airlied: we try for 40-bit
davem1: and that's all you'll get from DMA API, 32-bit addresses
airlied: on PCIE cards
davem1: right, you should fallback to 32 if that fails
davem1: but it's all a NOP, that message is a red herring
airlied: ah yes
airlied: maybe the ioremap of regs fail
airlied: if you don't see the register mmio base printed
davem1: that is printed
davem1: [ 56.708129] radeon: No suitable DMA available.
davem1: [ 56.708140] [drm] register mmio base: 0x00800000
davem1: [ 56.708150] [drm] register mmio size: 65536
davem1: [ 56.708160] [drm:radeon_driver_load_kms] *ERROR* Fatal error while trying to initialize radeon.
mcgrof: just tested 2.6.32-rc5 + git xf86-video-ati, drm, etc but glxinfo still indicates Software Rasterizer. I read on lwn today about f12 having 3d support now so I figured this would be available on git, is there any customizations to the build to get 3d working?
mcgrof: I have an HD4870
jcristau: what version of mesa?
mcgrof: jcristau: today's git pull
mcgrof: let me check logs :)
airlied: davem1: so it should git r300.c:r300_init
davem1: airlied: right, just added diags, I bet it's irq_kms_init or similar failing
davem1: reboots
nursultan: oh hai fans.
nursultan: how do I enable XV (Overlay) on amd785g rv620 onboard card
airlied: there is no overlay
airlied: only textured video
mcgrof: Xorg log seems to not be complaining
mcgrof: http://bombadil.infradead.org/~mcgrof/tmp/Xorg.0.log
davem1: [ 55.877187] vga_client_register() fails with r=-1
jcristau: mcgrof: what about LIBGL_DEBUG=verbose glxinfo?
nursultan: airlied: tvtime complains bout it. maybe I should change to radeonhd?
jcristau: nursultan: or not
airlied: nursultan: no driver can support hw that doesn't exist
nursultan: oh
nursultan: so there is just texture overlay ?
airlied: nursultan: just textured video Xv
airlied: nursultan: xvinfo should show the list of adapters
nursultan: aaah
airlied: if that reports 0 then you need kernel support
airlied: davem1: uggh
mikkoc: nursultan: i have the same card as yours and i have some issues.. does kms work for you?
nursultan: i forgot xvinfo :(
davem1: airlied: for some reason vgaarb doesn't register the radeon device
airlied: davem1: is it a VGA class?
airlied: or just display class in lspci?
nursultan: mikkoc: sorry its not mine just for a friend who wants to watch analog tv with tvtime
davem1: "Display Controller"
nursultan: I'm just asking I'll try later
airlied: davem1: ah thats a bug then
mikkoc: ah ok
mcgrof: jcristau: http://bombadil.infradead.org/~mcgrof/tmp/glxinfo-libgl-debug.log
davem1: airlied: I can test anything real quick.
airlied: it should just continue instead of failing at that point
davem1: ok
nursultan: did got it 2 work? it's a chakra/arch linux installation
airlied: I'll think about a proper solution, display controller class doesn't decode vga
airlied: I should change the register function to just return 0 in that case
airlied: adds to list
davem1: builds and reboots
davem1: W)))TTT
davem1: !!!!
davem1: works
mcgrof: what does?
jcristau: mcgrof: you didn't build the r600 driver.
mcgrof: should the Configuration section of http://dri.freedesktop.org/wiki/ATIRadeon be removed?
davem1: KMS radeon on sparc64
jcristau: mcgrof: no wonder it doesn't work.
airlied: davem1: gimme dmesg ;-)
davem1: airlied: X came up too
airlied: davem1: probably trashing things, it'll complaing about dri versioning
davem1: airlied: no DRI, quake3 used sw rendering
airlied: if using user modesetting on top of kernel modesetting
mcgrof: jcristau: erm... how do I enable compiling it?
davem1: airlied: http://vger.kernel.org/~davem/x.log
airlied: davem1: if you get the libdrm with that flag built and -ati against it you should get proper userspace
davem1: airlied: will try that, please push the change to Linus to ignore the vga client register return value
davem1: I'm tempted to force a panic to see if it makes it to the screen with X running :-)
airlied: davem1: I'll queue it up tomorrow when I'm near a real machine
jcristau: mcgrof: depends how you build mesa. there's a --with-dri-drivers configure option iirc
airlied: davem1: not without the userspace bits
davem1: oh right...
airlied: wierd aboutg the bios rom
davem1: no BIOS on these cards
davem1: only openfirmware
airlied: davem1: ah you have dual-head?
davem1: airlied: yeah, one Sony 24" and one Dell 24"
airlied: cool just making sure it wasn't buggy ;-)
davem1: hehe
airlied: without a bios we just make shit up
davem1: the output appears on both monitors when it comes up
airlied: yup with proper X it should be possible to use xrandr
airlied: I dispaly console anywhere i can
airlied: just in case
mcgrof: jcristau: hm ok, I was using this http://paste.pocoo.org/show/147233/
mcgrof: goes to configure mesa manually
davem1: airlied: I'll futz around with userland and let you know how it goes
mcgrof: ah now I need xxf86vm, xdamage and xfixes
mcgrof: I take it I probably need some more bleeding edge versions than what my distribution provides, or should old crap be ok?
mcgrof: goes for the distro crap
mcgrof: seems to be building
mcgrof: restarts X
mcgrof: jcristau: ok so I built mesa now with --with-dri-drivers but I still get software rasterizer
mcgrof: http://bombadil.infradead.org/~mcgrof/tmp/glxinfo-libgl-debug-02.log
mcgrof: my xorg.conf has the ModulePath "/local/xorg/lib/xorg/modules,/usr/lib/xorg/modules"
mcgrof: and well above is my build script
jcristau: mcgrof: set LIBGL_DRIVERS_PATH to where you installed the r600 driver
mcgrof: jcristau: to run glxinfo ?
jcristau: to run whatever you want accelerated
mcgrof: oh
mcgrof: will try gltron
mcgrof: something like LIBGL_DRIVERS_PATH=/local/xorg/lib/xorg/modules/drivers/ ?
mcgrof: does a search for r600_dri.so
taiu: mcgrof: your mesa version is 7.5, git build should give 7.7
mcgrof: /local/xorg/lib/dri/r600_dri.so is where my stuff is at it seems
mcgrof: taiu: oh wtf
mcgrof: wow nice, gltron ran smooth so I take it it worked
mcgrof: tries google earth
jcristau: if you want to use libGL from /local/xorg/lib you need to set LD_LIBRARY_PATH
jcristau: /local/xorg/lib is not in the default ld.so search path
mcgrof: googleearth complained about software rendering
chithead: "glxinfo | grep -i render"
chithead: also be aware that if you run a 32 bit application on 64 bit system, you need 32 bit mesa too
mcgrof: IRQ's not enabled, falling back to busy waits: 2 0
mcgrof: direct rendering: Yes
mcgrof: OpenGL renderer string: Mesa DRI R600 (RV770 9440) 20090101 TCL
mcgrof: ah I see
mcgrof: which might explain google earth
mcgrof: given google earth is only 32-bit AFAICT
mjr: chithead, does it nowadays work through DRI and not just AIGLX though, 32->64bit?
chithead: mjr: I am not sure I understand what you mean
mcgrof: jcristau: ok thanks, so I have a /etc/ld.so.conf.d/a-local-xorg.conf with /local/xorg/lib that should suffice ay?
jcristau: probably
mcgrof: ok lets see if I can enable compiz
mcgrof: btw kudos :)
mjr: chithead, that 32-bit mesa/dri clients can use direct rendering acceleration nowadays and not go through the X server via GLX?
mjr: on 64-bit DRM
chithead: the 64 bit drm supports both 32 bit and 64 bit dri
mjr: I think that's what I was looking for, thanks
mcgrof: "desktop effects could not be enabled" oh well another battle for another day
twoerner_: airlied: ping
mcgrof: csmash seemed to have worked fine too, I can never get tired of playing that game
airlied: twoerner_: pong
twoerner_: airlied: i still have the deadlock problem with the latest F-12 kernel without the pcieaspm=off option
twoerner_: airlied: is there anything else I can do about this?
airlied: twoerner_: so pcie_aspm=off helps still? or never did?
twoerner_: it helps
airlied: okay so the aspm workaround didn't work then
airlied: you are using -97?
glisse: airlied: some of the lockup are not fixed with aspm off
airlied: glisse: eah I know but it fixed this one
davem1: airlied: I assume I have to enable radeon-gallium in mesa too...
airlied: davem1: no need, just normal radeon driver once it finds libdrm_radeon
davem1: doesn't work
davem1: that doesn't bring in xorg_dri2.c from the gallium state trackers
airlied: it should autodetect libdrm_radeon using pkg-config
davem1: which is where DRI2ScreenInit is defined
airlied: davem1: just --disable-gallium
airlied: at least until the non-gallium paths work
davem1: It did detect libdrm_radeon
airlied: then the normal r300 driver should be fine
davem1: And then Xorg wouldn't startup because it couldn't resolve DRI2ScreenInit
airlied: davem1: should be part of the DDX
airlied: -ati
airlied: might help to grab 1.7 X server now that its out
davem1: Hmmm...
twoerner_: airlied: pcie_aspm=off is helping with -97
davem1: grumble, I didn't rebuild Xorg, ok
davem1: I thought I could get away with just rebuilding libdrm and xf86-video-ati
twoerner_: airlied: but why isn't it default?
airlied: davem1: should work
airlied: davem1: I just noticed you had a prerelease X server ;-)
davem1: airlied: Doesn't because Xorg is where DRI2ScreenInit comes from for drivers, and that's what I'm not getting
davem1: airlied: So I have to rebuild Xorg with libdrm in place
airlied: davem1: mabe the server you have missed dri2 support
airlied: it shuold be built in thuogh
davem1: airlied: git grep shows it there
davem1: we'll see what xserver rebuild does
airlied: twoerner_: I added a patch to make it aspm turn off on r600/rv770 from mjg59
airlied: twoerner_: what gpu is it?
twoerner_: it is a 3870
airlied: twoerner_: we really want aspm on by deafult since it saves power
airlied: just stupid AMD gpus seem to fail
twoerner_: but with it enabled i get the X server to lock very simple
airlied: mjg59: ^^^^ I think we need aspm me less hard patch
twoerner_: moving a window around it all that is needed
airlied: twoerner_: yup hence why we have an option for r600 to turn it off
airlied: just haven't perfected the correct option et
twoerner_: i do not have the problem with F-11 and drm, mesa and ddx from git
airlied: twoerner_: we only turned aspm on for F12
twoerner_: ohh
twoerner_: that might be the reason ;-)
airlied: r600 seems to be the only casualty and only on some machines
twoerner_: hmm .. only on some machines
twoerner_: what is needed for this=
twoerner_: ?
airlied: well I haven't seen it here at all, for now we'll just hopefully disable it on all r600/700s
airlied: and revisit in f13
airlied: twoerner_: hopefully mjg59 can tell me a better patch
airlied: and we can put that in tomorrow
airlied: though it does look like that patch should dtrt but i don't know the aspm stuff that well
mcgrof: openarena works swell too, fps stays in the 90s even at the highest texture detail settigns at 1024x768
mcgrof: what's a good test other than games?
davem1: inputproto removed XI_RawEvent but xserver still uses it...
davem1: checks out an older inputproto to work around this...
mjg59: airlied: Sure. I told you there's already a function to do that?
airlied: mjg59: yeah I added that
airlied: mjg59: http://pastie.org/671442
airlied: is in the -97 kernel twoerner_ is running
mjg59: airlied: And that doesn't work?
airlied: mjg59: according to twoerner_ adding pcie_aspm=off is still necessary for him
mjg59: airlied: Ugh. Ok, it's on my list.
mjg59: That code's definitely running?
airlied: yes definitely should be called for his pu
airlied: gpu even
mjg59: Sigh
mjg59: Right, I'll find (a) a machine and (b) a card
mjg59: But today is RHEL, so no guarantees that it'll be immediate
airlied: twoerner_: you are using modesetting enabled I assume?
airlied: my patch didn't hit non-kms path
airlied: adds to list and goes to bed
airlied: twoerner_: let mjg59 know if kms or not-kms
glisse: win 1
twoerner_: mjg59: i am using kms
twoerner_: airlied: jup, kms and mesa-dri-experimental
davem1: airlied: almost working, one of the ioctls goes tits up in the kernel
davem1: airlied: it's RADEON_PARAM_DEVICE_ID and it causes an oops on the kernel copy from userspace, investigating...
davem1: airlied: there's garbage in drm_radeon_info->value, somehow the pointer put there by userspace got 64-bit sign extended.
davem1: airlied: we have to give compat treatment to this address in any case
AndrewR: agd5f, OQ r600 patch works on RS780 (RS780 9611). OpenGL 1.5 !
revx: bridgman: from 8:40am to 2am, you're at it again...
revx: how do you do it?
bridgman: I sleep intermittently ;)
bridgman: cool... OQ for r600
davem1: airlied: I have it working, quake3 goes too
davem1: airlied: but full screen in quake3 doesn't mode switch :-(
davem1: airlied: I'll email the patch I used to get things working.
davem1: airlied: for some reason ioquake3 thinks the only mode available is 1920x1200
davem1: airlied: because I can fullscreen properly with mplayer
davem1: airlied: it's late here, I'll try to debug it tomorrow
davem1: airlied: otherwise, things work perfectly FWIW
Rikki-Tikki-Tavi: Using Driver "radeon"
Rikki-Tikki-Tavi: server glx vendor string: SGI
Rikki-Tikki-Tavi: output of glxinfo
Rikki-Tikki-Tavi: is that normal?
ajax: yes.
glisse: Rikki-Tikki-Tavi: glxinfo | grep render
Rikki-Tikki-Tavi: thx
Rikki-Tikki-Tavi: also
Rikki-Tikki-Tavi: client glx vendor string: SGI
Rikki-Tikki-Tavi: guess it's normal, too
Rikki-Tikki-Tavi: well cya
Rikki-Tikki-Tavi: thanks
witukind: Hi, how good can I expect KMS to work with a RV280 (Radeon 9200 PRO), X.org 7.5, Mesa 7.5.2, Linux 2.6.31.5 and libdrm 2.14.15 ? Is the slow scrolling issue in Firefox still present and does XRender work good?
witukind: Also what happened to xcb-proto package?
jcristau: there's no support for radeon kms in mesa 7.5 iirc
witukind: ok, so it's 7.6 minimum I guess
witukind: I guess I should just wait for Linux 2.6.32 and mesa 7.6 then
chithead: mesa 7.6 has already been released, and kernel 2.6.31 is enough
witukind: oh ok
witukind: so let's do a compile fest ^^
ralesk: witukind → xcb-proto, why, what happened to it? :)
witukind: ralesk, nevermind I didn't remember that xcb-proto is available from the xcb project and not in xorg 7.5 :)
ralesk: heheh :)
happycube: r200 supports kms now? if so, cool
chithead: all radeons have kms support, except for r800
happycube: cool (i was thinking 3d)
ReDAeR: Hi Guys
ReDAeR: I'm trying to set up Xorg at Arch Linux. I have two problems first firefox starts in 640x480 resolution second is i miss 20pixels on the edges.. So in this screenshot: http://img194.yfrog.com/i/weirdm.png/ I can't see a part of the word File
ReDAeR: If i'm using vesa drivers i see the full resolution but if i use the radeon drivers i miss lik 20 pixels
ReDAeR: Any idea what's going on?
ReDAeR: Link for Xorg config: http://dpaste.com/112713/
agd5f: ReDAeR: looks like a desktop config issue
ReDAeR: Ok ty agd5f il look into that then
ReDAeR: agd5f i tried a different WM but it has the same problem
ReDAeR: As i said if i use vesa drivers i don't have the problem so can it be something with the driver?
agd5f: ReDAeR: the driver has nothing to do with window placement
ReDAeR: I know but i miss like 20 pixels on all edges so it's like it's scaling to 110%
ReDAeR: Different WM doesn't help
agd5f: ReDAeR: edges of what?
ReDAeR: my screen
ReDAeR: Example if i start up a terminal i need to press enter twice before i see what i'm typing
ReDAeR: and the full name is like [Robert@ReDAeR ~]$
ReDAeR: While i just see @ReDAeR ~]
agd5f: in the terminal?
agd5f: or cut off like part of the terminal is off the screen?
ReDAeR: Terminal in the Window
ReDAeR: part of terminal is off the screen
agd5f: ReDAeR: what kind of monitor?
ReDAeR: Samsung 32" fullHD
agd5f: so a TV?
ReDAeR: Don't know the exact number but i can look that up for you
ReDAeR: Yes
agd5f: probably you need to adjust the tv to turn off overscan
ReDAeR: TV -> HDMI -> DVI -> PC
ReDAeR: Let me get my 10000 page TV manual :D
ReDAeR: WTF agd5f ur god!
ReDAeR: Thank you very much :D
agd5f: ReDAeR: np
yangman: blah at TVs that overscan digital signal :(
taiu: of all the weird 3d effects i'v managed to create this one is kinda cool
ReDAeR: agd5f You have any idea why firefox starts in a resolution of 640x480?
taiu: in doom3 everything behind glass is upside down, otherwise oerfect
ReDAeR: taiu show us :)
agd5f: ReDAeR: depends on your wm
taiu: maybe it's the fragment.position thing
agd5f: taiu: does it use nv_fragment program? I don't think we handle that yet
ReDAeR: agd5f ok ok
taiu: agd5f: isn't there a bit to flip, which gets this corect way automagigcally
agd5f: taiu: could be.
agd5f: taiu: probably in one of the SU regs I would guess
Dr_Jakob: doom3 uses read/copy/write pixels for the glass effect.
MostAwesomeDude: That seems like a weird choice.
Dr_Jakob: well not write pixels
Dr_Jakob: but doom3 has the distortion effect on things behind the glass.
MostAwesomeDude: Sure, but why not a vert shader instead?
MostAwesomeDude: Maybe I just like vert shaders too much.
Dr_Jakob: that wont possible work.
Dr_Jakob: http://media.photobucket.com/image/doom%203/Section-9_Wipo/Doom%203/doom3-20090102-033117.png
Dr_Jakob: that kind of per-pixel distortion can't be done with vertex shaders.
MostAwesomeDude: Oh wow. I wonder how many copypix calls are required for that.
Dr_Jakob: one, per surface that distorts something.
MostAwesomeDude: Hm. I must really not be understanding how the effect's done, then.
Dr_Jakob: you render the scene undistorted
Dr_Jakob: then read back that into a texture
Dr_Jakob: sample from that texture with distortion applied and write back to the target.
MostAwesomeDude: Hm.
dileX: colors look fine with lastest mesa GIT for xorg/st (resolution is smaller not 1280x1024), but good approach
Dr_Jakob: dileX: which hardware/server version?
logari81: is drm-next in 2.6.32RC1?
jcristau: logari81: that doesn't mean anything. drm-next is a branch, there's always new stuff in it.
logari81: jcristau: then what I should have asked is if 2.6.32RC1 includes the changes which last message in bug 24097 refer to.
dileX: Dr_Jakob: rv515, xorg-server 1.7.1 (ddx latest, libdrm-2.5.15, kernel linus-tree 2.6.32-rc5-git3 with latest drm-next)
dileX: (libdrm-2.4.15)
Dr_Jakob: ok
dileX: Dr_Jakob: logs, confs etc see
dileX: dmesg: [drm] LVDS-10: set mode 1024x768 2b
Dr_Jakob: ok, thanks for the info, I can't realy help but I was a bit interested in it.
mjg59: airlied: Well, I can hang this card equally well with and without pci_aspm=off
mjg59: airlied: (Radeon 3600)
mjg59: airlied: So, tbh, if aspm is making a difference even with the code you added, I suspect it's just a timing difference somewhere else in the stack
mokoloko: haha okay I've couple of times complained about latest devel distros freezing... Well it wasn't caused by radeon driver... It was caused by pulseaudio+audigy combination :D
mokoloko: I use onboard card but I've left audigy there because Im lazy and now after a nice "autumn clean" I decided to finally remove it
mokoloko: and everything works now even kwin effects although there are lots of small glitches under kde but they're probably known...
mokoloko: at least everything boots and workd
mokoloko: fracking pulseaudio :D
mjg59: There's no terribly plausible way that pulseaudio could freeze your system
Ghworg: Pulseaudio can expose bugs in the underlying ALSA driver
mokoloko: it always happend after it apparently loaded my usb audio logitech shizzle (dont use just came with keyboard and mouse combination and its integrated in their receiver)
mjg59: mokoloko: So, perhaps the issue was in the driver for the usb audio device?
mokoloko: first it apparently loads my integrated acl888 then usb audio and then audigy ---> freeze
mjg59: I'm still not sure how this makes it pulseaudio's fault, but still...
mokoloko: I don't think since there're no issues anymore after I removed audigy
mokoloko: I remember when once I tried to switch back to audigy and all I heard was loud "crackling" sound and computer froze
mokoloko: with fedora 11
mjg59: Well then
mjg59: Sounds like an audigy bug
mjg59: (and still not pulseaudio)
mokoloko: or maybe the card is just broken (been there while unused)... anyway things works now and thats the main thing :)
airlied: agd5f: so the SS patch seemed to cause a problem for AndrewR
mjg59: airlied: ^
airlied: mjg59: so how does aspm get affected by timing if its all hw level
mjg59: airlied: aspm will introduce latency at some point in the chain
mjg59: But given that I can wedge a card in the same way with aspm turned off, I don't think it's fundamentally aspm's fault
airlied: mjg59: its not the "same way" ;-)
airlied: since some people can only wedge the card with aspm on
airlied: all card wedges may look alike but generally aren't actually alike
mjg59: Well, given that I can wedge the card without aspm, I can't usefully reproduce
airlied: maybe my motherboard can't do aspm
airlied: as I can't wedge my card at all
mjg59: But the kernel looks like it does the right thing with that call, so I tend to think that it's not aspm's fault
mjg59: And instead that it's some timing-dependent thing
airlied: yes sounds sane
glisse: mjg59: r6xx docs says that changing the number of lane needs fully idle gpu
glisse: isn't what aspm about ?
mjg59: glisse: No
mjg59: glisse: aspm is putting the lanes into a different state, not reducing the number of them
mjg59: aspm's also controlled by hardware - the only role the OS has is in enabling it
airlied: I don't understand then why aspm off is still helping twoerner_
airlied: since I should have done the same thing with that patch
glisse: airlied: maybe the lockup is trigered by somethings else on the bus
agd5f: airlied: yeah, I posted that ss patch for feedback as I don't have any mobile atom cards at the moment
mjg59: airlied: There'll still potentially be latency elsewhere
glisse: btw i have yet no luck into reproducing X pattern usage which leads to corruption
airlied: agd5f: it works fine on my lvds, its seems to have broken a desktop card
glisse: i was wondering if Ben exa patch could helps here
airlied: mjg59: so what hw did you test with? mb/gpu?
agd5f: airlied: weird
mjg59: airlied: A 3600, Intel SDV
twoerner_: airlied: that is a good question
twoerner_: airlied: is there anything i can test?
airlied: twoerner_: keep checking aspm off helps going forward and I'll try and think abou tit some more
laska: airlied: i still have a bug with ttm on multiseat radeon configuration
laska: airlied: also i found an application that runs on 1st radeon videocard and touch second radeon card in multiseat configuration
airlied: laska: that is iwerd
airlied: probably do with mode switchingi though
airlied: X probably changes the mode on all screens or something crazy.
laska: something crazy i suppose
laska: i setup the system so that first X11 should not have access to second X11
laska: the problem with extreme tuxracer
laska: when it start on :0, it do mode switching or something similar
airlied: laska: can ou put conf/logs up?
agd5f: airlied: http://www.botchco.com/alex/xorg/0001-drm-radeon-kms-atom-force-disable-spread-spectrum.patch
agd5f: that might fix ss issues
laska: but also it do something strange with senond radeon card (it linked with :1), so that monitor becomes blank and write "signal out of range"
agd5f: airlied: did you see the patch from Mathias Fröhlich makeing atom card info per device rather than per module?
laska: airlied: i already post it: https://bugs.freedesktop.org/show_bug.cgi?id=24536
airlied: agd5f: no i missed that
airlied: not sure how its per module now
agd5f: airlied: it was a static global struct
airlied: ah fail
laska: airlied: 1st Xserver starts with "X0 :0 -novtswitch -layout Seat0" and second with "X1 :1 -novtswitch -sharevts -layout Seat1"
airlied: that might explain laska issue a bit
agd5f: yeah, that's what I was thinking
laska: airlied: agd5f: actually i have a small bonus from this bug
laska: after this bug my secong cards seems to initialize properly
airlied: I'll push that patch into linux-next and send to linus
laska: my second card is soft booted, and it looks like slightly incorrect -- i can't use 1280x1024@75 videomode
laska: it looks like two same images with little shift from each other
laska: but after etracer do something with 2-nd card, i can use 1280x1024@75 normally
laska: agd5f: can you point me to this patch?
spreeuw: http://www.botchco.com/alex/xorg/0001-drm-radeon-kms-atom-force-disable-spread-spectrum.patch
laska: spreeuw: i mean the patch from Mathias Fröhlich makeing atom card info per device rather than per module
agd5f: laska: I posted it to the dri-devel ML
laska: agd5f: thanks
agd5f: laska: http://www.botchco.com/alex/xorg/0001-drm-radeon-kms-atom-Make-card_info-per-device.patch
laska: thanks, i test it just now
LordVan: argh catalyst driver sux .. don'T support 5700 series only 5800
laska: airlied: agd5f: thanks for patch. It seems fix the problem with etracer second x-server
agd5f: laska: cool
laska: agd5f: unfortunately, it fix also backside effect when 1280x1024@75 on second radeon becomes usable
agd5f: laska: what mode should it be getting?
agd5f: laska: might try the other kms patches I posted to dri-devel today
laska: agd5f: it looks like posting problem. 1280x1024@60 works fine, on 1280x1024@75 the picture is garbaged (looks like two slightly shifted images)
laska: agd5f: but if the bios post my second radeon card, then 1280x1024@75 is usable
laska: agd5f: i apply your patches also
agd5f: laska: what two cards are you using?
laska: IGP Radeon HD 3300 and Radeon HD 4350
agd5f: laska: can you pastebin your dmesg?
laska: agd5f: shure. i upload a photo with 1280x1024@75
laska: agd5f: photo of a screen https://bugs.freedesktop.org/attachment.cgi?id=30759
laska: agd5f: http://pastebin.com/m2d633c47
agd5f: laska: can you dump the regs from the problematic card using avivotool in both the working and non-working states? avivotool regs all
laska: avivotool? where can i get it?
laska: working means booted by bios?
agd5f: laska: working and non-working 1280x1024@75
laska: agd5f: where can i get avivotool?
agd5f: laska: http://cgit.freedesktop.org/~airlied/radeontool
laska: agd5f: what videocards register avivotool will print? is it possible to specify it explicitly?
laska: agd5f: am not shure that it will print registers of second videocard
laska: agd5f: sorry, i found an option
laska: agd5f: done, how to send them to you?
agd5f: laska: alexdeucher AT gmail DOT com
laska: agd5f: sent
ajami: airlied, were you able to figure out the issue with the blank boot with -97 kernel?
airlied: ajami: yeah I think we narrowed it down
airlied: need to do a build with a few more patches in it
ajami: airlied, so me not booting is an x issue, not a kernel one?
airlied: ajami: no its a kernel bug alright
ajami: It's a kernel bug, then why was the bug component changed to xorg-x11-drv-ati?
ajami: airlied: ^^
airlied: ajami: because the kernel has too many bugs
airlied: so we blame graphics one on different people
ajami: airlied: lol ic
cxo: hey guys does Compiz work yet on HD4xxx cards?
chithead: cxo: yes, if you use kernel 2.6.32_rc1 and mesa from git
cxo: This is probably a stupid question, but I'm guessing its more stable than fglrx for just running compiz?
cxo: what should I be specifically building when I build 2.6.32?
chithead: radeon drm
cxo: so build 2.6.32, build mesa-git and obviously xf86-video-ati and then thats it?
biotube: and libdrm
chithead: libdrm-2.4.15 should be enough
cxo: Do i need to somehow disinfect my system of fglrx before hand?
chithead: yes, all traces of fglrx must be removed
chithead: especially kernel module and opengl libraries
biotube: installing mesa over it and a new kernel should do it, shouldn't it?
cxo: wouldnt building mesa replace the libgl stuff?
chithead: not necessarily
cxo: Ok then how do I do that then?
cxo: Its not like Ati left a nice uninstall script for me to use
cxo: and even if they did, it would probably not work
chithead: if you installed fglrx through your distro's package manager then you might be able to uninstall it that way too
soreau: cxo: If you installed fglrx manually, it may have left one in /usr/share/ati
cxo: ok i will check
cxo: hasnt built a kernel in a while
cxo: i think linus needs to separate linux into desktop, server and embedded or something, there is every driver under the sun in linux now
cxo: takes the short cut and uses ubuntu's kconfig
happycube: nah, that can be different defconfig's. :)
cxo: wonders why IBM Calgary IOMMU support is being built in by default
cxo: Should DRM be static?
biotube: probably not
chithead: if you want kernel modesetting, then compiling in drm will give you fast framebuffer console after boot
biotube: just remember to build in the firmware if you do
cxo: and the firmware is where?
biotube: i don't remember, but at the main menu hit the slash key and enter 'firmware' as your search term and it'll tell you
cxo: well i see the firmware section at the top level, nothing about radeon in there
cxo: you wouldn't know the symbol name would you?
cxo: Is agpgart still necessary for a pci-e card?
biotube: well, the symbols you're interested in are CONFIG_FIRMWARE_IN_KERNEL and CONFIG_PREVENT_FIRMWARE_BUILD
cxo: already had those,
cxo: I thought you guys were talking about something radeon specific in the kernel
biotube: do you have the second unset?
cxo: both are set
biotube: CONFIG_PREVENT_FIRMWARE_BUILD will STOP firmware from being built; unset it
cxo: ok
cxo: disable selinux!!!!!!
cxo: You know even if you build all the modules and bzimage, its less than 500mb, you wonder how Windows manages to get into 10s of Gbs and not support anything out of the box
biotube: to be fair, most of Windows's size is userspace trash
revx: um
revx: it's Vista on it's WinSxS - backwards compatability
revx: something Microsoft fights to keep
revx: long live free software and not having such ********
revx: :D
biotube: it's a poor design that requires gigs of libraries for backwards compat
revx: biotube: indeed, the size is 10+GiB in Vista Ultimate!
cxo: Did you hear Apple filed a patent for putting ads in the OS?
revx: that's... scary
MostAwesomeDude: I actually suggested to an MS VP that they use Wine for providing w32api compat.
soreau: cxo: *in* the OS?
cxo: I wonder if that was purely strategic or if they're actually going to do it
MostAwesomeDude: He was lukewarm on the idea, to say the least.
soreau: that is just insanity
soreau: MostAwesomeDude: lol
revx: MostAwesomeDude: Wine has trouble at best.. I can't even run LTSpice in it
chithead: they can use wine for win16 compat
cxo: soreau, http://www.tomshardware.com/news/apple-patents-advertising-mac-osx,8909.html
revx: (although I should be using F/OSS eda tools)
cxo: I can just see it now... 10yrs from now, all operating systems that come with new PCs are free, but have advertising built into them
cxo: scratch 10yrs, maybe like 3yrs instead
MostAwesomeDude: Right now.
MostAwesomeDude: Go check out Dell.
MostAwesomeDude: Or Gateway.
MostAwesomeDude: Or Apple.
MostAwesomeDude: They make machines, they absorb the cost of the OS, and then they fill it up with ads.
cxo: i know there is a lot of crappy default software, but Dell is still probably paying MS for each OS
cxo: pretty powerful stuff if you ask me, imagine service bulletins or something, every PC in the world gets the same message at the same time
biotube: "Big Brother Is Watching You"
biotube: "And Shouting In Your Ear"
cxo: bottles of Tide dish washing liquid and Ford cars running around on your desktop at all times
cxo: Everyone should just be made to take a Marketing class in school. This way everyone becomes cynical and just filters out advertising, reducing the ROI of all this online marketing and thus reducing its clutter on the web
biotube: you mena they aren't?
biotube: s/mena/mean/
cxo: well obviously people are making money from the ads, otherwise why are they still there
cxo: there is someone out there continuously clicking on the damn blinky banners
soreau: that is very true. I've always been extremely cynical ever since I can recall. I never could understand the people that can't understand the concept of 'to good to be true' and actually buy into needless products
MostAwesomeDude: Stupid doesn't really obey entropy or Brownian motion.
MostAwesomeDude: 99% of the stupid resides in 1% of the population.
soreau: I just don't understand why no one has invented a machine that is a washer and drier in one. Maybe they have, but I haven't heard of it yet
soreau: I wonder if you can get a patent without working out all the details :P
revx: soreau: because of severly conflicting goals in the parts
cxo: water and electrical heaters, not a good mix
revx: I used to live next to the world hq of whirlpool... all of my friend's parents being engineers there
biotube: although sideways washers make the goal more obtainable
soreau: revx: It was a rhetorical question really, leading to a potentially OT discussion
revx: trsut me, they were working on it, to no solution...
biotube: cxo: could work for a gas dryer
cxo: hmm gas dryer, interesting
revx: bricks will be shat by lg if whirlpool comes up with such a device
cxo: I read that if anyone does get all crazy like put adblock on as default into browsers, "they" are planning to inject the ads directly into your packet stream
MostAwesomeDude: SSL.
revx: MostAwesomeDude: I havn't been around much but I'm wondering: what parts of the driver are you playing with theese days?
soreau: Gallium 3D FTW! :)
soreau: Will there ever be GEM for radeon or is it already here? :P
revx: soreau: yes
biotube: it's ttm under the covers, isn't it?
revx: AFAIK it's already in the mainline kernel
soreau: The only reason I was asking is because the difference in the 'renderer' strings reported from glxinfo on intel and radeon
soreau: radeon reports DRI2 while intel reports GEM
MostAwesomeDude: revx: Gallium, mostly.
cxo: I was actually going to place an ad on kijiji for my HD4870 if you guys said compiz wasn't going to work, I've just had it with fglrx, i cant take it anymore. I'm so frustrated. I just see red!
soreau: cxo: Why wont compiz work?
chainsawbike: revx, the heating is not the hard bit - all you need is a way to get a good air flow thru it that is sealable and heat it pre-intake seal
cxo: fglrx has become really unstable of late, i cant even keep 24hours uptime anymore
soreau: cxo: I meant with the open driver
cxo: chainsawbike, microwave technology
cxo: soreau, oh i dont know, i was talking about fglrx, i came to ask if compiz worked with the oss driver, i'm building 2.6.32 now for it
soreau: cxo: It should work
soreau: Though I'd recommend drm-next kernel
revx: MostAwesomeDude: well anything more specific? :P
soreau: for that chipset
cxo: What is drm-next?
chainsawbike: cxo, mocrowave would do it yes... but its the sealing that will be the pain due to the heat and chemicals it needs to withstand
MostAwesomeDude: revx: Afraid not, sorry. :3
biotube: cxo: a separate kernel tree
revx: so you're all over then? :P
cxo: is it on kernel.org?
biotube: yes
biotube: but 2.6.32 should have a new enough version of it
soreau: cxo: See the wiki link in the topic
MostAwesomeDude: revx: More like, I'm nowhere. I need to finish the bits of r600g I've started, and get it all public.
eosie: MostAwesomeDude: do you wanna push a few patches of mine? ;) http://storm.unas.cz/eosie_patch_set.tar.gz
cxo: Do i need to rebuild X if I rebuild Mesa?
MostAwesomeDude: cxo: No.
MostAwesomeDude: eosie: Looking now.
revx: MostAwesomeDude: well keep on keeping on with the awesome work :)
MostAwesomeDude: eosie: First patch: Did I really miss that one? That definitely should be there, good catch.
MostAwesomeDude: revx: It's what I do.
eosie: yeah
cxo: sweeet android driver in 2.6.32rc5 breaks the build
cxo: dont they do build tests anymore?
cxo: can i just exclude all staging drivers?
cxo: or do i need some for radeon?
biotube: I'm pretty sure you need the option enabled for kms, but just disable everything but the KMS option
soreau: either way, you want to compile with kms support. you always have to option to disable it later for whatever reason
ajami: airlied, no pressure or anything, lol, when do you think KMS is going to work again for r6xx classic?
MostAwesomeDude: eosie: Blend fixups look mostly reasonable, although I'd appreciate having the non-optimized blends work, so I may split that patch.
MostAwesomeDude: eosie: 1D texture emit may or may not be right, I'll have to check with nha.
eosie: MostAwesomeDude: i've run piglit on these, the 1D texture emit is right
MostAwesomeDude: eosie: Are you on r5xx or r3xx? I think your DSA changes might hit a hardlock I discovered last time I worked on that stuff.
eosie: MostAwesomeDude: r5xx (RV530)
MostAwesomeDude: Hm.
rehabdoll: the 2.6.32-rc's really corrupted my ext4 /
rehabdoll: just a word of warning
eosie: MostAwesomeDude: running piglit and various mesa/progs all the time... hardlock on what gpus?
MostAwesomeDude: eosie: On my old x1950, the previously-commented-out r500-only regs caused hardlocks.
cxo: really?
cxo: has /home on ext4
eosie: MostAwesomeDude: even tried compiz, window borders renders correctly with the blending patch and despite the fact some effects are rendered incorrectly, it's usable
eosie: MostAwesomeDude: well so better comment them again :)
MostAwesomeDude: eosie: I'll test on my r4xx and see how close they get.
MostAwesomeDude: Might be nothing to worry about, might have been a problem somewhere else.
eosie: s/renders/render/
MostAwesomeDude: eosie: On the whole, these look reasonable; I'll push in a bit. I have to finish a few things before I can reboot and switch back to my r4xx. :3
MostAwesomeDude: (Shouldn't push w/o testing.)
eosie: ok
AndrewR: agd5f, no, patch 0001-drm-radeon-kms-atom-force-disable-spread-spectrum.patch doesn't help for my lockup.
airlied: AndrewR: reverting the ss patch from master helps?
airlied: just to reconfirm
AndrewR: airlied, one moment, re-testing this right now ....
cxo: In terms of performance, how long do y'all reckon radeon would take to catch up to fglrx in 3d acceleration?
airlied: cxo: never
biotube: fglrx DOES support OGL 3.0
airlied: in features probably years, in features + perf never ;-)
airlied: also some features may be subject to patentes
airlied: so maybe the first never was more accurate ;)
biotube: wishes software patents would hurry up and die
dmb: biotube, are you sure, because glxinfo says no
dmb: biotube, and i have thre 5770
biotube: dmb: well, i remember one of the releases announcing support for it
biotube: but I haven't used fglrx in months
dmb: OpenGL version string: 2.1.9016
biotube: (multiuser computer)
dmb: my only choice right now it to use fglrx :)
dmb: airlied, is 5770 coming after 58xx support?
dmb: modesetting
airlied: dmb: they sounds similiar
airlied: I've no idea though
dmb: airlied, do docs have to be released before anything gets started?
dmb: register guide
airlied: dmb: no AMD are writing support from what I know
airlied: but I don't know much about it other than Alex only got the hw
dmb: oh
dmb: biotube, yeah, i thought i read something about that also
dmb: biotube, on windows, it shows 2.something also
dmb: biotube, maybe it was just a beta driver or something
dmb: biotube, i don't know any games (or anything) that uses opengl 3 anyway
biotube: well, OGL 3 isn't that different from OGL 2.x anyway
biotube: just some extensions became core functions
biotube: or something like that
dmb: thats all that ogl is in the first place, a bunch of extensions, and a specication that says you must have this to be this version
eosie: however there is a functionality in GL3 that isn't in the older versions: ClearBuffer API
dmb: i think directx is different
biotube: well, technically only direct3d's comperable
AndrewR: airlied, reverting spread spectrum patch from your drm-next still helps. But one moment - may be there was wrong kernel image (i only install modules usually ...). Few more minutes please
eosie: by older versions, I mean as extensions possibly available in the older versions
AndrewR: airlied, double-checked - without spread spectrum patch I have no problem. With it (even with Alex's patch on top of it) - i have just black screen.
airlied: AndrewR: have you a second machine to ssh in from?
AndrewR: airlied, yes
airlied: if you do, can you boot with nomodeset on the command line to runlevel 3 (or without gdm)
airlied: then rmmod radeon, modprobe radeon modeset=1
airlied: and see if it lets you see dmesg
AndrewR: airlied, one moment
AndrewR: airlied, shold i test with Alex's patch, or just bare drm-next?
AndrewR: *should I
airlied: AndrewR: either or, whatever one dies
AndrewR: and how you guys test Cube2 (Sauerbraten), on r780 it gives me strange picture, levels without walls .. very hard to do anything ...
airlied: AndrewR: I expect the kernel is oopsing I just don't know where
AndrewR: airlied, hopefully i will give you dmesg soon ... even dual-core machine not infinite fast
AndrewR: on plus side - there was some corruption in mozilla under KDE4 (OpenGL compositing). Now I can't see any problem .. but may be it will return back after some time. (?)
AndrewR: may be something like videoram_show_free_space [command] was already written? (at least its nice to know when you hit low VRAM condition, no?)
airlied: mount debugfs
airlied: /sys/kernel/debug/dri/0/radeon_vram_mm
airlied: granted the used/free are backwards, I should fix that
Kano: hi, when will be hd 5 series supported?
AndrewR: airlied, total: 65536 ... for integrated RS780. and dmesg reported 256 MB VRAM ready ...
airlied: AndrewR: its in 4k pages
airlied: Kano: when its done
AndrewR: airlied, ah, thanks.
Kano: airlied: days, weeks or years?
AndrewR: so i have some 72 Mb free ....
AndrewR: airlied, may be you can document in on wiki? if this interface here to stay for some time ....
AndrewR: *it
airlied: Kano: all 3? until the code is published I don't know how long it'll be until it happens
airlied: then it'll be 0 since I'll know
airlied: AndrewR: yeah I should do once I fix it ;)
Kano: at least 2d
Kano: 3d does not interest me much on r800
Kano: but using vesa on highend cards is really bad
AndrewR: completely stupid question ... baut may be famous 'black elements on KDE4 panel' bug related to way compositor in OpenGL mode works? I maen, if it uses texture-as-pixmap, and at some time oixmap got evicted (?) from VRAM and GTT, so engine can't acces it anymore ... you get black texture ... or not?
airlied: AndrewR: with DRI2/KMS that can't happen, not really with DRI1 either in theory
AndrewR: airlied, so, it has something else as origin ... thanks, sorry for many typos in few words
Kano: airlied: would be defaulting to 1024x768 60 hz more usefull when ddc fails? you often get curious res like 1280x768 then
AndrewR: airlied, http://pastebin.com/m48ea3a1e (oops)
dmb: Kano, yeah, vesa on my 5770 is quite slow
dmb: doesn't vesa do some 16bit stuff?
AndrewR: airlied, ops, it was not all http://pastebin.com/m6b553755
airlied: Kano: if DDC fails it shuold only get 800x600
Kano: thats too low
airlied: AndrewR: excellent I can track it down
airlied: Kano: its also the won't blow up monitors resolution
Kano: i used 1024x768 75hz for years as fallback, nobody complained
MostAwesomeDude: Kano: Linus will complain. :3
airlied: I suspect your userbase to be a lot lower than mine
Kano: airlied: must be a joke
Kano: how many ppl have got 800x600 displays?
agd5f: Kano: lots of LCD monitors don't like > 60 hz
Kano: agd5f: i could live with 60hz default, but not 800x600
dmb: Kano, netbooks
Kano: dmb: you know 1 netbook with amd gfx card?
airlied: Kano: gateway noe
dmb: oh true
airlied: one
airlied: anyways its a default you can change it no the command line
airlied: or in xorg.conf
airlied: also its not a radeon decision
Kano: well as there is no xorg.conf by default
airlied: having per-driver default is pointless
airlied: anyways 800x600 will remain the default for broken hw, which mainly is projectors
airlied: and I have a few of those that fallover at 1024x768
MostAwesomeDude: Broken projectors *are* broken. :T
dmb: ugh
dmb: projectors are awful with different modes
dmb: i was doing a presentation in class that other day, and couldn't find a resolution that the projector would like
dmb: wound up doing 800x600
dmb: as awful as it looked
airlied: agd5f: any ideas on AndrewR backtrace?
agd5f: airlied: maybe some dereference in the list loop
agd5f: I see one bug
airlied: agd5f: where do you check its LVDS?
airlied: since enc_priv might not be dig
agd5f: args.usSpreadSpectrumPercentage = percentage; should be args.usSpreadSpectrumPercentage = cpu_to_le16(percentage);
agd5f: airlied: only lvds has dig->ss
airlied: yes but you cast it blindly
airlied: it could mean anything
airlied: once enc_priv contains anything dig->ss could be random
agd5f: yeah
agd5f: need to check active_device
agd5f: first
agd5f: ok, patch on the way
dmb: agd5f, are you able to reproduce that dvi issue with any other hardware? Because I just replaced the card with the 5770 (and it was not fund squeezing it in the case)
agd5f: dmb: I can't reproduce it here
dmb: if you post a patch, it may take a while for me to test then :P
agd5f: airlied, AndrewR: http://www.botchco.com/alex/xorg/0001-drm-radeon-kms-atom-fix-potential-oops-in-spread-sp.patch