VIA Releases 800 Pages of Documentation For Linux

billybob2 writes "VIA has published three programming guides that total 800 pages in length and cover their PadLock, CX700, and VX800/820 technologies. The VIA PadLock provides a random number generator, an advanced cryptography engine, and RSA algorithm computations. The VX800 chipset was VIA's first Integrated Graphics Processor, while the CX700 is a System Media Processor designed for the mobile market. This is another step in VIA's strategy to support the development of Free and Open Source drivers under Linux, which comes pre-installed on VIA products such as the Sylvania NetBook, HP Mini-Note, 15.4" gBook, gPC, CloudBook, Zonbu, and VIA OpenBook. Earlier this week, VIA hired Linux kernel developer and GPL-Violations.org founder Harald Welte to be VIA's liason to the Open Source community."

Comments

Anonymous Coward.

[Anonymous Coward]

Via (=Way) to go! :)

Via what method?

[Anonymous Coward]

Guh?

Re:Via what method?

[beav007]

Just thought I'd let you know that I just modded you up.

Wait...

Re:linux?

[bloodninja]

Now Linux drivers can be written for the hardware. Just like TFS says.

800 pages in length

[Anonymous Coward]

VIA has published three programming guides that total 800 pages in length

How many pages in width?

Re:800 pages in length

[Drinking Bleach]

700, with a depth of 300.

Re:800 pages in length

[Anonymous Coward]

How many pages in width?

Only one, certainly.

Re:800 pages in length

[eddy]

The only thing disappointing is that we still don't have PadLock[esque] instructions in AMD's and Intel's mainstream CPUs. You need to max out a modern 2-core highly clocked CPU to match a fanless C7 1.2GHz CPU in SHA and AES performance. What the hell is the problem? NIHS?

XSHA for teh wins already!

Re:800 pages in length

[Deltaway]

And increasing with time every passing second! But see, if we're just talking about the size of it, then Wikipedia beats it in all respects: It's larger, older, and gets larger as it gets older(at least so far). Let's get to the dimension of quality. Then we can really measure the colossality of the thing.

Re:800 pages in length

[eddy]

>A single core on a 3Ghz Core2 can match the performance of Padlock.

Which of course, is pathetic, all things considered. It's like hammering in a screw. Yeah sure, with a big enough hammer it'll go in...

>There is nothing magical about this

Who mentioned magic? I sure as hell didn't.

>The fact that the Core2 can keep up says volumes about the poor implementation of the C7.

Yes, an Intel 3.0GHz Core2 CPU at 100% load keeping up with a ~12W fanless CPU. I can see how you'd consider that a loss for the VIA implementation, if you're on drugs.

I don't know what the hell the point of your comment was, I seems to be argumentative just for the sake of it. The facts are simple: If Intel and AMD worked together on a cryptographic instruction set, we'd get FANTASTICALLY BETTER performance in these scenarios. We're talking 10-20x the performance of just bruteforcing it, spending CPU time that could be used for something better.

If you want to argue against that, I suggest you visit the local bar. I believe its name is /dev/null

Re:800 pages in length

[Makoss]

A single core on a 3Ghz Core2 can match the performance of Padlock. I can't provide a link as the figures are unpublished but it's not particularly hard to work out how.

I don't suppose you could provide any numbers along with that claim? Because a non-padlock CPU matching the performance for AES-256 would be really useful sometimes.

For reference here are padlock numbers on a moderate Padlock equipped CPU:
cpu family : 6
model : 10
model name : VIA Esther processor 1200MHz
stepping : 9
cpu MHz : 1197.115
cache size : 128 KB

Using "openssl speed":
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 47592.92k 155506.46k 359193.00k 531778.27k 621832.68k
aes-256-ecb 58605.48k 213317.70k 578567.91k 1008950.60k 1287371.44k

And of course, as has already been mentioned, watts matter.

Re:800 pages in length

[smallfries]

Ah, I was talking about the 2Gb/s claim on Via's page. I would expect that to be 250MB/s of throughput for AES. The overhead of openssl is another matter although I would expect it to be less of a factor on a Core2. The single core of a Core2 should exceed 250MB/s, although not by much.

Re:800 pages in length

[12357bd]

I suggest you visit the local bar. I believe its name is /dev/null

Fantastic name for a geek's bar!!....

See ya at /dev/null! Great!

Disclaimer!: No!, I! don't! work! for! Yahoo!

Re:800 pages in length

[vuffi_raa]

actually being pdf's the width would be 8.75" with the depth being 8800" or in a standard print 3.04"

Re:800 pages in length

[Makoss]

So no, it is not pathetic that a 3Ghz general purpose processor can match the special purpose extensions on the C7. Given that the achievable speedup is much larger than the ratio in clock speeds (let alone the extra the Core2 is doing) is shows that the VIA performance is shit.

If it were true that the Core2 could match the speed of the Padlock AES, adjusted for clock speed, then padlock would be disappointing. Not worthless, as a complete VIA based system including a pair of disks will run on ~30 watts, but disappointing.

However that's simply not the case. The best numbers I can find are around 125MB/sec for a 3GHz core2, you list 250MB/sec and reference "unpublished results". For the sake of argument I'll accept your numbers.

AES-256-CBC on a 1GHz Via part, an older board than my other post, does 511MB/sec with all of the overhead of openssl.

So the performance adjusted for clock speed is 6x the Core2 using your numbers, and 12x using the best numbers I can find. If you think a 6-12x speedup is "shit" then that is your prerogative, however I think you will have a hard time finding people who agree with you.

There are a lot of things about the VIA boards that are shit. The general purpose speed for example. Without padlock the same board that got 511MB/Sec gets 11MB/sec, that is shitty performance. But what do you expect out of a CPU that doesn't need a cooling fan and has a heatsink that will fit in a 1U chassis?

Re:800 pages in length

[smallfries]

The figures that I found googling were about 45MB/sec for openssl. If it hits 511MB/sec then yes that is much more impressive, but that is ten times higher than the top few results in google suggested. The unpublished figures that I mentioned will be released in a few months: they're not mine but I can't really spoil another researchers thunder, as it were. Even ignoring those results there are published results for Crypto++ that show 20 clocks-cycles per byte for AES. That's 150MB/sec per core.

