FIQ code keeps the entirety of the driver on the ARM side and thus open source. Moving to a GPU implementation means that a part of the driver becomes, of necessity, closed source, and thus the foundation gets flamed for not being open source enough. Again.obcd wrote:Is there a post here that might give a different impression? ;)
I just didn't found the performance boost a satisfying answer explaining why the usb driver would be implemented as FIQ first and as VPU code afterwards?
. Take it as an expression of high interest.
Maybe if you spent some of your profits on hiring more programmers and engineers...jamesh wrote:The Foundation can NEVER win. Whatever we do!
I say do what will work best. The Open Source or DEATH people, will complain either way.tufty wrote:FIQ code keeps the entirety of the driver on the ARM side and thus open source. Moving to a GPU implementation means that a part of the driver becomes, of necessity, closed source, and thus the foundation gets flamed for not being open source enough. Again.obcd wrote:Is there a post here that might give a different impression?
I just didn't found the performance boost a satisfying answer explaining why the usb driver would be implemented as FIQ first and as VPU code afterwards?
Simon
Dom, can we infer from your statement that a FIQ based solution is not distant, ie close?dom wrote:That's a distant goal. The code Gordon is working on now is FIQ based.... wrote:I thought the approach was to make a EHCI translation layer which would run on the GPU?
And maybe if you were not so unrelentingly negative people would listen to what you have to say?... wrote:Maybe if you spent some of your profits on hiring more programmers and engineers...jamesh wrote:The Foundation can NEVER win. Whatever we do!
Why does this driver have to be closed source?tufty wrote:FIQ code keeps the entirety of the driver on the ARM side and thus open source. Moving to a GPU implementation means that a part of the driver becomes, of necessity, closed source,
Anything that runs on the GPU is closed source. FIQ code will run on the Arm and therefore will be open source.p4trykx wrote:Why does this driver have to be closed source?tufty wrote:FIQ code keeps the entirety of the driver on the ARM side and thus open source. Moving to a GPU implementation means that a part of the driver becomes, of necessity, closed source,
We do have a C/C++ compiler as well!mahjongg wrote:The GPU is a proprietary piece of digital logic, which can execute a proprietary assembly language assembled with a proprietary assembler.
Its not simply "closed" software running on a known architecture.
So no actual code can be released, as it would divulge details about the GPU that Broadcom doesn't want to be divulged, because it would show the competition how their GPU hardware works.
You already have ALL the source code for the driver right now - feel free to dive in - there are lots of people complaining, but very few actually trying to help! At the moment, no GPU code has been written - and it may never be written depending on how the FIQ approach goes. I believe it was proposed because the GPU can service interrupts much faster than the Arm, so it was an option should the Arm not be fast enough.obcd wrote:So, by reveiling a piece of code (that has nothing to do with graphics) that runs on one of the 47 cores which forms the soc gpu, competitors would be able to figure out how the gpu was designed?
I can understand that Broadcom needs to give it's permission before the code can be made public.
It still doesn't explain why we need both the FIQ and VPU approach.
If the driver can't be made public, so be it.
If it works as expected, I have no need to start digging into it's source.
Ah, yes... Obviously I was only talking about writing assembler code, which I would think would be the norm for writing code for the GPU. Obviously if you can also use C (C++) then there is no reason not to divulge the code, but as was already said, I would strongly suspect it would be remarkably like the ARM fast interrupt (FIQ) code in that case, as its simply doing the very same job..jamesh wrote: We do have a C/C++ compiler as well!
In fact the vast majority of code is C - speed of development and maintenance reasons as much as anything. We need to use assembler for vector code or very time critical stuff.mahjongg wrote:Ah, yes... Obviously I was only talking about writing assembler code, which I would think would be the norm for writing code for the GPU. Obviously if you can also use C (C++) then there is no reason not to divulge the code, but as was already said, I would strongly suspect it would be remarkably like the ARM fast interrupt (FIQ) code in that case, as its simply doing the very same job..jamesh wrote: We do have a C/C++ compiler as well!
Jamesh, I see here https://github.com/raspberrypi/firmware/issues/19 that the USB problem has been identified and worked on for 6 months already, has the foundation or Broadcom given itself a deadline to fix it?jamesh wrote:One way to test - instead of copying to the stick, copy to /dev/nul. So if it still goes wrong it indicates a ethernet problem. But more information is needed - wired or wireless? DIstro?
Although these discussions don't fix the problem, the problem is being worked on. There is no 'final solution' as yet.
From reading the rest of this thread, it appears that Broadcom have no interest in fixing their problems and the foundation doesn't have the manpower to give you a deadline. As always, if anyone is willing to help they will gladly accept it...mic34 wrote:Jamesh, I see here https://github.com/raspberrypi/firmware/issues/19 that the USB problem has been identified and worked on for 6 months already, has the foundation or Broadcom given itself a deadline to fix it?
It has been said that Gordon is a Broadcom employee, so surely they must have given him a deadline for this task?Kemp wrote: From reading the rest of this thread, it appears that Broadcom have no interest in fixing their problems and the foundation doesn't have the manpower to give you a deadline. As always, if anyone is willing to help they will gladly accept it...
