Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(256)

Side by Side Diff: src/gpu/vk/GrVkGpu.cpp

Issue 2159333002: Recycle small uniform buffers. (Closed) Base URL: https://skia.googlesource.com/skia.git@master
Patch Set: Update values Created 4 years, 5 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « src/gpu/vk/GrVkBuffer.cpp ('k') | src/gpu/vk/GrVkPipelineState.cpp » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
1 /* 1 /*
2 * Copyright 2015 Google Inc. 2 * Copyright 2015 Google Inc.
3 * 3 *
4 * Use of this source code is governed by a BSD-style license that can be 4 * Use of this source code is governed by a BSD-style license that can be
5 * found in the LICENSE file. 5 * found in the LICENSE file.
6 */ 6 */
7 7
8 #include "GrVkGpu.h" 8 #include "GrVkGpu.h"
9 9
10 #include "GrContextOptions.h" 10 #include "GrContextOptions.h"
(...skipping 133 matching lines...) Expand 10 before | Expand all | Expand 10 after
144 144
145 // set up our heaps 145 // set up our heaps
146 fHeaps[kLinearImage_Heap].reset(new GrVkHeap(this, GrVkHeap::kSubAlloc_Strat egy, 16*1024*1024)); 146 fHeaps[kLinearImage_Heap].reset(new GrVkHeap(this, GrVkHeap::kSubAlloc_Strat egy, 16*1024*1024));
147 // We want the OptimalImage_Heap to use a SubAlloc_strategy but it occasiona lly causes the 147 // We want the OptimalImage_Heap to use a SubAlloc_strategy but it occasiona lly causes the
148 // device to run out of memory. Most likely this is caused by fragmentation in the device heap 148 // device to run out of memory. Most likely this is caused by fragmentation in the device heap
149 // and we can't allocate more. Until we get a fix moving this to SingleAlloc . 149 // and we can't allocate more. Until we get a fix moving this to SingleAlloc .
150 fHeaps[kOptimalImage_Heap].reset(new GrVkHeap(this, GrVkHeap::kSingleAlloc_S trategy, 64*1024*1024)); 150 fHeaps[kOptimalImage_Heap].reset(new GrVkHeap(this, GrVkHeap::kSingleAlloc_S trategy, 64*1024*1024));
151 fHeaps[kSmallOptimalImage_Heap].reset(new GrVkHeap(this, GrVkHeap::kSubAlloc _Strategy, 2*1024*1024)); 151 fHeaps[kSmallOptimalImage_Heap].reset(new GrVkHeap(this, GrVkHeap::kSubAlloc _Strategy, 2*1024*1024));
152 fHeaps[kVertexBuffer_Heap].reset(new GrVkHeap(this, GrVkHeap::kSingleAlloc_S trategy, 0)); 152 fHeaps[kVertexBuffer_Heap].reset(new GrVkHeap(this, GrVkHeap::kSingleAlloc_S trategy, 0));
153 fHeaps[kIndexBuffer_Heap].reset(new GrVkHeap(this, GrVkHeap::kSingleAlloc_St rategy, 0)); 153 fHeaps[kIndexBuffer_Heap].reset(new GrVkHeap(this, GrVkHeap::kSingleAlloc_St rategy, 0));
154 fHeaps[kUniformBuffer_Heap].reset(new GrVkHeap(this, GrVkHeap::kSubAlloc_Str ategy, 64*1024)); 154 fHeaps[kUniformBuffer_Heap].reset(new GrVkHeap(this, GrVkHeap::kSubAlloc_Str ategy, 256*1024));
155 fHeaps[kCopyReadBuffer_Heap].reset(new GrVkHeap(this, GrVkHeap::kSingleAlloc _Strategy, 0)); 155 fHeaps[kCopyReadBuffer_Heap].reset(new GrVkHeap(this, GrVkHeap::kSingleAlloc _Strategy, 0));
156 fHeaps[kCopyWriteBuffer_Heap].reset(new GrVkHeap(this, GrVkHeap::kSubAlloc_S trategy, 16*1024*1024)); 156 fHeaps[kCopyWriteBuffer_Heap].reset(new GrVkHeap(this, GrVkHeap::kSubAlloc_S trategy, 16*1024*1024));
157 } 157 }
158 158
159 GrVkGpu::~GrVkGpu() { 159 GrVkGpu::~GrVkGpu() {
160 fCurrentCmdBuffer->end(this); 160 fCurrentCmdBuffer->end(this);
161 fCurrentCmdBuffer->unref(this); 161 fCurrentCmdBuffer->unref(this);
162 162
163 // wait for all commands to finish 163 // wait for all commands to finish
164 fResourceProvider.checkCommandBuffers(); 164 fResourceProvider.checkCommandBuffers();
(...skipping 1397 matching lines...) Expand 10 before | Expand all | Expand 10 after
1562 } 1562 }
1563 1563
1564 // Currently it is fine for us to always pass in 1 for the clear count even if no attachment 1564 // Currently it is fine for us to always pass in 1 for the clear count even if no attachment
1565 // uses it. In the current state, we also only use the LOAD_OP_CLEAR for the color attachment 1565 // uses it. In the current state, we also only use the LOAD_OP_CLEAR for the color attachment
1566 // which is always at the first attachment. 1566 // which is always at the first attachment.
1567 fCurrentCmdBuffer->beginRenderPass(this, renderPass, 1, colorClear, *target, *pBounds, true); 1567 fCurrentCmdBuffer->beginRenderPass(this, renderPass, 1, colorClear, *target, *pBounds, true);
1568 fCurrentCmdBuffer->executeCommands(this, buffer); 1568 fCurrentCmdBuffer->executeCommands(this, buffer);
1569 fCurrentCmdBuffer->endRenderPass(this); 1569 fCurrentCmdBuffer->endRenderPass(this);
1570 } 1570 }
1571 1571
OLDNEW
« no previous file with comments | « src/gpu/vk/GrVkBuffer.cpp ('k') | src/gpu/vk/GrVkPipelineState.cpp » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698