Much wow, New "AMDGPU" Kernel Driver

[osbios]

I honestly have no idea if/how the CPU microcode ties into the GPU. The problem here is that you need the microcode for the CPU to initialize, and you need to initialize the CPU to use the integrated GPU, therefor you need a non-free blob to use intel graphics.

No you don't. But microcode gets updated by bios/efi/os to fix CPU bugs.

I have never heared "Virtual assembly" before but I do understand intermediate bytecode, and intermediate representation (IR). Not even google knows virtual assembly.

That is the reason why I use quotation marks. Like you noticed by now patrickjp93 likes to make up terminology on the fly and we end up interpreting as best we can.

But maybe he just has a neuronal network overflow stack exception handling paradox error with ketchup on his hands?!

[yoloswag9000]

No you don't. But microcode gets updated by bios/efi/os to fix CPU bugs.

The microcode is stored on the CPU when its shipping. It doesn't work without a mirocode. You can in fact disable updates to it but there is no way to use modern CISC-like CPU without microcode.

[YoloSwag]

@YoloSwag Time for you to go back to school on OpenGL.

http://waset.org/publications/8403/virtual-assembly-in-a-semi-immersive-environment

C is translated into virtual assembly on its way into the GPU just as I said via the driver.

And the only difference between an API and a programming language is semantics. By your logic C isn't a language. It's just a simple API for a compiler, which no veteran programmer should agree with. Certain keywords and syntax translate to certain computational functions. That is a language.

As per your Intel doc, feel free to read the parallel studio manual like I did. Now, I have more important things to do than argue with a child who couldn't code his way through a binary search tree.

For some reason, I've been tagged in a thread that I didn't even comment on...

 

EDIT: and suddenly, there's someone here who wants me to go back to school just to know something about OpenGL

[bogus]

For some reason, I've been tagged in a thread that I didn't even comment on...

EDIT: and suddenly, there's someone here who wants me to go back to school just to know something about OpenGL

You know the drill... Pack your bags and kiss your parents goodbye.

If they ask what are you doing just tell them "It's something I have to do... some Internet shit you will never understand. I will return when I'm a master of opengl. " and close the door in a dramatic way.

[osbios]

The microcode is stored on the CPU when its shipping. It doesn't work without a mirocode. You can in fact disable updates to it but there is no way to use modern CISC-like CPU without microcode.

Nearly all devices ship with some kind of firmware. But that is not the problem. Often they are not meant to be updated, or only to fix major bugs.

The radeonsi firmware blobs on the other hand contain new code. For example for the UVD video encoder. AMD basically put part of the code in the blob, that they didn't want to be open source. And because of that you can make the case that the driver is not fully oss.

[monstercameron]

Nearly all devices ship with some kind of firmware. But that is not the problem. Often they are not meant to be updated, or only to fix major bugs.

The radeonsi firmware blobs on the other hand contain new code. For example for the UVD video encoder. AMD basically put part of the code in the blob, that they didn't want to be open source. And because of that you can make the case that the driver is not fully oss.

the firmware and drivers are totally different things. the driver is fully open and is loaded into the kernel while the firmware is loaded onto the gpu asic.

[osbios]

the firmware and drivers are totally different things. the driver is fully open and is loaded into the kernel while the firmware is loaded onto the gpu asic.

 

That makes no sense to me. Loaded into the kernel? You mean loaded into ram and executed by the CPU and not the GPU? Not really a good argument.

There are deeply interconnected. In case of radonsi the UVD part of the driver wont work without the updated firmware.

 

Let me give you an example how this could affect you as an end user.

 

Image the current firmware blob v1 enables feature X on your GPU.

And then the release firmware blob v2 that enables feature Y but disables feature X.

 

Now in the case of open source you could go and reimplement X. But in the case of this two firmware blobs there is no way to get X and Y working at the same time.

[yoloswag9000]