Maybe I'm missing something in your figures but how is 511MB/sec a 6-12x speedup over Core2? You can't just multiply out the clock-speed because the length of the longest path in the AES circuit won't allow the circuit to scale to 3Ghz.

The argument is quite simple: a "good" result for special purpose hardware is at least 10x faster than a general purpose circuit. This is roughly the order of speed-up in software specialisation, and for a lot of problems the hardware speedup is much higher.

The Via can produce 2x the throughput of a single core on the Core2. Applying a block cypher is inherently parallel so we can assume that using both cores will match the performance.

Sure your other arguments are nice, like the Via uses less power etc etc. But the point remains: for a processor that incorporates a special-purpose hardware circuit just to do AES the performance is lack lustre compared to the fastest general purpose architecture.

Re:800 pages in length

[Makoss]

I'm getting the figures I have from openssl 0.9.8g running in Linux on either a 1GHZ Nehemiah CPU, or a 1.2GHz Esther. You can find similar numbers by searching for "openssl speed padlock aes".

Maybe I'm missing something in your figures but how is 511MB/sec a 6-12x speedup over Core2? You can't just multiply out the clock-speed because the length of the longest path in the AES circuit won't allow the circuit to scale to 3Ghz.

I said "the performance adjusted for clock speed", yes it's a pretty meaningless number. The hardware implementation certainly won't effortlessly scale to 3GHz for the reasons you mentioned any others. It was a poor attempt at normalization.

I should have either given the encryption per watt, or noted that I'm seeing linear scaling between the 1GHz and 1.2GHz parts I have, so perhaps one could expect the 1.8GHz part they ship to continue that trend. However as I don't have one on hand, I can't verify that.

Anyway, the point I'm trying to get to is not that the VIA CPUs are better than a Core2. But that I would like to see hardware AES, or at least something that matched or bettered the performance of Padlock, on a Core2.

Specifically I want to be able to read off an encrypted aggregate block device, and stream that out a gigabit connection over encrypted IPv6/IPsec connections. Without completely monopolizing the CPU.

The point is that if core2 had a padlock equivalent running at 3GHz*, you could do the above on a 10GigE connection. Or more practically, you could encrypt everything with no meaningful processing overhead. Yes this is a minority consideration, but it is one that's useful to me. Check my signature and you can probably guess why I care.

* I don't think it's too much of a stretch that between correcting the "shit" padlock implementation, and the compromises needed to make it run at 3GHz, it might be about even.

Look, this is not a Core2 vs. VIA argument. There is no contest there, the Core2 is on the order of 10x faster at everything (except AES/SHA), as it ought to be. The VIA CPUs are not as good. It's a smaller design team, with a smaller budget, running on really old process tech. Of course they are crappy, that they are slow and shitty is given, it does not need to be argued.

I don't particularly care if the CPU comes in a blue box or a green one, or if it's extra special hardware or a new software technique using existing hardware. All I want is to see a fast general purpose CPU that can do AES-256 at 1GB/Sec or better per core.

Re:800 pages in length

[smallfries]

I can see that we've been arguing at cross purposes somewhat. My original claim that the Padlock implementation was shit was not an indication that hardware acceleration for crypto is a bad idea. Perhaps I should mention that I work as a post-doc in a crypto group, I published a paper last year on accelerating RSA on graphics cards, and there are guys sitting a few desks away who design instruction set extensions.

I know they're a good idea, and I agree about your target application being an interesting one. In fact I woud say that it will become a vital one within five years. My point was only that Padlock could be much, much better than it is. And yes, your analysis is correct that the relative size of the design time at Via vs the one at Intel is responsible for this.

Your business looks interesting. I was looking into doing something similar last year: essentially I want to store 2-3TB of data somewhere. I want it to be robust and highly available, with fast download speeds and I don't want to pay the earth for it. I would prefer if the storage was an encrypted block device at the far end that I can mount and decrypt locally.

When I ran the numbers it looked like I could turn a 100% profit over my running costs, offering 250GB slices for (and my memory may be way off here) $50 a year. Your site looks interesting, but would you offer a service like the above for a reasonable price?

Re:800 pages in length

[Makoss]

I figure padlock works about as well as everything else on a VIA platform, so my expectations are pretty low. You seem to be in a much better position to judge just how bad it actually is. My experience has been that with increased knowledge in any specific field comes increased scorn for just how bad most people are doing things.

Sounds like an interesting paper, did you end up with a working test implementation that gave good results? I'm guessing that you may have run into annoying latency, particularly when reading data back from the GPU?

My business, of which I am a founder but not the entirety, is pretty interesting (Then again I would say that...). Our middle tier of service uses VIA boards and takes advantage of padlock to do full encryption of the system and storage disks, which is why I've an interest in padlock. (And a bit of worry about the recently released cold boot attacks on encryption keys.)

Our top tier hardware for example does not use full disk encryption, because it would impact performance. We get ~350MB/sec internally from the disk array and the rate at which we currently can process data for backups is limited to how fast we can SHA-256 chunks of an updated file, which is just a bit over the 350MB/sec the disk array can do. Adding more processor power is easier said than done as the thermal load of 12 storage disks, 2 SAS database disks, and two dual-core CPUs is really pushing the cooling limits of the amount of airflow you can squeeze past all of the hardware in a 2U chassis. Which is why something than can do AES-256 at 600MB/sec in ~12 watts would be very appealing.

As for 2-3TB of offsite data, what with 1TB disks being as inexpensive as they are, the biggest problem is really what you mean by "robust and highly available". What that says to me is two sets of offsite hardware, both of high quality, and two sets of colo bills. In addition to a replication scheme between the offsite storage locations. All of which starts to get kind of incompatible with the "don't want to pay the earth for it" constraint. Even so $50/250GB doesn't leave a lot to work with.

