{"push_id":841325187,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"eb0fda21bf0fc43f591dfe2a6302fc014c425118","before":"b65cfea2a48ce74ac98e2b10006e9d8b868d4553","commits":[{"sha":"eb0fda21bf0fc43f591dfe2a6302fc014c425118","author":{"email":"1dda8fffc4cb6d511b3f0060aad9cd12fd7f75f8@chromium.org","name":"reveman"},"message":"ui: Rename gfx::BufferUsage enum values and add BufferUsage::GPU_READ.\n\nThe problem with the current usage modes is that we currently use\nSCANOUT for anything that doesn't require CPU access. When importing\na buffer we typically don't care about anything but having the GPU\nbe able to read from it. SCANOUT is not a good description of that\nand currently means GPU read/write support.\n\nThis patch attempts to make usage more explicit and it solves the\nuse case where a buffer type can only provide GPU read and not GPU\nwrite support (e.g. SHM fallback). Here are the new usage modes:\n\n- GPU_READ\n- GPU_READ_WRITE\n- GPU_READ_CPU_READ_WRITE\n\nGPU_READ is useful when importing a buffer and all you care about is\nbeing able to use it for sampling and optionally scanout.\n\nGPU_READ_WRITE is useful for things like WebGL or GPU raster where\nwe want the ability to write to the buffer using GL and potentially\nuse it for scanout.\n\nGPU_READ_CPU_READ_WRITE is the usage mode that allows CPU access and\nis used for one-copy and zero-copy texture initialization. There's\nnothing preventing this mode from also supporting scanout.\n\n- GPU_READ_CPU_READ_WRITE_PERSISTENT\n\nThis usage mode indicates that the data will be persistent across\nUnmap()/Map() calls but will likely become part of the normal\nGPU_READ_CPU_READ_WRITE usage once all buffer types support this.\n\nBUG=538325\nCQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel\n\nReview URL: https://codereview.chromium.org/1420923005\n\nCr-Commit-Position: refs/heads/master@{#356108}","distinct":true,"url":"https://api.github.com/repos/dstockwell/chromium/commits/eb0fda21bf0fc43f591dfe2a6302fc014c425118"}]}