NVIDIA, Mentor Graphics May Harm GCC

[GreatEmerald]

With current gcc targets (real ISA) you can have a fully open source stack/os. This virtual ISA (PTX) target constrains you to platforms supported by nvidia drivers (and maybe even certain driver versions depending on nvidias discretion). Which makes it kinda less useful for GNU I guess.

I agree that it's not all that useful and that it might be a maintenance burden the GCC maintainers do not want to take. But I don't see what this has to do with software freedom.

Yea that's fine but this is creating functionality in gcc that can only be used with a proprietary part. There is a difference between choosing to used proprietary libraries in your app and compiling with gcc and building functionality into gcc which requires it and I personally think it's a bad trend which I wouldnth want to see.

Again, no, it's not a requirement. It's separate from GCC. It's not like now installing GCC would pull in proprietary software, it's rather like the proprietary software supporting the output of GCC. GCC makes the output, and proprietary software just so happens to be able to use it as an input. But that's of no concern of GCC.

[log0]

I agree that it's not all that useful and that it might be a maintenance burden the GCC maintainers do not want to take. But I don't see what this has to do with software freedom.[/QUOT]

Again, no, it's not a requirement. It's separate from GCC. It's not like now installing GCC would pull in proprietary software, it's rather like the proprietary software supporting the output of GCC. GCC makes the output, and proprietary software just so happens to be able to use it as an input. But that's of no concern of GCC.

More like GCC making output for proprietary software (I don't see what PTX would be else useful for). To make it more extreme, you could see it as a way of adding proprietary plugins to GCC (with PTX being the interface here), which it kinda goes against what gnu stands for.

[bridgman]

As I said, if even AMD would support the development of opensource the way it is painted to the outside world by their PR loudspeakers, the today's picture would be different.

??? I hear comments like this from time to time, but I don't think anyone has actually been able to provide an example of these alleged "PR loudspeakers". Can you give me an example please ?

Thanks,
JB

[Guest]

Well, AMD might offer some documentation of their ISA, but compared to the speed the development for real open source UNIX like systems, mainly the *BSD lines, is going on, there is a lot to reconsider and there is also a lot to be unraveled as PR from AMD. OPEN in strictu sensu means the support for all platforms. And this is not exclusively the pool of Linux derivates around.

Pardon me, but you're terribly mistaken. Being open has nothing common with supporting every system around. Those "real open source UNIX like systems" are irrelevant today. Following your logic most of the Open Source software is not open, because it focuses mainly on Linux. Your assumption is clearly incorrect.

[Sonadow]

Pardon me, but you're terribly mistaken. Being open has nothing common with supporting every system around. Those "real open source UNIX like systems" are irrelevant today. Following your logic most of the Open Source software is not open, because it focuses mainly on Linux. Your assumption is clearly incorrect.

QFT. Open != cross-platform

There are tons of opensource projects that target Windows or OS X exclusively.

[GreatEmerald]

More like GCC making output for proprietary software (I don't see what PTX would be else useful for). To make it more extreme, you could see it as a way of adding proprietary plugins to GCC (with PTX being the interface here), which it kinda goes against what gnu stands for.

As I mentioned, people might be able to find some other use for it in the future, even if not very likely. And I don't see how that is similar to adding proprietary plugins at all.

[johnc]

Nobody has yet to explain what, exactly, the issue is here and how it is principally different then what is quite ordinary today.

When you compile code into x86 assembly, is there not some closed-source microcode on the Intel or AMD chip that converts that into binary code? What is the difference here?

[rvdboom]

And? Is that a reason not to support it? Most of your hardware in your computer has most likely a proprietary firmware and you still use it. If Nvidia cards could directly understand PTX would the new backend suddenly be OK then?

It can be a reason for GCC not support it as it's a FSF project and FSF do not have such relaxed stance. Actually, I don't know personnaly if it's a valid reason or not, but I consider valid to ponder about it. Is it fitting the goals of openness of GCC to be able to generate code that can only be used using proprietary, closed source libraries? It is not a simple question.

Most developers? All I see is that most big OpenSource projects have a very relaxed stance. Just look at the Linux kernel itself or projects like Blender, XBMC and so on. Of course this all happens within the confinements of the GPL but that's ok. Even important as it keeps those projects free.

Well the kernel itself warns you that it's "tainted" when you use NVidia's proprietary driver. And it's definititely

All I can see is that many people on Phoronix have a blind hate for anything that is closed source. Whereas most of the actual open source developers have a relaxed view.

I disagree with you. Free software and open source as expressed by every developpers I've read tolerate closed source when there's absolutely no other choice, but request open source as much as possible. And the FSF definitely does not want any.
The only people I see that have such tolerance are some users who are using Linux for their stuff but are not really concerned by openness.

Simply because Linux is the best tool for my line of work. It's that easy, no hidden agendas and no fanboism, neither for free nor for closed software. I simply want a tool that works best and this new gcc backend is another step to an even better tool.

There you go.

[rvdboom]

And a proprietary application compiled with GCC can have a dependency on external proprietary libraries (probably even the same CUDA libraries), without which the program won't run. Again it's of no concern to GCC.

That makes sense, I guess.

[tarceri]

Again, no, it's not a requirement. It's separate from GCC. It's not like now installing GCC would pull in proprietary software, it's rather like the proprietary software supporting the output of GCC. GCC makes the output, and proprietary software just so happens to be able to use it as an input. But that's of no concern of GCC.

GCC would be encouraging the use of proprietary software this is should be a concern to the GNU project.

Nobody has yet to explain what, exactly, the issue is here and how it is principally different then what is quite ordinary today.

When you compile code into x86 assembly, is there not some closed-source microcode on the Intel or AMD chip that converts that into binary code? What is the difference here?

CPU's don't have drivers that compile assembly code gcc creates the machine code

Basic gcc compilation process:

- preprocessing (to expand macros)
- compilation (from source code to assembly language)
- assembly (from assembly language to machine code)
- linking (to create the final executable)