To price it out using some hardware prices that are fresh in my mind: 10TB servers (12 disks, RAID6) with quality components such as redundant PSUs will set you back about $6.5K each, more if you don't build them yourself. Slowish 10mbit colo costs $100-200/Month. For a redundent setup that's $13k in hardware, and say $150 *2 * 12 = $3600 in colo costs per year.

$50/Year for a 250GB slice would get you $50 * 40 = $2000/Year. Not enough to even cover colo costs if you want replication, and only $200/Year more otherwise. Unless I'm missing something it doesn't seem like $50/Year for 250GB of offsite storage is doable unless you already own your own datacenter/colo facility. And even ignoring the colo costs you would have to cut a lot of corners on the hardware to make a profit at $50/year/250GB.

The best we could do would be about $0.80/GB/Year for a single offsite copy. We have plans for something vaguely like this, and by the time we get anything ready to release, that price will probably have dropped a bit. But $0.20/GB/Year is just not doable without seriously large volume. $0.20/GB is in the range of what current commodity storage such as S3 charges per month.

If you looked at our website you probably saw that what we're doing is pretty constrained. Basically a NAS box with some extra features that keeps itself completely backed up to replicated storage, and is replaced at no additional cost and will a full copy of the backed up data if it ever fails. Our prices, though better than anyone else in the industry that we've found for high capacity, are still probably quite a bit higher than you're looking for in the 2-3TB range.

That being said we do have some really interesting and novel stuff in development for how distributed data storage is done. Unfortunately I'd have to kick my ass really hard if I discussed it on an open forum before we finish and release it.

Re:800 pages in length

[smallfries]

The GPU implementation barely worked ... and it took about 12 months to get it into that state. The original idea was simple enough - can we do multi-precision integer algorithms on a GPU. We went for the 7800GTX, theoretically it should have been 35x quicker than the CPU reference. In practice almost everything went against us:
1. Driver issues - to make the approach work we needed to generate hundreds of specialised shaders. There is a huge latency issue in the driver for doing the context switch that doesn't relate to the costs in hardware.
2. Unit sizes - the shader hardware hides its huge startup times pretty well when you are doing millions of iterations of a single small shader. We were shading hundreds of quads with each shader then switching. In combination with point (1) this kills performance.
3. Program length penalities. Nvidia have really optimised for tiny shaders. Longer programs have a super-linear slowdown.
4. The CG compiler was shit. You can't turn off unsafe floating point optimisations that break integer code...

The list goes on, but you get the idea. In the end we managed to squeak past the CPU implementation and go about 2x as quick. Only for our reviewers to complain that they would have written better CPU assembly... Perhaps things have changed with CUDA, but Nvidia certainly needed to improve their game on the 7 series. The final issue would have been the card memory latency but we spent all our time just trying to win on the compute cost. For exponentiation with large key sizes there is a lot more computing than memory access.

You noticed that my requirements don't line up with my budget :) Ideally I would take robust to mean mirroring, at different colo's, each on a different backbone. When I was costing up what I was prepared to spend that dropped to RAID-5 on a single box. Such are the constraints of my wallet :) The $50/250MB/yr estimate was based on similar costs to what you said, obviously a factor of two from avoiding replication. The profit margin only considered the running (bandwidth/colo) costs, and I think it took 18-24months to break even on hardware. That was when I decided it wasn't worth the effort for me, although I'm still interested in paying someone else for doing the work.

I'll keep an eye on your website, because if you go into that market with prices in that region you have no competition at all. The current wave of backup providers / media sharers give tiny chunks of storage for at least 10x the cost. You've picked a good market to get into. My personal guess is that 5 years from now everyone will have some sort of "cloud storage" to steal last years buzzword. The main driver is that people are switching to laptops from desktops, and nobody wants to carry around that kind of storage. Fast broadband + fast office connections make it practical to carry a virtual disk where ever you go. The privacy angle is key for a lot of people, but if that works I think it is a service that has monetary value.

I could guess what your plans are just by considering what I would do: dump the RAID hardware and move to JBOD. Implement the replication and redundancy in software by going down the same route as Google did with GFS. Slash the hardware costs as much as possible and invest in the service that you can run over the top of a bunch of cheap machines spread through different colo sites.

Re:800 pages in length

[Makoss]

Sounds like a frustrating time. Completely out of my area of expertise, but good luck with future work. Reminds me of why I decided to get out with a MS and start a business...

and I think it took 18-24months to break even on hardware

Which is a bit further than you can hope to stretch things when you're just getting started. That's a long time to not be making any money. Additionally unless you have piles of money laying about to cover the unexpected, it will make your service a lot more fragile because you simply won't have left yourself the resources to deal with problems. For instance, most of our current service offerings break even within 12 months, because anything longer would seriously compromise our ability to provide support and hardware replacement to our customers.

cloud storage

It's a very interesting problem, and I agree that it will be an inseparable part of future data storage. This gets back to where the discussion started, on Padlock. I've yet to see a cloud storage or clustered storage implementation that isn't shit. Want to make yet another shitty cloud storage system? Grab FUSE, convert file paths + (offset % 8192) to a hash, and stuff it into a DHT (Chord, CAN, Tapestry, take your pick). Congratulations, you're the newest crappy cloud storage provider!

The reason my company didn't do that is because we didn't think that anyone would seriously be interested in something so shabby, though the market seems to be proving us wrong. Guess that's what we get for all having come from technical backgrounds.

However, there is also the problem that when all you have is a crappy product that is basically on par with what everyone else has, it comes down to a battle of marketing. Instead I'd rather spend my time working on something that is far enough ahead of the curve that even the combined marketing suck of a bunch of CS people can't drag it down.

Re:800 pages in length

[Josh Triplett]

Intel *did* introduce AES instructions. In fact, the current development version of GCC has support for them already; the release notes for GCC 4.4 say "Support for Intel AES built-in functions and code generation are available via -maes.".

font?

[B5_geek]

I hope they used a very tiny font!

I want to love Via, but they keep disappointing me.

Re:font?

[bloodninja]

I hope they used a very tiny font!

I want to love Via, but they keep disappointing me.

ATI started off with 800 pages as well. They kept adding to it, to the point where ATI graphic chipsets are almost as well supported Intels, and even have budding 3D support in the free drivers. I have faith in VIA.

