Ccing by request.

We have no intension of supporting osmesa moving forward.

The right thing would be switching to use SwiftShader whenever possible.

capn@, sugoi@: should we switch to use SwiftShader when --override-use-software-gl-for-tests is passed in, on platforms where SwiftShader is enabled (Win, Linux, Mac)?

Submitter: SwiftShader should support WebGL in this configuration via --use-gl=swiftshader with no code changes needed to the browser. Can you please confirm?

> The right thing would be switching to use SwiftShader whenever possible.

@zmo:

The intention is good, but as mentioned in the issue description, swiftshader currently does not support all texture formats that osmesa does.

In particular, all my textures in my WebGL project are rendered as fully black in swiftshader, while they render correctly with osmesa (and all physical desktop GPUs).

I suspect this is a bug or missing feature in osmesa, probably in the DXT texture implementation. In any case, this renders (no pun intended) swiftshader useless for headless testing of many WebGL sites.

> Submitter: SwiftShader should support WebGL in this configuration via --use-gl=swiftshader with no code changes needed to the browser. Can you please confirm?

@kbr:

Yes, `--use-gl=swiftshader` works fine with many WebGL examples. The issue is not that swiftshader doesn't work at all, but that it is not (yet?) a practical replacement for all use cases due to rendering bugs (see above).

I would (probably) be happy to use swiftshader if it could render the contents of my page correctly.

Independent of whether or not osmesa is intended to be supported going forward:

At least with my current understanding, this issue looks like a refactoring accident, with osmesa accidentally no longer being counted as a software GL implementation, when it was before. It is not that Chromium is working less well with osmesa than it did before, only that it no longer uses it even if explicitly requested.

It would thus be fantastic if we could fix the enabling/disabling logic, so that developers whose sites swiftshader cannot yet render continue to have an opt-in alternative that can.

Would you mind giving us a list of formats that SwiftShader doesn't support in your tests?

SwiftShader is fully compliant with the OpenGL ES 3.0 spec and does expose and support the GL_EXT_texture_compression_dxt1, GL_ANGLE_texture_compression_dxt3 and GL_ANGLE_texture_compression_dxt5 extensions.

SwiftShader also passes the WebGL conformance test suite, so if a format that should be supported isn't properly supported yet, we would like to add it as a test in that test suite, to help us make sure we don't break that support going forward.

Note that ASTC support isn't currently exposed, so if that's what you're using, this could be the issue (although I don't know that OSMesa supports ASTC).

Also, if you can provide us with a simple WebGL test that reproduces your issue, we'd be happy to look into it.

Thanks

niklas@: let me echo sugoi@'s request. We should figure out why your content isn't rendering with Swiftshader and fix whatever's wrong. A huge amount of effort has been expended to switch all of Chrome's software rendering testing from OSMesa to Swiftshader, and we are going to delete Chromium's copy of OSMesa and, ideally, the OSMesa support code once that's complete.

Hmm, what sugoi@ said really sounds like what I'm doing should really work in swiftshader. I'm using what three.js calls "RGB_S3TC_DXT1_Format".

Let me dig a bit deeper and check whether this isn't the result of some building / packaging error, as the Linux system I run this on is a bit custom.

Just in case a blind guess helps: I remember there were some patent issues with S3TC leading to some software shipping it separately. Would Chromium's S3TC support be linked in its main binary or in some separate location (e.g. .so file)?

SwiftShader's support for S3TC is built in, and was enabled on all platforms earlier this year: https://swiftshader-review.googlesource.com/16808 On my Linux system, https://www.khronos.org/registry/webgl/sdk/tests/conformance/extensions/webgl-compressed-texture-s3tc.html?webglVersion=1 passes and has all extensions enabled, when using SwiftShader.

I have finally managed to get a Chrome 67 binary build for Ubuntu 16.04 onto the system in question and indeed the textures look fine there with swiftshader.

So I suspect the textures being black really is some form of packaging, build, compiler, or similar error. I am totally at a loss on what the error could be though, as all other swiftshader functionality works fine except from this specific type of texture (all three.js textures examples that work on Ubuntu Chrome also work fine on my build with swiftshader).

Unfortunately, I'm running out of time to investigate this -- debugging all the way into specific features of swiftshader is much more effort than making sure an entire feature like swiftshader or osmesa is enabled. So I'll have to stop here for now and hope that the problem will have gone away by the time osmesa will be fully removed (or investigate more at that time).

Let us use the rest of this issue for the actual problem I filed: --use-gl=osmesa being ignored when --headless is given.

Obviously I'll recommend you guys to fix the logic around the line I linked to treat osmesa as software implementation (as it was before) to keep it working until you finally delete all osmesa support, as opposed to keep it present-but-not-working-in-practice. Especially if it was just a refactoring accident.

The fix looks fairly easy (deleting that extra or-condition), but I don't feel equipped to send a CL without knowing why that condition was put there in the first place.

That said, I won't be terribly sad if you can't fix it; I can live with patching chromium for my use case until the osmesa code disappears entirely.