Nightwulf|work: hi all
fudje: hey
yangman: uuuuuuuuuuuugh
yangman: rebooting fixed my issue
yangman: apparently I somehow managed to get the card into a bad state
nanonyme: yangman: Sounds more like Windows to me.
yangman: or not...
yangman: ugh
Zajec: exoerienced that yesterday after switching from radeon to radeonhd :) hard lock up
nanonyme: Zajec: If the states between radeon and radeonhd are *that* different, there *really* is a problem with having two such separate opensource drivers with different codebase. :P
Camoeba: yangman: lol
airlied: switching drivers always is busted.
airlied: you've no idea where you are reiniting from.
Zajec: there should be simple RST input on GPU :)
Toksyuryel: nanonyme: it's not something I see ever changing. there's always gonna be some people who don't like atombios and some of them will be able to code drivers
nanonyme: Toksyuryel: Doesn't everyone use atombios anyway now?
nanonyme: Moot point.
Toksyuryel: afaik this project does not
airlied: Toksyuryel: yse it does
Toksyuryel: hm
Zajec: airlied: not for everything
airlied: for any digital outputs on any of the r6xx.
nanonyme: Toksyuryel: The public story is that it changed due to pressure from ATi.
airlied: Zajec: and the advantages for the end user aer?
Toksyuryel: on paper support for new hardware faster
nanonyme: Zajec: Wasn't the point mostly that ready code wasn't dumped but new stuff should be made using atombios?
Zajec: airlied: most won't see difference... just in my case using ppl from Atombios make me unable to switch to console from X
Toksyuryel: WHAT
Toksyuryel: now hates atombios. immensely.
airlied: Zajec: wierd, it works on radeon, so I suspect bad coding
nanonyme: Do radeon and radeonhd use the same atombios parser?
airlied: granted atombios isn't designed to go to text mode, most OSes that gpus are designed for never re-enter text mode
airlied: so its hardly top of their list of things.
airlied: nanonyme: mostly, radeon has had some work done for powerpc.
airlied: that I don't think ever got ported.
Zajec: airlied: hm, i didn't thought radeon may work for me... just tested with with radeonhd by adding Option "AtomBIOS" "pll=on"
nanonyme: Right, that's a bit odd then that they behave different.
Toksyuryel: for many purposes a full-blown windowing system isn't really needed.
airlied: nanonyme: we don't use atombios to get back to text mode
Toksyuryel: a lot of X applications never spawn more than one window
nanonyme: Ah, right.
airlied: as I said no other OS requires it.
airlied: we simply just backup a load of register state and pray it works
wenchien: ah
Zajec: wow... thought it's more complex
wenchien: for the atombios, i have a question about src/rhd_atombios.c :P
nanonyme: airlied: Has *that* behaviour been checked to work the same way in both drivers?
airlied: with accel we of course shut down the accelerator engine.
Zajec: and there actually exists some specified way of switching to text
airlied: nanonyme: not that I know off I only deal with it on radeon
nanonyme: Right.
airlied: Zajec: you can program a text mode buts its messy, and X sorta dictates you go back to what was there.
airlied: not text mode.
wenchien: i have a multiseat setup, with two radeonhd, and both X try to get the atom bios from legacyBIOSLocation...
nanonyme: So much for the benefits of two projects and ability to share code. ;)
Zajec: shocked me with that "news" :)
airlied: wenchien: try radeon see if it does it different, it worked the last time i played
Toksyuryel: two projects only works if they are in some kind of competition
Toksyuryel: and have a reason to keep one-upping eachother
wenchien: airlied: i modified radeonhd to force the second card read the bios from pci/rom
nanonyme: Toksyuryel: There is one such, the major problem is that it harms end users.
Toksyuryel: I think that, if atombios is being used now, merging back into one project is the right thing to do
wenchien: airlied: so i'm curious about that
Toksyuryel: but I'm a bit torn really
Toksyuryel: the name radeonhd sounds cooler
nanonyme: Afaik merging is impossible on short-term, there's too many differences in the codebase.
wenchien: airlied: why didn't we try to read the bios from pci/rom first, and use legacyBIOSLocation as a fallback?
Toksyuryel: obviously it can't happen overnight
airlied: wenchien: I've no idae I dont' work on radeonhd
Toksyuryel: but if there is no longer a reason to be seperate, plans should be made at least
airlied: I just know radeon does it right for me.
airlied: Toksyuryel: there isn't a major amount of code to merge, like if radeon wanted two separate modesetting paths for analog and older digital outptus we'd port it.
Toksyuryel: but I think that if they don't change the name to radeonhd, they can just **** off and keep the projects seperate <3
airlied: but really I have to ask what my users want, and they don't care
wenchien: airlied: i'll try radeon tonight when i'm home. thanks. :)
airlied: but kms makes the point moot and thats where i'm heading
airlied: really if all the DDX does is acceleration and both drivers have quite similiar accel code then whats the point in both existing.
Toksyuryel: simple- this one is called radeonhd.
Toksyuryel: thus it is cooler
Toksyuryel: and then there's novell
Toksyuryel: this driver has a lot of things going for it <3
airlied: why does it matter who writes it?
nanonyme: Well, technically the progression mightn't get any faster with only one driver anyway. Would likely end up with there being one git tree with all current radeonhd stuff as branches. :)
Toksyuryel: ugh, not git >.<
nanonyme: Toksyuryel: They both use git anyway. :P
Toksyuryel: too many people using git :(
MostAwesomeDude: Toksyuryel: What's wrong with git?
Toksyuryel: very clunky and hard to use, and the hashed filenames are really annoying
MostAwesomeDude: What do you think of, say, Subversion?
nanonyme: Awful for big projects with a lot of devs. :)
Toksyuryel: worse
MostAwesomeDude: Well, there ya go.
wenchien: airlied: if i use radeon, do i need the drm modules in the git tree as the radeonhd do?
MostAwesomeDude: I mean, I don't think there's anything better than git, and actually I've come to like it.
Toksyuryel: MostAwesomeDude: bzr is better
wenchien: airlied: or the drm modules in 2.6.28 is just fine
wenchien: ?
Toksyuryel: mercurial probably is better too
airlied: wenchien: same drm modules for radeon/radeonhd
Zajec: wenchien: you need drm modules from git for r6xx/r7xx
MostAwesomeDude: Toksyuryel: 'k. Good luck convincing Linus to switch. :3
Toksyuryel: I don't care if linus switches
Toksyuryel: he's the one writting git so he's kind of invested into it anyway
airlied: Toksyuryel: bzr is slow
airlied: very sllooowww..
nanonyme: Good luck getting the rest of the kernel developers to switch without Linus. ;)
wenchien: use the one in r6xx-r7xx branch?
airlied: wenchien: yup, radeon also has a branch for accel.
Toksyuryel: radeonhd is an in-kernel project?
MostAwesomeDude: Toksyuryel: Anyway, git was written *because* no kernel devs really had a fondness for the other DRCS systems.
MostAwesomeDude: And fd.o just all uses git now. That's life.
Zajec: Toksyuryel: radeonhd is just a DDX driver... just like radeon
nanonyme: Toksyuryel: Well, the mesa/drm part goes in kernel.
Toksyuryel: still likes bzr, it's easy to use
nanonyme: Imo makes sense the developers don't need to use several version control systems.
Toksyuryel: well I didn't know this was a kerneldev project, so nvm :(
airlied: its not.
airlied: only the drm bits are.
yangman: omg
yangman: it was an alignment issue with the shader stream
yangman: I'll finish it up tomorrow morning. need sleep
arkascha: the ordinary radoen driver gives me a massive better compiz performance than radeonhd. Using openSUSE-11.1 @ ATI R5x. Is that normal ? I expected the other way around ?!?
Zajec: should be similar as both use the same DRM and Mesa
arkascha: Zajec: maybe some options are missing for me ? Do I have to enable DRM different from the radeon driver ?
loki_666_: yesterday i tried radeon driver on my rs780, i had a very weird issue while playing video with XV: with both mplayer an mythtv internal player, video are playing at maximum speed (regardelss of the video fps)
loki_666_: but not with xine
loki_666_: with radeonhd driver it's working fine
loki_666_: anyone experienced this before?
Zajec: arkascha: no, just changing "Driver" in xorg.conf should be enought
Zajec: for both you need to add "Option" "DRI" and I belive you have that already
nanonyme: Zajec: Plus choosing exa?
nanonyme: Oh, right. rs5xx. Then not. :) Read that later chipset.
arkascha: Zajec: ok, that's what I did. Fact is that radeon is faster. Strange.
loki_666_: i dont understand, why the DDX needs to do "something" to enable audio ouput on hdmi? why can't be just like for any other sound card?
loki_666_: why the alsa driver alone is not enough?
Zajec: loki_666_: driver has to attach sound to some output (DVI-D_1 for example) and set clocks values
Zajec: there are two pairs of clock registers: multiplying and dividing
Zajec: for details you can ask Christian Konig
loki_666_: ah ok
nanonyme: Zajec: Btw, is ALSA used at all in HDMI audio?
nanonyme: Since surely it's not going through the card. (Which mixer does the mixing?)
Zajec: nanonyme: yes, alsa is needed
nanonyme: Hmm.
Zajec: it detects audio "engine" on GPU and transferrs sound to it
nanonyme: Right... So should alsamixer be detecting some audio channels in the audio "engine" in the GPU?
Zajec: yes
nanonyme: Right, then I get how it works. :)
Zajec: alsamixer -c 1
Zajec: you can usually only (de)mute GPU audio channel/mixer (don't know right word)
nanonyme: For me that gives "rong -c argument '1'". Either the syntax is wrong or I don't have support.
Zajec: or your card doesn't have audio engine... hm
Zajec: did you try aplay -l ?
nanonyme: Well, I don't even have a monitor which could play the sounds. :P
nanonyme: I was just checking on the mixing.
nanonyme: alsamixer without any arguments does show several HD channels though.
Zajec: alsamixed and aplay should show ATI HDMI device anyway
nanonyme: Argh, I'm just being an idiot.
nanonyme: Forget the previous.
Zajec: ? :P
nanonyme: Remind me to recheck when I actually get the card back from maintenance? :D
Zajec: ;)
nanonyme: But yeah, so it's shown as yet another sound card to ALSA then.
nanonyme: Meaning you probably have to change audio output to that in programs.
Zajec: yeah, smplayer supports this great :)
nanonyme: I suspect all decent ones do. Audacious seems to have the functionality required but I can't really test.
Zajec: nanonyme: http://files.zajec.net/blog/smplayer.audio.alsa.devices.png :)
nanonyme: There's an option "Mixer card" which you choose the device with.
nanonyme: Aight.
nanonyme: Zajec: So... If you'd want the sound to play on *both* cards, you'd need an extra audio abstraction layer?
Zajec: didn't google for that :)
nanonyme: It'd seem like a logical conclusion to me anyway. That is, the extra layer would forward audio to both cards.
Honk: pulseaudio can do that
nanonyme: It is one good example of sound abstraction, yes.
Honk: and you can tell alsa to use pa as default device :]
Honk: so it's easy to make all programs use it
Honk: nanonyme: "one example"? last time I checked pa was the only one that could do it *g*
Honk: though it's been a while *shrug*
nanonyme: Honk: JACK can't do it?
Honk:
nanonyme: Honk: JACK is much older than PA. :P
Honk: a few years ago I couldnt find a way to do it with jack
nanonyme: Ah, right.
Honk: or arts or any of the other well known audio deamons :]
nanonyme: Well, I dunno. I don't yet need the behaviour, I hope we'll get rid of the problems in PA before I feel the need to migrate.
nanonyme: It's quite clear there are situations where PA either needs to do full sound card virtualization or give the program access to the actual hardware.
nanonyme: (Like say, OpenAL+EAX)
Honk: I never worried about that stuff :)
Honk: I'm quite ok with stereo
nanonyme: It's not just about that. ;) PA as is kills the possibility to use support for environmental sound in games afaik. ^^
nanonyme: Means no sane gamer would ever want PA.
nanonyme: (At least unless the problem is fixed)
Honk: that's pretty much the same though, you dont really need eax for stereo :P
nanonyme: Stereo as in stereo against mono?
nanonyme: Yes, you do.
Honk: euhh, apps seemed to work fine when I used my onboard sound card that doesnt even support eax :]
nanonyme: It's not just working fine, it's about that eg your footsteps sound just the right when you move from one room to another.
nanonyme: I think that can even mean seamless changes in EAX2.
Honk: that's what I keep saying: I'm fine with simple stereo sound :]
loki_666_: does anyone use hdmi on rs780?
loki_666_: i'm still having issues when trying to add custom modelines with xrandr
nanonyme: bridgman: Hrm, started wondering: it's probably the third-party guys who take care of the warranty repairs (in my case Asus), not AMD/ATi, right? (Oh, and hi)
bridgman: absolutely; we just ship them containerloads of chips
bridgman: and hi ;)
nanonyme: Right. Hope those guys know what they're doing so I'm back in testing the driver soon.
bridgman: actually you're better off if they don't know what they are doing, toss the board and give you another one (rather than trying to diagnose and fix it) ;)
nanonyme: bridgman: Americans. *rolleyes* I'd much prefer the more eco-friendly solution as in them sending me a completely new card immediately, putting the card away for diagnostics, fixing it, then reselling it.
nanonyme: People are much too accustomed to it being cheaper to produce a new device than fix the old. :P
bridgman: I agree completely; I recycle pretty much everything (or use it to light my masonry heater) but I still cringe even at the amount of packaging I recycle
bridgman: then again, you try desoldering a 1200-pin BGA then come back and talk to me about repair ;)
nanonyme: :D
nanonyme: bridgman: It's all about money. If the card price goes up enough, eventually you find a guy who wants to do the repair for the money you two can agree on.
bridgman: agreed; it's the same with cars, but the price keeps going down and our used car lots keep growing
nanonyme: bridgman: As you said yourself, we're running out of the cheap countries.
nanonyme: When prices go up, it might get sensible to fix stuff again.
bridgman: there are still cheap countries, but most of them are underwater
bridgman: Elbonia lives !
bridgman: the current trend is to push out to cheap parts of countries where the big cities have become expensive
bridgman: it's actually great for raising incomes around the world, just kinda distorts a lot of the traditional feedback systems in business and economics
yangman: bridgman: so, figured out the scaled Y'CbCr code. my algorithm was right, but I was running into an alignment problem with that was messing up the texture loading code following the ALU clause all day long
yangman: ... that sentence constructino makes no sense. sorry, just woke up ;)
bridgman: yangman; that's great - programming shaders is pretty fiddly, isn't it ?
yangman: bridgman: yeah... I still don't know what the alignment has to be. it just worked out in the end because the 4 MOV operations are redundant, and I was adding exactly 4 MULADD operations
yangman: but, at least I can *finally* start working on my assignments from school once I get this cleaned up and sent to the ML :p
bridgman: yes, it's good to do that from time to time ;)
bridgman: bbl
Zajec: Do I get idea of Xv correctly? We upload video frame in original size (like 640x480) and we tell GPU to scale it to (for example) 1600x900?
yangman: Zajec: yes. also, you can upload images in formats other than RGB
yangman: the actual Xv API is a lot more complicated, but PutImage seems to be the only drawing call that's actually used
nanonyme: yangman: Also apparently the only operation supported in xvinfo in quite a many drivers.
nanonyme: s/many/few/
nanonyme: *sigh*
Zajec: ok, then what means packed Xv? :0
Zajec: (packed uploads)
Zajec: it means uploading 5 frames at once, or what?
yangman: Zajec: oh, the last commit? it refers to the format of the image
yangman: Zajec: decoded video frames are either packed or planar. for former is how things like BMP and PNG are stored. the latter, in simple terms, separates each channel out into their own bitmap, so data used to construct each pixel isn't actually next to each other
yangman: Zajec: planar is useful for cases where you don't need as much data from certain channels compared to others
Zajec: damn, even Xv has to be so complicated?! :P
nanonyme: Zajec: What in life is *not* complicated? :P
MostAwesomeDude: Zajec: It's really not that bad.
MostAwesomeDude: Almost all of these formats can be decoded either by texture engine or by simple shader.
Zajec: ok, and what's the reason for having image splitted?
Zajec: it sounds only most costly
Zajec: did I ask quite stupid question? ;)
nanonyme: To a wise teacher no question can be stupid, rather just another chance to educate the pupil? :o
Zajec: nice sentence. really
nanonyme: (Not that I consider myself one. Mostly a recycle center for religions and life philosophy. Philosophy/religion in, simple aphorisms out ;)
yangman: Zajec: image data tends to be more compressible in individual channels than with multiple channels interlaced together
Zajec: huh, interesting
yangman: Zajec: also, with planar, you can have channels with more detail than others
yangman: Y'UV420, for example, has 4 bytes of Y per byte of U or V
yangman: there's really no way to pack that in a easy way while keeping pixel adjacency
Zajec: yangman: another great topic :) thanks for explaining
ech0s7: yangman: with latest pull, i have fixed
ech0s7: do you remember my problem ?
ech0s7: of monitor corruption
Zajec: ech0s7: 08022009.mp4 it was you?
ech0s7: yes
Zajec: hehe :) yeah, fixed yesterday night
ech0s7: thanks so much :D
ech0s7: now see one moment my xorg.lof
ech0s7: log
Zajec: it's agd5f work :) i just tested
ech0s7: i have a lot of: Ran out of VB space!
ech0s7: $ cat /var/log/Xorg.0.log | nopaste
ech0s7: http://rafb.net/p/toobig.html
Zajec: i don't see any that line
ech0s7: one moment
nanonyme: ech0s7: http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/commit/?h=r6xx-r7xx-support&id=038de45b4c09356d0b46a03f6e69eece6aaf907b related to this?
ech0s7: nanonyme: now i see
Zajec: ech0s7: i meant I don't see such a line in my Xorg.0.log...
agd5f: you shoudl only see that line if the number of vertexes is large thatn the space to hold them
Zajec: one exception is whet I try to rotate PANEL... then I get lock up and a lot of that "VB space"
Zajec: but who would like to rotate PANEL :P
Zajec: except crazy testers :)
ech0s7: see my log
ech0s7: http://pastebin.com/m31394d1c
nanonyme: Whoa.
nanonyme: Wonder if increasing verbosity level would show anything more.
ech0s7: nanonyme: how ?
Zajec: startx -- :0 -logverbose 7
Zajec: uhm :)
nanonyme: :0 ? :)
nanonyme: Oh, right.
nanonyme: I'd suspect that's unnecessary though, I think the numbers are used in order from smallest to biggest.
Zajec: yeah, just used to use that full version :)
nanonyme: Zajec: I was just puzzled at first by that and your next line, thought you had typoed in a smiley or something. ;)
ech0s7_: nanonyme: how can i increase verbosity level ?
Zajec: startx -- -logverbose 7
ech0s7_: ok
nanonyme: ech0s7_: Listen to Zajec. :)
ech0s7_: nanonyme: i have lost connection
nanonyme: Ohh.
ech0s7_: system freezed
nanonyme: I didn't notice.
ech0s7_: yes because i have still ghost nickname
ech0s7_: now kill him
nanonyme: Actually I think it already dropped, I just failed to notice.
ech0s7_: ok
ech0s7_: restart X
ech0s7: the log is too big for pastebin
rainbyte: hi
nanonyme: ech0s7: gzip, upload somewhere that allows binary files?
nanonyme: Text compresses well.
ech0s7: i'm doing
nanonyme: :)
ech0s7: this is the log: with verbose level 7: http://ech0s7.netsons.org/private/log.txt
nanonyme: The second log does show three more function calls than the first one before the running out of VB space, apparently. *shrug*
ech0s7: i don't know very well the driver, but this function seems to be the problem: RHDDRIGetIntGARTLocation ()
ech0s7: nanonyme: in the previous log i have deleted some row of paste
nanonyme: And I don't suppose there could be any card-dependent hard-coded values related to those messages...
nanonyme: I dunno, I pretty much give up seeing that high an amount of structs to study. :P
ech0s7: :)
nanonyme: Hmm, actually the code is pretty well organized...
nanonyme: Out of interest, what was your card again?
ech0s7: rv620: radeonhd 3470
nanonyme: Right, nothing then. :)
ech0s7: ok
nanonyme: Meh, I could probably just stare into a hole into my monitor looking at the stuff. Probably better idea to just make a bug report to get some regular dev on it. ;)
Zajec: ech0s7: agd5f added more debugging info, can you try with current git?
nanonyme: Yays, ignore my last comment. :)
ech0s7: ok Zajec, now try
MostAwesomeDude: nanonyme: Go ahead and stare until it hurts. That's how you learn.
nanonyme: MostAwesomeDude: Atm mostly hunting down just what on Earth eg pack3 and e32 do. :)
agd5f: nanonyme: e32 emits a dword to the command buffer
nanonyme: Ah, right.
agd5f: pack3 emits a packet3
nanonyme: Hmm, I suppose I'd have to read the card specifications to understand just what the significance of sending each dword has...
nanonyme: But yeah, makes sense now, at least on the surface level. :)
MostAwesomeDude: nanonyme: Everything sent to the card is for the CP, so it's part of a packet.
MostAwesomeDude: e32 is just for custom packets that are easier to express raw.
nanonyme: Right. The second argument of pack3 looks semi-intuitive, the third one not.
agd5f: nanonyme: take a look at the r5xx accel guide
kcodyjr: fwiw i'm seeing this Ran out of VB space issue as well. switched to r6xx drm as well just to be sure.
nanonyme: I guess I might as well, thought I'd have to start reading the guides sooner or later to figure out what exactly is going on. Where's the guide available?
agd5f: http://www.x.org/docs/AMD/
nanonyme: :P
nanonyme: agd5f: So only 275 pages of text. ;)
agd5f: nanonyme: the pm4 section describes the packets
nanonyme: Right, right. :)
ech0s7: Zajec this is the new log: http://ech0s7.netsons.org/private/log.txt
nanonyme: Hrm...
nanonyme: agd5f: So is the number simply packet3 type identifier or am I making stupid guesses in the dark still?
agd5f: yeah packet type is specified in the packet header
agd5f: 0,2,3
makomk: yangman: your actual issue was that you weren't updating the offset of the texfetch instructions in the CF instruction referencing them.
nanonyme: agd5f: Hmm, I meant the n in pack3(ib, IT_*, n), btw, just to make myself clear.
agd5f: nanonyme: that's teh count
nanonyme: Ahh.
agd5f: number of packets to follow
nanonyme: Btw, you seemed to leave type-1 packet out. Why, exactly?
nanonyme: (I mean, sure, packet-0 are recommended instead but still)
yangman: makomk: makes sense. thanks
nanonyme: (Or rather, they're recommended if you want to address the entire address space)
yangman: ... I think the Y'CbCr->RGB matrix for BT.601 and BT.709 are identical
yangman: my linear algebra is weak, but that's what octave tells me
nanonyme: Better not trust machines in giving complete answers to matrice problems. :)
agd5f: nanonyme: no use for type1
agd5f: for most things
yangman: I'm not solving this by hand :p
yangman: just verying the values on the various pages I see
nanonyme: yangman: You don't have to solve it but you need enough linear algebra to determine if the answer is a) sensible b) complete.
nanonyme: Computers tend to eg not know the difference between one and infinite.
yangman: nanonyme: it's a well defined invertible matrix. so, yes, complete
yangman: nanonyme: and it's pretty sensible
nanonyme: Right.
yangman: it means less work. I'm all for less work
nanonyme: Sure, sure, I'm not telling you to do it by hand. ^^ The very point of matrices is that you can use computers to solve the problems. :)
kcodyjr: yangman, they are the same except the scaling constants
yangman: ok, I think I'm satisfied with it. just gotta rebase it
agd5f: yangman: looks good
yangman: cool
Zajec: could it be pushed into r6xx-r7xx?
Zajec: in current state?
yangman: huh, that should have been 4th instead of 3rd column in the comment
yangman: and there's a typo in the scaling matrix explanation
Zajec: is this normal and expected I get a little worse quality image using Xv?
Zajec: with X11 it's sharper
yangman: Zajec: like this? http://yangman.ca/radeonhd_xv_test1.png
yangman: I think the texture samplers are still set to bilinear also. we can probably bump it to bicubic
Zajec: yangman: yes... i think (you took other frame and quality is quite low anyway)
Zajec: ok, hope it will make a trick :)
yangman: the patch I sent earlier fixes exactly that difference. not sure if it's what you mean by sharp
Zajec: earlier? missed that... does that earlier patch apply on top of your color-fix-patch?
yangman: I'm referring to the patch I sent to the mailling list 20 minutes ago
Zajec: ah, then I mean sth different...
Zajec: just captured difference with mplayer but it's the same frame :P maybe manual screenshot will help
Ge0rG: hm. somehow xvideo feels much more sluggish than yesterday with r6xx git... but maybe its just my feeling
yangman: Ge0rG: how so?
Ge0rG: yangman: can't give you numbers, its just a strange feeling when playing back a h264 1080p .ts file
Ge0rG: but my other test cases play well, so maybe its just my eyes ;)
yangman: Ge0rG: give the new code a try. one less shader instruction, so, who knows, maybe it's faster ;)
Ge0rG: *pu*
yangman: or, rather, one less required GPR. same number of instructions
Ge0rG: yangman: yup, looks good. must have been my eyes ;)
Ge0rG: but black has finally become black today :D
Zajec: got screens
Zajec: yangman: can you compare http://sirius.cs.put.poznan.pl/~inf80100/x11.png and http://sirius.cs.put.poznan.pl/~inf80100/xv.png ? notice it's 2*1.1MB
Zajec: yangman: it shows exactly what I mean by sharper X11
agd5f: Zajec: is that video scaled or native size?
yangman: huh, interesting
Zajec: native
Zajec: didn't scale window and didn't even use -zoom for xv
yangman: try the latest code
Zajec: it is... from 3 minutes ago
yangman: ok
yangman: what's the colour format?
Zajec: oh, moment
Zajec: VDec: vo config request - 1280 x 688 (preferred colorspace: Planar YV12)
Zajec: VDec: using Planar YV12 as output csp (no 0)
Zajec: hm, this one?
yangman: yup
yangman: gamma ramp issue, maybe?
Zajec: i used kscreenshot for capturing (it's probably "import" conosole program based) as captuing from MPlayer didn't give right effect
Zajec: yangman: can I check this somehow?
yangman: check the shape of the histograms
Zajec: yyy, khem? ;)
Zajec: shape? histograms?
yangman: heh
yangman: load up both in GIMP, crop away the window decorations, then go to Colours->Info->Histogram
yangman: this is for 2.6. I'm not sure if 2.4 is still the same
yangman: it'll give you a graph of the distribution of colour values
Veza: Doesn't radeonhd read Modelines at all?
yangman: when we discussed this earlier, we were pretty sure the scaling was the cause of the mismatch. we weren't sure whether or not gamma ramp adjustments are also needed.
Veza: ..I wish to set modeline 1280x768, but there's no mark about in the log.
adamk: Veza, Have you also used the "PreferredMode" option in the monitor section?
Veza: no
adamk: You may want to check out the various wikis on xrandr 1.2
adamk: For example: http://wiki.debian.org/XStrikeForce/HowToRandR12
Veza: adamk: thanks. It seems I should replace Modelene with xrandr scripting..
adamk: I don't think there's anything you can do with the 'xrandr' command that you can't do in your xorg.conf file.
adamk: It sometimes takes a little experimenting, at least at first :-)
Veza: I tried even "-logverbose 9", but it made X die and adapter shutdown. Reboot required..
yangman: Veza: use the autodetected values and xradr as much as possible. add mode lines manually only when it's not autodetecting the correct values
Zajec: yangman: http://sirius.cs.put.poznan.pl/~inf80100/x11.histogram.png and http://sirius.cs.put.poznan.pl/~inf80100/xv.histogram.png
Veza: yangman: autodetect doesn't work on this old lcd
yangman: Zajec: thanks
Zajec: yangman: that's weird... actually X11 histogram looks weird for me
yangman: hm... hard to say if it's a gamma ramp thing or not. I'd probably have to run some tests of my own
yangman: yeah, looks like there's artifacts in G
yangman: and you may have missed a black border somewhere when cropping x11
Zajec: hm, hope I didn't change X11 with Xv histograms... will double check
Zajec: I used correct files and filenames but am not happy about the result... i made window to small and it's compared wrong way
Camoeba: Zajec: when I looked at the x11 and xv pic you posted, they may not have been the right frame...
Camoeba: right being the same frame...
masa-: if there are these different colorspaces, how many of them are used in different types of videos? and is it the players job to select the correct one and pass it to the output 'thingy' (what was xv called again..?)
Zajec: Camoeba: ok, i'll make real test tomorrow, eventually day after tomorrow
Guest95160: hello, i get thousends of "Copy: Ran out of VB space!" when i move text around. one time the computer even hardlocked
legume: yangman: Zajec is right about xv being soft, have a look at the xwds I posted in this thread http://www.phoronix.com/forums/showthread.php?t=15018
legume: yangman: it's radeon as well as radeonhd and nothing to do with your colour space change which is cool
yangman: probably need to play around with the texture sampling, then
kcodyjr: current r6xx head is playing a dvd, quite watchably despite mild tearing, at 0.2 ish system load. very nice work.
leeguy92: when using GL, at what point are the vertexes actually put through the GPU, and translated to their actual positions on the screen? is it at the call to glEnd()?
leeguy92: *transformed
airlied: leeguy92: there isn't a really defined point
airlied: glFinish definitely does it.
airlied: but gl rendering can be delayed, the stuff gets queued up into a buffer in the driver and when its ordered to or when it hits some limits it sends it to the card
airlied: where it may get queued up behind other rendering
leeguy92: ah, so it's not cached until the end of all of the drawing or anything. (you would have to cache the matrices as well i suppose)
kcodyjr: airlied, did you get a chance to look at that xorg log?
airlied: kcodyjr: wierd, DRI2 changes musta screwed up r600 kms paths
airlied: kcodyjr: it shouldn't be calling exa anything on r600 yet
airlied: leeguy92: the vertices are usually put into a vertex buffer, and whenever the command buffer fills up it gets sent to the hw
airlied: or at Flush/Finish time
kcodyjr: i do believe the latest commit eliminated video tearing
kcodyjr: airlied, even with exa disabled, it still tries to get the exa private when modesetting, which is where it segfaulted before i started messing with it
kcodyjr: also, getting this with latest r6xx radeonhd: (EE) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned -9
kcodyjr: anyways, airlied, unless you can give me further instructions, i think i'm as far with that merge as i can get... wait, would you expect your unmodified kernel tree plus that ddx to work? let me try that combination.
airlied: kcodyjr: not sure why its derefencing exa stuff in r600 kms paths but I haven't tested it in ages
airlied: it might just need a return somewhere
kcodyjr: i investigated it somewhat; the call looks kinda integral to me
kcodyjr: let me dig up the file/line number...
kcodyjr: drmmode_display.c:create_pixmap_for_fb()
kcodyjr: driver_priv = exaGetPixmapDriverPrivate(pPixmap);
kcodyjr: being called from drmmode_set_mode_major
kcodyjr: comment all that out, it's unable to save the bo to driver_priv, but this is what happens: http://pastebin.com/m7b4074a0
Ge0rG: is it possible to get KMS working with radeonhd?
airlied: Ge0rG: no.
airlied: Ge0rG: if you mean currently
airlied: kcodyjr: I'll have to take a look at the changes for r600
kcodyjr: hmm, commented out the exa guts of copy_fb_contents, and i was able to get a startup
kcodyjr: it took like 3 seconds to draw the -retro stipple
kcodyjr: but start it did
Ge0rG: airlied: I'm curious, because my rv770 card seems to automatically add underscan / black borders on a 1080p tft display. so I'd like to see if it would work better with a kernel video driver != vesafb
Ge0rG: airlied: do you happen to have some KMS tree one could test, with at least console framebuffer working on a rv770?
kcodyjr: Ge0rG, mine did that as well actually
kcodyjr: the radeonhd driver will not work with radeon kms though, you'll have to use airlied's patched radeon tree
Ge0rG: it looks really stupid to have four overly fat tuxes on a mis-scaled 1280x1024 vesafb
kcodyjr: which will require having several X components at git heads, and the result won't be all that usable
kcodyjr: i just now got it to start
Ge0rG: is already running kernel, drm and rhd from git. can't be much worse ;)
kcodyjr: yes it can
kcodyjr: xserver, handful of x libraries and xproto's...
Ge0rG: still, I'd like to see a properly scaled video framebuffer at least for one time
airlied: Ge0rG: my drm-2.6 kernel tree on kernel.org drm-rawhide branch, you need to add pciids in drm_pciids.h for r6xx cards though
kcodyjr: i can confirm it will give you an fbcon at native resolution, give or take intermittent ddc issues
kcodyjr: and with much pain you can get X, if you use twm as your window manager it might even be usable.
Ge0rG: airlied: is it supposed to work with r7xx too?
airlied: Ge0rG: in theory, it needs more testing.
airlied: kcodyjr: wierd it should use shadowfb for X
Ge0rG: is using fluxbox. :>
airlied: kcodyjr: so should be as fast as the non-kms paths
airlied: granted I haven't played with it in ages
kcodyjr: it is actually
kcodyjr: but the non-kms paths aren't particularly fast either
kcodyjr: not that i'm expecting them to be ;) i'm just warning Ge0rG not to get excited about kms plus X .
Ge0rG: kcodyjr: yeah, I understood the warning :>
Ge0rG: still wonders about the future of radeonhd+kms
airlied: not sure radeonhd+kms makes much sense you end up running the same codepaths as radeon+kms nearly exacrly
Ge0rG: this becomes political again...
kcodyjr: for the purpose of testing kms it makes no sense; i think the beef is that all the accel work has been happening in radeonhd, and let's face it, new accel features is like free beer
kcodyjr: otoh if kms is going to become "the way" then sooner or later some integration has to happen somewhere
airlied: Ge0rG: thats not political
airlied: kcodyjr: the accel work is in both places.
kcodyjr: well, r6xx accel work
airlied: kcodyjr: what other accel work is going on?
kcodyjr: in 2d land nothing that i know of
airlied: 3D accel is nothing to do with radeon/radeonhd
airlied: its all in mesa
kcodyjr: but clearly i can have Xv with radeonhd and not with radeon at the moment, just to name one
kcodyjr: but i don't wanna get into pissing contests about driver trees turning into the sherwood friggin forest. i just want to finish up whatever testing and reporting regimen you require on those patches.
airlied: kcodyjr: wierd it works here.
airlied: kcodyjr: its the same code in radeon as radeonhd for Xv.
kcodyjr: i'm using your -radeon tree
kcodyjr: err your -ati tree; radeon-gem-cs2 branch
kcodyjr: that's expected to do Xv on R600 ?
airlied: kcodyjr: so you are ust mixing things up then
agd5f: kcodyjr: no, but the r6xx-r7xx-support brach or radeon supports XV and EXA
airlied: kcodyjr: you can'
kcodyjr: if they've reached feature parity then politics doesn't sound like a very good reason to keep two trees anymore
kcodyjr: but anyways what's next?
yangman: kcodyjr: doesn't mean the code is compatible. better to wait for kms
airlied: kms is a parallel development to r600 accel, we ain't crossing the streams just yet.
airlied: r600 accel needs a lot of work and design to be useful in a kms world
kcodyjr: let me rephrase that: what's next with kms code merges and related testing
kcodyjr: i don't think i said i was expecting accel in the kms world yet. did i?
airlied: kcodyjr: for r600 we have to design a command submission that works
airlied: kcodyjr: you just said you expected Xv.
kcodyjr: you'd said the accel work was in both places
kcodyjr: which, as we've realized, led to me crossing lines in my head about what you were saying
kcodyjr: no matter. no, i don't expect working accel in the kms world, but for a moment i thought you were implying there was some.
airlied: not until we can design some CS mechanism.
airlied: which probably relies on the docs getting out
kcodyjr: that's what i thought. brainfart over. ;)
kcodyjr: hm. and i really haven't gotten us anywhere, except be able to run r600_demo on your kernel tree with modesetting turned off
airlied: well I'm going to reuse your patch to enable r600 drm in kernel at some point
kcodyjr: so what should i be doing next
kcodyjr: there isn't a whole lot use for better edid parsing in-kernel until there's a userspace that can make good on that information
airlied: kcodyjr: btw in your kms stuff is shadowfb getting enabled?
kcodyjr: yes, it is
kcodyjr: and the desktop is apparently stable, to the extent i've tried pushing it anyway, couple overlapping terminals and twm
kcodyjr: ahh, hrm, i should expect radeonhd to behave identically whether i'm using r6xx drm or the one i just merged, shouldn't i
kcodyjr: with modesetting not enabled i mean
kcodyjr: so what's the roadmap for getting kms upstream?
airlied: kcodyjr: port to new TTM codebase, get TTM upstream
airlied: get radeon kms upstream
airlied: but really need to have a working 3D driver before that
airlied: so we can validate the interfaces for memory management aren't insane
kcodyjr: any chance we can cull the number of active branches?
kcodyjr: modesetting-gem and r6xx-r7xx-support mesa/drm.git branches in particular vs. your kernel tree
agd5f: kcodyjr: they serve different purposes at the moment
airlied: I can pull the patch you did into my drm-rawihde tree
kcodyjr: agd5f, just checking. culling branches is always to be desired. ;)
kcodyjr: still doing a clean kernel build, let me be sure those patches leave a working radeonhd. goodness knows what other differences there might be between the two drm.git branches and the kernel tree.
kcodyjr: if we can at least reach an inter-branch sync point, i'm thinking that keeping up with future changes will get a little less hairy...
kcodyjr: what's the magic incantation to release the fbcon and get vga back so i can unload radeon.ko ?
airlied: echo 0 > /sys/class/vtconsole/vtcon1/bind
kcodyjr: hmm, that won't restore the vga console though, will it
airlied: nope
kcodyjr: reboot... and don't forget modeset=0 this time...
airlied: kcodyjr: or vbetool post sometimes works :)
kcodyjr: too late, the reboot's already done
kcodyjr: thanks though ;)
kcodyjr: this machine has some serious kick for being just a tv controller
kcodyjr: confirmed. tear-free video playback with latest r6xx radeonhd, latest modesetting-gem libdrm, and your latest kernel plus my patches with modeset=0
kcodyjr: agd5f, perhaps it's worth asking what specific purpose the r6xx-r7xx-support branch of libdrm is serving? could that be folded into modesetting-gem?
kcodyjr: i guess the underlying question is, what's the measure of those particular branches jobs being complete
agd5f: kcodyjr: there's no libdrm changes, it's just the r6xx0r7xx-support kernel modules
agd5f: radeon drm with r6xx/r7xx support
kcodyjr: oh. ok ;)
kcodyjr: i'm trying to think of any reason to tell airlied that i'm not satisfied with those patches, but i can't seem to find any
kcodyjr: neither on the basis of incorrectness nor incompleteness; acknowledging that CS is yet to be tackled
kcodyjr: airlied, the modesetting ddx fails to start when modesetting isn't enabled - is that tree expected to be backward compatible?
kcodyjr: rmmod radeon ; modprobe radeon and it switches to fbcon, sets native, and trying the ddx then succeeds as before
kcodyjr: i'm thinking it's no surprise that case failed; it was trying to align down the GART and i've never seen that happen. guessing your modesetting ddx just hasn't been rebased in awhile.
cxo: ello
cxo: I know this isnt your cup of tea, but do you think that my card never works with the catalyst driver because i flashed it with a different bios?
cxo: works ok with the radeonhd driver and on windows
bridgman: cxo; probably not but I guess it all depends on what bios you flashed with ;)
bridgman: what GPU and distro are you trying to use with fglrx ?
cxo: i tried both ubuntu 8.04, 8.10 and fc9
cxo: hd4870
kcodyjr: ok airlied i can't think of anything else i haven't done that i should
cxo: originally a visiontek, but i flashed it with the Asus HD4870 TOP video bios
kcodyjr: please push those at your discretion... if there's something else useful you think i could be doing, what would it be
cxo: bridgman: during init, pci ids aren't validated against the bios or something like that??
cxo: hmm or was that a highly classified question
bridgman: normally if you flash the bios you either brick the card or you don't -- the card becomes whatever the new bios came from and that's it
bridgman: flashing across consumer/workstation product lines is a different story
bridgman: were they both 4870s ? you can't flash between 4850 and 4870; bios size is different among other things
cxo: of course, they were both reference 4870 PCBs
cxo: the asus had a better fan profile and higher stock clock than the visiontek, 2+2=4 so i flashed it
bridgman: then, without sounding like we support flashing or anything, it should work
bridgman: did it have the same speed of memory chips ?
cxo: i'm not sure. I thought that was controlled by the bios
bridgman: bios controls how fast we run them; chip speed controls whether or not they work reliably at that speed
cxo: card works fine in windows by the way
bridgman: yeah, but the windows driver has a lot more adaptive code
cxo: fglrx just gives me a blank screen when trying to start X, then i got to ssh in and kill X
bridgman: windows drivers will run over a borked AGP but where the linux driver just crashes
bridgman: anything interesting in the log ?
cxo: No
bridgman: then it should work ;)
cxo: i threw gdb on it, and its stuck in some readlock
bridgman: did you save the old bios image ?
cxo: yes
bridgman: did you try fglrx before flashing ?
bridgman: I feel like tech support in india ;)
cxo: hmm now that you ask, i actually did
bridgman: and did it work ?
kcodyjr: hm. good. although i can't get vgacon back, i can rmmod radeon; modprobe radeon modeset=0 and run X with radeonhd again.
cxo: no it didnt, thats when i got pissed, and installed windows on a spare drive
bridgman: ok, so flashing the bios probably wasn't the issue ;)
cxo: yeah i guess it wasnt
bridgman: maybe fglrx doesn't like you
cxo: the feeling is mutual
bridgman: if you have a spare partition you might want to put a fresh install of 8.10 and try again when the next cat comes out
cxo: 9.2?
bridgman: yeah... but then again I hope to start pushing open 3d code soon so that might keep you busy
cxo: ok
cxo: does compiz run with the current radeonhd?
bridgman: on 5xx, 690 and lower chips but not on 6xx/7xx, you need mesa for compiz
bridgman: you can run metacity or kwin with Xrender (EXA) though
bridgman: running with a compositor used to give you much better performance before the recent optimizations; probably still helps a bit but not so much as before
cxo: which driver am i supposed to use with my 4870, the xf86-video-ati or this one?
bridgman: do you have a coin ?
cxo: nope
bridgman: ok, google something; if the number of hits is odd, use radeonhd
cxo: Results 1 - 10 of about 87,200,000 for coins
cxo: dammit its even
cxo: i think i liked the sound of radeonhd better
bridgman: or you could pick based on whatever forum you are hanging out in more
bridgman: yeah, radeonhd sounds better
cxo: sees red when he sees ATi in anything
bridgman: we were also thinking "radikal", since the new display controller for 5xx and up was called "kaleidoscope" internally
bridgman: after we acquired Chromatics, they changed their internal signs to chromATIcs, which I thought was clever
bridgman: in breaking news, Fudzilla says that Chinese salesman wasn't killed by an exploding phone after all, it was a home-made gun
bridgman: lithium-ion battery users around the world can relax
yangman: bridgman: so, I ran some math, and the inverse conversion matrix for BT.601 and BT.709 are the same. we don't have to worry about it :p
yangman: a clever bunch, those MPEG guys
yangman: of course, would have been easier if someone just outside said this on their explanations
kcodyjr: i don't know why they documented the distinction if there's no difference
bridgman: I guess that explains some of the "it hardly makes a difference" comments, but the forward matrices seemed pretty different
bridgman: it's a shame I don't remember a single thing from university
yangman: I just ran it through octave
yangman: had to quadrupal check my math because I couldn't believe it
bridgman: yeah, I guess my initial reaction is the same
yangman: er, I meant "outright" instead of "outside". my fingers are getting ahead of my brain again
bridgman: aw crap, I don't want to have to re-learn matrix math (although I did just run across my university textbooks while unpacking ;)) but this seems odd to say the least
bridgman: then again the bt.709 colourspace decision was totally political, so maybe someone clever was doing the math before the decision
bridgman: I would be very impressed if that was the case
cxo: its a sign
bridgman: i agree; the question is "a sign of what" ;)
bridgman: yangman; so why would we have a register bit to choose between 601 and 709 ?
bridgman: please don't say politics ;)
cxo: Well i'm not Moses, but it basically means that the problems you have in life have answers, you just need to remember them
kcodyjr: well, would they still be equivalent if you increase the precision
yangman: that's a good question. to both
yangman: I'm gonna run the calculation again :p
bridgman: oh geez; do a google search for "bt.601 bt.709 coefficients"
bridgman: apparently a lot of people were unhappy with the decision to use different coefficients
bridgman: not clear whether there was a practical difference or not, stay tuned
bridgman: notice I haven't actually disagreed with yangman yet ;)
yangman: getting something totally wacky right now...
yangman: I forget how I got the matrixes I needed
yangman: gonna go find my linear algebra textbook...
rainbyte: hi
yangman: huh, it's not on the book case with all my other textbooks. weird
bridgman: its a sign
rainbyte: bridgman, sorry for the question but, what is it all this about bt.601 and bt.709?
bridgman: they're the standards for digital representation of SDTV and HDTV respectively; we were looking through them trying to figure out what colour spaces they used, so that we could make the right decisions about how to convert the "YUV" values that go into Xv back to "RGB" values for display on the screen
bridgman: big picture question is "ok, so we have these numbers in the digital video stream, what do they mean ?"
bridgman: let's say you have a bitmap image, where the colour in a pixel is 100 for red, 50 for green, 250 for blue
bridgman: the red used in the image might not match what your monitor calls red
bridgman: ditto for the other colours
bridgman: the whole mess is collectively called colour management
bridgman: and it's not pretty ;)
kcodyjr: actually i was doing further readin
kcodyjr: reading even
bridgman: uh-oh ;)
kcodyjr: i think we may be missing something fundamental, but the consequence of doing it "right" may mean an awful lot more work for the conversion
rainbyte: ahh, from what I read about (mostly from fansubs) bt.709 is used for hd video (anything width that 1024) and bt.601 for the rest
kcodyjr: we've been strictly looking at color -format- changes; RGB vs YUY vs YV12 and such - we're ignoring primaries
kcodyjr: http://en.wikipedia.org/wiki/CIE_1931_color_space
rainbyte: bridgman, is that info right? or am I talking about other different things?
kcodyjr: those are correct rainbyte but, very specifically applied to converting Y'UV to RGB
rainbyte: ahh, ok, thanks kcodyjr
rainbyte: I think I have to read more about these things
yangman: well, yes, we're ignoring primaries (at least for now)
yangman: dang it, how did I get the correct inverse matrix...
kcodyjr: what i'm trying to get at though is that these additive spaces are falling into two categories, the luma-chroma and the tristimulus
kcodyjr: we've been using tristimulus as the fundamental but really the luma-chroma are the more flexible
yangman: hm... I must have been doing something stupid with octave the first time running those numbers :(
kcodyjr: can i get you guys to follow me down mental whack job lane for a few minutes? ;) maybe we should all get coffees and open a fresh browser? i'd like to knock about the idea of using CIE xyY as the logically fundamental colorspace
bridgman: kcodyjr; what I found was that the primaries used for SD and HD were different but so close as to be irrelevent
bridgman: SD seems to use EBA/EBU/whatever primaries, while HD uses a the EB-whatever colours for two of the primaries and a slightly different value for the third
bridgman: most discussions claim the change was political and not visible
bridgman: I gave up on coffee and switched to rye
bridgman: and put some wings in the oven, gonna need energy ;)
bridgman: "How do you know which set of coefficients were used when encoding a MPEG-2 stream? Usually, the coefficient information is stored in the header of the MPEG-2 file (the "matrix_coefficients" field in the "sequence display extension"). Newer versions of GSpot will be able to read and display this information. Also, DGDecode v1.20+ (with Mpeg2source(info=1)) can be used to view it. If this extension field is not present in the he
bridgman: I found the above at : http://forum.doom9.org/archive/index.php/t-133982.html
bridgman: not yet validated
bridgman: of course this is no help because the player doesn't pass the information to Xv ;(
bridgman: but then again agd5f added an xvattr for this, so presumably the player *can* pass it...
bridgman: is suddenly hopeful
yangman: ok, I think I'm gonna give up for now and work on my assignments
yangman: I'm fairly certain I wasn't doing something wrong when I ran those numbers this morning
yangman: but, the result is good, so, \o/
rainbyte: bridgman, so can it be posible to use that in order to decide which one is going to be used in that moment?
yangman: s/wasn't/was/
kcodyjr: sorry for going quiet; in fact i did go get a coffee
bridgman: yangman; I'll play with it for a while, check backlog later
bridgman: rainbyte; probably, but it would be player-dependent
bridgman: then again if players are already patched to support the old chips with hw overlay then we could use the same xvattr for new chips
rainbyte: bridgman, but anyways, you need a player to watch the videos so that's not a problem I think
rainbyte: (maybe I think wrong, hehe)
kcodyjr: ok just flipped through that thread bridgman; that's focusing specifically on the video standard issue
kcodyjr: i'm talking about color correction more broadly
bridgman: ah, ok - you got coffee, I got rye, yangman got homework, let's talk
kcodyjr: ;)
bridgman: what could go wrong ?
kcodyjr: to each their own. i really am fueled on coffee, it's sickening...
kcodyjr: well i realize right out that the kind of change i'm considering imposes constraints on the logical pipeline
kcodyjr: it would almost have to be triple buffered...
kcodyjr: but the beauty of CIE xyY is that it's two things at once: it is truly primary-independent, and it's mathematically luma-chroma compatible
bridgman: I'm gonna have to go talk to google again, yes ?
kcodyjr: i'm not understanding
bridgman: if we're gonna talk about CIE xyY I need to go see what it is
bridgman: or you need to tell me ;)
bridgman: I tend to doze during benefits-first presentations ;)
kcodyjr: http://en.wikipedia.org/wiki/CIE_1931_color_space
bridgman: specs... I like specs...
kcodyjr: executive summary: two crucially important "standard" colorspaces to consider
kcodyjr: CIE XYZ represents the standard observer, or, the average human eye measured on a given field of view
kcodyjr: CIE XYZ has a correspondence to the 3 wavelengths your eye is sensitive to
kcodyjr: the other is CIE xyY; where x and y are coordinates on that funky color graph, and Y is the same Y from CIE XYZ; and that Y was also deliberately defined to be equal to luminance
kcodyjr: if you're working in chroma-luma then you can ignore the luma when you're doing colorspace correction
kcodyjr: whereas if you're working in trispace (which RGB is a set of cases of) all 3 values are always important
bridgman: being able to ignore luma is an interesting point, hadn't thought about that
kcodyjr: but most importantly of all; if you know a color's (x,y) coordinate, and you know your target displays' 3 primary wavelengths, it becomes a straightforward calculation to convert from generic xyY directly to your monitor's native
kcodyjr: giving you a proportion of your 3 colorants, conveniently in fixed point, which you can then multiply by the luminance value, hitherto ignored
bridgman: where does gamma fit in ?
bridgman: ah yes, x has two peaks; this is starting to come back now
bridgman: I was very young then
kcodyjr: gamma is merely response curve; as applied to streams it seems meaningful on the luminance, as applied to display it's independent per physical colorant
kcodyjr: well, that's where x has a harmonic coinciding with z
kcodyjr: what's driving me to want this approach though, is the change in display technology
bridgman: go on
kcodyjr: in a CRT-only world, you always had the 3 standard primaries with known wavelengths
kcodyjr: that's no longer true
bridgman: xyY seems to be chroma-luma, I hadn't seen display tech moving that way
kcodyjr: xyY -is- chroma-luma but it's a unique chroma-luma
kcodyjr: in that it defines the relationship from the color to the entire pure-wavelength line; and is thus readily convertible to any set of tristimulus values
bridgman: I actually thought plasma, lcd and (digital moving mirror thingy) were all still basically rgb
kcodyjr: or for that matter, any arbitrary number of primaries
kcodyjr: they are still rgb
kcodyjr: but the particular red, gree, and blue wavelengths of a pure color are no longer consistent
kcodyjr: crt green != lcd green
bridgman: there's two separate factors, arent' there ? the monochromatic diagram is the reference (which is good, it's a superset) but the xyY is really just an encoding decision
bridgman: old crt green != new crt green
kcodyjr: that as well, yes
bridgman: I'm told my old green toyota tercel faded from red to green ;)
kcodyjr: lol well that's 80's toyotas for you, i had one too
kcodyjr: look at the 2nd horseshoe diagram on that page
kcodyjr: see the triangle defined in it?
bridgman: "These colors, although they are on the border of the gamut, have no counterpart in monochromatic light."
bridgman: it's stuff like that which made me drop out of university ;)
kcodyjr: heh. well that makes sense actually - there is no single-wavelength for purple; it exists only as a combination of red and blue
bridgman: yep; triangle points correspond to real world phosphors or whatever, triangle is what you can make from those phosphors
kcodyjr: but you'll note the phosphors are themselves defined by x,y coordinates
bridgman: what happened to roygbiv ?
kcodyjr: whawho?
bridgman: the mnemonic for remembering spectral high points.. .Red Orange Yellow Green Blue Indigo Violet
kcodyjr: oh... don't remember that one
bridgman: then again I guess the outside of the horseshoe makes it to violet
bridgman: geez, where did you go to school ?
bridgman: ;)
bridgman: I guess "and in what decade" is the real question ;)
kcodyjr: well if you think about it, the higher up in frequency, the closer wavelength*2 comes to the red receptor
bridgman: you think that's what causes the second bump ? not disagreeing, just never occurred to me
kcodyjr: pissant yuppie school in massachusetts's beeutiful blinder-wearing merrimack valley
bridgman: sounds nice
bridgman: I went through U of T engineering science; no girls after first year ;(
kcodyjr: actually that's a 4:3 resonance in wavelength, not sure what the frequency relationship is but it's got to be somesuch effect
kcodyjr: the lineup on that graph is just too perfect
bridgman: good catch
kcodyjr: but even that isn't what got my attention
kcodyjr: i'm not sure what the name of the algorithm is
kcodyjr: but consider an (x,y) point on that graph
kcodyjr: then consider any 3 arbitrary primaries
kcodyjr: it can't be that complex to determine the amounts of each primary that triangulate the (x,y) point
kcodyjr: and the 3 primaries are fixed on one end of the pipeline by the monitor, and on the other end of the pipeline by the chosen encoding standard
bridgman: so you're thinking the monitor becomes the anchor (so LUT only handles gamma) and apps convert to monitor space ?
bridgman: or at least apps identify colour space so framework can convert ?
kcodyjr: apps identify what colorspace they're working in, and default to sRGB to mesh with common assumption. anyone that cares will know to change the setting.
bridgman: I hate to say it but the guy who was suggesting colourspace conversion during compositing is sounding a bit smarter every day
kcodyjr: it would happen during compositing
bridgman: not you ;)
kcodyjr: but doing it in CIE xyY is the missing element
kcodyjr: heh i know someone else said it
kcodyjr: the real scanout buffer has to be tristimulus
kcodyjr: but not just any tristimulus; it has to be the RGB that the monitor actually emits
kcodyjr: next step away is the backbuffer, that has to be the CIE xyY then
kcodyjr: which means X almost -has- to work on a "shadow" framebuffer in sRGB
kcodyjr: the compositor would -like- to work exclusively in one colorspace, it's probably an arbitrary design decision which
kcodyjr: - LUT correction is only meaningful within a given tristimulus colorspace
kcodyjr: so, the extent of idea which is actually formed is, the compositor stage should deal with CIE xyY inputs and outputs
kcodyjr: though i'm unsure about how whether things need to be translated beforehand or on the fly
kcodyjr: see what i said about grab a coffee before i start this?
kcodyjr: it's a radical idea but it makes real ubiquitous color correction computationally feasible
kcodyjr: anyone want to pipe in? ;)
bridgman: sorry, had to pull the wings from the oven; not bad
bridgman: it's nice when you use Frank's Red Hot to take the edge off the spiciness ;)
kcodyjr: i did say the snacks were important. ;)
bridgman: ok, let's see... LUT's can't do colour space correction, only gamma in rgb-space, so the compositor output needs to be in monitor space
bridgman: we're not likely to get all the apps changed, so apps need to output in whatever-space
kcodyjr: semantic correction: lut's do gamma in any tristimulus space, rgb is just the most likely
bridgman: true, whatever monitor does when you hit RGB lines
kcodyjr: right; it could be orange-green-cyan, though its gamut would presumably suck
bridgman: so the compositor really wants to be doing the colour space conversion
kcodyjr: i was thinking that there's two roads; either X continues to think in RGB or X is made to think in luma-chroma
bridgman: X is older than you
kcodyjr: unless X already has a native color model that's xyY compatible then screw the 2nd approach and just make the X controlled framebuffer be sRGB by fiat
kcodyjr: but the compositor itself wants to ignore color conversion, it just wants to composite
bridgman: I like "app says what colour space it's output is, sRGB is default in absence of better info"
kcodyjr: yes. that brings up the challenge of what api's need colorspace control calls added to them but let's leave that aside for the moment
bridgman: the compositor is in flux and already uses shaders; everything else is stodgy and may be fixed function or 2d
kcodyjr: i think we need to ignore current implementation until the theory is nailed down - particularly let's ignore doing things on-the-fly while we're flowcharting it
kcodyjr: can we make assumptions like, pageflipping and shadowfb are required for this to work?
bridgman: I don't think so; page flipping doesn't know about source windows
bridgman: only the compositor knows about all the different app windows
kcodyjr: app windows draw to their logical handles in their chosen (or sRGB default) colorspace. compositor picks that up, copies to a temp while performing source->ciexyY conversion.
kcodyjr: compositor itself deals with those temp's and produces an assembled frame, still in cie xyY
kcodyjr: that gets translated to the monitor's space and written to the back buffer, which must then be delivered by flipping or copying during vblank
kcodyjr: but one app in particular is a question; the X server itself. does it make sense to mandate shadowfb, and the shadowfb is the sRGB buffer? translated to CIE xyY during shadow flush? or does that totally break exa...
kcodyjr: and separately, to implement exa, does that mean that acceleration now occurs in the compositor's colorspace?
bridgman: guess I'm not sure what you mean by "the X server" - the server doesn't draw on its own AFAIK, it just manages windows and stuff; clients draw by making calls to various drawing (acceleration) APIs
kcodyjr: except when no acceleration api's are active
bridgman: for each API we need to make a colour space decision and that will probably be sRGB
kcodyjr: or when exa refuses the call
kcodyjr: semantic correction; a default color space decision; some api's but not all will be able to support colorspace control per whatever their native element is
bridgman: do you mean EXA refuses the call or just "the driver's EXA hook refuses the call so it falls back to the default code in the server for that acceleration API" ?
kcodyjr: the latter
bridgman: so you're still drawing through EXA
kcodyjr: what does it do, turn it into a gazillion 1x1 solids as a last resort?
bridgman: I think it just software renders; not 100% sure though
bridgman: that's one of the many reasons I'm glad we hired agd5f ;)
kcodyjr: the X driver needs to supply a framebuffer to something; presumably that fb gets used when an accel call isn't doing the job
bridgman: I can ask him dumb questions in private
kcodyjr: ;)
bridgman: there probably are some non-acceleration drawing calls but I doubt they are used these days
bridgman: cairo/pixman maybe
bridgman: something for me to ask about tomorrow
bridgman: anyways, for every drawing path we need to define a colour space or say "yeah, I can live with my output being interpreted as sRGB"
bridgman: I find colours are subtly different every time I change acceleration apis anyways
kcodyjr: yeah that's because either nobody ever had this discussion, or it never led anywhere
kcodyjr: i was able to smash through the brick wall and make sense of it in the print world
kcodyjr: believe me it isn't easy getting a color laser printer to spit out the same colors two days in a row
bridgman: the best advice I have seen on the internet so far is :
bridgman: I highly recommend obtaining a copy of DIGITAL VIDEO AND HDTV ALGORITHMS AND INTERFACES by Charles A. Poynton, Morgan Kaufmann Publishers, 2003
kcodyjr: noted for when i have $$ for book buying...
bridgman: I can imagine; people with expensive colour printers actually care about colour
kcodyjr: expensive in this case was $30,000
bridgman: I just care that red != green != blue
kcodyjr: used
bridgman: yep
bridgman: ooh
kcodyjr: xerox docucolor 2045, with the 60x firmware upgrade ;)
Samad: hi all
kcodyjr: yesterday's tech now, to be sure
bridgman: I'm used to sitting through presentations where the primaries all map into slightly different shades of sickly green, and you have to guess at what point the presenter is trying to make
rainbyte: bridgman, do you recommend that book as introduction for video devices programming
bridgman: Samad; hi
Samad: i need help about driver programming
bridgman: not sure, I haven't read it myself
Samad: hi bridman
kcodyjr: so, i was hoping we'd provoke others to join the discussion
rainbyte: hi Samad
bridgman: I looked through a few pages on GoogleBooks and it looked useful
Samad: hi rainbyte
Samad: i need help about driver programming
Samad: mean RAMDISK partition
rainbyte: bridgman, ahh, ok, but is it an advanced book or for beginners?
rainbyte: ahh, you haven't read it, sorry bridgman ^^
bridgman: seems to be pretty advanced
bridgman: to be precise, on this channel we're sorting through a bunch of different interpretations of standards
bridgman: all the people who provided those differing interpretations seem to think this book is the bible
bridgman: so either it's really good and the author is way smarter than us or it's really ambiguous
bridgman: I have a stack of books which were supposed to be definitive but which turned out to be brilliantly ambiguous
Samad: i need help about driver programming
Samad: mean RAMDISK partition
bridgman: do you have specific questions ?
Samad: yes
bridgman: hmm.. this channel is really graphics driver programming; not sure where to go for ramdisk
bridgman: ask away, maybe someone will know
Samad: I have partition my ramdisk upto 750 MB out of 4 GB but i need 3.5 GB out of 4 GB
bridgman: that will leave 512M for your OS and all the I/O ? that's going to be pretty small, isn't it ?
Samad: no
Samad: os XP RAM 4 GB
bridgman: hmm... this is actually linux graphics driver programming so probably not a lot of windows expertise here
Samad: i have used MmAllocatePagesForMdl() not getting expected result
Samad: can u help me the channel where i can get help?
bridgman: I don't really know what to suggest; it's a perfectly reasonable question but I don't know who would have the answer
bridgman: my first thought would be one of the MSDN forums
cxo: are you talking about the pmem driver??
Samad: hmm
cxo: to use the video card memory?/
Samad: no RAM memory
kcodyjr: don't suppose yangman's still with us
yangman: just finished reading the backlog, actually
bridgman: this is the only useful forum discussion I found :
bridgman: http://www.techtalkz.com/microsoft-device-drivers/285197-using-mdls.html
bridgman: you want to find a forum where MVP's hang out
bridgman: and that's the best I found
Samad: ok thanks
bridgman: that link seems to point to an archive, trying to find the active forum now
yangman: is CIE practical to use in a 1-byte-per-channel space?
yangman: seems like we'd be losing an awful lot of precision
bridgman: it's wierd; looks like the forum was very active until June 2008 then died, which supports it being an archive, but I cna't find the primary forum
bridgman: yangman; I think kcodyjr is suggesting CIE be the lingua franca for managing the conversions, not that we do everything in CIE space
bridgman: might use 16-bit or float for the colour space definition
yangman: right, ok.
kcodyjr: i was actually thinking 32-bit floats
bridgman: then the actual data would be 8 bit per component in whatever space
yangman: yeah, that makes sense. everything I've been reading so far references CIE in one way or another
kcodyjr: no i mean 32 bits per channel
bridgman: you might want to stay away from floating point frame buffers
kcodyjr: that's my first instinct as well
kcodyjr: but i understand the r6xx is pretty happy about doing floating point math
bridgman: all the internal calculations are floating point; shader engine is a floating point math monster
bridgman: we convert to fixed on the way in and out
kcodyjr: normally in luma-chroma, a lot more precision is given to luma because that's where the eye is more sensitive
bridgman: from/to
bridgman: that's why everyone uses rgb, you ignore that little optimization then you don't have to worry about 16/8/8 framebuffers ;)
kcodyjr: but then, most colorspaces are somewhat attuned to the human perceptive oddities; the chroma values are (to varying degrees) optimized stepwise
kcodyjr: not so with xyY; there we're looking for a mathematically linear space, deliberately devoid of perceptual tweaks - we will need high precision it might actually need to be floating point as well
kcodyjr: it may mean taking special care to ensure that only the involved code accesses the "real" floating point framebuffers, but it would make the whole thing smoother
bridgman: I imagine the calculations would have to change enough to PO everyone
bridgman: you can't just add the R's, add the G's, and add the B's any more
bridgman: you add the Y's and sort of average out the x's and y's
bridgman: pain in the ol' heinie
kcodyjr: weighted average
bridgman: I don't think we have a weighted average shader instruction
bridgman: go away ;)
kcodyjr: and yes we're talking about a fundamental shift from tristimulus to luma-chroma in the rendering/compositing steps
kcodyjr: heh ;)
kcodyjr: shouldn't be too hard to simulate ; push push mul push push mul add div
kcodyjr: think i'm missing a constant in that. oh well. postfix math was awhile ago .;)
bridgman: I'm sure that will run just as fast as an add, right ?
kcodyjr: heh ;)
bridgman: do we really call it postfix these days ? is Reverse Polish Notation politically incorrect too ?
bridgman: I feel very old
kcodyjr: i have no idea, it was postfix when i was in high school, circa 1994
yangman: postfix is just easier to say
bridgman: http://www.hpmuseum.org/rpn.htm
yangman: postfix is also more or less self-explanatory. if someone brought up "RPN" out of nowhere, I'd have to ask what it is ;)
kcodyjr: but we digest...
bridgman: yeah, I have the same problem with postfix, ie "what the heck is..." ;)
bridgman: I vaguely remembered "infix" being the opposite of RPN and guessed
kcodyjr: prefix is the opposite of rpn; infix is what most of us call "normal"
bridgman: ok, so blah blah blah we'll talk about all the options then decide to do it in the compositor, right ?
bridgman: compositor guys will love it because then you need a cmopositor
bridgman: driver guys will love it because the colour management people will stop bugging them
bridgman: colour management guys will love it because they think someone is listening to them
bridgman: everybody wins
yangman: hooray
kcodyjr: hardware guys will love it because they get told what people will pay for in the next upgrade, that is, hardware weighted average instructions...
bridgman: so where does colourspace definition go; in the composite extension ?
kcodyjr: that i don't know
bridgman: ah yes ;)
kcodyjr: driver guys not so much because -LOTS- of things will need touching
yangman: so, what colourspace is the backbuffer?
bridgman: I think the driver is not touched
kcodyjr: what does the composite extension do -exactly-
bridgman: driver just passes the values through
bridgman: I don't know exactly, it sorta says "hey you can redirect me"
bridgman: give me a minute
bridgman: I sort of have just-in-time understanding
bridgman: "This extension causes a entire sub-tree of the window hierarchy to be rendered to an off-screen buffer. "
kcodyjr: the no. we're talking about a compositing step entirely independent of that.
kcodyjr: we're also talking about -compelling- the entire window hierarchy to be off-screen
yangman: does that include the window decorations, or is that wm dependent?
bridgman: http://ktown.kde.org/~fredrik/composite_howto.html
bridgman: kcodyjr; I understand, the composite extension just makes it possible for the compositor to do it's thing
bridgman: there's probably some kind of protocol which tells clients to make the windows compositable
bridgman: that's the next thing to understand
kcodyjr: i'm reading it as, the composite extension brings details of the hierachy to the compositor rather than just the entire assembled desktop
bridgman: there is a common protocol for window managers
kcodyjr: but we need a compositor even when we're only seeing a single assembled desktop
bridgman: agreed, but that is increasingly becoming the norm
bridgman: I always run Compiz, just so I can show people video on a spinning cube
bridgman: it makes them think I'm smarter than them
kcodyjr: personally i hate the spinning cube; plus which overlays might still have been useful if compositing was done in a 2d realm
kcodyjr: overlay would just be a late-compsite
kcodyjr: late-composite even
kcodyjr: but i digress again
kcodyjr: even in the non-compositing-extension case though; certain api usages imply compositing, imo xv is one of them
bridgman: I agree; but Keith likes coordinate transformations
bridgman: every new protocol has to include them somehow
bridgman: the spinning cube was inevitable
kcodyjr: i don't see that we're talking about a protocol here
kcodyjr: oh, that
bridgman: hold on a minute, let me find the protocol that window managers and compositors use
bridgman: that's probably the best bet
bridgman: ewww.. ICCCM
yangman: on a sort of related topic, anyone happen to know how to do exponents with arbitrary base quickly using only exp2?
kcodyjr: oh heck, there was a combination of exp and log that did that, but i forget it...
kcodyjr: reading that composite howto
bridgman: don't you just multiply or divide by 2/base or whatever ?
bridgman: before doing the exp2 ?
yangman: and, from a more practical point of view, we need to nail down how exactly an app sends a "colour accurate" rectangle into the pipe for display, with the limitation that it can only write to a 8-bit-per-channel buffer
kcodyjr: server-extension-driven compositing is based around consciously activating it, telling it to redirect all current and future toplevel windows offscreen
bridgman: I was thinking that the app draws in whatever colour space it wants, then tells the next stage how to interpret the 8-bit values for each primary
kcodyjr: what we're talking about has to apply to what x thinks of as the "onscreen" buffer; so we're talking about implementing compositing independently of the compositing extension
bridgman: AFAIK the composite extension says "you can composite me" and another app does the compositing
bridgman: we would modify the compositor to include colour space correction, and probably hook the composite extension so that it also announces colour space
bridgman: and again I'm only guessing here, it might be an ICCCM function
kcodyjr: composite extension says "server can redirect all apps' toplevels individually to offscreen buffers so that a compositor can later reassemble them"
bridgman: we need to find out what Compiz passes upstream in order to tell clients or their toolkits to punch the xomposite extension button and start drawing offscreen
nanonyme: Heh, I wonder if r6xx/r7xx ends up getting a regular Mesa driver at all or just a Gallium3D one. :P
yangman: so, what's the colour space of the main buffer? because at some point everything needs to be mashed together
bridgman: both; we've got mesa semi-running now
nanonyme: Oh, didn't know.
bridgman: fixued function and shaders are working, just crashes after the first frame
kcodyjr: yangman, the proposal is CIE xxY
bridgman: needless to say that's top of the list ;)
kcodyjr: sorry, CIE xyY
yangman: but we only have 8-bits per channel
nanonyme: bridgman: Just wondering since apparently Gallium3D just went in mainline Mesa.
bridgman: the informal plan is that we'll have classic mesa running ok about the same time Corbin & co have 3xx Gallium running, then we put the two together to get 6xx Gallium3d
kcodyjr: 8 bits per channel will function but may not give us the optimal results we want
bridgman: our guys are chomping at the bit to do Gallium3D as well
yangman: let me be more specific: I like the idea of using CIE as the back buffer, but I think we need to stay with RGB in the near-term
bridgman: and now that G3D has hit master it's just about time
kcodyjr: one channel for x, one for y, one for Y; x and y being comparable to U and V, that's more precision than we usually get... but we also don't have any implicit bias, it's linear
nanonyme: So depending how far the driver for classic Mesa is, might not make sense to do it at all. :p
nanonyme: (But yeah, apparently it's far enough to justify its existence)
kcodyjr: then you really mean stay with tristimulus near-term, and it comes down to picking the "standard" R, G, B values, since those will be immutable in a tristimulus model. i suggest the same primaries used in sRGB.
bridgman: I guess; if our work goes real slow and Corbin's goes real fast we might jump across before having useable classic mesa, but I don't think it will work that way
yangman: right. I think that's the implicit assumption right now?
kcodyjr: yes it is
bridgman: kcodyjr; I think we should stay with tristimulus long term and use CIE values for documenting colour spaces
nanonyme: bridgman: Well, I think developers keep saying that it's really easy and fast to make drivers for Gallium3D. *shrug*
kcodyjr: but a tristimulus "main" framebuffer does make truly accurate color correction impossible
yangman: so, what happens in the case that a user has a monitor that has a gamut that's not equal to sRGB, but bigger for certain primaries, and want to be able to use all of it?
bridgman: one option for the main frame buffer would be CIE xyY
bridgman: just not the default
yangman: relatedly, how does it work for Windows/Mac?
kcodyjr: oh i see what you mean
bridgman: the problem is that the display isn't xyY
kcodyjr: yangman, using rgb-based "main" framebuffer, that case is not possible
bridgman: I'm suggesting that the output of the compositor is whatever space best matches the display
kcodyjr: then the compositor has to either deal natively in CIE xyY, or convert to xyY and back on-the-fly; there's no other way i know of to convert between spaces with different primaries
bridgman: yangman; that raises another good point; we might want a query mechanism so that a truly enlightened app can find out what kind of display is available so it can optimize the colour space it's using
bridgman: and maybe it would simply pick CIE xyY as the output
bridgman: kcodyjr; I was thinking that the compositor would know the CIE xyY values of the app frame buffer primaries, and the xyY values of the display primaries, and would do the best it could
bridgman: converting on the fly while compositing
kcodyjr: xyY is not a tristimulus space, it's a luma-chroma space
bridgman: using an intermediate buffer with CIE values doesn't buy you anything
kcodyjr: yes, it does: it means you're only dealing with averaging and addition operations during the composite step; whether that's of any value probably depends on the hardware
bridgman: I understand that, but convention is to describe tristimulus colour spaces using the CIE xyY values of the primaries, right ?
yangman: btw, gamma ramp adjustments aren't cheap in shader, afaics. it's not easy to do arbitrary-base raised to arbitrary-power
bridgman: but you lose precision if you go with 8-bit-per-component CIE xyY values; you want more bits for Y and fewer bits for xy most likely
yangman: so, LUT seems like the only way to go
bridgman: staying with app and display colour spaces gets you more bang for your bits
bridgman: but LUT can't do colour space conversion, only R' = f(R), G' = f(G) etc...
bridgman: where f and f are different, of course ;)
yangman: right. only the ramp portion
yangman: just commenting on doing colour space conversion in shader in general
kcodyjr: conceptually the tristimulus color spaces are defined by 3 channels, each of which corresponds to a wavelength of monochromatic light
kcodyjr: in other words, the physical primaries are always dots along that horseshoe shaped line
kcodyjr: the -could- be described with an (x,y) pair, but more accurately described with a wavelength measurement
yangman: it'd help if we had someone that really understood how colour spaces is currently handled along the entire stack of Windows/Mac, so at least we know what the status quo is
kcodyjr: i think the ideal format for overall precision would be CIE xyY using 32-bits floating per channel
bridgman: but the primaries are usually not along the outside of the horseshoe, are they ? almost every pic I see places them well inside the monoochromatic outside
kcodyjr: primaries are -always- along the outside of the horseshoe, that's their definition, unless the physical phosphors are somehow multichromatic
bridgman: I don't think we have the memory bandwidth to handle 128-bit pixels today
yangman: my best guess is apps assume sRGB space, but it's really just fit to whatever primaries the display is capable of, and apps that know better can compensate for it appropriately
kcodyjr: no, even apps that know better will not be able to effectively compensate
kcodyjr: not without a deliberate primary correction
kcodyjr: there's no "neat" way to deal with the primaries changing, the system wasn't set up for it
yangman: so, what does charts like this mean?: http://www.xbitlabs.com/images/other/24inch/6gr1s.png
kcodyjr: probably a limitation in how finely it can control the luminance near the top and bottom of its range
bridgman: http://en.wikipedia.org/wiki/Color_space
kcodyjr: but the meaning of the points is that they correspond to a physical emission of monochromatic light
bridgman: not like I feel good about citing wikipedia, but...
yangman: so, that corresponds to the range of colours the display is capable of, right?
kcodyjr: the inside of the triangle is the range of colors the display can produce, yes
bridgman: for a display, yes; for a file colour space it's what the colour space can represent
kcodyjr: the meaning of the area inside the horseshoe is that a straight line between any two points -on- the horseshoe, mixes those two colors in the way you'd expect
bridgman: what you can display is the intersection of file format colour space and display colour space
bridgman: and your colour conversion takes everything from the app colour space, tries to convert it to display colour space, and clips the colours that don't fit into the display colour space
yangman: right
yangman: so, how feasible is that to do in shader?
bridgman: should be a no-brainer
kcodyjr: which brings us back to CIE xyY's advantage; from there a color can be conveniently (relatively) remapped into an arbitrary set of multistimulus primaries
bridgman: sure, but if you convert a -> CIE and CIE -> b you can just cnnvert a -> b and eliminate the middleman
kcodyjr: true. but that's not reality.
kcodyjr: reality looks more like:
bridgman: I think it is reality; you want a hypothetical 32-bit-per-component intermediate frame buffer
kcodyjr: a -> CIE; b -> CIE; c -> CIE; d -> CIE; ... ; CIE -> z
bridgman: I'm saying do it all in one shader
bridgman: or a -> z, b->z, c->z at copy time
yangman: so, the thing is, only 2 types of apps really care about colour space: image editors/viewers, and video players
kcodyjr: that means coming up with multiple conversion matrices, and -that- assumes that it can be done as a matrix
yangman: everything else doesn't care what it's drawing to
kcodyjr: introduce the heavyweight page composition application, you're putting a gazillion images onto a page, each of which probably has a separate colorspace
yangman: the question is, is all that extra work a good idea when it potentially gives no benefit most of the time
yangman: we can still provide a hardware accelerated colour space conversion hook
kcodyjr: flip side: is it possible to make the shaders adaptive enough to go from an arbitrary space, to an arbitrary space
yangman: but seems a little overkill to manage the colour space of absolutely everything
kcodyjr: plus which, even if done inline, you need a 32 bit float per channel intermediate value., because you still have to pass through the xyY space
bridgman: but 32-bit-float-per-channel comes for free inside a shader; it's just godawful expensive when you go off-chip to the framebuffer
nanonyme: yangman: Isn't the whole WM-equivalent in Windows aware of colourspaces?
kcodyjr: yangman, the alternative is to say that unless you happen to have a display whose physical primaries match the sRGB standard, you're SOL
kcodyjr: ok; then let's consider it - is it possible to be flexible enough with shader logic
bridgman: the annoying part is that apparently modern displays are pretty close to sRGB
bridgman: so for $220 you can un-SOL yourself
kcodyjr: or would we need fixed routines from every imaginable space to every other imaginable space
kcodyjr: how about $1500 when you can't find a worthwhile upgrade for your agp based system
bridgman: I guess we could use 10-bit-per-pixel, might be enough for Y
bridgman: bah... X2, 780/790, probably still outruns your AGP box
kcodyjr: and we're not talking about the card either we're talking about the display; good luck even finding out what the primary wavelengths are before buying it, and it could well be your $3000 lcd hdtv that you can't get color correction on now
yangman: nanonyme: I don't know, but I don't think it would be
bridgman: I agree that we need colour correction; just saying that this feels like one of those cases where "pretty good" will greatly improve everyone's lives and "perfect" will never get past IRC and conferences
kcodyjr: it's possible but i don't think we're there quite yet
bridgman: sRGB is afraid of the edges too :
bridgman: http://en.wikipedia.org/wiki/SRGB
kcodyjr: it's possible that the "standard" primaries just aren't pure monochromatic
yangman: I was on a huge LCD-review-reading spree a few months back. most of them are near-but-not-quite sRGB. the better ones have more gamut in the green direction
nanonyme: yangman: If it's at all related, at least monitor colour profiles are directly mapped to the monitor on the OS level, not on program level. Maybe I'm just misunderstanding what you're trying to get. :)
yangman: that chart I posted earlier is for the monitor I have
bridgman: kcodyjr; yeah, I think we need to understand that with some urgency
bridgman: every phosphor I have seen has an emission curve, not a spike
bridgman: I think that corresponds to a probability distribution not an actual blend of colours, but
bridgman: it's never been clear
yangman: nanonyme: having been learning about this stuff over the last couple weeks at every level, I think it's actually done at both
kcodyjr: emissions happen at a single wavelength when electrons fall from one valence to the next lower
kcodyjr: the distribution of wavelengths thus depends on the distributions of compound in the "phosphor"
kcodyjr: so yeah it stands to reason they wouldn't be perfectly clean
kcodyjr: but the principle does hold: given three fixed points in the (x,y) coordinate space, you can compute the tristimulus values to reach another given point in that same plane
nanonyme: yangman: Indeed, might be wrong. My knowledge goes about as far as that you get to pick the profile in monitor settings under the display settings.
kcodyjr: in fact it's probably simpler than calculating based on curve coordinate
bridgman: and I guess the blend of colours drags the result away from the edge
kcodyjr: logical, since the edge is defined as pure monochromatic and anything in the middle can be defined as a blend of any two points on the horseshoe who share a line passing through the point of interest
kcodyjr: i think it's a paper algebra question whether it can be done in a single step
bridgman: ok, light up the MostAwesomeDudeSignal
bridgman: he likes that stuff
kcodyjr: lights a bonfire and puts some MostAwesomeDude bait on it, hoping smoke signals will suffice...
nanonyme: wonders what the MostAwesomeDude symbol looks like
kcodyjr: hmm... it couldn't be....
kcodyjr: spreads out a bunch of birdseed
yangman: so, putting the CIE stuff aside for the moment... what's a stop-gap measure we can implement in the next, say, 3 months, and merged into xorg?
kcodyjr: and poises a heavy rock on a cliff above, just for effect...
bridgman: now we're talking
bridgman: that would be an Acme ruckscak ?
bridgman: rock
kcodyjr: ;)