Re:font?

[Ilgaz]

Disappointed for what? Do you expect a "10 PRINT HELLO WORLD" like thing in age of 2008?

Chipsets are way too complex stuff, they will indeed have 800 page documentation. People developing that kind of deep stuff actually uses all those 800 pages of documents.

Re:font?

[Asztal_]

They should have asked the OOXML people to help out.

Re:font?

[Jason Earl]

Personally, I would say that hiring Harald Welte is a better indication of VIA's intentions than the release of documentation. Nobody in their right mind is going to hire the owner of GPL-Violations.org unless they are absolutely serious about Free Software.

Welte eats vendors for breakfast. Hiring him grants VIA instant credibility. If VIA drops the ball it is very likely to get crucified. Unless the executives at VIA have the intellect of fence posts this indicates a sea change for Free Software support from VIA.

Re:font?

[Nutria]

Welte eats vendors for breakfast. Hiring him grants VIA instant credibility.

It also distracts him from GPL-Violations.org.

Re:font?

[Jason Earl]

I didn't realize that Welte did gpl-violations.org for a living.

Re:my family have a confectionery business...

[Drinking Bleach]

I'm sure Linux developers love having their cake and eating it too!

Re:my family have a confectionery business...

[bloodninja]

I'm sure Linux developers love having their cake and eating it too!

The cake is a... yeah, you saw that one coming didn't you?

state of integrated graphics

[walshy007]

makes you wonder, what with intel and via and amd/ati opening their documentation etc, if it will get to the point in the near future where nvidia will be the only binary blob in regards to video drivers.

come to think of it, this trend is something similar to what happened with wifi a few years back. Everyone was using binary blobs, then atheros, ralink etc release specs and oss drivers. let us hope this pressures the remaining vendors to do the same.

Re:state of integrated graphics

[DrSkwid]

and also the only one with fully accelerated 3d

Re:state of integrated graphics

[Ilgaz]

They need serious competition from ATI and Linux fans choosing ATI because of document availability.

Same goes for Via too.

The pressure can only be done via free market and people's reason for choosing a product. Lets say, a huge customer like a country Army chooses ATI for their computers over NVidia just because ATI is documented. I tell you to count days (not weeks!) before Nvidia does similar move. Just watch the governments after the documentation of VIA, the salesman will have a real hard to beat argument: "It is open!"

Does the security agencies, armies still buy Nvidia while choosing Linux/BSD because the source is open? It really makes no sense to have binary thing running in supposed to be open and secure OS.

Re:state of integrated graphics

[CastrTroy]

Intel has fully accelerated 3D for the features it supports. They may only have low end cards, which don't have support for more advanced features, but I'd like some assurance that my video card works now, and can continue to be supported in 10 years from now, when it's not hot stuff and the manufacturer decided they don't care about a product they no longer produce.

Re:state of integrated graphics

[Darkness404]

Honestly, I don't think that most Linux-users will be picking VIA. VIA is known for making really cheap hardware, but it many times doesn't last as long nor run as fast as Intel/AMD chips. Yes, the gPC and others use it, but for the average person who walks into a store and buys a computer, it will have an AMD or Intel chipset most likely.

That said, I think that it is great that VIA is opening up docs, and I can't wait for nVidia to do the same, compiz cubes for everyone!

Re:state of integrated graphics

[Ilgaz]

Now it is open, some very advanced developer may pick it and make that cheap hardware integrated graphics become the fastest performing integrated graphics in that class. They are very much tied to software/driver you know.

You know, such things happened, some people fixed Creative's advanced sound drivers to work fine in Vista I heard.
I got an impression that even big name guys like NVidia and ATI aren't performing the way they should because of drivers. Especially on OS X/Leopard I notice it. 70% of bad feedback about Leopard came because of Nvidia/ATI drivers.

Re:state of integrated graphics

[Yfrwlf]

Well mobile and affordable/portable chips is a really big thing right now. Sure, users wanting powerful systems may not choose VIA but the market for small and portable computers is quite large. ^^

Re:state of integrated graphics

[UncleTogie]

It is cheaper and easier to not use ancient crap.

That all depends on who's buying the parts...

Your mindset considered, you'd better not look too closely into industrial control systems.... your head might explode.

Re:state of integrated graphics

[gnuman99]

I'm sorry, but I'm not picking ATI just yet. I want to see results, not just "useless" specs as I will NOT be writing a video driver just because there is some specs for it.

nVidia cards just work with any modern kernel. And they will work for conceivable future.

ATI cards circa 2000 had some dev(s) working on them and ATI was co-operating or so was the word. That was when I chose the ATI card 7200 with 64MB, VIVO etc. And guess what? The drivers sucked and continued to suck. Then ATI discontinued Linux support for the dev(s) "writing" driver and then we had no Linux support AT ALL for few cards.

Today it just looks like a deja-vu for me. I don't see anything that resembles stability of nVidia drivers from any maker, be it open source Intel (crashed trying to get EVE Online running under Wine for example) or from ATI.

