Lightspark May Work Towards A Gallium3D State Tracker

[bridgman]

I think I understand the disconnect now. You think the work required for 3D support on new GPUs is larger than the work required to implement a new GPU-based video decode framework and drivers and wonder why we work on 3D as a priority.

In actual fact, nearly everything you listed is shared from one generation to the next, and what we are doing to enable 3D on new hardware is *less* than what it would take to implement a new video decode framework... and the video decode framework would require pretty much everything we do for 3D anyways (eg the ability to compile and run shaders, the ability to draw primitives, the ability to access memory etc...). Remember that it's the upper levels of Mesa, shared across all GPU hardware vendors, which deal with all of the GL specific nasties... and it's that common code which needs most of the work to support higher levels of GL.

The proprietary drivers already have GL 4.x and OpenCL; video decode acceleration is WIP but is already working for some users. Mplayer supports GL output which doesn't normally have tearing issues unless you are running with a compositor, which I doubt you would want on an HTPC system.

[fabiank22]

Simple; the devs (both AMD and non-AMD) are all working on higher priority stuff first. Until the underlying Gallium3D hardware drivers are implemented and being used in all the major distros it doesn't make much sense building more upper layers and expecting them to be used.

Like I said, I don't get your focus. 3D requires a rather large sum of parts to work, shaders, advanced OpenGL, memory management, and so on. Even if you reach a milestone like glxgears(which took quite an amount of work) it won't mean that much, because hey, just basic 3D to the user.

Video Acceleration on the other hand would actually produce somewhat of a sales point. I'll make an example: My dad owns a 1080p HDMI-Plasma-TV and we both have a rather large collection of Music-DVD's, Blu-Rays, Rips of that for convenience and so on. In an ideal world I would build a simple and silent shuttleesque multimedia-PC within the range of 300-400?, put in a low class ATI-Card for HD-Playback, install Linux and Mplayer and simply transport my blu-rays or external harddrives whenever I want to watch/show something.
This is pointless right now because of the license costs for Windows 7 + DVD-Software alone are in the range of half the hardware costs.

I get that the Gallium-work needs to be done, that the new GPU-generations are knocking, and I don't mean to belittle your efforts in any way, but right now every ATI-generation is in the state of "half-working" - half-working 3D(getting there but not fast enough to be considered reasonable yet), half-working Video Acceleration(tearing, APIs, software), OpenGL 2.1, no OpenCL.

Maybe I misread things, but I don't think the developers were looking for "more features than OGL", but rather "something much smaller and simpler" where available.

The problem with discussing whether OpenGL is simple/okay enough for Lightsparks needs is that there is no consensus on what OpenGL actually means - some are talking about the OpenX-family(OpenGL ES, OpenGL, OpenCL, that audio thing), some mean OpenGL the spec(aka 4), and some mean the Mesa/Gallium implementation. So our discussion could be misinformed because the Lightspark devs may simply want to skip around the problems of the latter, facing the same problems KDE has right now.

[bridgman]

Maybe I misread things, but I don't think the developers were looking for "more features than OGL", but rather "something much smaller and simpler" where available.

If you want to run a few shaders, Gallium3D will probably be the simplest way to do it... and if you use Gallium3D, the thing you write ends up being called a state tracker.

[liam]

Read the replies.

Basically nobody thinks that writing a new state tracker is his best option. The best idea I heard was for him to continue to use cairo and write some shaders for the remainder. Apparently he hasn't come close to utilizing all the features of OGL, according to the commenters.
Having said that, I think the idea of a simple compositing state tracker is kinda neat.

[monraaf]

I don't understand why he doesn't use the Clutter toolkit for this. It has got textures for image files, cairo textures for your vector graphics and other drawing operations, video textures for video playback. They can respond to events, and you can combine and composite them in any way you want. And you can achieve all this with a minimal amount of code.

I'm afraid that by trying to reinvent the wheel and extending the scope of his project instead of focusing on the core, it will never reach a level where it's a viable alternative to the proprietary flash player.

[Jimmy]

Since when does Internet Explorer 9 support WebM natively? It will still require installing additional codec packs.

Since when does IE support Flash natively? Requiring the user to download and install something to view a web page isn't that obscure or prohibitive. Its just switching Flash for codecs. To the end user it's the same thing: download and install something.

Not ideal, but still workable.

[Svartalf]

The fact that everyone seems to be considering the raw Gallium3d API for acceleration goes to show how much OpenGL sucks. Think about it for a moment.

Keep trolling...

[bridgman]

I know, which is why I'm kind of surprised nobody has come up with a state tracker that does the thing DirectShow + GPU-Backends do(of course minus the codecs). I know that NVIDIA got their thing going and won't write Gallium Code, but I don't really get why you ATI-guys don't simply write "one API to work with all" for your Cards, give the nouveau-guys the option of hooking their stuff in and support that for a while. It would basically give you a monopole on cheap multimedia open-source linux solutions, if the vendor adds in BluRay-support there would have been even a slice of that web-enhanced TV-Solution market.

Simple; the devs (both AMD and non-AMD) are all working on higher priority stuff first. Until the underlying Gallium3D hardware drivers are implemented and being used in all the major distros it doesn't make much sense building more upper layers and expecting them to be used.

Probably. Doesn't change my point though.

Sure it does; if he meant Direct3D then he was right-ish, if he meant to include DirectShow then he was wrong-ish

[fabiank22]

Direct"something" is not the same as Direct3D. The equivalent of using OpenGL would be using Direct3D. The equivalent of using DirectShow on Linux would be a dedicated video client, which could use Gallium3D or could use the hardware directly in the same way that EXA and Xv do in the open drivers.

I know, which is why I'm kind of surprised nobody has come up with a state tracker that does the thing DirectShow + GPU-Backends do(of course minus the codecs). I know that NVIDIA got their thing going and won't write Gallium Code, but I don't really get why you ATI-guys don't simply write "one API to work with all" for your Cards, give the nouveau-guys the option of hooking their stuff in and support that for a while. It would basically give you a monopole on cheap multimedia open-source linux solutions, if the vendor adds in BluRay-support there would have been even a slice of that web-enhanced TV-Solution market.

VDPAU and the ISV-only version of XvBA are probably closest to DirectShow; not sure about the latest Intel video stack (ie I don't know the internals, not I have doubts about it)

XvmC with MPEG only. Which I don't understand even harder, because their on-CPU Chips are capable of 1080p easily, working support for that on all three major plattforms would give a good opportunity to kill off the complete market for cheap graphic cards and third-party mainboard graphics. Sis and Via would be so finished once Sandybridge hits, and a small segment of NVIDIAs market too.

For clarity, I believe Vincent meant "Direct3D" not "DirectSomething"

Probably. Doesn't change my point though.

[bridgman]

For clarity, I believe Vincent meant "Direct3D" not "DirectSomething"