fix: tolerate drivers that eliminate the mercator-only uniforms - #91
Open
giswqs wants to merge 1 commit into
Open
fix: tolerate drivers that eliminate the mercator-only uniforms#91giswqs wants to merge 1 commit into
giswqs wants to merge 1 commit into
Conversation
In the source-projected flat (wgs84) shader gl_Position is computed from u_anchor_clip + deltaClip, so shift_x, shift_y and u_worldXOffset only feed the v_mercatorPos varying, which the fragment shader never reads. Mesa (Intel, AMD, llvmpipe) eliminates that chain at link time and reports the three uniforms inactive; NVIDIA keeps them active. mustGetUniformLocation then threw on every frame as soon as MapLibre left the globe transition (zoom >= 12 with the globe preset, or any zoom in plain mercator), and MapLibre's frame loop swallowed the exception, so the layer silently vanished with no error in the UI. Look those three uniforms up without throwing, the way matrix and u_eye_matrix already are; a null location is a no-op for gl.uniform1f. The fake GL fixture gains an inactiveUniforms option so the tests can model a driver that drops them. Fixes opengeos/GeoLibre#2357.
|
@giswqs is attempting to deploy a commit to the carbonplan Team on Vercel. A member of the Team first needs to authorize it. |
Author
|
Here is a demo showing the layer disappears at high zoom level on my laptop. https://zarr-layer.demo.carbonplan.org/?dataset=temperature_v3 screenrecording-2026-09-11_19-35-33.mp4 |
2 tasks
giswqs
added a commit
to opengeos/GeoLibre
that referenced
this pull request
Sep 12, 2026
On Intel and AMD integrated graphics (Mesa) a Zarr layer with a CRS vanished as soon as MapLibre left the globe transition: at zoom 12 and above with the globe projection, and at every zoom in plain Mercator. @carbonplan/zarr-layer compiles its flat source-projected shader there, where shift_x, shift_y and u_worldXOffset only feed a varying the fragment shader never reads. Mesa eliminates them at link time and reports them inactive, the renderer's strict uniform lookup threw on every frame, and MapLibre's frame loop swallowed the exception, so nothing surfaced in the UI. NVIDIA keeps the uniforms active, which is why it never reproduced there. Carry the upstream fix (carbonplan/zarr-layer#91) as a patch-package patch until a release ships it: look those three uniforms up without throwing, as the renderer already does for its matrix uniforms. A test pins the installed bundle so a dependency bump that silently drops the patch fails the suite. Fixes #2357
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On Mesa GPUs (Intel and AMD integrated graphics, llvmpipe) a layer whose store carries a CRS disappears as soon as MapLibre leaves the globe transition: at zoom 12 and above with the
globepreset, and at every zoom in plainmercator. Nothing is reported in the UI. Reported against GeoLibre in opengeos/GeoLibre#2357, reproduced with the NOAA OISST sample and a small UTM store.Cause
The flat source-projected (
maplibre-proj4) vertex shader computesgl_Positionfromu_anchor_clip + deltaClip, soshift_x,shift_yandu_worldXOffsetonly feed thev_mercatorPosvarying, which the fragment shader never reads. Mesa eliminates that chain at link time and reports the three uniforms inactive, while NVIDIA keeps them active.mustGetUniformLocationthen throwsFailed to get uniform location for shift_xon every frame, the program is never cached so it is recompiled each frame, and MapLibre's frame loop swallows the exception, so the layer silently stops drawing.Verified by dumping the active uniforms in WebKitGTK on llvmpipe: the ECEF variant used below zoom 12 keeps all three, the flat variant compiled at zoom 12 loses them.
Fix
Look those three uniforms up with the non-throwing
gl.getUniformLocation, the waymatrix,u_eye_matrixandu_anchor_clipalready are. A null location is a no-op forgl.uniform1f, so the upload sites need no changes. The fake GL fixture gains aninactiveUniformsoption so tests can model a driver that drops them; two new tests cover the program build and the render path, and both fail without the fix.Verified in GeoLibre against Mesa llvmpipe (WebKitGTK) and NVIDIA (Chrome): the layer now renders at zoom 12.5 and 14 in globe and at 11.5 and 13 in mercator, with no errors thrown.
Fixes opengeos/GeoLibre#2357