Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

RadeonHD IRC Logs For 2009-6-23

Search This Log:

Nightwulf|work: hi all
ieatlint: i've got radeonhd 1.2.5 running on my laptop with an RS780M chip on an unrecognised card (hp laptop)... everything seems to work fine except xrandr orientation/rotate which simply reports that the only supported mode is "normal" -- any trick/or configuration that i might be missing?
yareckon: hi guys, using your code for the first time.... works great once I figured out that it doesn't work through my kvm
MostAwesomeDude: Your KVM probably doesn't forward EDIDs correctly.
yareckon: quick question that I couldn't figure out from the wiki: what is the timeline if any for video decode accel on the R6xx
yareckon: ?
yareckon: MostAwesomeDude, I think that is the issue.... will have to get a new one
MostAwesomeDude: yareckon: There's several types of video acceleration.
MostAwesomeDude: Xv, which is colorspace conversion and scaling, is done.
yareckon: hm... ok
MostAwesomeDude: XvMC and VDPAU, which are full offloading of video, can be done with Gallium3D (a software pipeline) or UVD2 (an onboard chip.)
MostAwesomeDude: Right now, AMD isn't likely to tell us how to use UVD2, so you'll have to wait until somebody writes the Gallium code for r600.
yareckon: ok, and there is some support for these techs currently in radeonhd?
MostAwesomeDude: Nope.
yareckon: ok, thanks
MostAwesomeDude: radeonhd has nothing to do with it; this will all happen in the 3D driver, which isn't part of radeondh.
MostAwesomeDude: *radeonhd, even.
yareckon: what is the name for the 3D driver for the radeon cards based on the latest specs released by AMD.
yareckon: thought this was the same project
yareckon: maybe have been reading too much phoronix ? :)
yareckon: Also, both tech's above run on the GPU right? Gallium will run video decode through a different set of chips on the card, but won't be able to use the UVD2 chip?
MostAwesomeDude: The 3D drivers are called r300 and r600, and they live in Mesa.
MostAwesomeDude: Gallium will use the 3D engine for video until I get UVD docs, at which point I'll try to move as much as I can to the UVD.
yareckon: ok...
MostAwesomeDude: Gallium also lives in the Mesa repository right now.
yareckon: alright, thanks for the full explanation...
MostAwesomeDude: No problem. :3
MostAwesomeDude: I really should write up a nice, big blog post explaining where Radeons are at right now,.
yareckon: I'd link to it ;)
yareckon: it's neat that you can offload the video decode to different part of the GPU even if you don't have the specs for the dedicated chip
yareckon: shows how flexible GPUs are becoming
MostAwesomeDude: Yeah, definitely.
yareckon: still an alphabet soup of tech though... even between vendors you have to learn a new set of acronyms
yareckon: thanks for all of your work, I'm certainly scrolling around better than 30 mins ago, when I hardly could resize a window without waiting for it to jerk into place
MostAwesomeDude: Heh.
MostAwesomeDude: Could be worse; "GPU" is almost certainly the 3D engine these days, but there's still a handful of other chips onboard that do graphics processing.
ieatlint: hey, i've got an issue with xrandr and screen rotation/orientation not being support (reports only "normal" is allowed) for my RS780M chip on radeonhd 1.2.5
ieatlint: there any known issues or the like?
yareckon: thanks MostAwesomeDude, I'll see you around..
Lippancs: What's the easiest way to go about writing R7xx shaders? I
MostAwesomeDude: In what context?
Lippancs: Do I have to hand code instructions using C macros or is there an assembler/compiler som sort?
MostAwesomeDude: Well, it depends on how you're communicating with the hardware.
Lippancs: I looked at the r600_demo code and got scared :)
MostAwesomeDude: Most people don't want to talk directly with the card; they should be using a library.
Lippancs: I want to do some gpgpu-like stuff, no graphics
MostAwesomeDude: Ah.
MostAwesomeDude: Which library?
Lippancs: I'd start with r600_demo first
MostAwesomeDude: Ah.
MostAwesomeDude: Well, you can use the r600 programming guide, and hack shaders into r600_demo, but that's *really* painful.
Lippancs: yep, that's what I thought
MostAwesomeDude: The typical GPGPU library hides the whole process of setting up the shaders, sending everything to the card, and retrieving your results.
MostAwesomeDude: And if we had any GPGPU libraries supported in open-source drivers right now, I'd recommend that. :3
MostAwesomeDude: Unfortunately, nobody's stepped up and written anything yet.
Lippancs: yeah, that's why I want to part with CAL
Lippancs: I'd like to do some hacking which I can't with CAL
MostAwesomeDude: Ah. Well, we have tons of documentation, but not really very many programmers.
MostAwesomeDude: Still a step up from having no docs and no programmers. :3
Lippancs: true
bridgman: there's a shader assembler/compiler in the 6xx/7xx 3d driver which seems to work; I'm a bit rusty on what it takes as inputs these days, but it should take mesa IL or arb_fp/vp as inputs and generate ready-ish-to-run outputs
MostAwesomeDude: This is true.
Lippancs: that sounds great
MostAwesomeDude: I'm looking forward to GPGPU through Gallium, but must admit that I know nothing about the various libraries.
bridgman: Richard thinks he found the "killer bug", btw... the new CS API in drm takes a buffer base and offset, then adds them to get the effective address
bridgman: unfortunately mesa was already adding the offset before we heard about CS doing it...
MostAwesomeDude: Ha! Yeah, that'd do it.
bridgman: and mesa was still doing it, so effective address = base + offset + offset
bridgman: boomski
MostAwesomeDude: is glad to see that others make his mistakes
bridgman: with a bit of luck things should return to normal once that is fixed
bridgman: and we can start working through the redbook tests at reasonable speed ;)
MostAwesomeDude: You should recommend the trivial tests before redbook; they're a bit easier. :3
bridgman: ahh, good to know
bridgman: Cooper likes ther redbook tests though ;)
MostAwesomeDude: r300g does about half of trivial, but very little of redbook.
MostAwesomeDude: So that's my rationale.
MostAwesomeDude: I really should fix more of the redbook ones.
bridgman: Lippancs; once we get arb_fp and textures running on the 6xx/7xx 3d driver you should be able to start doing some really easy compute stuff like that
bridgman: won't be fast but you'll be able to see what is happening
Lippancs: ok, thanks
bridgman: depending on complexity and timing, I guess you have a bunch of options from there;
bridgman: wait for opencl
bridgman: write shaders in tgsi and run them over gallium3d ('cause that'll be next on everyone's list)
bridgman: use the existing Stream tools that compile down to il and figure out how to translate il into tgsi or native shader ops
bridgman: or, the ever popular, go back to CAL ;)
Lippancs: bridgman: nice summary :)
bridgman: if you want to stay open source you're probably going to want to learn tgsi anyways
MostAwesomeDude: Gallium's like the flying car. Yes, it's the future. No, it doesn't just magically fly without a bunch of R&D.
Lippancs: opencl is pretty similar to CAL though and doesn't include opening up the shader compiler, does it?
bridgman: at least I don't have a 1960's copy of Popular Mechanics with Gallium3D on the cover ;)
MostAwesomeDude: (No, throwing the dev box out the window does not count as flight.)
bridgman: opencl would run over CAL, it's sorta one level higher
bridgman: opencl generates il, CAL runs il
MostAwesomeDude: Lippancs: The shaders are compiled into native language in software; it's not an open/closed sort of thing.
bridgman: yep, the open/closed part just goes with specific implementations
bridgman: the CAL and IL APIs are open, but we don't plan to release the actual shader compiler source to the public
bridgman: but il is just another intermediate language
MostAwesomeDude: Hm. Is IL not "intermediate language?" Something specific?
bridgman: sorry, il is what we call the intermediate language that feeds into our proprietary shader compiler
bridgman: so it's the "shader language" for CAL
MostAwesomeDude: Ooh.
bridgman: we thought Just Another Intermediate Language (JAIL) would be tacky
MostAwesomeDude: Just a bit.
Lippancs: what I meant is that with CAL I have no control over low level stuff like buffers' actual physical address - with the open source drivers I can do whatever I want.
bridgman: and Yet Another Intermediate Language would be hard to pronounce
MostAwesomeDude: Lippancs: Well, yes and no.
bridgman: is that actually useful from an app POV or just for debugging ?
Lippancs: So going through CAL is not an option for me ( I don't feel like reveres engineering CAL)
MostAwesomeDude: We probably won't be making available the ability to locate things arbitrarily in VRAM...
MostAwesomeDude: The kernel's memory manager will arbitrate access to the card.
MostAwesomeDude: You *could* hack it up as much as you want.
Lippancs: MostAwesomeDude: I know, but I can still hack the driver for my purposes
Lippancs: exactly
MostAwesomeDude: But the stuff that we'll be distributing is very much "push button, receive bacon."
bridgman: mmm, bacon
Lippancs: bridgman: i'm hungry too :)
bridgman: MAD does that when he's tired of talking
bridgman: mentions bacon and everyone leaves
MostAwesomeDude: I never get tired of talking. :3
bridgman: ;)
MostAwesomeDude: But yeah. You have your shader program, you give it to CUDA-Gallium or CTM-Gallium or OpenCL-Gallium, it compiles it, sends it to the card through libdrm.
MostAwesomeDude: libdrm and the kernel arbitrate what you can do to the card, so instead of exposing the really low-level stuff, it just returns a BO with the results.
MostAwesomeDude: Fairly simple, TBH.
Lippancs: bridgman: when saying "there's a shader assembler/compiler in the 6xx/7xx 3d driver" you meant agd5f's r6xx-r7xx-3d branch of drm?
MostAwesomeDude: Lippancs: r6xx-rewrite branch of mesa.
Lippancs: ok, thanks
bridgman: in src/mesa/drivers/dri/r600
bridgman: r700_assembler.c, r700_shaderinst.c, r700_shader.c, I think