For a 2D desktop, I may chose Via, if they have drivers available, or embedded ATI (maybe, if cheap). But for major video cards like the top of the line cards today from BFG Tech (*best* warranty support I've seen from any company so far :), I'm still inclined to use nVidia. nVidia embedded solution (with DVI output) is also what I'm looking for.

This is from a guy that runs Linux as a desktop. That runs XP under KVM and hasn't booted Windows native for almost a year now (Vista installed on another partition on this box, for development testing).

Aside: There are blobs all over the system. For examples, look at,
    1. BIOS
    2. hard drive
    3. network card/chip
    4. the CPU itself

Finally, OSS is NOT anymore "secure" from security standpoint (ie. no bad code slipped into distribution) than any binary only blobs like Windows. There are just different methods of putting stuff into them.

When was the last time you installed from source, AND reviewed all the code/changes AND compiled with compiler you trusted? Was it done on a 100% secure machine without any hardware trojans? If you haven't done all that, you may as well be running that binary blob. There is no difference.

Re:state of integrated graphics

[someone1234]

I hope the linux people will buy ATI/AMD otherwise they will die soon, very soon.

Re:state of integrated graphics

[Jorophose]

Not only that VIA made a smart move with its Nano design.

Realising that its C7 design, and by extension the Atom design, are not what people want, they moved towards an ultra-low voltage Core Solo design for their ITX motherboards. The Nano is strong enough to run Crysis with an 8600GT, all on miniITX hardware.

Not to mention the VX800 can output at 1900x1200, and can do hardware-playback of MPEG2, MPEG4 h.264 & ASF, along with a few other formats. This is all going to be documented for linux. So, HTPC builders, get ready! If VIA or a VIA partner is going to release a miniITX box based on the Nano, you bet your ass that would be the best MythTV platform ever, especially since nVidia is promoting MiniITX with PCIE x16, so you could even have a monster video card to boot.

Re:state of integrated graphics

[Jason Earl]

Many of the netbooks coming out have VIA chipsets. I haven't picked one up to date because I knew the hardware was not particularly well supported. I've bought VIA in the past, and been disappointed.

VIA chipsets would be great for thin clients and X terminals as well, but once again, VIA's support has historically been sub par. I actually am a little surprised VIA hasn't done this earlier. VIA competes very well on the low power and low cost end of the scale and Linux is fairly important in this market.

Re:state of integrated graphics

[DrSkwid]

Yeah, I'm so glad I can't use my $500 video card today because it's much better to be able to use my $0.50c card in 10 years time!

Piss off you idiot.

I've still got my ZX81 (qitrh 16k rampack), BBC Micro, (the 386 & 486s I ditched), a P54C, a Pentium 75, a Pentium 150, a Pentium Pro Proliant 800 (I cba to find out what speed - probably 200Mhz), another Proliant a bit later 500Mhz I think, then its on to the Pentium IIIs - 10 all the same 700Mhz ish (from a skip), an IBM E-Server dual PIII 733Mhz (that runs my business), a Dell PIII I was using as my terminal until recently, a couple of AMDs - an 800Mhz Opteron and a 2400, some AMD roughly 1Ghz thing I never use, an Intel dual 1Ghz PIII and at the top of the tree an Intel quad core 2.4Ghz. You really don't want my list my pile of VGA/NIC/SCSI and other ISA/PCI/AGP cards and other peripherals.

That's 27 years of still working hardware, from companies who came and went.

Re:state of integrated graphics

[walshy007]

"When was the last time you installed from source, AND reviewed all the code/changes AND compiled with compiler you trusted? Was it done on a 100% secure machine without any hardware trojans? If you haven't done all that, you may as well be running that binary blob. There is no difference."

at some point you have to trust someone, even if you review all the source how do you know the compiler your using isn't compromised? however, why trust many different sources with varying goals when you can trust one source that can be reviewed on what it's doing by others.

While almost impossible to review all of the code yourself, there are others who go through it to scratch their own itches, if anything suspect appeared it gets headlines on the project quickly, or just removed as quickly as it was added.

I'd compare your statement to, someone can use a bulldozer to open the walls of my house, so why should I lock my doors and windows?

and before you say nobody checks code, people do, far fewer than the number of users perhaps, but people do.

Re:state of integrated graphics

[FrankieBaby1986]

and why do industrial control systems need 3d graphics cards again?

Re:linux?

[JSBiff]

Well, as one of the other respondants pointed out, once the docs are out there, it can benefit any operating system, but the point is that VIA wants Linux, in particular (and the technologies like X that operate with the Linux kernel) to better support their products. I think of the three, the one that is most likely to be directly used by the Linux kernel dev is the crypto engine documentation. I think there are kernel-space crypto block device drivers (LUKS - at least, I think it's kernel space; I suppose it might be implemented in user-space) which could be accellerated by the padlock engine. In fact, I think the kernel already has some support for the padlock - whenever I boot my laptop, on which I have used LUKS to encrypt my /home partition, I get a warning that the padlock engine was not found (of course, because I have an Intel Core2 Duo, so don't have padlock).

First Atheros and now this?

[slimjim8094]

It's just a coincidence they came one after another, but I think companies are going to quickly realize that there's no benefit to keeping things locked up.

Suddenly they won't need to pay to write drivers, just release the documentation to write them (of course, it would be nice if they gave us a base). The OSS community will make the drivers more stable, cleaner, and faster. We will use the drivers for things they didn't imagine. All of this will save them money and sell their hardware (features added for free? added incentive to buy my stuff? sign me up!)

I think we may have reached critical mass, at least on the driver side.

Re:First Atheros and now this?

[Paradigm_Complex]

No, sadly we're no where near critical mass. Not yet. There's three main problems:

(1) Companies lose control if they open source their drivers. Examples: Dell recently killed certain features from their sound drivers, and a ways back Creative was upset at someone who hacked up features into their Vista drivers which were purposefully absent (but present on their XP drivers). Both Dell and Creative "lost" here even with closed source drivers - they'd have never stood a chance to screw over their customers if the drivers were open.

(2) Many companies, which should focus on hardware, still worry others stealing their technology from open sourcing their drivers. nVidia is the biggest example here.

(3) Managment people are stupid and can't seem to comprehend how giving away this information can benefit them.

Slowly things are going the right direction, but it'll be quite a while yet. For the time being the F/OSS community will just have to remain in the weird flux of having some things work better than their closed source counterparts (rt2570 works sooo much better on Linux), while some things are worse (x264 acceleration).

Re:First Atheros and now this?

[Yfrwlf]

I'd really like to see some standardization APIs created for more devices so that you only need one driver per hardware class. Imagine if you could just remove the whole proprietary problem with devices so that drivers were simple and new hardware was much easier to support. Perhaps some completely new interface standards could really help, just like how firewire made media drivers obsolete. Any new features can simply be extended to the firewire driver and that one driver updated to take advantage of newer hardware. Perhaps it could even be like OpenGL where devices could actually implement their own newer functions without *having* to have an update to OpenGL. Wouldn't it be nice to see the same thing for graphics cards? ^^

Re:First Atheros and now this?

[Kjella]

a ways back Creative was upset at someone who hacked up features into their Vista drivers which were purposefully absent (but present on their XP drivers). (...) Creative "lost" here even with closed source drivers - they'd have never stood a chance to screw over their customers if the drivers were open.

Creative licensed certain features for XP, that they didn't want to pay for in Vista. It wasn't that Creative was trying to force customers to buy more expensive cards, it was that Creative itself would have to pay an obscene sum to a third party for Vista support. Not getting permanent rights sounds like short-term cost saving on Creative's part but whoever cashed his bonus back in 2001 probably doesn't care. Whoever owned the rights probably knew they had Creative by the balls and got too greedy, so they did the only other thing they could which was to remove those features. Contractually Creative probably had to complain about the license violation. While it shows open drivers is good, but I don't think Creative was being evil here.

Re:First Atheros and now this?

[MostAwesomeDude]

http://en.wikipedia.org/wiki/Gallium_3D

Re:First Atheros and now this?

[gnuman99]

Your network driver or even an encryption chip, well, not quite the same as a 3D driver.

Only the ignorant will say that a company will not need to write their own OSS drivers for 3D cards just because they've released the specs. It doesn't work like that.

Re:First Atheros and now this?

[Yfrwlf]

I'm in love. Thank you. ^^

That's really great that some developers take the modular and API structural systems to heart. The divisioning of work is a great feature that allows for much easier development among other things. I hope the Linux kernel also becomes more modular and flexible in the future, and all software really. I think due to competition you'll see this kind of thing more and more, because the huge unmodular software stacks will become more ignored because they are more difficult and less usable, while the ones that are more modular and thus powerful will see more adoption.

Re:First Atheros and now this?

[Paradigm_Complex]

Perhaps accusing them of trying to screw their customers with that was overly harsh, I'll admit. Still, it still stands of an example where a company would lose control if they open source drivers, evil or otherwise.

Re:First Atheros and now this?

[Squeeself]

Not critical mass, no. The waters are just starting to rush a little faster now. The flood is coming to save you Nvidia...Just don't be building up anymore dikes while its on its way.

Re:First Atheros and now this?

[MrZaius]

I'm sure they couldn't have possibly open sourced that section - Like the man said, it was proprietary code implementing someone else's (presumably patented, or else why bother) feature. It's all but certainly just ilke the licensed code that had to be replaced when the iD games were open sourced.

That said, though, you were right to say that they screwed the customer. To pull an advertised feature for cards already sold because you're too cheap to pay up for a licensing fee or to pay to have it recoded in a cleanroom is damned near synonymous with "to screw."

Re:First Atheros and now this?

[ShadowRangerRIT]

Except that drivers already *are* the standardization API. The hardware differs for performance reasons, and takes different commands to operate, but the driver provides a single standard interface to interact with the device without compromising performance(in theory).

In order to avoid drivers, you'd have to develop a hardware interface standard so all hardware was controlled the same way. Which would hamstring hardware developers by narrowing the options for controlling the hardware or force them to put what used to be the driver in the firmware, so the "standard interface" simply got reinterpreted into internal commands on the card instead of the CPU, possibly requiring special purpose hardware to drive the conversion

Re:First Atheros and now this?

[Yfrwlf]

Some hardware, like ATI, has it's own BIOS on-board so that communication with the device is easier. I believe that an API is possible even for things which change quickly as long as there's enough planning to cope with such extreme changes, but to simplify the API, things like these on-board BIOSes certainly do help.

Unichrome Pro support

[Anonymous Coward]

Next step: Release the documentation for the display adapters please.

The open source drivers mostly can't handle the mpeg2/mpeg4 acceleration, and without that the Epias collapse when you try to watch some higher resolution video. That makes them quite unsuitable for living room usage, which is a shame because they could make excellent HTPCs. With better drivers the better Epia boards could handle HD video just fine..

Re:Unichrome Pro support

[Kent Recal]

Amen!
They may even expirience a small sales boost when all the linux enthusiasts and integrators can finally build their HTPCs around VIA-boards.

Re:Unichrome Pro support

[billybob2]

Even with the released documentation, we also need a good leader like Harald Welte to bring together the OpenChrome and UniChrome developers to work on the same codebase. Right now the split effort is really wasteful.

Re:Unichrome Pro support

[Two9A]

Most definitely. I've just spent two days grappling with the Unichrome driver for X, trying to get it to play video. Of course, the first time I try to play a video file, X crashes and takes IRQ #11 with it, taking the Ethernet chip offline.

So, I'd welcome better support for the CLE266, personally ;)

Re:Unichrome Pro support

[Yfrwlf]

I'd most like to see acceleration for the open source codecs like Vorbis, Snow, Dirac, and others, but mpeg is better than nothing.

Just about time - now for the other solutions

[owlstead]

I'm trying to run Ubunu on a VIA epia for some time now, but their graphics solution is as unstable as hell. There is either the binary driver from VIA itself, or the OS one, but both are not quite what you would expect. Now the question for me is: will it also affect the CN400 chipset (and especially the graphics driver)? Because 5 minutes of average uptime before the machine freezes is not workable. I do think the UniChrome Pro support packages are most important for VIA, the rest already seems to work pretty well.

It seems that each time that a company is on the ropes, they pledge OS support. It would be a good idea for companies to do something when they are not on the brink of extinction. VIA is in a tight spot. They're moving out of the chipset business, and since the eye of Intel is currently on the mobile CPU/chipset business, they can expect the Nazgul to come riding in pretty soon (I don't know too many old testament stories, which seem more appropriate for VIA).

