The Libdrm & xf86-video-amdgpu Repositories To Follow For FreeSync

[darkbasic]

you are imbecile. if they hardcode it, i will not be able to get fixes

That's exactly the point: you need to program something and that's why you need a SOFTWARE to do so.
If you are not familiar with terms like "software" go read wikipedia and you'll find that microcode is still software: https://en.wikipedia.org/wiki/Software

so go fuck yourself

you are imbecile

Go fuck yourself, I'm not going to take insults from random idiots on the net. If you're not grow enough to talk to people without insulting them, then go back playing with your toys.

the only people spewing bullshit here are people who call it driver
nouveau developers can't implement hardware features. btw, i see correlation between { imbeciles who call driver closed because its fimware is replaceable } and { people who are interested in nouveau(i.e. who sponsor most linux-hostile hardware vendor) }

Yuo're a double imbecile then because
1) Freesync is a monitor and display interface hardware feature and I'm not the only one interested to know about which kind of support is required by the card
2) I'm far from being interested to sponsor Nvidia, but it doesn't mean that I shouldn't be interested in the nouveau progress.

There is a big difference between calling an IDEA "bullshit" and between calling a PERSON "idiot" or "imbecile". It shows how small of a person you truly are.
I've always been respectful towards *people* and I've never insulted anyone, especially bridgman who I respect greatly. Respecting people doesn't mean that I should respect all their ideas too, while not respecting their ideas doesn't allow you to not respect people. Grow up.

[bwyan]

lol...

[smitty3268]

Well, that escalated quickly.

[uid313]

I would love to see Intel adopt FreeSync too.

[chithanh]

What are the chances of the other drivers being able to use this feature?

There is a hardware specific part which would be necessary to implement in each driver, and there is a hardware independent part which can be re-used by other drivers from what I can tell.

NVidia hardware already supports DisplayPort Adaptive Sync (it's their G-Sync for notebooks), so I guess it would in principle be possible for desktop cards to support it too. Unless of course, NVidia implements something blocking that, which would not be out of the ordinary for that company.

"purely open-source Radeon Linux graphics driver" you forget the fimrware

The Linux driver itself (the part which runs in the kernel) is fully free and open source software. However, it works only in combination with a separate piece of proprietary software that needs to be loaded into the hardware at runtime.

The hardware is not, and that's where the microcode comes in.

you forget that firmware is part of hardware, not driver

These statements are misleading, too. The microcode is clearly software, not hardware, and it comes with all the practical and ethical problems of proprietary software.

[salsadoom]

Ignoring the flamewar going on here..

I am really excited for FreeSync in Linux. Because wow, it really does look great. I have a relatively modest monitor with only 75hz and testing out games on Windows (bleh..) with it going it really looked completely glass smooth and perfect to me. That said, in general I don't have a tearing problem since I ditched nvidia for my rx 480, not in games and not in the desktop. So that's nice, but the adaptive sync does look good beyond that, and it'll be sweet when we finally get it.

[artivision]

The driver is purely open source. The hardware is not, and that's where the microcode comes in.

The display/sound/energy/cooling management are not part of the hardware, but you did close them in VBIOS. Why we need this to run the open driver? And what we can do if that isn't provided some day? I hope that you didn't decide to hide another secure processor inside GPUs to.

[bridgman]

The display/sound/energy/cooling management are not part of the hardware, but you did close them in VBIOS. Why we need this to run the open driver? And what we can do if that isn't provided some day? I hope that you didn't decide to hide another secure processor inside GPUs to.

Not sure you can call the VBIOS "closed" when we provide open source header files for the structures in the data tables and an open source interpreter for the command tables.

Don't understand your question about "what if it isn't provided some day ?" since the VBIOS ships with the GPU.

[starshipeleven]

I've enough of this bullshit. Microcode is not hardware. If you think it's hardware then let's hardcode everything and stop distributing it.
If you want the flexibility that the microcode gives you then please at least be honest about it with your users. I don't ask you anything else.

He said that microcode is not the driver, not that microcode is hardware.

The driver is code running on the CPU of the host system, while microcode and firmware (in this context) are code running inside the peripheral itself.

There is no functional difference between microcode/firmware loaded at runtime or inside a ROM in the device, but keeping it external allows the vendor to update this firmware easily, as flashing memory chips on the peripheral is dangerous.

And for the nth fucking time: If you want to get rid of firmwares/microcodes campaign for some goddamn open hardware, don't shout at closed hardware vendors, because a vendor of closed hardware can't and won't open up the firmwares in a million years, the only thing you can get is pissing them off so they don't even provide a half-decent opensource driver for their hardware.

And getting flamed by everyone with a modicum of interest in their open drivers, of course.

Regarding freesync, is there any nouveau developer interested to implement it? It would be funny if they do

It's beyond pointless. Nobody will buy an expensive freesync gaming screen and an expensive (more or less) NVIDIA card to get total shit 3D performance because the card is stuck on min clocks.

[starshipeleven]

These statements are misleading, too. The microcode is clearly software, not hardware, and it comes with all the practical and ethical problems of proprietary software.

Wrong, the fact that it is running inside the peripheral itself pretty much eliminates any practical problem, as the only thing required is some code to load this blob in the peripheral itself at runtime.
There is no kind of documentation of how the hardware works at this level and it is unrealistic to expect it for closed hardware, so even with opensource firmwares you won't be able to have the community fix them in case of bugs.

The ethical side is theoretically there, but in practice we are talking of very dumb and low-level stuff, It's not UEFI, it's not ME, it's not a CPU core running VxWorks while the other core runs your OS, so it's not a bigger threat than any other closed hardware you can choose (with or without firmwares).