Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync changes from mozilla-central #3806

Merged
merged 12 commits into from Nov 28, 2019
Merged

Sync changes from mozilla-central #3806

merged 12 commits into from Nov 28, 2019

Conversation

@moz-gfx
Copy link

moz-gfx commented Nov 28, 2019

No description provided.

nical added 12 commits Nov 28, 2019
This chanes the shader parsing code to only inject #included shader sources once (the first time) if they are included multiple times.
This will allow some extra flexibility needed by the multi-brush shader.

Differential Revision: https://phabricator.services.mozilla.com/D53651

[wrupdater] From https://hg.mozilla.org/mozilla-central/rev/a1138b7e56a3be562fe49e5b1dc755ed34ebf389
This is an experiment with only image and solid to see what the infrastructure can be like.
If it works out I'll extend the it with more brush types. More work will be needed to get text rendering in there as well.

The multi-brush shader includes all brushes that it potentially needs suport for. Which brushes actually get compiled in is then specified via WR_FEATURE defines.
Since brushes can't have the same names for their entry points, they specify the function to use via a macros (WR_BRUSH_VS_FUNCTION and WR_BRUSH_FS_FUNCTION).

Differential Revision: https://phabricator.services.mozilla.com/D53725

[wrupdater] From https://hg.mozilla.org/mozilla-central/rev/e55fa1d9bb896507057a99a33bf281598d2b287d
…ings. r=gw

The 'multi-brush' shader will have to dynamically switch between different brushes. In order to support that without needing the sum of all brush varying locations, allow aliasing a number of generic slots.
This patch makes the assumption that one a vec2 and a vec4 cost the same amount of varying register space, which is suggested by the glsl specification about shader locations. If it is not the case we can add more granularity to the varying slots which are all vec4 at the moment. This also assumes that an unused varying is always optimized out.

Differential Revision: https://phabricator.services.mozilla.com/D53726

[wrupdater] From https://hg.mozilla.org/mozilla-central/rev/e5dad5475df4dfcec89e9ab4c137154fc91bddc3
@moz-gfx
Copy link
Author

moz-gfx commented Nov 28, 2019

@bors-servo
Copy link
Contributor

bors-servo commented Nov 28, 2019

📌 Commit ad42d1e has been approved by moz-gfx

@bors-servo
Copy link
Contributor

bors-servo commented Nov 28, 2019

Testing commit ad42d1e with merge 03e4b5e...

bors-servo added a commit that referenced this pull request Nov 28, 2019
Sync changes from mozilla-central
@bors-servo
Copy link
Contributor

bors-servo commented Nov 28, 2019

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: moz-gfx
Pushing 03e4b5e to master...

@bors-servo bors-servo merged commit ad42d1e into servo:master Nov 28, 2019
2 of 3 checks passed
2 of 3 checks passed
Community-TC (pull_request) TaskGroup: failure
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.