The OpenGL Support State For Mesa 8.1

[smitty3268]

Build your own or be ready to pay freedesktop's legal fees when they get patent trolled

Didn't Apple invalidate the patent when HTC tried to sue them?

And isn't HTC a member of some linux patent group which would keep them from suing?

The floating-point support is still a problem.

[smitty3268]

It seems so, but actually GLSL seems to be a bigger job than the other extensions - and for GL 3.2 and 4.x the GLSL work is not yet started. I'm not an expert however.

I think the main GLSL bits for GL 3.2 is just the natural stuff that comes with supporting geometry shaders. Which admittedly is going to be a lot. GL4 is still a long way off.

[galibert]

It seems so, but actually GLSL seems to be a bigger job than the other extensions - and for GL 3.2 and 4.x the GLSL work is not yet started. I'm not an expert however.

Once you have the geometry shaders, the tesselation shaders are in a large part more of the same. In other words, the issues we're going to have with having more than two shaders, the register linking, interpolation provider, all that will be done. It will just be adding a pair of passes. Only the software rendering will require work to implement the fixed-function part of the tesselation.

Two things I think are going to be painful with 4.00+:

• double support - gallium is fundamentally not ready for this, intel may or may not be be ok (as long as you have hardware support of course)
• subroutines - nobody is ready for this

The rest looks mostly ok (more direct access to vram pointers, more possibilities to keep things in vram, more fallout of unifications...).

OG.

[curaga]

And isn't HTC a member of some linux patent group which would keep them from suing?

OIN does not require _all_ of a company's patents to be thrown in the pool. It's entirely possible HTC is in without the graphics patents, say, with only mobile patents.

[89c51]

OIN does not require _all_ of a company's patents to be thrown in the pool. It's entirely possible HTC is in without the graphics patents, say, with only mobile patents.

We should ask politely. I don't think anyone approached HTC so far regarding that patent. And someone -hopefully influential- must do it.

[Gusar]

Why are people always making such a big deal out of s3tc? Is it really so hard to install libtxc_dxtn from a third-party repo? I'm sure there's an Ubuntu PPA with it, for Fedora RPMFusion has it, for Arch it's in AUR, Gentoo has it in the main repo even.
Yeah, the ideal would be to not require even that. But Fedora users are already used to getting some stuff (multimedia packages) from third-party repos, and Ubuntu users are no strangers to PPAs. So why the big deal out of the requirement to install an extra package?

Float textures are different, you can't just install an additional tiny library, you need to recompile mesa with --enable-texture-float. Even that can be handled with drop-in replacement packages from third-party repos, though this requires that the third-party repo maintainers always keep the replacement in sync with what the distro ships. So it's not as simple as libtxc_dxtn, which is a one time deal - you install it and that's that.

[89c51]

Why are people always making such a big deal out of s3tc? Is it really so hard to install libtxc_dxtn from a third-party repo? I'm sure there's an Ubuntu PPA with it, for Fedora RPMFusion has it, for Arch it's in AUR, Gentoo has it in the main repo even.
Yeah, the ideal would be to not require even that. But Fedora users are already used to getting some stuff (multimedia packages) from third-party repos, and Ubuntu users are no strangers to PPAs. So why the big deal out of the requirement to install an extra package?
.

Convenience is the reason. The average user will only care about his game (or whatever) not working. And coming from other operating systems which offer one click installs he won't bother to copy paste commands or built it himself. For him Linux will suck.

[Gusar]

he won't bother to copy paste commands or built it himself.

Which isn't required. Like I said, third-party repos have the library packaged, and distro users are familiar with those already.

For him Linux will suck.

If installing extra packages makes Linux sucks for him, then it already sucks for him. So why is a special big deal being made out of this particular library?

[mirv]

Which isn't required. Like I said, third-party repos have the library packaged, and distro users are familiar with those already.

If installing extra packages makes Linux sucks for him, then it already sucks for him. So why is a special big deal being made out of this particular library?

Technical reasons. S3TC is a rather good texture compression - 1/8th size best case scenario (from RGBA to DXT1, alpha channel discarded). Amount of memory used isn't the only issue; there's also time taken having to transfer data around. So from a performance perspective, it's quite nice.
There's also other side effects. What if you wanted to generate mipmap levels from a base texture? In distributing a game, you can just provide the base texture, then generate the mipmaps at runtime. This makes for a smaller game data set - and if you're looking at something such as, say, megatexture-type implementations, and you have to provide the data up front, it can add up to a few gigabytes of extra data that's not actually required.
So yeah, having the freedom to use an open source library implementation of S3TC is kind of useful.

[asdx]

Which isn't required. Like I said, third-party repos have the library packaged, and distro users are familiar with those already.

If installing extra packages makes Linux sucks for him, then it already sucks for him. So why is a special big deal being made out of this particular library?

You are trying to defend the broken patent system we have and come with excuses. What a retarded conformist you are.

You are one of those users we need less off. Seriously, fuck off.