ATI Evergreen 3D Code May Soon Go Into Gallium3D

[etnlWings]

HDCP's been a losing battle for a while. What will be impressive is when there's a library for reconstructing all the bits necessary (it's mostly Java, I believe) to be able to navigate your BD ROMs.

[pingufunkybeat]

Anything that lets me watch a BluRay on my Linux computer without running strange closed-source software is great in my book.

There is a shelf full of HD movies in my local video rental shop, and I have a 1080p monitor, yet I can't watch any of it. Screw the MPAA mafia.

[TomcaT-SdB]

What part of this aren't you getting? That's not a response to the argument I put forward.

I suppose I should have spelled it out more clearly, that given certain market conditions, technology adoption tends to happen at a fairly brisk rate. Without going back through the thread, it seemed like your argument was that a significant portion of the population doesn't require the latest and greatest tech to meet their specific use cases (based on the VCD quality comment, etc). I fully understand this, and agree, many people aren't early adopters. I still have an old CRT SDTV at home. But, even if I _wanted_ to, I couldn't go out and buy an SDTV without spending quite some time searching for one shopping at retail stores. Blu-ray is supplanting DVD sales much faster than the switch from VHS to DVD, so barring digital distribution, Blu-ray is on track to become the standard for content distribution regardless of how many people think DVD resolution is just fine for them. 3D blu-ray releases could very well be the standard distribution type for releases in the next few years.

...never mind whether anyone uses it. My HDTV came loaded with recipes and meditation routines. I didn't ask for any of it and I sure as hell don't use it (let alone require that my PC and receiver be new-age-bullshit-enabled) but by your logic, that makes me a 'holistic raw food' chef.

Last I checked, there wasn't an industry wide push for cook-book TV's. Small additions which help with product differentiation aren't in the same league as major feature sets like 1080p or stereo support.

Excuse my brusque manner but learn to read. Your evidence doesn't support your premise. Your proceeding argument was a blatant strawman.

Learn to comprehend and debate then. My premise is quite simple, the entertainment industry is showing a strong embrace of stereo in the upcoming year(s), therefore there ought to be plans in place supporting it in the free driver set. At the very least, make sure that it's accounted for early on so that there's not a "crap, we need redo significant parts of the driver to do this" when / if the devs can get around to it.

If standardization efforts for stereo formats for general consumer use, stereo hardware production, and stereo content production doesn't show a strong embrace of stereo then I'm not sure what would be considered embracing stereo. Making baseless assertions about the status of stereo within the industry doesn't help support your position, which, I think is that stereo support isn't important for the drivers (correct me if I'm wrong here).

We probably have two different views on the importance of content. In my view (as a Linux only user for several years now), being able to use current content is important. A technical problem like "we can't support stereo" is something that should be avoided if possible. Again I agree on the premise of getting basic OGL support in place first, so in that regard I think we're in violent agreement. I think that stereo support should be high on the "after initial OGL support is working" feature list based on the reasoning above.

3D TVs have been on the market for a number of months, now and the various 'old hotness' features give us a good indication: rear projection, plasma, 720p, LCD, HDMI, 1080i, 1080p, 100hz, LED. With every single upgrade, the prices remained punitive until the next gimmick arrived. 3D isn't going to be any different.

As was my initial objection, which rested with your assumptions, not your question.

Stereo capable TV's have been on the market for over a year. Stereo TV's which _officially_ support the upcoming standards AFAIK aren't officially out yet. I'm not sure what the price will be, but the cost of the set may be less than you anticipate. Given that the cost to produce the panels was the major reason for the costs of the features you listed, that isn't in place now. HDMI inputs are on low-end sets BTW, and have been for some time now. HDMI is cheap to implement, so it's not a cost driver. What may be a cost driver would be the shutter glasses though, but I haven't heard pricing for those from set vendors.

[droidhacker]

Anything that lets me watch a BluRay on my Linux computer without running strange closed-source software is great in my book.

There is a shelf full of HD movies in my local video rental shop, and I have a 1080p monitor, yet I can't watch any of it. Screw the MPAA mafia.

This won't do that though....
All this does (in theory) is allow you to decrypt the garbage between your GPU and your monitor -- which doesn't apply AT ALL to linux since it isn't even implemented.

What it DOES do is it allows you to capture the output of an HDCP device and decrypt it into a usable format.... i.e. universal video capture device for HDMI. Cute, but too late in the processing to be of much value since at this point it has already been decoded from h264 into just plain too much crap that you can't fit on any known disk...

What we need isn't HDCP, it is the AACS and BD+ crap.
Note: Got AACS. Its quite dead.
BD+ is still the ugly mess.

http://forum.doom9.org/showthread.php?t=150014&page=3

http://www.videolan.org/developers/libbluray.html

... if these hackers ever get it done

Just note: HDCP is from the GPU to the monitor. AACS and BD+ are from the disk to the GPU and are unrelated to HDCP.... i.e. you start with a compressed, encrypted, and scrambled h264, apply AACS and BD+ to generate a compressed but NOT ENCRYPTED OR SCRAMBLED h264, decompress it, and encrypt it again with HDCP, then send it off to the monitor, which decrypts and displays it... or I might be slightly off in this... it might be AACS and BD+ from the disk to the CPU, wide open from the CPU to the GPU, and then AACS from the GPU to the monitor.

bridgman: what is the stumbling block keeping UVD as such a super secret? Is it HDCP? Or does UVD also do AACS and/or BD+?

[droidhacker]

Note: software players contain their own AACS keys, which suggests to me that the first decrypts are all in the CPU.

[bridgman]

bridgman: what is the stumbling block keeping UVD as such a super secret? Is it HDCP? Or does UVD also do AACS and/or BD+?

Without going into details, the content remains encrypted all through the decode process, and encrypted content is passed down to UVD by the driver. To say that "wide open" is discouraged would be an understatement

I can't really be more specific than that, sorry.

[TomcaT-SdB]

bridgman,

Thanks for the work on the drivers. Debates aside, the work that's being done for the open source drivers as well as fglrx improvements is much appreciated. Quick edit: Thanks for the Q&A sessions as well.

[darkbasic]

as well as fglrx improvements is much appreciated

Bah, fglrx needs to support latest kernels and xorg-server instead, otherwise it's just a useless pile of shit...

[nanonyme]

Bah, fglrx needs to support latest kernels and xorg-server instead, otherwise it's just a useless pile of shit...

Bah, that just means it's useless for you.

[darkbasic]

Bah, that just means it's useless for you.

Obviously. I cannot use it, otherwise I will be much more than happy being able to switch from open to fglrx with a simple 'eselect mesa'