Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2008-11-17

Search This Log:

airlied: spstarr: did you get EXA to crash yet? without composite?
spstarr: nope
spstarr: oh im trying..
airlied: so how long did it take previously?
spstarr: not very long, if i dragged a QGraphicsWidget based KDE plasma widget on the root desktop it would lockup instantly by moving it around a bit
spstarr: when i move that around now, it hasn't wedged yet
spstarr: or it would lock if loaded mplayer and watched a movie
spstarr: (just on the initial load of the window)
airlied: spstarr: so better than it was at least.
spstarr: airlied: definitely, in terms of stability
spstarr: one sure way I could crash EXA was killing plasma and restarting it causing a lot of full DFS calls
spstarr: im about to do that
airlied: spstarr: see if kms gets any better with that server :)
spstarr: will try in a bit
airlied: but hopefully that makes EXA on the agp r300s at least stable for now
spstarr: i will try in a bit, im fixing weather condition code ;)
airlied: spstarr: no hurry, I'm just happy if AGP gets a bit better by accident :)
spstarr: you say that, and you likely know it will ;)
spstarr: though the GPU reboots i had before might be unrelated to EXA blowing up? (or they might be)
airlied: well you can try the old server again see if it dies, then the new server.
spstarr: the old one dies :)
airlied: I'm guessing not doing operations for no good reason is a good plan.
ssieb: is there any way I could help with testing? I have a couple of computers with onboard RS690
ssieb: I also have an HD 2600 PRO, but with no computer to put it in at the moment :-)
ssieb: although I do plan on getting one in the near future
airlied: ssieb: mainly install things, see if they work, or crash etc.
zhasha: glisse, how do you get started writing for gallium. I can't find any documentation :/
glisse: zhasha: reading code
zhasha: I had a feeling that was it
zhasha: I suppose I should read softpipe then
glisse: i would suggest intel or nouveau driver
zhasha: i915 then?
glisse: yes or nouveau nv40
zhasha: I didn't think nv40 was considered stable?
glisse: zhasha: neither i915
glisse: nouveau is way more advanced than us :)
zhasha: oh, well then
zhasha: nouveau it is
zhasha: glisse, do you know what /srd/gallium/drivers/nouveau is for?
zhasha: src*
glisse: i think it's the winsys or common stuff for all nv driver
zhasha: how do you reverse engineer the proprietary drivers? do you have some magical decompiler or are you all just ASM wizards
glisse: we didn't decompile we spy what the driver sends to the card
glisse: basicly you draw a triangle in red
glisse: grab the cmd stream the driver sends to the card
glisse: draw a triangle in blue
glisse: grab the cmd stream the driver sends to the card
glisse: and compare the two to find where and how colors are routed
glisse: and you do that for every single gl functions
glisse: but now we docs for r300
glisse: have*
zhasha: how do you spy on it?
glisse: zhasha: look at tools like revenge
glisse: http://cgit.freedesktop.org/~z3ro/revenge/
glisse: or iba stuff too
glisse: as we are on linux we could also hack the kernel to be a middle man btw the card and the driver
zhasha: yeah that idea did strike me
zhasha: but the documentation they gave us, does that go unchanged for r500?
glisse: we have docs for r5xx too
glisse: all things are at x.org/docs/AMD/
zhasha: oh sweet.
glisse: their are also r6xx docs for shader informations
zhasha: I take it the instruction set for r5xx is different than that of r3xx?
zhasha: glisse, there's one thing I haven't found in my search for gallium knowledge, and that's whether we will be able to handle things like CrossFireX and SLI
glisse: well it's not a gallium issue
glisse: it's a driver issue
glisse: and there is different way to split rendering in crossfirex
glisse: so it's more about having a good design from the start to allow support of such functionalities
zhasha: Well, I should be getting my new PC today with an Intel card in it. Maybe I should try out Gallium3D on it :)
glisse: and r3xx & r5xx are very close in the way you program them
glisse: biggest diff is the frag prog
zhasha: glisse, the skeleton driver you wrote for gallium-0.1, is it still usable in gallium-0.2?
marcheu: zhasha: drivers/nouveau is the stuff that's common to all pipe driers, it's not the winsys
zhasha: should we adopt their layout and have a "radeon" and "r3xx" "r5xx" etc.?
glisse: zhasha: well we should have somethings like radeon and r3xx but no need for r5xx
glisse: we will have r6xx though
zhasha: glisse, will you be starting the gallium driver from scratch?
glisse: zhasha: i have bits somewhere on an hd
logari81: what is the status of old cards like ati rage 128, which project is responsible for them?
marcheu: trashbin.freedesktop.org
hifi: logari81: I got lockups with rage 128
oga: logari81: no one really cares about anything that's not nvidia, radeon or intel.
libv: what a sad, empty world this has become.
chithead: there is ongoing work with via, and smartmedia got a boost from mandriva and their loongson computer
chithead: s/smartmedia/siliconmotion/
spstarr_work: will test kms tonight im in the process of moving this week to my new place.
ohay: what's the difference between the the "radeon" and "ati" drivers ?
ohay: are they the free and restricted, respectively ?
bobbens: ati is a wrapper for the radeon, mach64 and others a believe
bobbens: s/ a / I /
ohay: what name appears on xorg.conf when using the restricted driver?
bobbens: by restricted you mean closed source?
jcristau: ohay: fglrx
ohay: yes
jcristau: restricted is the ubuntu newspeak for closed source
bobbens: weird
ohay: so what's the difference in using "ati" or "radeon" on the device section of xorg.conf ?
chithead: ohay: "ati" is a wrapper for radeon, r128 and mach64 drivers
stoned: pi got bit by something
stoned: it itches
ohay: ok, soory for the dumb question, but what's a wrapper ?
stoned: and I ran out of gold bond
stoned: ohay, dictionary.com
adamk: ohay, 'ati' just loads the correct open source driver for your video card.
stoned: ohay, it wraps around something inside it
adamk: ohay, There is no harm in using 'ati' or 'radeon' if your card is supported by the radeon driver.
stoned: ohay, like you can considr this example, .NET
ohay: oh, ok
agd5f: stoned: it just loads radeon or mach64 or r128 based on the pci id
stoned: .NET has wrappers I think in VB, C#, Ruby, blah blah
adamk: Or, correction, it loads the correct open source driver for your ATI video card.
stoned: same logic?
ohay: it's just that the system freezes sometimes when using X
stoned: ohay, it used to happen to me in fglrx
stoned: not in radeon and I have 3d working too
stoned: its fantastic its slow but free and good
ohay: and I haven't got any debuggin' codes
stoned: damn mosquito bite
stoned: itches
zhasha: ohay, Alt+PrtSc+R then go to vt1 and look at dmesg to figure out whats going on :)
ohay: first I was using Mandriva and xorg.conf used "ati". It ran every simple OpenGL feature like glxgears and even Compiz/Fusion on KDE4
ohay: but for some reason it started freezing
at-2500: good morning boys and girls. i'm having some kind of problem here with my omnibook vt 6200 // radeon mobility m6 ly. german anyone?
ohay: so I installed Ubuntu and it ran "radeon" and I didn't use any desktop effects, but it still froze
ohay: I'm using Radeon Mobility 7500 on a IBM T42 laptop. Has anyone else had problems with this chip ?
otaylor: ohay: Are you sure about that chip?
chithead: ohay: does the problem still occur if you disable direct rendering?
otaylor: ohay: I didn't know they made T42's with r200 graphics
adamk: The 7500 is r100.
ohay: looking at thinkwiki.org it seems the first models had the 7500 rv200 chips
at-2500: (if not, never mind) i installed kubuntu 8.04 using a live dvd. it only started in safe grafic mode using vesa driver // 800x600. i tried using the radeon driver but the best i got was a black screen with moveable mouse.
otaylor: ohay: Ah, the good old "change the innards, keep the model # the same" game
ohay: zhasha: I just ran glxgears it it froze again. I tried Alt+PrtSc+R and nothing happened
ohay: I'll just have to kick the power button harder this time
adamk: ohay, The locksups only happen when you run a 3D application?
ohay: actually no, the last time it happened while I was browsing the K menu
ohay: I'll try disabling the DRI extensions
adamk: How consistent are these lockups? Can you run *any* 3d apps?
ohay: previously on Mandriva I ran Compiz for a while, but after 2 days it started freezing on me
ohay: now on Ubuntu, glxgears is the first 3D app I used
adamk: Do you know if it's AGP?
ohay: I think it is, how do I check?
chithead: ohay: lspci should tell (run update-pciids if unknown devices are listed)
ohay: ok, there's ATI Radeon Mobility M7 LW (Radeon Mobility 7500)
ohay: on 01:00.0
ohay: is that where the AGP bus is?
chithead: yes that is agp
zhasha: ohay, Alt+PrtSc+R takes away control of the keyboard and returns it to the kernel. then you can switch VTs
ohay: so I should do this and then Ctrl+Alt+Fx ?
at-2500: okay, i've got this problem here with a radeon mobility m6 ly and kubuntu 8.04. if i try using the ati or radeon driver in xorg.conf, and restart x, i just get a black screen with a moveable mouse. help anyone?
adamk: I'm enjoying this KMS goodness in fedora 10 but I've run into a slight issue trying to get both monitors working.
airlied: adamk: that the 640x480 issue you mentioned?
adamk: kms sets them up properly, with my LCD at 1280x1024, and my CRT at 1600x1200. If I just start X without an xorg.conf file, I get cloned displays at 1280x1024. With this xorg.conf file, the CRT starts up at 1600x1200, but the LCD jumps to 1400x1050, even though KMS has it at 1280x1024 (which is correct): http://pastebin.ca/1259742
adamk: airlied, No, something new :-)
spstarr_work: looks at koji for goodies
spstarr_work: -113
airlied: adamk: does the preferred mode fix it?
airlied: adamk: when we have fully dynamic memory allocations we can make it work nicer.
spstarr_work: -48 DDX
adamk: Yes, it does correctly set it to 1280x1024... But switching between X and the console does act as if KMS isn't active (ie. that flicker that takes a few seconds)... Maybe it's just a matter of finding the same mode that kms is using and putting that in my xorg.conf file.
spstarr_work: hmm
adamk: Is there some way to find out what resolution and refresh rate is being used by kms, or even what modeline?
spstarr_work: airlied: did any of my sysprof info help you find any issues?
spstarr_work: regarding the sluggishness
airlied: adamk: good question :), should put it in sysfs somewhere.
airlied: spstarr_work: not yet.
spstarr_work: ok
spstarr_work: i will test kernel + DDX in 1 hour w/o KMS first (i need to get KDE code commited today is freeze for features :/)
spstarr_work: drm: make 800x600 be standard not 640x480 <-- this work let KMS work on the r1xx at 800x600 (it defaults to 640x480)
airlied: spstarr_work: yeah I wanted the same default a X uses.
spstarr_work: MODULE_PARM_DESC(vramzero, "Zero VRAM for new objects");
spstarr_work: hmm
airlied: spstarr_work: big dirty workaround
spstarr_work: so the code before was zeroing out the VRAM ?
spstarr_work: and now its disabled unless turned on by kernel opt
airlied: for some reason it was causing blank lines of text randomly
airlied: I'm hoping that "fixes" it.
adamk: Woohoo, figured it out.
adamk: I started X without an xorg.conf and it used the kms mode. I grabbed the modeline info with xvidtune and dropped that into my xorg.conf file.
adamk: Now I have nice fast switching from X to tty and back.
airlied: adamk: nice.
adamk: Well, till xfce4 kicked in and decided to adjust the resolution based on what I once set in "Display Preferences"
adamk: Argh.
adamk: rm .config/xfce4/mcs_settings/display.xml :-)
spstarr_work: limit VRAM use to 90% hmmm
spstarr_work: will try all these things maybe sooner, my boss left and im gonna skip outta here too ;)
spstarr_work: somehow
adamk: Ahhhh, and now, after doing the same thing with the other monitor, I could spend all day just switching back and forth from tty to X :-)
aneas: does the radeon driver support vertex/fragment shaders on r500? or is this none of its business?
airlied: aneas: the mesa driver does it.
MostAwesomeDude: aneas: Mesa r300 driver does support custom shaders, yes.
aneas: i hope thats exactly what i need, lets try brb :)
aneas: damn :(
aneas: just GL_ARB_{fragment,vertex}_program extensions. no GL_ARB_{fragment,vertex}_shader
aneas: :C
aneas: i _really_ need this. is there a way to use mesa software rendering for a single program? like an env var or something
jcristau: aneas: LIBGL_ALWAYS_SOFTWARE=1
aneas: oh boy, sometimes the truth just hits you in the face :D
aneas: thx!
spstarr: ouch airlied
spstarr: its very very sluggish with KMS on.. profiling....
spstarr: offscreen pixmaps
spstarr: worse offenders:
spstarr: memmove() 14.97
spstarr: fbCompositeSrc_8888x8888sse2 14.20
spstarr: fbCompositeSolidMask_nx8888x8888Csse2 4.03
spstarr: Offenders in RADEONDownloadFromScreenCP:
spstarr: memmove() itself
spstarr: airlied: EXA composite is on, Xcomposite is off
spstarr: Xorg.log:
spstarr: 1408 x 1050 x 4 = 5808K
spstarr: texture size is 21024K, exa is 21024K
spstarr: fb size is 5808K 17456K
spstarr: Add fb id 13 1400 1056
spstarr: II) RADEON(0): Remaining VRAM size (used for pixmaps): 21024K
zhasha: holy carp. 15 seconds for memmove?
spstarr: zhasha: yeah its hurting bad
spstarr: moving windows is fine, its redrawing their contents that is slow as hell
spstarr: oh
spstarr: (**) RADEON(0): Option "EXANoComposite" "true"
spstarr: (**) RADEON(0): EXA: Disabling Composite operation (RENDER acceleration)
spstarr: (
spstarr: tee hee..brb
zhasha: that would fall in the category of offscreen rendering correct?
spstarr: I thought i commented that out
spstarr: brb
spstarr_desk: hmm
spstarr_desk: X crashes now
spstarr_desk: with EXA composite on
spstarr_desk: getting crash dump
spstarr_desk: DRM Command submission failure -12
spstarr_desk: Fatal server error:
spstarr_desk: DRM Command submission failure -12
spstarr_desk: gdb attaching X...
spstarr_desk: Program exited with code 01.
spstarr_desk: oh man X just crashes and there's no way to get at it
spstarr_desk: Interrupt enable: 02000001
spstarr_desk: Interrupts received: 136307
spstarr_desk: Current sequence: 90888 90888
spstarr_desk: Counter sequence: 90888
spstarr_desk: CS: 50383
spstarr_desk: RADEON_CP_RB_WPTR 0002f460
spstarr_desk: RADEON_CP_RB_RPTR 0002f460
spstarr_desk: goes back to non KMS
airlied: wierd kms crashed with that?
airlied: anything in dmesg?
spstarr_desk: looking
spstarr_desk: lemme check backlog dmesg laptop is rebooting
spstarr_desk: ERRORs:
spstarr_desk: Nov 17 18:52:21 segfault kernel: [ 617.618014] [drm:drm_buffer_object_validate] *ERROR* Failed moving buffer. e3d81000 1444 4000027 2000020
spstarr_desk: Nov 17 18:52:21 segfault kernel: [ 617.618014] [drm:drm_buffer_object_validate] *ERROR* Out of aperture space or DRM memory quota.
spstarr_desk: Nov 17 18:57:29 segfault kernel: [ 925.617011] [drm] LVDS-10: set mode b
spstarr_desk: Nov 17 18:57:29 segfault kernel: [ 925.617011] [drm] bios LVDS_GEN_CNTL: 0x30ff24
spstarr_desk: ( shutdown itself <---)
airlied: nuts..
spstarr_desk: not using the aperture?
spstarr_desk: (i dont know the default it uses the bios doesnt let me adjust it0
airlied: ran out of RAM, clearly not a winning solution
spstarr_desk: ouch
airlied: VRAM even
spstarr_desk: it alloc'd all 64MB of it that fast?
spstarr_desk: Xorg Log:
airlied: well 21mb was left over for pixmaps.
airlied: the server shouldn't send that many things to the driver that it fills.
spstarr_desk: 1408 x 1050 x 4 = 5808K
spstarr_desk: texture size is 21024K, exa is 21024K
spstarr_desk: fb size is 5808K 17456K
spstarr_desk: Add fb id 13 1400 1056
spstarr_desk: (II) RADEON(0): Front buffer size: 5808K at 0x01144000
spstarr_desk: (II) RADEON(0): Back buffer size: 5808K at 0x005ec000
spstarr_desk: (II) RADEON(0): Depth buffer size: 5808K at 0x00b98000
spstarr_desk: (II) RADEON(0): Texture size: 21024K at 0x016f0000
spstarr_desk: (II) RADEON(0): Remaining VRAM size (used for pixmaps): 21024K
spstarr_desk: 1408(?) 1400x1050 ithought
airlied: its sending something to the card it can't fit in the remaining vram.
airlied: spstarr_desk: rounding
spstarr_desk: ok
airlied: or alignment more technically
spstarr_desk: it worked when i used EXANoComposite
spstarr_desk: it booted but was sluggish
airlied: yeah not using hw for anything not a good plan
spstarr_desk: hmm
spstarr_desk: going to laptop.. testing non KMS + EXA with exacomp on..
spstarr: apparently the sysprof yesterday was EXANoComposite ;p
spstarr: no wonder...
airlied: that would explain a lot.
spstarr: X redrawing xchat isn't as bad now at all
spstarr: the delay is a lot, lot less, probably normal
spstarr: now to try to crash this
zhasha: to get kms, would i have to grab 2.6.28?
spstarr: man, that's smooooth
airlied: zhasha: no.
zhasha: can it be compiled as a module?
spstarr: airlied: your exa fixes really seemed to have fixed these issues
spstarr: will try to lock it up though then try with XComposite on
airlied: zhasha: kinda... against 2.6.28 tree I think
airlied: I think the modesetting-gem branch of drm git works, but really its a bit all over the place at the moment unless you are using Fedora.
airlied: as upstream changed some APIs and I haven't had time to re-do my trees.
glisse: airlied: i will change back to remove start/end offset :)
glisse: tomorrow
glisse: now zzzzZZZZzzz
glisse: :)
spstarr: profiles xchat refresh
airlied: glisse: more the kms changes :)
spstarr: airlied: the biggest offender is pixmap_region_substractO
glisse: oh yeah too many bits changes here and their :)
zhasha: meh, too much work for too little gain. ill just wait till its final
spstarr: at 12.50
glisse: i need to ask krh what i should pick as front buffer too
spstarr: not sure what that routine does
airlied: glisse: he's travelling for a couple of days
glisse: i will try to find out from spec and code then
spstarr: airlied: I still see this but kms didnt lock on rebooting
spstarr: Nov 17 18:57:33 segfault kernel: [ 927.715013] handlers:
spstarr: Nov 17 18:57:33 segfault kernel: [ 927.715013] [] (acpi_irq+0x0/0x23)
spstarr: Nov 17 18:57:33 segfault kernel: [ 927.715013] [] (usb_hcd_irq+0x0/0xa3)
spstarr: Nov 17 18:57:33 segfault kernel: [ 927.715013] [] (radeon_driver_irq_handler+0x0/0x135 [radeon])
spstarr: Nov 17 18:57:33 segfault kernel: [ 927.715013] Disabling IRQ #9
spstarr: but dont think its radeon
MostAwesomeDude: glisse: I know I haven't been around much; are you really getting started on r300 in Gallium?
airlied: MostAwesomeDude: he's planning on it
MostAwesomeDude: Hm. I'm in too.
spstarr_coding: may the best win (DRI2 vs Gallium) :)
MostAwesomeDude: It's not a war!
airlied: wonders how glisse fights himsel
spstarr_coding: i mean the two competing approaches right now
airlied: approaches to what?
rx__: looks around the channel
rx__: waves the radeonhd flag
spstarr_coding: with the two directions DRI2 is going and Gallium3D will go
airlied: spstarr_coding: they aren't two directions
airlied: they are just not related at all.
soreau: compiles radeonhd with non standard flags
spstarr_coding: DRI2 will be sooner :)
airlied: remember what I said about using words you don't understand to make sentences that make no sense?
airlied: you are doing that again.
airlied: DRI2 and gallium3d are not competing anything, they are completely different things.
soreau: I haven't been around much either.. what is the core purpose or goal of gallium?
airlied: soreau: to provide a new framework for 3D GPU drivers, that is portable across OSes and rendering interfaces.
rx__: it's the new mesa
MostAwesomeDude: Frontends + Backends
soreau: And is there a way to bug gatos for 1024x768 tv-out code(s)?
airlied: so you have a single core 3D driver that gets reused under OpenGL/DX10 on Linux/Windows.
airlied: soreau: I don't thnk gatos exists anymore.
airlied: it also abstracts the GL state machine from the driver a lot better.
soreau: airlied: Is this to say open radeon drivers?
rx__: MostAwesomeDude; have you tried the new fglrx? =p
soreau: rx__: I am currently running the 'new' fglrx
MostAwesomeDude: rx__: No, had to help run a conference over the weekend.
soreau: It's the same old problems, now with a new version!
airlied: soreau: it could in theory be used if a DX10 gallium interface is published.
soreau: airlied: That sounds kinda windowsish to me
rx__: MostAwesomeDude; booooo
airlied: soreau: but mainly it allows for a cleaner driver interface on Linux to hw with shaders.
soreau: airlied: So what's the point of it being portable across os's? I know I'm being ignorant here ;)
MostAwesomeDude: soreau:
MostAwesomeDude: Ack, stupid keyboard.
soreau: lol
soreau: Blame the hw!
airlied: soreau: so TG can do one driver and sell it across more OSes.
MostAwesomeDude: soreau: It means that ymanton's XvMC code could magically work on r300 and i965 because it doesn't do anything HW-specific.
soreau: airlied: TG?
airlied: soreau: Tungsten Graphics the people who write mesa mostly.
soreau: MostAwesomeDude: Ahh
soreau: Oh
RTFM_FTW: other *NIXes I assume?
airlied: nope other Windows OS.
RTFM_FTW: somehow I doubt that Microsoft is going to do that
RTFM_FTW: unless I'm missing something here :D
RTFM_FTW: (which is likely)
airlied: RTFM_FTW: TG do it.
airlied: the drivers just talk to the DirectX driver model
RTFM_FTW: I'm still not at all seeing the point
RTFM_FTW: since the IHVs have a fully functional, closed source D3D runtime
airlied: some might not, for embedded markets
RTFM_FTW: along with a OpenGL (ES, non-ES) runtime as well
airlied: TG write drivers for IHVs
RTFM_FTW: ah embedded
RTFM_FTW: I *could* see some possible use there
RTFM_FTW: although many of the embedded vendors just write their own driver stack :D
airlied: RTFM_FTW: or contract it out.
airlied: TG obviously have customers for the idea :)
RTFM_FTW: meh the one I deal with does that in house :D
RTFM_FTW: in any case there might be others who don't have internal team(s) available to do that
airlied: RTFM_FTW: some customers of some embedded chipset don't like the in-house drivers :)
RTFM_FTW: too bad for them
RTFM_FTW: heh in any case I'm clearly biased towards a certain vendor :P
MostAwesomeDude: IMO the Wine guys should port their D3D to Gallium.
robokopp: hm what could they achieve?
airlied: native D3D instead of D#D->GL translation
robokopp: hm sounds great :), would that be a performance advantage or rather a compatibilty one?
robokopp: or i mean, ease of programming
RTFM_FTW: well the D3D -> GL translation shouldn't be too bad as time goes on and more GL extensions are added
RTFM_FTW: since (for the most part) the mapping between D3D[N] and GL[N] for a given version are quite close
robokopp: ah ok
RTFM_FTW: as much of the D3D10+ functionality has been implemented via GL extensions or (to some extent) GL core
RTFM_FTW: EXT_texture_integer, EXT_gpu_shader4, EXT_geometry_shader, ... are examples of that
RTFM_FTW: or GL 3.0 for that matter
robokopp: ok
MostAwesomeDude: robokopp: In short, yes, both.
MostAwesomeDude: It would help performance and also compatibility.
razboinik: i followed directions on http://www.x.org/wiki/radeonhd:DRI, im using intrepid, but when running the autogen for radeonhd get dri disabled
razboinik: i tried --enable-dri
razboinik: i also installed from git xextproto, pixman, xproto, dri2proto
razboinik: but nothing
razboinik: well the only thing i didnt rebuild was the xserver. im not on x64 so it says is not neccesary
MostAwesomeDude: razboinik: Wrong channel.
razboinik: mostawe: where should i go?
spstarr_coding: #radeonhd :)
razboinik: asked the same nobody replied :P
airlied: does radeon work? if so then its not this channels problem
razboinik: found problem xf86driproto-dev missing
spstarr_coding: airlied: flash videos not corrupt anymore
spstarr_coding: w/o kms
airlied: spstarr_coding: nice.