You are viewing libv

LIBV Intentionally Breaks Videodrivers - Pleased to meet you, hope you guess my name. [entries|archive|friends|userinfo]
Luc Verhaegen

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

Pleased to meet you, hope you guess my name. [Jan. 28th, 2008|10:42 pm]
Previous Entry Share Next Entry
[Tags|, ]
[music |The Rolling Stones - Picture Disc 08 - Sympathy for the devil (1979)]

A lot of effort is being made to re-market AtomBIOS.

For instance, AtomBIOS function tables are being actively and consistently referred to as "scripts".

Wikipedia tells us that: "... [scripting languages] are distinct from the core code of the application, which is usually written in a different language, and by being accessible to the end user they enable the behavior of the application to be adapted to the user's needs."

At no point do AtomBIOS functions come close to fitting the definition of script, at least not as we get them. It might start life as "scripts", but what we get is the bytecode, stuck into the ROM of our graphics cards or our mainboard.

The tools to generate this bytecode can now of course be written, but such tools are currently not available, nor is anybody planning on writing them. There are also no tools to replace functions in our existing vga BIOS images, or tools to generate brand new images. But none of this matters as ATI doesn't want us to flash our graphics cards ROMs in the first place.

Then there is the warped use of "legacy", another sign of advanced marketing. In the radeon driver, all the code that directly programs the modesetting of r1xx-r3xx (and rs4xx) radeons has now been moved to files starting with "legacy".

Once again, wikipedia provides some clarity: "A legacy system is an old computer system or application program that continues to be used because the user (typically an organisation) does not want to replace or redesign it."

So C code, that sets up hardware directly, and that can be evolved as driver frameworks and modesetting models evolve, is being labelled "legacy". Yet it is exactly this C code that recently got completely restructured to support RandR1.2.

And then AtomBIOS... Bytecode that cannot be replaced, with a seemingly fixed (but surreptitiously moving) API, which enforces a given way of working to the driver developer... That stuff is not legacy... Right?

So MIT licensed C code is "legacy", and untouchable bytecode is "scripts".

I'm sure that if this is repeated enough, people might actually start believing it.
linkReply

Comments:
From: (Anonymous)
2008-01-29 03:10 am (UTC)

(Link)

"Script" : "A set of commands written in an interpreted language to automate certain application tasks." Of course, the definition of "commands", "interpreted language" are both ambiguous, and some people will include bytecode as the result of the interpreted language and thusly bin it with scripts. Perhaps "functions" or "tiny executable segments" would be more precise, but most people don't hang on the definition of each and every word.

"So MIT licensed C code is "legacy""
This has nothing to do with anything; "legacy" is a term often used for old ways of doing things (as "legacy" means "heritage", "old", "things past"). The "New" way of doing things is to use the Atombios, thusly making the current, non-Atombios code "legacy"/"old"/"retired"/whatever-other-synonym-you-choose-to-use-here. Again, no need to hang on the definition of every word.

Should we be upset that the Atombios is taking control of certain key parts of the control of the hardware out of our hands? Maybe, maybe not, that's a different discussion.
[User Picture]From: libv
2008-01-29 09:41 am (UTC)

(Link)

And which company do you work for :)

Thing is... Once the political wind changes inside AMD, AtomBIOS will be declared legacy. And then the question becomes; what is the new naming scheme going to be? What will we be imposed with then? And what tricks will be pulled inside -radeon to support this?

There will be a time when ATI can politically accept that AtomBIOS, as it is now, is not the solution. There will be a time when the voices inside that say that it is not the right technical solution for a problem that didn't solving in the first place, will no longer be muffled.

Script is incorrect here, bytecode is right. Script is being forced down our throats to have us believe that it is safe and easy to work around and fix.

The warping of these two words make it impossible to deny: it is something wrong, that somehow has to be made to appear right.

But i guess that for that i would have to go and describe the technical problems i see with AtomBIOS, which is time i would like to spend on code first, but if pushed enough, i will do so.
From: monikajixeb
2008-07-13 10:21 am (UTC)