Re:Just about time - now for the other solutions

[thsths]

> I'm trying to run Ubunu on a VIA epia for some time now, but their graphics solution is as unstable as hell.

Yep, same here. The rest of the board works quite well, but I had endless trouble with the built in graphics. With Ubuntu 8.04 it seems to work ok now, but the picture is still a bit fuzzy.

Re:Just about time - now for the other solutions

[guzzloid]

I'm running a CN400 on Debian etch. I had the same problems with ubuntu, but then I switched to plain old Debian + the latest openchrome driver, and the problem pretty much went away. I do still get the occasional freeze during rewinding in MythTV, but my average uptime is on the order of three or four months. Have you got the latest SVN checkout of the openchrome library?

This tutorial should work on ubuntu too:
http://wiki.openchrome.org/tikiwiki/tiki-index.php?page=Compiling+the+source+code+on+Debian

My main annoyance is the fact that I use TV-Out almost exclusively (it's a MythTV box), and the OS driver doesn't seem to be able to correctly sync interlaced video. Sometimes it syncs on the odd 50Hz interlaced frames instead of the full 25Hz full-screen refresh (it's a PAL system). Unfortunately, after a brief scan of these new docs, I can't see anything that would indicate an odd-even frame timer, and I don't know that any of it is applicable to the CN400 :-(

Re:Just about time - now for the other solutions

[guzzloid]

p.s. also worth checking your X-Config too: here's my VIA video settings (tailored for TV-out...)

Section "Device"
        Identifier "VIA Unichrome Pro II"

        Driver "via"
        Option "ActiveDevice" "TV"
        Option "TVType" "PAL"
        Option "TVOutput" "S-Video"
        Option "TVDeflicker" "0"
        #Option "TVDotCrawl" "true"
        Option "EnableAGPDMA" "true"
        Option "AccelMethod" "XAA" # XAA - safe, EXA - CRASH
        #Option "EXANoComposite" "false" # disable exp. compositing
        Option "DisplaySize" "400 300"

EndSection

Re:Just about time - now for the other solutions

[owlstead]

I'm sorry, but I'm not that interested in Linux to try each distro to see if they work. And yes, it is a problem with the vendor and Linux: their support is not good enough for the open source drivers to work, if only for the basic 2D and 3D applications.

Re:Yay, more documentation for shit hardware!

[larppaxyz]

I've been running Opteron servers with VIA chipset for years. Most of my computers at home also have different VIA chipset. I never have had any problems. Servers have never crashed and they are running software that heavily uses I/O and cpu load is almost maxed out 24/7. And yes, they run linux of course. Can you tell us what kind of problems are you having or are you talking about some old KT133 chipset? I personally choose Intel or VIA when it comes to chipsets.

...for *Linux*

[Anonymous Coward]

So, all other non-Linux:ish systems are out of luck?

How does one write hardware specs which are only usable to Linux?

I'm mighty confused.

Re:linux?

[JohnBailey]

Don't you know? All The World Is Linux. Even X. Let's be honest, only someone smart enough to work on Linux could possibly be smart enough to understand the documentation anyway. Us thickos who work on other OSes will just have to try not to get drool on the screen.

Confession is good for the soul.

Re:Yay, more documentation for shit hardware!

[Ilgaz]

I just suggest that if you use Windows (any kind), give up MS manufactured drivers and get a WHQL certified chipset driver from Via instead.

For some reason (!) the Wintel manufacturer keeps shipping buggy drivers on Windows.

I tested this on a laptop and even a high end AMD based video workstation. Something really good happens right after installing them (hyperion or something) and rebooting. Instantly.

Of course, Linux like open source OS'es doesn't have such evil tricks etc.

Re:linux?

[jedidiah]

What other operating systems NEED to write it's own drivers rather than depending on the vendor?

WHO CARES?

It's a really short list.

What other "non-X" developers are salivating over these docs?

REALLY?

That's just a mistake in TFS

[BhaKi]

There is no such thing as OS-specific hardware documentation. The released documentation enables all interested OS-writers/driver-writers to write compatible software.

Re:That's just a mistake in TFS

[BhaKi]

A Winmodem is a hardware-plus-software suite for M$-windows whose modem-functionality is done in software and the hardware-part is just a ADC/DAC converter.

Re:That's just a mistake in TFS

[UncleTogie]

A Winmodem is a hardware-plus-software suite for M$-windows...

...and what would you call the documentation for this hardware, hardware that appears to be {in conjunction with software} designed for only one OS?

Re:That's just a mistake in TFS

[BhaKi]

Although the hardware-plus-software suite is Windows-specific, the hardware itself can be controlled by any OS (given the required documentation) to the same extent as Windows. So the hardware, and hence its documentation, is not inherently Windows-specific. But yeah, I do agree that it's theoretically _possible_ to write hardware documentation in a very Windows-specific way although I can't imagine anyone who would willingly do that.

Re:That's just a mistake in TFS

[Dahan]

I'm not sure what it would even mean for the hardware to be designed for only one OS. Can you give an example of how a Winmodem is designed only for Windows? In any case, seeing that Winmodems work fine in Linux, a non-Windows OS, whether they're "designed for Windows" or not is irrelevant.

Re:linux?

[Anonymous Coward]

It's a really short list.

FreeBSD, NetBSD, OpenBSD, DragonFly BSD, ReactOS, OpenSolaris, Haiku, Syllable, Plan9

Off the top of my head.

What other "non-X" developers are salivating over these docs?

DirectFB, ReactOS, Haiku, Syllable, Plan9

Again, just off the top of my head.

It's O.K, we all know they're just wasting their time. Linux and X are perfect and there will never be anything better, so who else ever needs access to hardware documentation?

Fighting the Atom?

[phorm]

I've been using Via boards for awhile in lower-power (as in watts) webservers and media machines. In terms of power return on low-consumption machines they rock.

One thing I've wondered is why the newer "lower power" rigs are using the Atom processor, which from I can tell in stats is inferior to - say - the C7 in terms of CPU-power-per-watt output.

Re:Fighting the Atom?

[default luser]

The Atom delivers MORE performance/watt than Via's solutions.

Atom destroys the C7 in performance/watt. The C7 has a relatively poor memory architecture and has piss-poor SSE performance in comparison to the Atom. The C7 also cannot match the low consumption of the Atom at a similar clock speed.

If you really think the C7 has good performance/watt, just see how a DESKTOP Intel Celeron keeps pace with the C7 in terms of power consumption. The power consumption is within a few watts, and the Intel chip delivers more than double the performance in some benchmarks. Never mind that the Intel board costs less than anything Via has on-offer.

The Via Nano is closer: it delivers better per-clock integer performance (2 integer units vs one on the Atom), but the two chips deliver the same per-clock SSE performance. When you consider that the Nano uses 3-10x the power of the Atom at various clock speeds, you begin to see how Via can't compete on performance/watt.

Re:Fighting the Atom?

[wild_berry]

Do you have numbers that account for the Intel NB and SB power consumption? When you include those numbers, I think that the Nano and Atom will be close for system-level performance/watt.

Re:Fighting the Atom?

[default luser]

You are of course referring to the D945GCLF with the desktop Atom and 945GC.

Intel is practically dumping the 945GC because it's built in an old 130nm fab, a fab Intel finds no monetary reason to upgrade. The desktop atom chip is much more frugal, with only a 4w TDP, so it is just the chipset holding it back.

The intent of the D945GCLF is not to be an ultra-low power board, but to be a CHEAP board to feed the $100-150 PC market, and find a use for old fab tech. There are much more efficient bridge chips available from Intel that can be used with the Atom: you can use standard mobile GM945 chips (10w less than 945GC), or if you want ultra-low power there is always the Poulsbo chipset featured in the Atom Centrino platform (2.3w total).

Hey, if manufacturers aren't making a low-enough power Atom board you crave and want, bug them to hell and let them know there's a market! Intel isn't the only MiniITX board maker in town, you know.

What are you doing with them?

[phorm]

Both of my newer via (C7) boards are being used as mini-servers right now, so I don't have much use for any graphics drivers, but prior to that I found that my Epia M and other unichrome-based boards worked fine with the via-provided, and later kernel-inherent drivers. They worked nicely for watching movies, some 3d games, etc, and no crashes. This was on a Debian-based system but being that Ubuntu is debian-based and the kernel is cross-distro I'd imagine they should be similar.

Via con Dios, hackers

[istartedi]

Via con Dios, hackers.

Documentation Readability

[Lead Butthead]

Not having read the said documentation yet, is it readable? A lot of documentations from design centers in non-English speaking countries are frequently written in incomprehensible or ambiguous Engrish that are more often than not, nearly useless. Kudos for trying however...

How reliable is their random number generator?

[KWTm]

I see that one of the chips in question is for a random number generator. Despite providing documentation/specs on how this chip runs, to make it possible to write free drivers, it's not the same as having the actual source code for the chip. With any other type of chip this would be well and good, but with random number generators, you can't really test them, and will need to rely on examination of the source code to prove that it works. Even then, it would not be that easy --see the Underhanded C Contest of 2007 in which people write encryption programs, and they work, and the source is open to inspection --and they STILL provide a back door to allow the encryption to be broken. (Man, that Underhanded C Contest is pretty scary.)

I hope the kernel developers and other programmers give us a choice whether to use random numbers from the Padlock chip or from some other source. Me, I'll just plug in my blinded webcam into my USB port and multiply it into any random stream for good measure.

Re:How reliable is their random number generator?

[RAMMS EIN]

You currently do have a choice. But the VIA RNG seems to work well.

Re:How reliable is their random number generator?

[denttford]

random number generator, an advanced cryptography engine, and RSA algorithm computations

Don't worry, thanks to Debian, Linux doesn't actually need these things; documentation is optional too.

Re:How reliable is their random number generator?

[Kz]

According to them, it's quantum-effect based:

http://www.via.com.tw/en/initiatives/padlock/hardware.jsp

in short, it's a set of free running oscillators, where the exact frequency of each is affected by thermal noise. the instabilities generate an easy to detect "beating", turned into bits and accumulated in hardware registers.

there's very little 'source code for the chip' to read and validate; but there are several tools to statistically verify random distributions.

(this one looks nice: http://csrc.nist.gov/groups/ST/toolkit/rng/index.html. i'll try to get some time to test it on my via mainboards...)

Re:linux?

[neumayr]

Absolution is even better.
Given the graveness of your sin, a donation of, say, 25% of your income to the FSF just might save your soul.

Re:Yay, more documentation for shit hardware!

[neumayr]

True that. I had negative experiences with VIA Socket 7, SIS Socket A and nVidia AM2 chipsets.
Seems I only have two choices left when it's time for a new mainboard..

Re:linux?

[c]

> but the point is that VIA wants Linux, in particular (and the technologies
> like X that operate with the Linux kernel) to better support their products.

It might be a lot more pressing than just "wants". It wouldn't surprise me if decent Linux support is now a requirement for VIA to get some of that "netbook" action.

c.

MythTV on Mothballs

[BrunoUsesBBEdit]

Amen!! When I saw how much power I had to draw to do CPU decoding of HD and STILL have stuttering, I retired it in favor of having more time to spend with my newborn. That was 18 months ago. I was sure that the scene would be better by now, but it is not. It's very sad.

When I saw the title of this article, I thought this was the breakthrough I've been waiting for... so sad.

While you are at it... STOP PUTTING VGA ON YOUR MOBOs!!!! --> See: http://www.bronosky.com/?p=54

LUKS is only a key management system

[Burz]

Dm-crypt is the primary crypto block device system that can work alone or together with LUKS.

Re:linux?

[doti]

don't feed the trolls

PDF?

[arth1]

Nothing shows a company's intent not to have documents read and used more than publishing them in PDF.
Scrolling through large PDFs is painful, no matter whether you use an open source program or Acrobat Reader, and the CPU fast enough to compensate hasn't been invented yet.

Re:linux?

[Nutria]

It's a really short list.

FreeBSD, NetBSD, OpenBSD, DragonFly BSD, ReactOS, OpenSolaris, Haiku, Syllable, Plan9

The BSDs share a lot of code, so they can be collapsed into one. The likelihood of OpenSolaris running well of such low-strength chips is low. Thus, the list is small.

Off the top of my head.

What other "non-X" developers are salivating over these docs?

DirectFB, ReactOS, Haiku, Syllable, Plan9

Excellent point. But these are supported by few developers, whose resources are probably aimed elsewhere. Except maybe Plan9, since it was fully-developed at Bell Labs.