HW Acceleration Working

[CaptainZalo]

I assume your tl;dr answer is "It's too hard, so don't bother." Didn't know it's such a hassle for a non-developer.

hi Captain,  the reason I do not personally recommend mali is that it is "too hard" for most people to handle. 

... but the more important reason is longsleep's point, namely, it really doesn't buy you anything except an experimental kernel , a bloated image , probably performance degradation , and a very limited in-memory accelerator for openGL GLES;  granted, 'some' things will work with it, and if you are 'needing' that 'something' (deliberately left un-mentioned) then by all means go for installing mali... but, you are going to be frustrated if you are not a skilled developer.

(hope this helps)

It wasn't a disgruntled reply. I just laid out the facts so others don't have to waste time on it.
Basically, the replies sum up to this:

Wait for the finished package (or suffer the agony of the consequences).

[pfeerick]

... it really doesn't buy you anything except an experimental kernel , a bloated image , probably performance degradation , and a very limited in-memory accelerator for openGL GLES;  granted, 'some' things will work with it, and if you are 'needing' that 'something' (deliberately left un-mentioned) then by all means go for installing mali... but, you are going to be frustrated if you are not a skilled developer.

That indeed does help Mark... that is the information hasn't really been mentioned, and wouldn't be known generally... but if that is all the Mali binary blob brings with it... what is all the fuss about it being the next best thing since the wheel?

Or is this because in it's current state, not everything is accessible yet? And because it's a binary... any bugs or issues are resolvable as the source code is not available? I thought the whole point of the mali binary (and HW acceleration, as per the thead title!) was that it basically unlocked more of the power of the onboard GPU, making things like video playback, etc, less CPU bound, and let the more capable and power efficient GPU do the work.

[MarkHaysHarris777]

... it really doesn't buy you anything except an experimental kernel , a bloated image , probably performance degradation , and a very limited in-memory accelerator for openGL GLES;  granted, 'some' things will work with it, and if you are 'needing' that 'something' (deliberately left un-mentioned) then by all means go for installing mali... but, you are going to be frustrated if you are not a skilled developer.

That indeed does help Mark... that is the information hasn't really been mentioned, and wouldn't be known generally... but if that is all the Mali binary blob brings with it... what is all the fuss about it being the next best thing since the wheel?

Or is this because in it's current state, not everything is accessible yet? And because it's a binary... any bugs or issues are resolvable as the source code is not available? I thought the whole point of the mali binary (and HW acceleration, as per the thead title!) was that it basically unlocked more of the power of the onboard GPU, making things like video playback, etc, less CPU bound, and let the more capable and power efficient GPU do the work.

preerick, thanks, you are asking the $10,000 dollar question-- and its a good question too !

... see what people are really wanting is hw acceleration, and mali isn't it.  The reason this is not coming forward the way people were expecting has literally legal, technical, and philosophical|political answers.

Longsleep is NOT (and he told me this with his own person) going to package this because it is not open source; period. (I agree with him, by the way, for political and philosophical reasoning). 

Without a proper EULA it (the whole packge) cannot be packed legally and distributed without violating the GPL. Longsleep has noted this many times, and some of us have confirmed that it's true.

And then technically, the experimental kernel with integrated drm (direct rendering manager) (which is never going to be integrated in the main kernel, says longsleep) in combination with the mali blob (even if legalized) is NOT hw acceleration !  Which is why technically longsleep has told everyone from the beginning (its even on his site) if you want video use Android !

So, pfeerick, we are literally between a very hard rock , and a very tight space. 

... which is why many people are feeling bamboozled.

[pfeerick]

... see what people are really wanting is hw acceleration, and mali isn't it.  The reason this is not coming forward the way people were expecting has literally legal, technical, and philosophical|political answers.

... which is why many people are feeling bamboozled.

Well, it's only taken a month to finally get there... since this thread started talking about mali being the solution to the hardware problem back on the 8th.

If there's no access to the source code, the issue is merely a legal one ... one of the better protections of the GPL is preventing proprietary binaries being used in GPL-licensed works... as that would circumvent the whole philosophy of the GPL!

But since the issue is that mali is not the hardware acceleration that we're after... for the sake of clarity, what is? And what is the likelihood of us getting that? Or is it likely that case that Android will be the GPU HW accelerated platform, and linux will be the more lightweight GUI and server platform? This will only remain an issue of contention and confusion until information about this is prominently noted for all to see.

[MarkHaysHarris777]

But since the issue is that mali is not the hardware acceleration that we're after... for the sake of clarity, what is? And what is the likelihood of us getting that? Or is it likely that case that Android will be the GPU HW accelerated platform, and linux will be the more lightweight GUI and server platform? This will only remain an issue of contention and confusion until information about this is prominently noted for all to see.

The answer is simple, and nobody is going to like it... so please don't shoot the messager.

... I had a very long talk with longsleep about this on irc some days ago... after I finally pieced together what is really going on here.  I do not want in any way to put words in longsleep's mouth, so please don't hold my feet to the fire for memory nor paraphrasing, and he told me that what it would take to fix this is about $100,000, dedicated and serious developers and about a year and a half.  The monetary amount was just a large amount indicating the magnitude of the problem... 

... but the timing I suspect, based on his professional expertise, is probably correct. Volunteers are not going to be able to do this work on their own any time soon.  That is just the truth.  Also, even if they could devote the time to it, we are talking about reverse engineering a closed system !

So again, I say we are between a very hard rock and a very tight space.  

And once again, longsleep's montra "if you want a computer use linux, if you want video use Android"

[pfeerick]

The answer is simple, and nobody is going to like it... so please don't shoot the messenger.

