Log in

New unichrome.sf.net code... Finally. - LIBV Intentionally Breaks Videodrivers [entries|archive|friends|userinfo]
Luc Verhaegen

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

New unichrome.sf.net code... Finally. [Oct. 16th, 2005|03:29 pm]
Luc Verhaegen
[mood |contentcontent]
[music |Soulwax - Much against ... - Mike rule Joe cream mix]

The latest unichrome X release was r30, which already dates back to january 27th of this year. There was a lot of solid development all through february, the brunt of this code was becoming ready for another release. Sadly, this is where VBE modesetting was introduced, and this code wasn't ready at all. r31 was put off.

Personally, i find VBE modesetting fundamentally unacceptable and it goes in against all i have done and am doing. Together with some semi-latent issues, this led to the final falling out of those "involved" in unichrome.sf.net. And unichrome-X-r31 never happened. By then I was too busy to churn out a suitable amount of code anyway.

Now, 8 months later, i'm introducing new code. One change is that releases will no longer be named unichrome-X-r??. The driver has been named xf86-video-unichrome, matching X.orgs modular driver names. The driver directory structure was altered too.

The first release will be called xf86-video-unichrome-0.2.1. Because, first of all, the 0.1.31 version had been hijacked by the forkers, even though this was a numbering scheme i had introduced. So now people will once again be able to tell which is which and who is to blame. And secondly, this release is quite far away from the old code, it represents a (slightly) different direction and it is a new CVS module (even though the trunks history has been kept).

This codedrop is quite large, so there will undoubtedly be hairy stuff in there.

Main changes:
- rework: Except for 2 nasty bits, Xv support has been completely rewritten. This has taken most of my time but i'm pretty happy with the endresult. That big, ugly and highly illogical blob, that no-one could get a hold on, has been reduced to some 2400 highly managable lines.

- removal: Video1 support. There is no real Xv way to compose 2 overlay engines on the same head currently. So, since Video3 is the only engine available on VT3205 and VT3204, I kept only HQV and Video3. Both are already largely seperate from eachother (except the toplevel PutImage), and full separation will be trivial to implement. Video1 can be added easily when the need arises.

- removal: cache prefetching memcpy. Should get an X wide implementation, and shouldn't care about pitch alignment. Actually, the only good solution here is the dma copy Thomas Hellstrom implemented in drm, but i still have to look into that. For those solely interested in cpu usage, feel free to port memcpy, you'll see my Xv rework performing measurably better than the old code.

- removal: XvMC VLD. Thomas Hellstrom is hereby invited to stick patches against xf86-video-unichrome up on the unichrome.sf.net tracker.

- addition: funky image formats: YUV420, RV15, RV16 and RV32. UYVY is not possible in hardware alone. Mainly to showcase the flexibility of managable code, as no-one uses these FourCCs anyway.

- rework: the in-driver-memory-management-abstraction was completely reworked. Xv also required 16byte alignment.

