Lightspark May Work Towards A Gallium3D State Tracker

[TemplarGR]

Flash will begin to die as soon as Firefox 4 is released and HTML5 <video> tag support is out in the wild. Nobody will need Flash to play H.264 videos any longer, and lots of other services (e.g. browser games) implement effects on top of <canvas> and JavaScript. Even Internet Exlorer 9 is there.

If people want to work on Gallium state trackers, please focus on OpenCL. It is the correct and portable way to implement stuff like this. A Gallium state tracker specifically for Lightspark will require multiple code paths to support other environments besides Linux. Gallium3D is no standard subsystem on the majority of operating systems.

Chrome 6 is out in the wild and plays video much better than Firefox 4 will...

[BlackStar]

So the Lightspark developers should abandond their project and go to work on OpenCL? Why would they do that?

Clean code. You don't want hundreds of state trackers.

You don't understand. Why would the Lightspark developers abandon their project to go work on something completely unrelated?

Clean code doesn't even enter the equation here. It's akin to asking of FreeBSD developers to go work on the Linux kernel or Mesa developers to go work on OpenOffice. If they were interested they'd be already doing that.

Using an abstract, open, multiplatform umbrella API you don't have to complicate things by building your own API.

And that umbrella API may be called Gallium. Why are you so dismissive?

[Jimmy]

Firefox doesn't support H.264 video. You'll still need flash for that.

More importantly, you'll need Flash for the snake oil Adobe is selling: ineffective DRM backed by DMCA thugs.

[V!NCENT]

@BlackStar,
Using OpenGL, or DirectSomething for that matter, is totaly overkill and leads to serialisation at the graphics lib State Tracker.

To everyone; Gallium3D is penetrating HURD (yeah laugh all you can but it works), Haiku and some orher niché OSs.

OpenCL is an extra layer, but universal.

I'm getting excited about how popular Gallium3D is getting; literaly everything graphics is getting accelerated by the GPU. Actualy, now that GPU's are programmable, the once boring and lame IBM PC has got an awesome co-processor.

Now give me Coreboot and I'll jump through the roof

[bash]

No need for H.264.

With the next generation Android OS and devices the WebM format will not only work on desktop computers (Firefox 4.0, Opera 10.6, Chrome 6, Internet Explorer 9) but also on mobile devices and Google TV sets.

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

So that leaves Firefox, Opera and Chrome on the browser side and Android on the mobile one. No idea how that will then magically make H.264 go away, seeing as the listed programs and systems don't even have a majority marketshare in either of the two markets.

Especially in the mobile space H.264 is pretty entrenched. Besides Android I have yet to see Apple, RIM or the Symbian Foundation announce support for this format in their respective mobile OSs. And those 3 alone have a global smartphone marketshare of 73%.

So I don't know where you get the idea there is no need or will be no need in the near-future for H.264. That codec isn't going away any time soon.

[V!NCENT]

Who sais that h.264 needs to die in order for WebM to exist? Can't WebM coexist and leave h.264 to the DRM'ed entertainment crap?

[fabiank22]

@BlackStar,
Using OpenGL, or DirectSomething for that matter, is totaly overkill and leads to serialisation at the graphics lib State Tracker.

To everyone; Gallium3D is penetrating HURD (yeah laugh all you can but it works), Haiku and some orher niché OSs.

OpenCL is an extra layer, but universal.

I have read these three sentences over and over just now and they don't make any sense whatsoever.

If using Direct"something" is overkill, then why does it work on windows? I mean they only do DirectX+DirectShow+GpuBackends and I haven't had problems with that. The reason why trying OpenGL isn't done is because the state of OpenGL within Linux is so laughable that people would rather write their own additional APIs to Mesa than using it. Using an API instead of writing your own addition to it should NEVER be overkill, or your API sucks. Enough said.

Also, it's nice to see HURD and Haiku still surviving from a pure academic point of view, kernel design and all that, but I don't think porting work for advanced hardware is worth anything.

As for OpenCL, well see about it once they get a good API/State tracker, before that happens it's all smokes and mirrors

I'm getting excited about how popular Gallium3D is getting; literaly everything graphics is getting accelerated by the GPU. Actualy, now that GPU's are programmable, the once boring and lame IBM PC has got an awesome co-processor.

Actually Gallium offers that in no way? OpenCL isn't working right now, the cairo-backend is only working with softpipe(which defeats the purpose), QT-backends are only just rumors, heck, even the OpenGl state tracker is stuck in 2004. Popular because some developer said he considers using Gallium in the craziest possible way?

[bridgman]

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.

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)

[bridgman]

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

[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.