[Xorg-driver-geode] Disable compression patch? huh?

[Jordan Crouse]

On 15/02/08 11:33 -0500, Warren Togami wrote:
> Jordan Crouse wrote:
>> On 15/02/08 11:03 -0500, Warren Togami wrote:
>>> Hi folks,
>>>
>>> I am now attempting to pull in the latest upstream drv-amd into Fedora.
>>>
>>> http://cvs.fedoraproject.org/viewcvs/devel/xorg-x11-drv-amd/
>>> We have very old patches in our Fedora 8 driver.  I have confirmed with 
>>> Dan Williams that two patches are no longer needed.
>>>
>>> http://cvs.fedoraproject.org/viewcvs/devel/xorg-x11-drv-amd/lx-disable-compression.patch?rev=1.1&view=log
>>> But this patch we are uncertain.  Ajax recalls that it was framebuffer 
>>> compression was definitely broken in some way in the past thus it was 
>>> completely disabled in our driver.  Interestingly, he also mentions that 
>>> "compression" actually uses more memory than without in this case.
>> Yes - compression doesn't mean what you think it means </princess_bride>
>> In this particular case, what is being compressed is the data traveling
>> across the internal bus between the memory controller and the display
>> controller.  In order to do this in the hardware, the pitch in the
>> framebuffer needs to be a power of two; so in the case of the OLPC
>> instead of a pitch of (1200x2=2400), the pitch would be 4096, which
>> ended up expending very nearly 2 MB more of memory.
>> Compression is most useful for situations where this is a enormous amount 
>> of traffic on the internal bus combined with high display
>> resolutions - like, say streaming video from a PCI attached NIC in 720p
>> resolution.  Most other people wouldn't use it, though they probably
>> wouldn't notice or care if it was enabled.
>> I do remember some issues with compression in the past, but we've had
>> it enabled by default in the driver for some time now, and I haven't
>> heard any complaints.  Part of the reason why we patched it out in
>> the Fedora driver was because we wanted it disabled for the memory
>> hogging reason, and the OLPC guys preferred to have it disabled in the
>> code rather then manually disabling it in the configuration file.
>> Jordan
>
> Thanks for the explanation.  Could we add a conditional upstream that turns 
> off compression for OLPC hardware without disabling it by default for 
> everyone else?

We could, but I would prefer for the OLPC guys to get over their
adversion for modifying the config file - that way, no code has to
change.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.