[Patch] i915gm: framebuffer compression+tiling on exa

[Pierre Willenbrock]

Peter Clifton schrieb:
> On Thu, 2007-11-01 at 12:11 -0700, Jesse Barnes wrote:
>> On Thursday, November 01, 2007 11:45 Pierre Willenbrock wrote:
>>> Hi list,
>>>
>>> i am using latest git of xserver, xf86-video-intel, drm and mesa.
>>> Since the merge of bufferobjects and support code into drm and
>>> xf86-video-intel, i was unable to use tiling. After looking at bug
>>> #12994 i found that i tried to disable framebuffer compression by
>>> disabling the option "Compression" instead of
>>> "FramebufferCompression", so i tried again, and found that i could
>>> use either framebuffer compression or tiling, but not both.
>>>
>>> Digging deeper into the driver sources, i found #define
>>> FBC_CTL_FENCENO, which was not used anywhere. So i tried adding the
>>> fence number of my frambuffer(3) to the FBC control register, which
>>> made the FBC and tiling work at the same time. A patch is attached.
>> Ah, excellent!  That definitely explains the bad behavior several people 
>> have been seeing.  Earlier (I think I even had a comment to this effect 
>> at one point) I assumed that the front buffer was using fence 0.  This 
>> looks like a real fix.  I'll go ahead and check it in.
> 
> Sorry to be annoying, but do you mind quickly explaining what "bad
> behaviour" this results in? (IE. is it a fix we need to backport for
> Ubuntu to fix bugs users might hit?)
> 
For me, it is a completely black screen with a nice mouse cursor, but
otherwise working x-server, when using tiling and compression. This may
look different when some 3d-application actually used the
depth-buffer(is using fence #0 here). The allocation order changed when
Eric merged buffer objects, i think.

Thinking further, my patch may have some bad interaction if tiling is
disabled, as it currently uses the fence_nr variable unconditionally(is
the fence number ignored? should the fbc get an unused fence in that
case? can the fence variable contain undefined data?).

Regards,
  Pierre