(Link)

Sinofsky: In a way that's a different question. That's sort of a question about how are we talking about our current products in the marketplace.
From: nchip
2008-01-29 11:56 am (UTC)

a bit like ACPI

(Link)

ACPI is also being sold as scripting language, abstraction layer, "drivers no longer need to care about PM", yadayada.

It's only when I started working on embedded hardware I realized how unnecessary such proprietary bytecode layer is. suspending peripherals from their drivers is really simple to do, much more so than trying to get buggy vendor-provided bytecode to execute correctly in a enviroinment it was not meant to be run in (hw vendor only tests windows). In x86 Linux have to hope ACPI isn't buggy and allows us to suspend, workaround ACPI bytecode messing up states of peripherals (hwmon sensors with bank switch register being a recent example), etc, etc. At arm, we can just put the chip in whatever lowpower mode we want from *driver* when last user application lets it free.

IMNSHO acpi and atombios-alikes usage should be restricted to various tables they provide - what devices are available and where, what parameters to use for RAMDAC etc.
From: (Anonymous)
2008-01-29 01:33 pm (UTC)

Re: a bit like ACPI

(Link)

Well, there is one thing where atombios functions are fantastic... At least compared to what we needed to do before... It makes a good replacement for running the full VGA BIOS with int10 and an x86emu.

When i have to choose between either, i would choose atombios. No discussion.

But... This is purely because engine setup and memory controller configuration etc, is just too much work to handle for all various pieces of hardware out there. But if anybody wants to spend the time, and it would be time very well spent on IGP devices, then it is very manageable to get rid of ASIC_Init too for some devices.

That said... Yes, it is rather awkward. The interface is trying hard to appear stable, but under the surface it really isn't. Plus, it is like any other BIOS; you do not really want to know what is going on, as it is not written for people to look at, just written to pass test cases.

The data tables, these are indeed very important, yet sadly, they also are not always perfect, and they do not expose all the necessary information either.

ASIC_Init, in bytecode, is a necessary evil, that, in all but a few cases where dedicated individuals spend a bit of time, will be hard to do without. Data tables, yes, we need thm, they tell us what we need to know as driver developers, yet they currently do not tell us the full story either, and it is getting worse, as data tables are being actively deprecated.

But for modesetting, we should not depend on bytecode, especially since only the easy bits are hidden, and the hard bits are still left up to the driver developers (like PLLs).
[User Picture]From: libv
2008-01-29 01:40 pm (UTC)

Re: a bit like ACPI

(Link)

That was me of course, not noticing that i wasn't logged in to lj on my work machine :)
From: (Anonymous)
2009-12-03 10:56 pm (UTC)

Oh boy…

(Link)

Is this post a reason I won’t ever use *any* project that you touched! You are fanatically nitpicking beyond belief. Who cares for all that shit? You’re not even following your own rules to the end. You split hairs over this stuff, while you still use a graphics card hardware that is *proprietary*!

Go on! Walk the whole way, and soldier your own computer! With your own tools. Built only with stuff that you have blueprints and everything of!

What is that? You think that’s unrealistic and pointless? Well... No shit? ^^
I does not make your life any better. Not in the short, middle, long or any run.
It only creates ulcers.

What? Your goal *is* to free *everything*? I respect that. But for me it’s far from being worth it. I think on bigger scales. In some decades everything will be completely different (but still the same) anyway. ^^

I change bigger things. I work on engineering whole social systems. Program communities. Hack physical lifeforms and lifeforms that only exist as mindsets/information/ideologies.
That is the future! Who cares about some irrelevant single hardware company, when you can change a whole planet?

Just watch me… Hahahaaaa!
[User Picture]From: libv
2009-12-04 04:46 am (UTC)

Re: Oh boy…

(Link)

eh?

This post is close to two years old, and on top, it is made anonymously.

You seem to think on bigger scales, i guess you mean timescales here. Good luck. I'll be happy to hear from your anonymous achievements in 2110.