[Openchrome-devel] KMS, TTM/GEM status

[Xavier Bachelot]

On 06/07/2011 10:25 AM, Thomas Hellstrom wrote:
> On 06/07/2011 03:38 AM, Forest Bond wrote:
>> Hi James,
>>
>> On Sat, Jun 04, 2011 at 02:01:55AM +0100, James Simmons wrote:
>>
>>>> I see you have continued your work on KMS and TTM/GEM support for the via DRM
>>>> driver.  Thank you for your efforts to move things forward.
>>>>
>>> Thank you for trying this code out.
>>>
>> I haven't actually tried it yet. ;)
>>
>>
>>>> I am wondering what the current status of this work is.  Do you foresee the KMS
>>>> and TTM/GEM support being merged into mainline anytime soon?
>>>>
>>> 	Going mainline will not be for a while. The main line driver has
>>> been in a state of decay for some time. The driver we work on is currently
>>> growing since it attempts covers several generations of VIA hardware. So
>>> alot of work needs to be done.
>>> 	KMS is being implemented but it's currently turned off by default.
>>> Unfortunely turning on KMS gives you the black screen of death. PLL needs
>>> to be programmed as well as the display fifo. TTM is mostly implemented.
>>> Fencing needs to be done. I plan to finish the TTM layer soon and start
>>> working on the xorg driver to use this layer.
>>>
>> I am glad you are continuing to make progress.  Thank you for your work!
>>
>>
>>>> Also, does your work tie into Thomas Hellstr?m's work on the openchrome Mesa
>>>> driver?  Do you have any idea what the status of that work is?
>>>>
>>> Last I seen the work has been stopped for some time. Currently no Mesa
>>> work is being done on my end. As for Thomas drm kernel driver I would say
>>> both our drivers are on the same level. The one difference is I have
>>> attempted to maintain the old VIA driver ioctl apis as well as support new
>>> TTM functionality at the same time.
>>>
>> Okay.  Sounds like it will be a long while before we can expect any improvements
>> in Mesa support.
>>
>
> When I stopped working on the mesa driver (openchrome-branch) it was
> actually working quite well, both with regard to robustness and speed. I
> just simply didn't have the time anymore since I got a child... I
> remember trying it out with a P4M890 (one of the last non-DX9 fixed
> function chipsets for Intel processors), and it beat the i965 driver
> running with the same processor on most things.
>
I can confirm the openchrome mesa driver was much better on a KM400 than 
the "regular" unichrome mesa driver.

> Anyway, that driver required the buffer suballocation (user-space
> fencing) and synchronization features of TTM, which aren't exposed by
> default by the GEM interface. This was to get up to speed with texture
> allocation and things like accelerated drawpixels and glBitmap.
>
I haven't tried Thomas' openchrome mesa driver with James' via drm 
driver yet, I'm pretty sure if it's not supposed to work anyway. I'll 
give it a run as time permit, but I guess some needed features are still 
missing, as James' work is not yet completed, both on the DRM and DDX 
side, and some tweaking would be needed in the DDX too, so not sure it 
worth it yet.

> /Thomas
>
Glad to see you're still reading the list Thomas :-)

Regards,
Xavier