Closed Bug 1389497 Opened 8 years ago Closed 8 years ago

Update webrender to 1007a65c6dd1fdfb8b39d57d7faff3cae7b32e0c

Categories

(Core :: Graphics: WebRender, enhancement, P3)

Product:
Core
Component:
Graphics: WebRender
Version:
57 Branch
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla57
Tracking Flags:
Tracking Status
firefox57 --- fixed

People

(Reporter: kats, Assigned: kats)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(4 files, 1 obsolete file)

Bug 1389497 - Update webrender to commit 1007a65c6dd1fdfb8b39d57d7faff3cae7b32e0c.
59 bytes, text/x-review-board-request
jrmuizel
: review+
Details
Bug 1389497 - Update Cargo lockfiles and re-vendor third-party dependencies.
59 bytes, text/x-review-board-request
jrmuizel
: review+
Details
Bug 1389497 - Update bindings for API change in WR cset 63ec62c.
59 bytes, text/x-review-board-request
kvark
: review+
Details
Bug 1389497 - Re-generate FFI header for change in WR cset 615bbe8.
59 bytes, text/x-review-board-request
jrmuizel
: review+
Details
+++ This bug was initially created as a clone of Bug #1388719 +++ I'm filing this as a placeholder bug for the next webrender update. I may be running a cron script [1] that does try pushes with webrender update attempts, so that we can track build/test breakages introduced by webrender on a rolling basis. This bug will hold the try push links as well as dependencies filed for those breakages, so that we have a better idea going into the update of what needs fixing. I might abort the cron job because once things get too far out of sync it's hard to fully automate fixing all the breakages. When we are ready to actually land the update, we can rename this bug and use it for the update, and then file a new bug for the next "future update". [1] https://github.com/staktrace/moz-scripts/blob/master/try-latest-webrender.sh
WR @ 101c69db1a989fe89c308dabd53cf50aedfe4a96: green https://treeherder.mozilla.org/#/jobs?repo=try&revision=a67744438b164bc50e5be6f1c29715a8772139b3 https://treeherder.mozilla.org/#/jobs?repo=try&revision=36639ac0837c3fcc1b248b16de52133fe41b6a91 WR @ 9e1a85e8226d7746e82902f44467293d1a9938ca: green, many pushes over the weekend https://treeherder.mozilla.org/#/jobs?repo=try&revision=681ca7e0ffc267c7fe3ac8522e22df7fc90b64cd https://treeherder.mozilla.org/#/jobs?repo=try&revision=f4423cac3e5445f515f01d29599d761532e90868 https://treeherder.mozilla.org/#/jobs?repo=try&revision=09ee67b83edf8c1d1114dd360567939b45cc3a34 https://treeherder.mozilla.org/#/jobs?repo=try&revision=d042ce8338a9122cdba52e501e9a8c62d79d54fa https://treeherder.mozilla.org/#/jobs?repo=try&revision=69731b2d17d758908b430c71e44defad7f896527 https://treeherder.mozilla.org/#/jobs?repo=try&revision=59970ba7ef5f5b1090890d6957a8b3cdb644605a https://treeherder.mozilla.org/#/jobs?repo=try&revision=504064fee6a767cf86b6b86b201a19e873297067 https://treeherder.mozilla.org/#/jobs?repo=try&revision=880ff9b8cf25904a2a5c1faf7593768eaf42ce5e https://treeherder.mozilla.org/#/jobs?repo=try&revision=c6a24240e783ed2173b5767cce7dd8a9c03bcdfa https://treeherder.mozilla.org/#/jobs?repo=try&revision=7ec5bfa2311ed400b4286c3850d1396b04cbab71 https://treeherder.mozilla.org/#/jobs?repo=try&revision=7a06dda3569046db3291aaa46b3d7532f4133883 https://treeherder.mozilla.org/#/jobs?repo=try&revision=818060bb1fc8c1ece9e91a408daee3005c017b88
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4) > WR @ c98d889ce14c94e96fefec7c58d628d653b1ea7c > > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=b863ad84c4ce1b50452a2af291f807e24d1367ea > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=74bb5eb06481ae2dc03ba5e10bf3dec3ea9c489e > > The linux tests are all fine, but the windows reftests seem to failing > differently than before. Compare [1] (before) with [2] (after) and look > through some of the tests. The after seems to have a lot of what looks like > font glyphs everywhere. On windows, WrExternalImageType::NativeTexture code path did not work. When I disable D3D texture usage, the problem was addressed. When the problem happened, ANGLE hit failure. I am going to look into it.
When I disabled DXGITextureData creation by modiyfing TextureClient::CreateForDrawing(), rendering result became OK. But it still cause error in ANGLE. gl.tex_image_2d() in Device::deinit_texture() hit error, since the function used tex_image_2d() for gl::TEXTURE_2D_ARRAY. It needs to be gl.tex_image_3d() for gl::TEXTURE_2D_ARRAY. The following is the call stack. > libGLESv2.dll!gl::Context::handleError(const gl::Error & error) Line 1945 C++ > libGLESv2.dll!gl::ValidateES3TexImage2DParameters() Line 317 C++ > libGLESv2.dll!gl::ValidateTexImage2D() Line 1967 C++ > libGLESv2.dll!gl::TexImage2D() Line 335 Unknown > xul.dll!webrender::device::Device::deinit_texture(webrender::device::TextureId self) Line 1253 Unknown > xul.dll!webrender::renderer::Renderer::update_texture_cache() Line 1681 Unknown > xul.dll!webrender::renderer::{{impl}}::render::{{closure}}(closure) Line 1530 Unknown > xul.dll!webrender::renderer::Renderer::render(euclid::size::TypedSize2D<u32, webrender_api::units::DevicePixel> self) Line 1515 Unknown > xul.dll!mozilla::wr::RendererOGL::Render() Line 162 C++ > xul.dll!mozilla::wr::RenderThread::UpdateAndRender(mozilla::wr::WrWindowId aWindowId) Line 223 C++ > xul.dll!mozilla::wr::RenderThread::NewFrameReady(mozilla::wr::WrWindowId aWindowId) Line 170 C++ > xul.dll!mozilla::detail::RunnableMethodImpl<nsCOMPtr<nsIWidget>,enum nsresult (__cdecl nsIWidget::*)(nsIObserver * __ptr64) __ptr64,1,0,nsIObserver * __ptr64>::Run() Line 1195 C++ > xul.dll!MessageLoop::RunTask(already_AddRefed<nsIRunnable> aTask) Line 453 C++ > xul.dll!MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask && pending_task) Line 463 C++ > xul.dll!MessageLoop::DoWork() Line 535 C++
The patch addressed an error at ANGLE. With the patch and https://github.com/servo/webrender/issues/1577, I did not see the error at Context::handleError(). But the rendering result still had the problem:( The problem might related to https://github.com/servo/webrender/pull/1581.
Assignee: nobody → sotaro.ikeda.g
Assignee: sotaro.ikeda.g → nobody
(In reply to Sotaro Ikeda [:sotaro] from comment #9) > Created attachment 8898090 [details] [diff] [review] > patch - Fix texture binding of RenderDXGITextureHostOGL::EnsureLockable() > > The patch addressed an error at ANGLE. With the patch and > https://github.com/servo/webrender/issues/1577, I did not see the error at > Context::handleError(). But the rendering result still had the problem:( > > The problem might related to https://github.com/servo/webrender/pull/1581. I don't understand this. Do you want this patch to land as part of the next WR update? If so I can add it to my try pushes. Or is it something that can land independently before or after the WR update? In that case it would be better to put it in another bug.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11) > (In reply to Sotaro Ikeda [:sotaro] from comment #9) > > Created attachment 8898090 [details] [diff] [review] > > patch - Fix texture binding of RenderDXGITextureHostOGL::EnsureLockable() > > > > I don't understand this. Do you want this patch to land as part of the next > WR update? If so I can add it to my try pushes. Or is it something that can > land independently before or after the WR update? In that case it would be > better to put it in another bug. I confirmed that the problem of attachment 8898090 [details] [diff] [review] still happen on latest gecko. Then I am going to create a new bug for it. RenderDXGITextureHostOGL::EnsureLockable() update binding of GL_TEXTURE_2D. But WebRender keeps texture binding state and uses the state to update texture binding. EnsureLockable() breaks how to bind texture by webrender. Therefore EnsureLockable() have to restore texture binding state when exiting the function. https://dxr.mozilla.org/mozilla-central/source/gfx/webrender/src/device.rs#945
(In reply to Sotaro Ikeda [:sotaro] from comment #12) > > I confirmed that the problem of attachment 8898090 [details] [diff] [review] > still happen on latest gecko. Then I am going to create a new bug for it. The problem breaks a bit of updating GPU cache. Bug 1391481 was created for it.
(In reply to Sotaro Ikeda [:sotaro] from comment #12) > > I confirmed that the problem of attachment 8898090 [details] [diff] [review] > still happen on latest gecko. Then I am going to create a new bug for it. Therefore Bug 1391481 could be independent to this bug.
Attachment #8898090 - Attachment is obsolete: true
I'll try to land this update tomorrow morning.
Assignee: nobody → bugmail
Alias: wr-future-update
Summary: Future webrender update bug → Update webrender to 1007a65c6dd1fdfb8b39d57d7faff3cae7b32e0c
Version: unspecified → 57 Branch
Comment on attachment 8898772 [details] Bug 1389497 - Update bindings for API change in WR cset 63ec62c. https://reviewboard.mozilla.org/r/170164/#review175320
Attachment #8898772 - Flags: review?(kvark) → review+
Comment on attachment 8898773 [details] Bug 1389497 - Re-generate FFI header for change in WR cset 615bbe8. https://reviewboard.mozilla.org/r/170166/#review175326
Attachment #8898773 - Flags: review?(jmuizelaar) → review+
Comment on attachment 8898771 [details] Bug 1389497 - Update Cargo lockfiles and re-vendor third-party dependencies. https://reviewboard.mozilla.org/r/170162/#review175328
Attachment #8898771 - Flags: review?(jmuizelaar) → review+
Comment on attachment 8898770 [details] Bug 1389497 - Update webrender to commit 1007a65c6dd1fdfb8b39d57d7faff3cae7b32e0c. https://reviewboard.mozilla.org/r/170160/#review175330
Attachment #8898770 - Flags: review?(jmuizelaar) → review+
Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8249e9175ae0 Update webrender to commit 1007a65c6dd1fdfb8b39d57d7faff3cae7b32e0c. r=jrmuizel https://hg.mozilla.org/integration/autoland/rev/1f7b22c5a326 Update Cargo lockfiles and re-vendor third-party dependencies. r=jrmuizel https://hg.mozilla.org/integration/autoland/rev/f75cec1930f2 Update bindings for API change in WR cset 63ec62c. r=kvark https://hg.mozilla.org/integration/autoland/rev/c7fc4a1e4360 Re-generate FFI header for change in WR cset 615bbe8. r=jrmuizel
No longer blocks: 1390422
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: