On Mon, 22 May 2017 12:05:28 +0200 "mike.valk@gmail.com" mike.valk@gmail.com wrote:
2017-05-22 0:06 GMT+02:00 ronwirring@safe-mail.net:
Because I deleted a previously email about this subject, I start a new email. Info. Lkcl said, he is not in favor of reverse engineering a mali gpu. Because it is about 150000eu and new gpus will emerge during the reverse engineering and the outcome is uncertain.
I agree on his arguments.
I assume you do not agree.
150000eu is a crowd funding of 30000 people, each 5eu. I would pay an extra 5eu to be able to buy a source code computer.
The issue with revese engineering the MALI gpu's is not justs about money. ARM ltd. actively Seeks and destroys attempts on a OSS mail driver.
So that money needed is not only going to coding but is probably also needed for legel fees and marketing against the smear and laster campaign.
They have already made one person's life very difficult: http://libv.livejournal.com/
I'd do it in a heart beat in spite of the evil people out there if I had the skills.
Incidentally, couldn't you do this in an mostly automated fashion? I mean: 1. Have computer program send bits to GPU 2. Have same program read bits from EDP (or whatever), to determine result and time spend on task. 4. Have another program create a spread sheet for the in-out-time info and stats. 3. Have developer look at these and code.
I do not know if 30000 people are interested or if they can agree on one board.
But freeing MALI would help a lot of devices out there. So I'd trough in some bucks. RE'ing MALI would not be for just one board.
Agreed. It must be for all boards and support opengl, opencl, vulkan.
You cannot get the mali source code faster, if you put more people on it?
Finding the right minds and right amount of them working on the same thing is a hard equation.
You could add me to that team but my skills would be of limited use. Adding someone of the same skill set would probably be even less effective.
So more money or more people is not the solutions. The right people and the right amount is needed.
Well, I'd put ten dollars to a campaign like this without a HW reward. I'm assuming that beings that there are so many Mali GPUs and hacker boards out there that other people would also be very interested in this. What would I need to know to do this? Quick, point me to the books! No, really, I would do such a thing, I don't have a lot to loose, though for free I'd be taking my time... But still, I'd need an education.
Thanks, David
On 30/05/17 22:48, doark@mail.com wrote:
Well, I'd put ten dollars to a campaign like this without a HW reward. I'm assuming that beings that there are so many Mali GPUs and hacker boards out there that other people would also be very interested in this. What would I need to know to do this? Quick, point me to the books! No, really, I would do such a thing, I don't have a lot to loose, though for free I'd be taking my time... But still, I'd need an education.
Start from the existing code http://limadriver.org/
On Wed, 31 May 2017 00:16:42 +0200 sam via arm-netbook arm-netbook@lists.phcomp.co.uk wrote:
On 30/05/17 22:48, doark@mail.com wrote:
Well, I'd put ten dollars to a campaign like this without a HW reward. I'm assuming that beings that there are so many Mali GPUs and hacker boards out there that other people would also be very interested in this. What would I need to know to do this? Quick, point me to the books! No, really, I would do such a thing, I don't have a lot to loose, though for free I'd be taking my time... But still, I'd need an education.
Start from the existing code http://limadriver.org/
I understand that I understand very little about this process so please read this with hearty laugh prepared.
Whereas other older people have gone from simple reverse engineering projects to more difficult ones I have come into the game late when all the projects are the most difficult. Let me assume that the GPU is a RISC model and uses 8-bit instructions. Then it would have a total of 255 instructions (the 256th would be all zeros and be a no-op because the wires on the line need a way to tell if they have an instruction on them and that is the most power conservative I can think of). Now let use assume that if the signed bit is set that the GPU receives an instruction to set an internal option. All that I could probably learn from the lima driver and also some idea of how the 2D rendering engine works and what it's instructions are. Now the questions come up: 1. What are the options for the 3D engine? 2. What are the instructions for the 3D engine? 3. How do the 2D, 3D, and video (de|en)code engine fit together?
To sum it up, I don't think it's as simple as downloading the code, signing up for the mailing list, and coding. It might be, someone could have left full specs laying around waiting to be turned into mock-up code and then real code; but I doubt it. That's not to say I will not try, but I just don't see this as a very productive path.
I suffer from the black box discouragement effect. Someone builds a black box, then a bigger black box, then an even larger black box; eventually no one knows how it works inside, even the people who designed it understand only a relatively small part.
Sincerely, David
On 06/17/2017 09:39 AM, David Niklas wrote:
On Wed, 31 May 2017 00:16:42 +0200 sam via arm-netbook arm-netbook@lists.phcomp.co.uk wrote:
On 30/05/17 22:48, doark@mail.com wrote:
Well, I'd put ten dollars to a campaign like this without a HW reward. I'm assuming that beings that there are so many Mali GPUs and hacker boards out there that other people would also be very interested in this. What would I need to know to do this? Quick, point me to the books! No, really, I would do such a thing, I don't have a lot to loose, though for free I'd be taking my time... But still, I'd need an education.
Start from the existing code http://limadriver.org/
I understand that I understand very little about this process so please read this with hearty laugh prepared.
Whereas other older people have gone from simple reverse engineering projects to more difficult ones I have come into the game late when all the projects are the most difficult. Let me assume that the GPU is a RISC model and uses 8-bit instructions. Then it would have a total of 255 instructions (the 256th would be all zeros and be a no-op because the wires on the line need a way to tell if they have an instruction on them and that is the most power conservative I can think of). Now let use assume that if the signed bit is set that the GPU receives an instruction to set an internal option. All that I could probably learn from the lima driver and also some idea of how the 2D rendering engine works and what it's instructions are. Now the questions come up:
- What are the options for the 3D engine?
- What are the instructions for the 3D engine?
- How do the 2D, 3D, and video (de|en)code engine fit together?
To sum it up, I don't think it's as simple as downloading the code, signing up for the mailing list, and coding. It might be, someone could have left full specs laying around waiting to be turned into mock-up code and then real code; but I doubt it. That's not to say I will not try, but I just don't see this as a very productive path.
I suffer from the black box discouragement effect. Someone builds a black box, then a bigger black box, then an even larger black box; eventually no one knows how it works inside, even the people who designed it understand only a relatively small part.
IF you can figure out how to reverse engineer the 3d engine, ikcl would be very happy I am sure. But I get the feeling from him that it is nearly impossible to do this.
Not sure why... but yeah... RK3288 with 3d engine would be cool I will admit that. or an even later more compatible processor.
Still, I think you have an uphill battle for that.
ps, I don't have much reverse engineering experience at all, so what I am suggesting, could be easier or harder.
I just don't know. xD
Sincerely, David
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sat, Jun 17, 2017 at 7:53 PM, zap calmstorm@posteo.de wrote:
IF you can figure out how to reverse engineer the 3d engine, ikcl would be very happy I am sure.
that used to be the case but is no longer true. please read section 2.5 of the bill of ethics before proceeding further with this thread: https://www.titanians.org/the-bill-of-ethics/
ARM's illegal and unethical activity which destroyed luc verhaegen's career and reputation - including several counts of slander as well as blackmail of the company funding his reverse-engineering efforts - was the last straw.
if we proceed to reverse-engineer MALI, logically it results in people buying more ARM products.
if people buy more ARM products, logically it results in more money (resources) going to support ARM's illegal and unethical actions.
any action which is taken that results in support or endorsement of unethical actions is, logically, itself, unethical
therefore, logically and plainly put: unless ARM's attitude changes the reverse-engineering of MALI is itself an unethical act.
so it's a simple chain of logical reasoning based on ethical principles.
l.
if we proceed to reverse-engineer MALI, logically it results in people buying more ARM products.
if people buy more ARM products, logically it results in more money (resources) going to support ARM's illegal and unethical actions.
any action which is taken that results in support or endorsement of unethical actions is, logically, itself, unethical
therefore, logically and plainly put: unless ARM's attitude changes the reverse-engineering of MALI is itself an unethical act.
So someone buying an nvidia card and using nouveau with it is by your logic unethical ? Tell that to rms he recommends old nvidia cards :P Besides I fail to see what else apart form more sales could convince arm to open their drivers.
Aftermarket devices fail to support original dev's the same way used books fail to support original authors, so that is also a consideration.
On 6/18/17, Bill Kontos vkontogpls@gmail.com wrote:
if we proceed to reverse-engineer MALI, logically it results in people buying more ARM products.
if people buy more ARM products, logically it results in more money (resources) going to support ARM's illegal and unethical actions.
any action which is taken that results in support or endorsement of unethical actions is, logically, itself, unethical
therefore, logically and plainly put: unless ARM's attitude changes the reverse-engineering of MALI is itself an unethical act.
So someone buying an nvidia card and using nouveau with it is by your logic unethical ? Tell that to rms he recommends old nvidia cards :P Besides I fail to see what else apart form more sales could convince arm to open their drivers.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sun, Jun 18, 2017 at 9:16 AM, Bill Kontos vkontogpls@gmail.com wrote:
if we proceed to reverse-engineer MALI, logically it results in people buying more ARM products.
if people buy more ARM products, logically it results in more money (resources) going to support ARM's illegal and unethical actions.
any action which is taken that results in support or endorsement of unethical actions is, logically, itself, unethical
therefore, logically and plainly put: unless ARM's attitude changes the reverse-engineering of MALI is itself an unethical act.
So someone buying an nvidia card and using nouveau with it is by your logic unethical ?
how did you gain that impression from a logical chain of "ANDed" statements which began with some illegal and unethical behaviour by ARM?
i note from the above context that you cut off the absolutely critical part of the chain of ANDed statements. you specifically cut the one *right* at the beginning, which was the illegal and unethical behaviour that ARM committed against luc verhaegen.
did you not read that part, or were you under the impression that it was not part of the chain of logical reasoning?
has NVIDIA engaged in similar illegal or unethical practices to that which ARM carried out against luc verhaegen, which we know were and are sanctioned by the CTO of ARM?
l.
has NVIDIA engaged in similar illegal or unethical practices to that which ARM carried out against luc verhaegen, which we know were and are sanctioned by the CTO of ARM?
Sorry I chopped it off to keep the conclusion only. Nvidia switched to requiring signed binary firmware with a blown fuse for any maxwell or newer card to run effectively blocking the work by the libre driver and delaying the release of the signed binaries to 2 years after the cards are actually released to the market. So they are actively blocking reverse engineering.
On 06/18/2017 02:09 AM, Luke Kenneth Casson Leighton wrote:
On Sat, Jun 17, 2017 at 7:53 PM, zap calmstorm@posteo.de wrote:
IF you can figure out how to reverse engineer the 3d engine, ikcl would be very happy I am sure.
that used to be the case but is no longer true. please read section 2.5 of the bill of ethics before proceeding further with this thread: https://www.titanians.org/the-bill-of-ethics/
ARM's illegal and unethical activity which destroyed luc verhaegen's career and reputation - including several counts of slander as well as blackmail of the company funding his reverse-engineering efforts - was the last straw.
if we proceed to reverse-engineer MALI, logically it results in people buying more ARM products.
if people buy more ARM products, logically it results in more money (resources) going to support ARM's illegal and unethical actions.
any action which is taken that results in support or endorsement of unethical actions is, logically, itself, unethical
therefore, logically and plainly put: unless ARM's attitude changes the reverse-engineering of MALI is itself an unethical act.
so it's a simple chain of logical reasoning based on ethical principles.
l.
Hmm... just out of curiosity, what is your plan then? to make your own processors from lowrisc? its not a bad idea, but I think until that is an option... we should use still use some form of arm. Unless you know of other options.
Just curious but what other options are there? Also, I think that makes it more reasonable to reverse engineer their products just to piss Arm off. They don't like their products being reverse engineered anyways... so why not do that to annoy them for their unethical acts? Besides it could make them realize that their evil actions need to be changed.
Also, the developer who was blackmailed may be pleased by this course of action.
Its not my favorite idea, but its better than letting mali run unchecked. In my opinion.
You are of course free to disagree but that's my stance.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sun, Jun 18, 2017 at 5:56 PM, zap calmstorm@posteo.de wrote:
Hmm... just out of curiosity, what is your plan then? to make your own processors from lowrisc?
replying in part to bill here as well: yes. and to use MIAOW for OpenCL and ORSOC GPU for actual rendering. it won't be perfect but it will be a start.
bill: nvidia are in the difficult position of likely having been pressurised by governments to lock down what is effectively viewed in military terms as a a weapon (the rest of us just call it a "GPU"). if you recall many years ago, iraq i believe it was purchased thousands of sony PS1s to make a supercomputer.
as there is an ongoing arms race in that regard it is only the latest processors which are likely to fall under, for example, U.S. BXPA Weapons-Grade "Munitions" classification. given the fact that it is after a couple of years that the source code is no longer DRM-restricted, we have a correlation that fits with the ongoing evidence.
now, as long as a replacement (libre) processor is well below the "state of the art" but is otherwise perfectly acceptable for mass-volume electronics purposes, it will fall outside of this potential trap.
its not a bad idea, but I think until that is an option... we should use still use some form of arm.
indeed. it may sound strange but when there is no other option (and by that i mean *exhaustive* analysis finds no other option) i do not mind "crossing the line" into what would traditionally be viewed by software libre purists as "unacceptable territory" *IF* in doing so it is part of a long-term strategy to *REPLACE* the very thing being leveraged [to make money etc. etc.]
for example: many software libre supporters flatly refuse to even *install* Windows NT... but if i had taken that attitude i would not have broken the NT Domains protocol, over 20 years ago.
it is the same here:
Unless you know of other options.
nope, i don't. always looking though.
Just curious but what other options are there? Also, I think that makes it more reasonable to reverse engineer their products just to piss Arm off. They don't like their products being reverse engineered anyways... so why not do that to annoy them for their unethical acts? Besides it could make them realize that their evil actions need to be changed.
and remove the one thing which would otherwise teach them a lesson?
i see both perspectives: i just believe that they are sufficiently arrogant in their power and beliefs that it is unlikely that they will change their minds. they've been told by their engineers countless times. they've been told by users countless times. they've been told by businesses who would otherwise buy more of their products countless times.
Its not my favorite idea, but its better than letting mali run unchecked. In my opinion.
yehyeh, i hear ya.
You are of course free to disagree but that's my stance.
no it's good to hear. thx zap.
l.
On 06/18/2017 03:14 PM, Luke Kenneth Casson Leighton wrote:
On Sun, Jun 18, 2017 at 5:56 PM, zap calmstorm@posteo.de wrote:
Hmm... just out of curiosity, what is your plan then? to make your own processors from lowrisc?
replying in part to bill here as well: yes. and to use MIAOW for OpenCL and ORSOC GPU for actual rendering. it won't be perfect but it will be a start.
bill: nvidia are in the difficult position of likely having been pressurised by governments to lock down what is effectively viewed in military terms as a a weapon (the rest of us just call it a "GPU"). if you recall many years ago, iraq i believe it was purchased thousands of sony PS1s to make a supercomputer.
as there is an ongoing arms race in that regard it is only the latest processors which are likely to fall under, for example, U.S. BXPA Weapons-Grade "Munitions" classification. given the fact that it is after a couple of years that the source code is no longer DRM-restricted, we have a correlation that fits with the ongoing evidence.
now, as long as a replacement (libre) processor is well below the "state of the art" but is otherwise perfectly acceptable for mass-volume electronics purposes, it will fall outside of this potential trap.
Please use lowrisc if you do this option, they already are libre. Their stuff is licensed under gpl3. That should also mean its easier to, load/less risk of idiots trying to but proprietary crap into it and get away with it like google does. bleh... google is so awful.
its not a bad idea, but I think until that is an option... we should use still use some form of arm.
indeed. it may sound strange but when there is no other option (and by that i mean *exhaustive* analysis finds no other option) i do not mind "crossing the line" into what would traditionally be viewed by software libre purists as "unacceptable territory" *IF* in doing so it is part of a long-term strategy to *REPLACE* the very thing being leveraged [to make money etc. etc.]
for example: many software libre supporters flatly refuse to even *install* Windows NT... but if i had taken that attitude i would not have broken the NT Domains protocol, over 20 years ago.
it is the same here:
I am glad wine was created, too bad that I cannot plan windows 95 games through wine yet... completely I mean.
Unless you know of other options.
nope, i don't. always looking though.
That is good.
Just curious but what other options are there? Also, I think that makes it more reasonable to reverse engineer their products just to piss Arm off. They don't like their products being reverse engineered anyways... so why not do that to annoy them for their unethical acts? Besides it could make them realize that their evil actions need to be changed.
and remove the one thing which would otherwise teach them a lesson?
i see both perspectives: i just believe that they are sufficiently arrogant in their power and beliefs that it is unlikely that they will change their minds. they've been told by their engineers countless times. they've been told by users countless times. they've been told by businesses who would otherwise buy more of their products countless times.
Dunno, I thought it was a good idea.
Its not my favorite idea, but its better than letting mali run unchecked. In my opinion.
yehyeh, i hear ya.
You are of course free to disagree but that's my stance.
no it's good to hear. thx zap.
l.
Tell me what you think of lowrisc when you get a chance. I mean as a base for your processors. heh.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sun, Jun 18, 2017 at 11:02 PM, zap calmstorm@posteo.de wrote:
Tell me what you think of lowrisc when you get a chance. I mean as a base for your processors. heh.
i feel that the lowrisc team fit better with the ethics of what i would like to see be achieved (note deliberate use of third person, i.e. that i am not personally tying a personal egoistic agenda to or correlation with the desire to see success).
i noted in particular that the lowrisc team has set up as a CIC. that's a big plus.
technically i am particularly impressed with the concept of using a 32-bit RISCV for GPIO, which they call "minion cores". bitbanging isn't really bitbanging any more if there's an entire CPU dedicated to it. the advantage of their approach is that you no longer require complex multiplexing hardware on the GPIO (as is normally done, with dedicated hardware blocks for each I/O function). you simply... load a different program into the minioncore and the pins which e.g. were previously I2C are now UART. or some-other-future-as-yet-unspecified-or-unforseen-I/O-interface. upgrading to the latest version of SDMMC is therefore dead easy: just write a new program for the minion core.
l.
On 06/18/2017 06:45 PM, Luke Kenneth Casson Leighton wrote:
On Sun, Jun 18, 2017 at 11:02 PM, zap calmstorm@posteo.de wrote:
Tell me what you think of lowrisc when you get a chance. I mean as a base for your processors. heh.
i feel that the lowrisc team fit better with the ethics of what i would like to see be achieved (note deliberate use of third person, i.e. that i am not personally tying a personal egoistic agenda to or correlation with the desire to see success).
i noted in particular that the lowrisc team has set up as a CIC. that's a big plus.
technically i am particularly impressed with the concept of using a 32-bit RISCV for GPIO, which they call "minion cores". bitbanging isn't really bitbanging any more if there's an entire CPU dedicated to it. the advantage of their approach is that you no longer require complex multiplexing hardware on the GPIO (as is normally done, with dedicated hardware blocks for each I/O function). you simply... load a different program into the minioncore and the pins which e.g. were previously I2C are now UART. or some-other-future-as-yet-unspecified-or-unforseen-I/O-interface. upgrading to the latest version of SDMMC is therefore dead easy: just write a new program for the minion core.
According to the lowrisc website though, you can make a 64 bit processor if you so choose though.
I am sure you know this, but I just hope you understand that better possibilities exist. ;)
I Wonder when they are going to crowdfund though...
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Mon, Jun 19, 2017 at 2:06 AM, zap calmstorm@posteo.de wrote:
According to the lowrisc website though, you can make a 64 bit processor if you so choose though.
yes. the minioncores would be on the same bus, not requiring any kind of cache coherency with either each other or with the main 64-bit CPU(s), either doing DMA writes (on their own) or responding to bus memory reads/writes in order appear as memory-addressable peripherals.
I am sure you know this, but I just hope you understand that better possibilities exist. ;)
you may be misunderstanding that the purpose of 32-bit minion cores is *in addition* to there being one or more main processor(s) which are SMP or NUMA, which themselves have a bus width (32, 64, 128 bit) that has absolutely nothing whatsoever to do with the minion-cores being 32-bit.
I Wonder when they are going to crowdfund though...
i get the general impression that they're quite happy to focus on development as opposed to raising funds to create an actual processor. each task requires different skills, time and effort. if the team focussed on crowdfunding that would be a serious distraction from their development efforts.
this therefore is an opportunity to create a crowd-funded processor which utilises their expertise. the one main thing which i could really do with is a DDR or other high-speed memory interface that is proven... and compatible with the GPL.
l.
On 06/18/2017 09:39 PM, Luke Kenneth Casson Leighton wrote:
On Mon, Jun 19, 2017 at 2:06 AM, zap calmstorm@posteo.de wrote:
According to the lowrisc website though, you can make a 64 bit processor if you so choose though.
yes. the minioncores would be on the same bus, not requiring any kind of cache coherency with either each other or with the main 64-bit CPU(s), either doing DMA writes (on their own) or responding to bus memory reads/writes in order appear as memory-addressable peripherals.
I am sure you know this, but I just hope you understand that better possibilities exist. ;)
you may be misunderstanding that the purpose of 32-bit minion cores is *in addition* to there being one or more main processor(s) which are SMP or NUMA, which themselves have a bus width (32, 64, 128 bit) that has absolutely nothing whatsoever to do with the minion-cores being 32-bit.
I Wonder when they are going to crowdfund though...
i get the general impression that they're quite happy to focus on development as opposed to raising funds to create an actual processor. each task requires different skills, time and effort. if the team focussed on crowdfunding that would be a serious distraction from their development efforts.
this therefore is an opportunity to create a crowd-funded processor which utilises their expertise. the one main thing which i could really do with is a DDR or other high-speed memory interface that is proven... and compatible with the GPL.
I guess I misunderstood then on both counts. well this is odd. xD
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Luke Kenneth Casson Leighton wrote:
indeed. it may sound strange but when there is no other option (and by that i mean *exhaustive* analysis finds no other option) i do not mind "crossing the line" into what would traditionally be viewed by software libre purists as "unacceptable territory" *IF* in doing so it is part of a long-term strategy to *REPLACE* the very thing being leveraged [to make money etc. etc.]
Richard Stallman (whose objection to non-free software should require no explanation) concurs, he has long said that installing and running non-free software is okay for the purpose of making a free replacement (see https://www.gnu.org/philosophy/is-ever-good-use-nonfree-program.html for his essay on this which includes a description of the limits of this methodology and rationale). Relatedly, he also has told University audiences that they should have reverse engineering courses (see https://audio-video.gnu.org/ for recordings of his many speeches). I agree with him on both points for the same reasons.
After all, once the reverse engineering is complete the free replacement should suffice to do the practical jobs and then the non-free, user-subjugating components should be removed in favor of using the free replacement.
for example: many software libre supporters flatly refuse to even *install* Windows NT... but if i had taken that attitude i would not have broken the NT Domains protocol, over 20 years ago.
I imagine this was and is also true for the Samba team.
On Sun Jun 18 07:09:40 BST 2017, Luke Kenneth Casson Leighton lkcl at lkcl.net wrote:
On Sat, Jun 17, 2017 at 7:53 PM, zap <calmstorm at posteo.de> wrote:
IF you can figure out how to reverse engineer the 3d engine, ikcl would be very happy I am sure.
that used to be the case but is no longer true. please read section 2.5 of the bill of ethics before proceeding further with this thread: https://www.titanians.org/the-bill-of-ethics/
ARM's illegal and unethical activity which destroyed luc verhaegen's career and reputation - including several counts of slander as well as blackmail of the company funding his reverse-engineering efforts - was the last straw.
Well I am kinda stuck with two Mali-GPUs, both I bought under the impression that the code is open-source if in FLOSS and I would imagine that there are others in this situation.
if we proceed to reverse-engineer MALI, logically it results in people buying more ARM products.
Actually, I read on wikipedia what Linux's support for Mali is and what the firefly and CHIP webpages described their product as (e.g. proprietary vs. opensource), and thus I seem to have been fooled, twice. Surly others will come to the same conclusions unless they dig into this ML, or the Linux kernel archives, or stumble on Luc's page?
if people buy more ARM products, logically it results in more money (resources) going to support ARM's illegal and unethical actions.
Which will happen anyways due to ignorance. I try to stay up on what companies are nice and which are not plus the general goings on in the opensource community (I know about Nvidia and AMD/Radeon), and this entire problem with Mali blindsided me. This is not a problem that is as well publicized as say, Linux giving Nvidia the F word.
any action which is taken that results in support or endorsement of unethical actions is, logically, itself, unethical
therefore, logically and plainly put: unless ARM's attitude changes the reverse-engineering of MALI is itself an unethical act.
so it's a simple chain of logical reasoning based on ethical principles.
l.
Unless you're trying to be merciful to those who are less fortunate. Look at those who buy prisoners from ISIS or any other violent group. Or, how about ransomware? Do we just tell people "Next time don't use windowz"? It's a tough choice, I agree Luke, but if I succeed you can be certain that I, like Luc, will pay dearly for my good intentions. Then at least Luc will gain a friend as I dwell in a state of solidarity with him, and his actions will not go to waste.
The reason I would really be interested in the Mali GPU driver is not because of the need for a basic driver, nor for the sake of games (though they do have an appeal), but because of the Opencl support which I'd really like to play with (My desktop card is an AMD and their Opencl support is non-functional at this time in my system for whatever reason in spite of my using the latest kernel and Mesa library).
Now can we get back to how to do the reverse engineering itself?
Sincerely, David
On Fri, Jun 23, 2017 at 4:27 PM, David Niklas doark@mail.com wrote:
Now can we get back to how to do the reverse engineering itself?
Someone should suggest Luc to open a monthly patreon-styled donation page for working on lima.
On 06/23/2017 11:29 AM, Bill Kontos wrote:
On Fri, Jun 23, 2017 at 4:27 PM, David Niklas doark@mail.com wrote:
Now can we get back to how to do the reverse engineering itself?
Someone should suggest Luc to open a monthly patreon-styled donation page for working on lima.
I second this notion. reverse engineering lima could open a lot of options to us if successful.
arm-netbook@lists.phcomp.co.uk
-
Bill Kontos -
David Niklas -
doarkļ¼ mail.com
-
J.B. Nicholson -
Jean Flamelle -
Luke Kenneth Casson Leighton -
sam -
zap