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

[Thomas Hellström]

Hi, Xavier.
Xavier Bachelot wrote:
> 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 ?
VIA did not fund it. I can't comment on who did yet.
> Are you the one working on this project ?
Me and a couple of other people.
> Does that work include Chrome9 chipsets ?
Nope.
> Is the new driver based on Gallium3D ?
>
Again no. At one point we considered updating Gallium3D to support 
fixed-function fragment paths,
but we didn't have time and resources.
> 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 ?
>
I've sort of gotten used to it, although I liked SVN with openChrome. 
Git is a bit confusing, though. Would be
interesting to hear what other people say.
> At which svn revision did you branch ?
>
I need to take a look at that. Was way back in may.
>> 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.
I'm fine with the openChrome DRM name. The reason the 3D driver is named 
unichrome is that people suspected we'd need a different driver for 
later VIA chipsets. It's a pure coincidence that the old 3D driver works 
as well as it does.
Lots of writes to unallocated memory and other problems, so it can go 
away, and we can stick with the unichrome driver name, perhaps.

/Thomas
>
> Cheers,
> Xavier
>