Matthew Garrett ([info]mjg59) wrote,
@ 2009-01-26 22:54:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Entry tags:advogato, fedora

Nnngh.
Intel have a magic communciation channel between the system firmware and the graphics hardware. It's based on a region of shared memory and judicious use of interrupts, and it's documented here.

Nvidia have a magic communication channel between the system firmware and the graphcis hardware. It's based on WMI and bonghits, and it's not documented.

Why, yes, I have spent half the day trying to work out how the NVIF method works.


(10 comments) - (Post a new comment)


[info]pjc50
2009-01-26 12:05 pm UTC (link)
Why do firmware authors do this? Why reinvent the wheel and make it square?

(Reply to this) (Thread)

[info]mjg59
2009-01-26 12:08 pm UTC (link)
The Intel one is fairly specific to Intel hardware, and to be fair I suspect that the Nvidia one may actually predate it. If you mean "Why did nobody go to the effort of taking this through a standards body" then, well.

(Reply to this) (Parent)(Thread)

[info]pjc50
2009-01-26 12:29 pm UTC (link)
What I mean is that the challenge of communicating between some bit of firmware on a PCI card and drivers on the host CPU is the sort of thing that ought to have something like a link-layer protocol which is standardised, open-source, or at least conventional.

The PCI hardware is completely standardised, and the drivers and firmware are necessarily device-specific, but there's common tasks like "driver synchronously read/write settings", "driver request state change with asynch notification of completion", "hardware asynch notify drivers of event", etc., which pretty much any reasonably complicated PCI device is going to want to use.

(Reply to this) (Parent)(Thread)

[info]mjg59
2009-01-26 02:09 pm UTC (link)
Shifting it to the PCI layer doesn't help a great deal, because you'd still have no standardisation on what these commands actually meant to the hardware. The transport layer isn't really the hard bit here (while using WMI is astonishingly insane, it's only about 10 lines of boilerplate code to sort out that side of things), the problem is that there's no incentive for the implementations to converge.

Some of what's going on is genuinely outside the realm of PCI, though. As an example, thermal management of nvidia hardware on a laptop at boot is going to be handled by the platform firmware. This will generally be conservative. Once you're booted into a functional OS you can offload that job to the drivers. That's not a case of you wanting to send information to the GPU - you need to communicate with the firmware. Other examples might be things like lid state and video connector attachment, things that are controlled by the platform rather than the thing at the other end of the PCI bus.

(Reply to this) (Parent)

[info]baljemmett
2009-01-26 12:34 pm UTC (link)
I look forward to seeing kbonghitsd!

(Reply to this) (Thread)

[info]aigarius
2009-01-26 01:40 pm UTC (link)
And then have it replaced by kvaporiserd :D

(Reply to this) (Parent)(Thread)

[info]pjc50
2009-01-26 03:26 pm UTC (link)
That'll never happen, it's vapourware ;)

(Reply to this) (Parent)

(Anonymous)
2009-01-26 04:28 pm UTC (link)
Slightly off-topic: could you please upload your LCA slides? :-)

(Reply to this)

So...
(Anonymous)
2009-01-27 01:31 am UTC (link)
"Why, yes, I have spent half the day trying to work out how the NVIF method works."

Did you succeed?

(Reply to this) (Thread)
Re: So...
[info]mjg59
2009-01-27 01:33 am UTC (link)
Somewhat. I've got a rough idea how it works but not what all the arguments do, so some further investigation is required.

(Reply to this) (Parent)

(10 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…