As I see in the git branch, thare is shitload of code ~85k locs, devoted to AMDIL. I believe this is the real AMD IL used in the proprietary driver, since I can't believe even Tom can't write so much code for 2 months. This is just fantastic, and really shows how much AMD are devoted to FOSS. This makes me proud owner of AMD's platform. Thanks Tom.
Announcement
Collapse
No announcement yet.
In Road To OpenCL, R600g LLVM Back-End Arrives
Collapse
X
-
you will not (1) export, re-export or release to a national of a country in
Country Groups D:1, E:1 or E:2 any restricted technology, software, or source
code you receive hereunder.
Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.
Comment
-
Originally posted by AnonymousCoward View Post-1000 for the license. This code is not open source.
The license text on the AMDIL bits appears to reference the current US export laws and qualifies the restriction based on the type of content (ie basically saying "if the US export control laws restrict it then you can't export...", not sure whether that qualifies or not since the restriction only applies to "restricted" content and the definition of restricted presumably comes from the current BIS regs.
any restricted technology, software, or source code you receive hereunderLast edited by bridgman; 10 December 2011, 11:01 PM.Test signature
Comment
-
I'm not sure I understand the need for all these abstractions... I thought the whole point of gallium was to make a single abstraction so that others wouldnt be required? Shouldnt it just be clover >> tgsi >> gpu, if run on the gpu, or clover >> llvm >> cpu, if run on the cpu?
Also would performing all these redundant translations effectively hurt end performance.... doesnt translating from this to that to these to those hurt performance? also assuming that one IR is less capable than another, (thinking of opengl) wouldnt you lose capability during one or more of these translations?Last edited by duby229; 11 December 2011, 01:40 AM.
Comment
-
Originally posted by Qaridariumhow is this possible in the past the official point was its not possible to use fglrx/catalyst source code in the galium3D driver.
Comment
-
Originally posted by AnonymousCoward View PostI don't get all this hype about OpenCL. I'm sure that there are some specialized niche applications making use of OpenCL but as a consumer I'd rather see AMD devoting some manpower to finally get video decoding working on the open drivers.
then you have as much chance (aka almost nil) of them doing that video decoding work now, as the so called HD 7000 Series ,the latest and greatest GCN (Graphics Card Next, got to love those PR innovators and their names to sell it to the masses) architecture has of actually dumping that closed Obsolete and dead UVD block and actually replacing it with a real open Linux usable hardware assisted video decode and actual Video ENCODE with SW patches within another 3 years, unlike the Intel and ARM/NEON cores that have that hardware encode/decode block capability right now, and perhaps far more importantly, are actively sending GIT patches to the FFMPEG/AVCONV developers etc. to make use of these HA blocks today.Last edited by popper; 11 December 2011, 08:35 AM.
Comment
-
Originally posted by duby229 View PostI'm not sure I understand the need for all these abstractions... I thought the whole point of gallium was to make a single abstraction so that others wouldnt be required? Shouldnt it just be clover >> tgsi >> gpu, if run on the gpu, or clover >> llvm >> cpu, if run on the cpu??
Originally posted by duby229 View PostAlso would performing all these redundant translations effectively hurt end performance.... doesnt translating from this to that to these to those hurt performance? also assuming that one IR is less capable than another, (thinking of opengl) wouldnt you lose capability during one or more of these translations?Test signature
Comment
-
Originally posted by Qaridariumhow it works to make the code structure of AMDIL compatible with Gallium3D? a simple rewrite? or a automate translating tool? or a chance in Gallium3D ?
Originally posted by Qaridariumhow is this possible in the past the official point was its not possible to use fglrx/catalyst source code in the galium3D driver. or is this only true for graphic stuff?
Normally the flow would be :
- OpenCL team pushes code back to the LLVM project
- open source graphics developers pick up changes from the LLVM project, either indirectly (as Mesa picks up new LLVM versions) or directly
In this case the code was pushed to LLVM and Mesa simultaneously, and consistent with our "30 seconds after approval" habit the code got into a Mesa branch before it hit the LLVM mailing listTest signature
Comment
-
popper, I've responded to these statements a few times in the past, guess once more won't hurt.
Originally posted by popper View Postgiven the year+ of stated legal review to be put in place to finally open up the UVD decode block for linux use that never seems to actually happen,
- the time-consuming part is not the review, it's what happens when the outcome from the review is "no" and you have to find new approaches & repeat
Originally posted by popper View Postand the fact that they cant even be bothered to compile and release the OpenCL OpenVideo driver for Linux video decode library that apparently relies on that closed UVD code block, and has existed for the windows SDK for a full year....Test signature
Comment
Comment