[Openchrome-devel] Future of via drm and unichrome 3D driver.

[Thomas Hellström]

Hi, Bruce!

BruceChang at via.com.tw wrote:
> Hello Thomas:
>     Thank you very much for your information. Sorry for my stupid questions. Do you mean your new DRM is totally incompatible with the DRM inside mainline kernel? If so, can VIA's MESA UniChrome driver, which we released to both openchrome and VIA's portal, be compatible with your new DRM module? Please be informeded that we expect it's the last patch with only few bugs fixed for the UniChrome from VIA although VIA is active in the opensource DRI/DRM field because it's qualified by OEM customer with stable function. If new OpenChrome DRM path created, will the new DRM(OpenChrome) branch impact VIA's MESA function?
>
>   
Yes, the new DRM is incompatible with the current via drm and the 
current "unichrome" mesa driver.

This means one either has to run the "via" drm with the "unichrome" mesa 
driver
or the "openchrome" drm with the "openchrome" mesa driver. Which one to 
use is determined by the xorg driver.

For a good OpenGL driver that can handle multiple clients and the new 
extensions, like accelerated pixel buffer objects and frame buffer 
objects, the "openchrome" drm is needed, but it makes drivers a bit more 
complex. This is in par with what Intel is currently doing with their 
drivers.
>> 2) Add chrome9 EXA support. Nobody's working on this. Needs more shader info. This is a good way for an open-source developer to get a feeling for how the new 3D engine behaves.
>>     
> I am also interested if there is any experts can help this. As VIA is developing this function based on our code before the feature of openchrome's code can meet customer's requirement, we can provide the information and share our experience if there is any expert is interested in this.
>   
Yes that would be helpful. I don't think there will be any successful 
open-source effort until VIA releases more pixel shader info or examples.
>> 3) A new chrome9 3D driver. Preferrably based on gallium. I don't think  anybody in the open source community is working on this. Is VIA doing any efforts in this direction?
>>     
> We prefer the G3D for Chrome9 too but we have few information about G3D. Based on your full experience, it will be appreciated if you can give us the guideline for the developing.
>   
The current G3D code lives in the gallium-0.2 branch.

Gallium consists of a state-tracker, which is common to all drivers, the 
Gallium driver interface between the state-tracker and the driver, and a 
driver-winsys interface which interfaces to the winsys module that 
handles 3D command submission and resource management.

A good way to start is to implement the hooks in the driver interface to 
translate Gallium state to Chrome9 state. This will also involve 
translating TGSI shader language to Chrome9 shader language, and have 
the resulting command stream dumped to the screen, for a simple 
applications like mesa/progs/trivial/*

Then a winsys module needs to be constructed, that takes the command 
stream and the resource requests and interfaces with the underlying 
operating system. For example dri+glx / drm or Windows.

Note that the driver / winsys interface should be sufficiently general 
to just change the winsys module and be able to support various 
operating systems like windows/linux and various windowing systems like 
GLX, WGL, EGL etc.

/Thomas

> Thanks and Best Regards
> =================================================
> Bruce C. Chang(???)
> VIA Technologies, Inc. 
> Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei
> Tel: +886-2-22185452 Ext 7323
> Fax: +886-2-22186282
> Skype: Bruce.C.Chang
> Email: BruceChang at via.com.tw
>
>
> -----Original Message-----
> From: Thomas Hellstrom [mailto:thomas at shipmail.org] 
> Sent: Wednesday, January 07, 2009 4:33 PM
> To: Bruce Chang
> Cc: openchrome-devel at openchrome.org; Benjamin Pan (Fremont); Harald Welte
> Subject: Re: Future of via drm and unichrome 3D driver.
>
>
> Hi Bruce.
>
> Openchrome currently has OpenGL support using the "unichrome" driver in 
> current mesa. However, that driver is full of bugs, logical errors and 
> quite unstable. Tungsten Graphics was asked to improve that driver and 
> add OpenGL 1.3, S3TC, accelerated GL_EXT_frame_buffer_objects and 
> GL_ARB_pixel_buffer_objects by a customer. This involved reworking the 
> DRM and the 3D driver to a point where it really became different 
> drivers. Also the memory management of the openChrome 2D driver has been 
> reworked to fit the unified memory manager in DRM. Part of this work was 
> done by Tungsten Graphics before the VMware merger. Part of it was done 
> by me on my spare time.
>
> At some point I'd like to push this work open-source, and the suggestion 
> is to create a new openchrome DRM driver and, during a period, obsolete 
> the VIA drm driver. Since VIA is starting getting very active in the 
> opensource DRI / DRM field, I won't do this if VIA thinks it's a bad idea.
>
> The OpenChrome 2D driver also has EXA support, using the 3D engine, but 
> that is separate from the mesa OpenGL driver. The OpenChrome 2D driver 
> directly programs the 3D engine.
>
> This is all CX700 and earlier unichromes.
>
> For an open-source chrome9 driver built on this framework, the following 
> would be needed:
>
> 1) Port VIA's new drm patches over to the new openchrome DRM. I can 
> volunteer to do that.
> 2) Add chrome9 EXA support. Nobody's working on this. Needs more shader 
> info. This is a good way for an open-source developer to get a feeling 
> for how the new 3D engine behaves.
> 3) A new chrome9 3D driver. Preferrably based on gallium. I don't think 
> anybody in the open source community is working on this. Is VIA doing 
> any efforts in this direction?
>
> Thanks,
> Thomas
>
>
>