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

Thu Jul 23 06:53:59 PDT 2009

BenjaminPan at viatech.com wrote:
> Hi Thomas,
>
> How are you lately?
> VIA recently took lots of heat from our request for chrome9 DRM driver to be included in main. Most criticisms are centered around that we don't have an open source 3D code to use it. Duo to Michael Larabel's reports in January http://www.phoronix.com/scan.php?page=news_item&px=Njk3NQ,
> http://www.phoronix.com/scan.php?page=news_item&px=Njk4MA, and again
> http://www.phoronix.com/scan.php?page=news_item&px=NzAxMQ, many are under the impression that VIA deliberately deviated from the goal we set out to do and don't want to work with open source. But they don't know is we wanted to merge our DRM with your codes back then but still cannot find them 6 months after Michael told people they are out. That's why we had to patch via DRM and submit chrome9 DRM again for our upcoming major release. But it is getting harder as people got wrong perception from these kind of misinformation.
>   
Hi, Benjamin!
People easily get the wrong impression and it's sometimes difficult to 
get it right again. Particularly when someone "Big" in open-source 
speaks up and get things wrong.

Anyway, the status of CX700 and older open-source next-generation is the 
following:

1) The openchrome TTM drm module is in drm.git 
git://anongit.freedesktop.org/git/mesa/drm branch modesetting-newttm. 
I'm currently working on fixing up the user-space interface, because 
Dave Airlie wanted it done differently. I'ts based on the same TTM that 
radeon uses plus some extra functionality. I plan to try and get this 
merged into the kernel staging directory for 2.6.32 if everything works out.
2) The openchrome CX700 and earlier 3D driver sits in mesa,  
openchrome-branch. It's quite elaborate with support for OpenGL 1.3, 
S3TC, GL_EXT_framebuffer objects and accelerated pixel-buffer-objects 
where possible. It's TTM-driven and uses linux high-resolution timers to 
reduce CPU-usage.
3) The openchrome TTM 2D driver sits on the ttm_branch of the openchrome 
repository. I't doesn't currently support XvMC.

So the phoronix articles aren't completely incorrect. The code isn't 
just ready for upstreaming yet, and it's not for the Chrome9 yet.
Please understand that I'm working full time for another employee and I 
have an 8 month old son to take care of, so the amount spent on the VIA 
drivers is currently spent making previous work ready for release, and 
that's on the little spare time I have.

> As today, DRM files in the openchrome source (rev. 758) are snapshots from last September. What's the status of the TTM for chrome9?

TTM for chrome9 would not be that hard to add. It looks like it's a 
matter of writing a TTM backend for the PCI gart,
engine initialization and support for the fence capabilities of the 
device, but there is no Chrome9 specific code in there yet.

> And how mature is Gallium3D today? 

Gallium3D v 0.3 which is in mesa master, I'd say is mature enough to 
write a driver on.

> We plan to add DRI2, TTM, and GLSL support
Does the Chrome9 shader language support glsl? I was under the 
impression that there are no branching instructions?

>  over the next few months. We can add them to the existing private code, or start an open source project to rewrite the entire 3D driver with structure based on Mesa. We barely have enough resource to do the former. The effort of the latter is of course much bigger. So without sufficient expert opinion for what can we leverage, it is hard to reach consensus that now is time to do so. Can you help us on that?
>
> Thanks,
>
> Benjamin Pan
>   
Benjamin, it depends on what you want to achieve. If you need a driver 
to hand out to customers the easy part is probably to continue using the 
private driver, but if you want acceptance in the open source community, 
I think you should go ahead and

a) Release the shader docs to a broader public.
b) Start an open-source 3D driver effort for Chrome9. I think the best 
option is to base that on Gallium3D. The difficult thing is to attract 
talented developers and they seem to prefer the Radeon and Nvidia hardware.
c) Start an effort to integrate Chrome9 and kernel modesetting with the 
new Chrome9 chipsets.

/Thomas

> -----Original Message-----
> From: Thomas Hellstr?m [mailto:thomas at shipmail.org] 
> Sent: Wednesday, January 07, 2009 12:33 AM
> 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
>
>
>
>
>
>
>
>
> BruceChang at via.com.tw wrote:
>   
>> Hello Thomas:
>>     Please forgive me if my question is too stupid. It's my understanding that OpenChrome doesn't have 3D support now. Is it correct? Are you developing the 3D module for Chrome9? Or you plan to implement the EXA with 3D module?
>>
>> 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 3:10 PM
>> To: Harald Welte
>> Cc: Bruce Chang; openchrome-devel at openchrome.org; Benjamin Pan (Fremont)
>> Subject: Re: Future of via drm and unichrome 3D driver.
>>
>>
>> Harald,
>>
>> Just to clarify,
>> This is not a chrome9 driver but largely reworked CX700 + older 
>> unichrome stuff. However, it's a good base for incorporating the new 
>> chrome9 stuff, since things like chrome9 aperture and initialization 
>> falls naturally in place and it would be straighforward to add drm 
>> modesetting and reserve buffers for v4l-type drivers.
>>
>> If this doesn't change your opinion, I'll suggest creating an 
>> openchrome- drm and 3D module with the aim to move chrome9 drm stuff 
>> over from VIA's patches.
>>
>> /Thomas
>>   
>>     
>
>
>
>   