Nearly all devices ship with some kind of firmware. But that is not the problem. Often they are not meant to be updated, or only to fix major bugs.

The radeonsi firmware blobs on the other hand contain new code. For example for the UVD video encoder. AMD basically put part of the code in the blob, that they didn't want to be open source. And because of that you can make the case that the driver is not fully oss.

I can't see the difference between downloading a firmware and uploading it to the device at runtime and a device with the firmware already uploaded before shipping. In both cases you need a firmware you can't trust and don't know anything about.

In case of radonsi the UVD part of the driver wont work without the updated firmware.

You say "updated firmware" but what you actually mean is "a firmware". Updating the firmware implies that there already is one. You simply need a firmware, it doesn't matter if it was uploaded by the manufacturer or the user.

[monstercameron]

That makes no sense to me. Loaded into the kernel? You mean loaded into ram and executed by the CPU and not the GPU? Not really a good argument.

There are deeply interconnected. In case of radonsi the UVD part of the driver wont work without the updated firmware.

 

Let me give you an example how this could affect you as an end user.

 

Image the current firmware blob v1 enables feature X on your GPU.

And then the release firmware blob v2 that enables feature Y but disables feature X.

 

Now in the case of open source you could go and reimplement X. But in the case of this two firmware blobs there is no way to get X and Y working at the same time.

again what does the firmware have to do with the drivers?

[osbios]

I can't see the difference between downloading a firmware and uploading it to the device at runtime and a device with the firmware already uploaded before shipping. In both cases you need a firmware you can't trust and don't know anything about.

You say "updated firmware" but what you actually mean is "a firmware". Updating the firmware implies that there already is one. You simply need a firmware, it doesn't matter if it was uploaded by the manufacturer or the user.

Firmware is not the problem. Drivers that depend on specific firmware for features is the problem.

And you can't trust hardware anymore then firmware anyway. But I don't argue about trust here.

I argue about the user being vulnerable to the power of manufacturers that create "oss" drivers that depend on specific firmware.

... In case of radonsi the UVD part of the driver wont work without the updated firmware. ...

again what does the firmware have to do with the drivers?

Why are you quoting me when you did not even read my text? Seriously...

[monstercameron]

Firmware is not the problem. Drivers that depend on specific firmware for features is the problem.

And you can't trust hardware anymore then firmware anyway. But I don't argue about trust here.

I argue about the user being vulnerable to the power of manufacturers that create "oss" drivers that depend on specific firmware.

Why are you quoting me when you did not even read my text? Seriously...

I did read your text, that is why I am quoting you lol, You claim the driver were no "fully" opensource, and you claim that is due to proprietary gpu firmware. Let me ask you again in a different way, what does the firmware have to do with the licensing of the gpu drivers?

[osbios]

Well, that is a different question then.

When the firmware would be a binary blob running on the CPU as a separate process that is managing/translating the communication between driver and GPU, would you still consider the driver that depends on it as open source?

Firmware classically did not have much power because the devices where less complex. Often they never got/needed firmware updates at all. So nobody cared.

But now there is this gray area where they get used to "outsource" parts that would go into the oss driver otherwise.

I remember some time ago when Nvidia removed support for more then 3 screens in there linux drivers just because that was the limit in windows.

AMD could do the same to a newer firmware version that you need for e.g. hardware video decoding. So there is the same potential of "surprises" for the users.

Just because this works with the GPL2 and the kernel developers are fine with it at the moment, does not change the possible implications.

[yoloswag9000]

I remember some time ago when Nvidia removed support for more then 3 screens in there linux drivers just because that was the limit in windows.

AMD could do the same to a newer firmware version that you need for e.g. hardware video decoding. So there is the same potential of "surprises" for the users.

Sure, but you argue that firmware which can not be updated is in inherently better. In your example however the user would not be able to use video decoding, even not if the user would sacrifice another feature.

 

Firmware is firmware. How and if you update it doesn't matter, it's simply a distribution problem.