And not have fun making you do the Macarena? Spoilsport!

And once again, longsleep's montra "if you want a computer use linux, if you want video use Android"

Yeah, well, each to his own... I'm pretty sure we both disagree with him on that one... but I do understand where he's coming from. Even if he were interested in getting GPU HW going... it's not like he's going to get paid for the 10 or so years it'd take him to get it done... unless we can bribe him with beer donations?

So the real issue is that the information needed to get GPU HW acceleration functioning on linux is that it's a closed system - the required information hasn't been made available. Hence, we're up the creek without a paddle, as unless the state of affairs changes... or someone wins a few million in the lottery and donates it to the cause (*hint* *hint*) ... so we should settle down and enjoy Android for our HW acceleration fix/adrenaline rush?

Does that about sum it up?

[MarkHaysHarris777]

Yeah, well, each to his own... I'm pretty sure we both disagree with him on that one... but I do understand where he's coming from. Even if he were interested in getting GPU HW going... it's not like he's going to get paid for the 10 or so years it'd take him to get it done... unless we can bribe him with beer donations?    

Its one thing more, and longsleep will tell you this with his own mouth; in fact I can almost quote him... the only reason he even develops these kernels (for all of us too) is that he wants them for his own interests in headless linux servers and virtualization.  Please don't miss the next part...  and he'll admit this too readily to anyone who will listen... the only reason we even have hdmi support in the kernel at all , is that it was easy for him to do it !!!  If it had not been trivial for his skill set, hdmi would not have happened either... that is just the truth (and we should be very thankful that gnu+linux on the PineA64 even has an hdmi capability).   

There is one more thing to add... and its fairly important... for this entire discussion.  Our kernels thus far have not had a cursor on the fbcon from the beginning (I don't know how many of you have noticed that) but real gnu+linux affectionados notice it immediately !    The fbcon is the ctrl-alt-F1 (thru F6) black screen consoles on a gnu+linux system.  Well, one of the things that the experimental drm integrated kernel does (by accident if you want to know the truth) is restore the fbcon cursor !!  

Have any of you ever tried to edit a file with vim , um , without a cursor !  ... talk about a mental nightmare.

If you want to see this for yourself, download the Gentoo image that Xalius built; it has the integrated direct rendering manager , and it has an fbcon cursor !!

[pfeerick]

If you want to see this for yourself, download the Gentoo image that Xalius built; it has the integrated direct rendering manager , and it has an fbcon cursor !!

Well, my OT contribution to this will be... thank goodness I manage my pine64 via SSH... missing cursors aren't an issue!! Serial terminal for the initial config, and wifi for the rest... who needs a monitor and keyboard! xD

And as I was hinting... I can see where longsleep's interests lie... in headless servers... so I'm just thankful to his efforts (and all the people who helped him) to get the kernel into the usable state it is... otherwise we wouldn't be having this discussion about linux on the pine64!

[jrullan]

Guys,

Two thoughts come to mind:

1) Isn't the whole idea of creating and developing a board like the Pine, RPI, and others like it to facilitate experimentation? If that's the case, why would "we" want to dissuade community members from experimenting with the MALI driver whether or not that is difficult for a non-developer?

2) It is the community at large, whether very experienced "smart cookies" or motivated newbies wanting to learn, that finally make a product great. I can understand the cautionary position some of you will assume regarding the reality vs expectations set forth by the Pine64 team when the product was launched, but hey, this is where we are today. What we as a community foster is what will ultimately make this platform a real success or a passing fad.

I think we should allow/promote/foster and ensure that wanting members of this community take a shot at it if they want to by providing guidance and encouraging them to do so. Unfortunately, the above replies to Terra854's suggestion to put together a "How To" as a community pointed in the opposite direction, discouraging "non-developers" members from trying it on their own. It doesn't seem right.

So, why don't we agree that MALI might not be the all mighty solution to every video acceleration problem, but still make an effort to encourage anyone that might want to experiment with it by putting together a How to, that at least lets "non-developers" achieve what lenny raposo did on their own?

[MarkHaysHarris777]

 I can understand the cautionary position some of you will assume regarding the reality vs expectations set forth by the Pine64 team when the product was launched, but hey, this is where we are today. 

You are correct, of course, on all points in your full post;  I wish to address the piece of your post that I have brought forward in the quote|paste above;

... most of the people (yes I mean the overwhelming majority) did not understand that they were investing in a startup company... they thought they were purchasing a fully developed $15 media center appliance; and, none of them (there might be a 1 or 2 out of 38,000) are kernel developers.

If we were talking about blinking an LED using the GPIO pins, I'd totally and whole heartedly support and back your entire post;  but we're not. We are talking about kernel development; an afternoon walk in the part for folks like Xalius, lennyraposo, or longsleep; however, most folks simply do not have the skills nor are they likely to develope the skills in the near future. In the mean time, they ARE going to be very frustrated individually, perhaps angry, maybe even-- hostile.

We have been helping individuals (even terra854) on the irc chat site with these issues. It has become obvious that rolling one's own kernel is not a trivial task for most pepple, and is not (generally speaking) a good place to 'start learning'.  Most of the people in this community are windows users, have little or no experience with linux, and are having extreme trouble making SD cards that work, and getting their images to boot properly.  That is where we are.

Getting back to the quote|paste above (snippet from your full post) it really all comes down to wisdom; knowing how to set expectations for the audience at hand. The very last thing I want to do is to encourage someone without the skill set to undertake rolling their own kernel , which not only sets a false expectation but is in some sense either unethical or immoral, only to have them become frustrated and angry again because this 'fully developed product' didn't meet their expectations. It really does come down to reality vs expectation; totally.