[Intel-gfx] [PATCH]fix for large texture with GEM-classic mode (bug#17964)
Eric Anholt
eric at anholt.net
Tue Oct 21 19:32:14 CEST 2008
On Tue, 2008-10-21 at 17:31 +0800, Xiang, Haihao wrote:
> Hi,
> Here are 2 patch for bug#17964. Sometimes a large texture(such as
> 2048x2048) works incorrectly under GEM-classic mode. There are two
> problems. Firstly there is an endless loop in intelEmitCopyBlit when
> using BLT to copy large texture image to mipmap tree. Secondly
> aperture_check only counts the first 3 level BOs,
> The BO for texture is always ignored
> (batchbuffer_BO->bind_table_BO->surface_states_BO->texture_BO).
Could you use git-send-email to send your patches, so they can be
reviewed inline?
@@ -263,8 +263,10 @@ got_flushed:
if (check_state(state, &atom->dirty)) {
if (atom->emit) {
atom->emit( brw );
- if (intel->batch->buf != last_batch_bo)
+ if (intel->batch->buf != last_batch_bo) {
+ intel_batchbuffer_flush(intel->batch);
goto got_flushed;
+ }
}
}
The batchbuffer has already been flushed by somebody here. Why flush it
again?
+ if (pass >= 2) {
+ intel->Fallback = 1;
+ return;
}
Where does that Fallback value get cleared?
if (intelImage->mt) {
/* Copy potentially with the blitter:
*/
+ useBlitter = GL_TRUE;
+ intel->Fallback = 0;
intel_miptree_image_copy(intel,
intelObj->mt,
intelImage->face,
intelImage->level, intelImage->mt);
Can't clear the fallback value like that, as you'll wipe out 915's
fallback state. Just return a boolean from the function of whether
blitting was successful. (even better, just do the fallback right in
the function)
The second patch looks good.
--
Eric Anholt
eric at anholt.net eric.anholt at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20081021/21b488fe/attachment.sig>
More information about the Intel-gfx
mailing list