- addition: For those who like a bit of "chrome": i've implemented the alpha plane.
Get the util xvattr (http://freshmeat.net/redir/xvattr/19550/url_tgz/ , GPLed sadly, someone should write an MIT implementation and stick it in utils) and adjust XV_OPACITY. Now hold something over the Xv window :) Sadly, this is not a very efficient use of resources. Thank VIA's implementation of an alpha plane on the unichrome for that.

- removal: VBE modesetting. Feel free to scream at me as much as you want, this is out and will stay out. Problems should get a proper and free solution or none at all. All a proper solution takes is clue, hardware and time.

- addition: CH7011 support. The CH7011 is a nice little chip. When i got my SK43G, i dropped everything else and implemented it. The code is cu-u-ute. Urgently needs an attribute system though.

- change: TV encoders now no longer have unichrome dependant code in their implementations. With two different output devices connected to two different chips, i felt confident to move the DI0/DVP0 bus setting away from the tv encoders. pBIOSInfo still needs to be broken up, but that won't happen until TTL, LVDS and TMDS code has been cleaned up or inserted.

- rework: driver layout matches X.org modular. All branches were surgically removed from the RCS files. New releases will branch off of HEAD at each release. Actual autoconf/automake build still needs to be added.

As one final note; I believe in drivers enjoying some amount of independence. It allows people to write code faster and have it tested independently of X releases. In the past, unichrome.sf.net was an active community and many people who enjoy throwing stuff at their hardware had gathered there. Problems were found quickly and efficiently and development was reasonably swift, with hardware availability being the main bottleneck. Unichrome.sf.net was, all in all, a good environment for driver development.

I now hope to have regular releases again. And hopefully, after several weeks of testing, stable code will trickle through to X.org again.

[User Picture]From: libv
2005-10-16 06:24 pm (UTC)

Last newsforge article.

Those close to unichrome will remember:

The sidebar there is very interesting. I was actually misquoted there.

When i said "I'm not happy with this underhanded stuff, as I'm a pretty head-on sort of person," I was actually talking about my own approach. The one which now resulted in a sizable chunk of code dropping out of the sky.

I had asked Jay to keep that under wraps, and he did, he used my words to signify something else. He never asked me directly to comment on the fork.

So, for the record: I don't consider everyone who actively participated in the fork as underhanded.
(Reply) (Thread)
From: (Anonymous)
2005-10-26 02:08 pm (UTC)
Ok after reading your mailing list and this blog, now am I slightly confused as to the current driver situation. :(
Will this unichrome-0.2.1 driver replace the current unichrome-X-r30 driver in xorg? or will it be an alternative driver in X for people to choose after (via vs unichrome?)
You say "stable code will trickle through to Xorg" do you mean that you will patch the current xvmc supporting via driver with your clean-ups? (is that possible) or will xorg loose xvmc when you release?
Can you explain what the situation is and what your goal is?
(Reply) (Thread)
[User Picture]From: libv
2005-10-26 02:26 pm (UTC)
In the post-modular days, it doesn't matter as much where your driver comes from.

The unichrome.sf.net code was forked. And as is the case with all forks, one or the other is bound to give in or up some time.

The fact that you call the xorg code unichrome-X-r30 says quite a bit. As part of the fork, a big hunk of my code and VBE modesetting was dragged into xorg, and it was versioned 0.1.31, what unichrome-X-r31 should've been had it ever been released. I will not claim anything with regard to that code, if it fails, it's due to the person who imported that code.

I am however taking some of the worst things in Xorg out, as i don't want the Xorg release to suffer from this terrible business. Apart from that, the forkers are welcome to dig their own grave.

What i want now is for people to stop whining about XvMC. It's a hunk of hairy code i'm glad i'm rid of. Let those who wrote it fix their own problems now.

If all you ricers find that XvMC is all you want, prepare to suffer as a consequence, as that no longer has me keeping idiotic crap out.

And this is all free software, the fittest code will survive. Time will tell.

Now shut -up about it already. It's pretty clear that it's wednesday and that there's only school in the morning.
(Reply) (Parent) (Thread)
From: (Anonymous)
2005-10-26 02:40 pm (UTC)
"In the post-modular days, it doesn't matter as much where your driver comes from."
ah neat, I hadn't considered that.

"The fact that you call the xorg code unichrome-X-r30 says quite a bit."
um, I was going from what you referred to it as at the start of your article, I needed some way of differentiating the two!

I was going to say thanks for the info... until you called me a "ricer".
(Reply) (Parent) (Thread)
From: (Anonymous)
2005-11-01 04:41 am (UTC)
"I was going to say thanks for the info... until you called me a "ricer"."

Well, he just can't stop fighting his own little war. Thought he got more relaxed during the last couple of weeks. I guess i was wrong :)
(Reply) (Parent) (Thread)
[User Picture]From: a_synx
2005-11-05 08:47 pm (UTC)
Good to hear you've got things figured out. Only... without XvMC, how will we scale movies? The current VIA driver you have masterfully concocted, nevertheless doesn't seem to enable hardware scaling, leaving people like me watching postage stamps instead of movies the size of the screen. I wish I could help, but with all this talk of hardware, especially the corrupt VIA junk, and I dun' even know what a VDS is. You've helped me on #xorg wonderfully before. I just hope this mess gets sorted out soon.
(Reply) (Thread)
[User Picture]From: libv
2005-11-05 10:52 pm (UTC)
Ah, but XvMC has nothing to do with scaling. Xv has all to do with that.

XvMC just implements hardware acceleration of the decoding of certain types of video. And just about every X developer agrees that the whole XvMC thing was poorly designed and that it needs a lot of work.

XvMC also fully depends on the Xv bit to do scaling and the actual overlay, so it is amazing how little has been done on the unichrome Xv side while a lot of noise was being made about XvMC.

Xv was severely cleaned up, i can now claim that i know what it's doing. And I'm the only person who can truthfully claim that. The forkers haven't got the faintest idea with what they still use, but then, who would, that almost completely original VIA code is such a useless mess.
(Reply) (Parent) (Thread)
[User Picture]From: a_synx
2005-11-06 12:18 am (UTC)
Oh good, I was worried for a minute! I'm aware that MC in XvMC stands for 'motion compensation' not 'hardware scaling', but I was worried that the XvMC removal might be the reason the (otherwise working) VIA driver no longer worked with XVideo. Perhaps in the context of debugging this video card I can learn more about how Xv works; what you said makes good sense towards that aim.
(Reply) (Parent) (Thread)
From: (Anonymous)
2005-11-11 07:16 pm (UTC)

Document ?

Might I suggest that you document your Xv knowledge ? If you are really the only one who knows it, that's bad. Such information should be public if it is available.
(Reply) (Parent) (Thread)
[User Picture]From: libv
2005-11-11 08:01 pm (UTC)

Re: Document ?

The code is highly clean and highly readable, and should be pretty transparent. Spend some time with it, you'll soon figure it out :)

Then go back to the old unichrome-X-r** code, but keep a watertight container and some water, to wash away the aftertaste of digesting food, handy, as you might need it. Mind you, i had already instituted quite a lot of cleanups there, before i was told by the forkers to keep away from Xv. Go back to where (the broken) capture code (which i removed too - if i ever get the hardware, i'll fix this, cleanly) was still included, and you'll get the full effect.
(Reply) (Parent) (Thread)
From: (Anonymous)
2006-01-28 02:50 pm (UTC)

Effect on other apps

Hi, can understand the dropping of XvMC. But what affect does this have on for example Xine or MythTV? Is it now a simple mather of selecting the XV video output method to get the "accelerated" MPEG2 video playback? Or is there still a bunch of patches needed in other apps to get the very nice low CPU usage during video playback.
Other question is on the TV encoders used on the EPIA boards, still the problem with swapping of the frames with interlaced playback? Understood this was pretty hardware related but BOB deinterlacing had some magic effect which caused good playback. This however is not so well implemented in MythTV in combination with XvMC. Would be very good to get real interlaced playback from quality point of view.
Anyway, good to see a new release, will fool around with it and probably trash my system a couple of times :) but heck gotta do something at night. Keep up the excellent work.
(Reply) (Thread)
From: (Anonymous)
2006-02-01 02:06 am (UTC)


Thank you for this driver. It is better than the unichrome-X-rxx driver, if you did not know that already. I am supposing that when I finally get the Xorg-6.9 it will be even better,
(Reply) (Thread)