1496779 - WebRender doesn't check for OOM on texture allocations

Status: REOPENED

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

Description

[Bobby Holley (:bholley)]

I don't see any checking for GL_OUT_OF_MEMORY in the code. I'm not sure what the sane way to handle vmem OOM is, but we presumably want to do something more than what we're doing now.

Comment 1

[Kelsey Gilbert [:jgilbert]]

Yeah, we should at least check for it. How we respond would change based on what's failing. If we're failing to grow a cache, maybe we can just make do with the cache we have.

Also yeah, GetError is slow, but so are allocations generally, and allocations are usually infrequent enough that it's probably fine to follow up all allocations with GetError. (That's what we do in WebGL)

One annoying thing about GL_OOM is that state isn't guaranteed to be unchanged by the error, unlike all other errors.(INVALID_OPERATION, etc) If you hit GL_OOM when trying to realloc a resource, there's no guarantee that you still have the pre-realloc resource. (that's one reason to avoid reallocating)

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Graphics memory is paged on Windows so we probably won't get an OOM unless we've run out of address space. I don't think we need to worry about this for the MVP unless it actually shows up as problem for people.

Comment 3

[Kelsey Gilbert [:jgilbert]]

It's paged, but large allocations can still fail due to other reasons. Max resource size in D3D is much lower than available physical memory usually.
Are you sure, @gw? I really recommend doing these checks. There should be no perf hit in the general case.

Comment 4

[Glenn Watson [:gw]]

If we think we can handle it in a useful way, then I'm fine to reopen.