[Openchrome-devel] ochr / drm / via-mesa big update

Xavier Bachelot xavier
Fri Sep 26 05:44:23 PDT 2008

Thomas Hellstr?m wrote:
> Hi!
> This isn't very official yet, so please keep on this list.
> Sometime during the autumn / winter TG will release a big update of the
> via drm and mesa driver.
> This includes
>     * Via AGP DMA stabilized and used for all command submission,
>     * Mesa driver stablized, mostly rewritten, OpenGL 1.3,
>       GL_EXT_frame_buffer_object, GL_EXT_pixel_buffer_object with
>       accelerated paths. CX700 extra texture level support, compressed
>       texture support. Looks like Gabriel's fix and VIA's changes are
>       mostly orthogonal to this, though.
>     * DRM TTM support, which means that the drm module is mostly
>       rewritten and not backwards compatible.
>     * Openchrome memory allocation from TTM, HW cursor support, faster
>       and stable EXA composite acceleration that mostly passes
>       "rendercheck". 3D + VESA modesetting working again. Much improved
>       recovering from signals and errors during startup.
> There are a couple of drawbacks that I hope will be fixed before the
> code is released:
> 1) Openchrome VRAM allocation goes through a user-space library
> "libwsbm", which uses various backends for memory allocation. Currently
> there's only a backend for the TTM memory manager, which means that
> OpenChrome _needs_ DRM to operate. It's possible to write a libwsbm
> backend that manages memory in user-space but it isn't done yet.
> 2) XvMC is not yet completely ported to TTM, but when it is, it will
> play much better with 3D and other VRAM intensive stuff. If, for
> example,  an Xv or XvMC client is paused <CTRL-Z>, the appropriate VRAM
> buffers will be thrown out (Using DMA) if there is a VRAM memory shortage.
This is excellent news :-) Closing the 3D driver gap is sorely needed.
A couple questions :
Did VIA fund the work or is it coming from somewhere else ?
Are you the one working on this project ?
Does that work include Chrome9 chipsets ?
Is the new driver based on Gallium3D ?

I understand you might not want to answer all of the questions.

> So the question is how to best integrate this?
> I think would be nice to have a GIT repo, otherwise we could put the
> OpenChrome stuff in a separate SVN branch until we feel it's OK to
> merge. The merge will probably be a bit painful, using SVN, though,
> since we've been developing using GIT and there has been a number of
> OpenChrome changes since we branched off.
The git question was already asked when talking about the integration 
into xorg. If you feel there is a need to switch to git and everyone 
agrees to, maybe either it can be hosted on the current svn server, or 
it might be hosted on the freedesktop git server, or even on both 
(periodical sync from openchrome git to freedesktop git) ?
How does everyone feel about switching to git ?

At which svn revision did you branch ?

> For DRM we need to completely replace or create a new driver with a
> different name. I think the drm developers will opt for the latter solution.
> Mesa Unichrome will be replaced. The new driver is using a bit more CPU
> for games with a lot of textures, like openarena on a C3, but is faster
> for other apps.
openchrome could be a good name both for the drm module and the Mesa 
driver. It's a bit confusing to have a 2D driver named openchrome, a drm 
module named via (and possibly another named via_chrome9) and a DRI 
driver named unichrome. Unifying anything to openchrome might make sense.


More information about the Openchrome-devel mailing list