On Wed, 25 Mar 2015 05:26:08 -0700 (PDT) "@lex" <[email protected]> wrote:
> On Monday, March 23, 2015 at 3:09:00 PM UTC-3, Siarhei Siamashka wrote: > > > > On Mon, 23 Mar 2015 08:13:46 -0700 (PDT) > > "@lex" <[email protected] <javascript:>> wrote: > > > > > On Monday, March 23, 2015 at 10:51:17 AM UTC-3, Siarhei Siamashka wrote: > > > > > > > > On Thu, 19 Mar 2015 05:04:33 -0700 (PDT) > > > > "@lex" <[email protected] <javascript:>> wrote: > > > > > > > > > On Thursday, March 19, 2015 at 8:42:32 AM UTC-3, Henrik Nordström > > wrote: > > > > > > > > > > > ons 2015-03-18 klockan 06:17 -0700 skrev @lex: > > > > > > > I have looked into ODROID r4p0 blobs and headers and did not > > find > > > > any > > > > > > > EULA, perhaps it is kept with the sources? > > > > > > > > > > > > http://forum.odroid.com/viewtopic.php?f=52&t=4956 > > > > > > > > > > Thank you all, > > > > > > > > > > So, the last hope is what Siarhei Siamashka is suggesting? Any > > chance > > > > this > > > > > will happen? > > > > > > > > The "last hope" for what? What kind of *real* problem are you trying > > to > > > > solve? Why would you expect us going "extra mile" in supporting every > > > > minor proprietary mali blob update? > > > > > > > > I have already mentioned in this thread that the r3p0 mali driver, > > > > which is integrated into the sunxi-3.4 kernel sources, works mostly > > > > fine (partially thanks to a bunch of workarounds). It is good enough > > > > for running and/or developing OpenGL ES applications. > > > > > > > > Allwinner devices have had a reasonably good OpenGL ES support in > > > > GNU/Linux via the Mali binary blob for roughly two years already > > > > (the installation instructions are available in the linux-sunxi wiki). > > > > In addition, a relatively popular Raspberry Pi board could have been > > > > also used to develop OpenGL ES applications just fine. > > > > > > > > The intention was to ensure that when the open source Lima driver > > > > is finally ready, it can run a wide selection of useful OpenGL ES > > > > applications which were to be developed. > > > > > > Thanks for the answer. > > > > > > I have r3p0 running as it should, and never said it was not good. > > > "good enough" is never "good enough" for a developer. > > > > OK. > > > > > Yes i could go with Raspberry PI board, better support, better > > community, > > > > Well, this "better support" thing is very much subjective and > > stereotypical. > > > > > etc.. but i prefer ODROID and i have my reasons.. > > > Your work is remarkable, indeed. > > > > > > The *real* problem is i want to have linux all the bells and whistles > > > Android have for this platform, my bad. > > > > I'm not sure if I'm a big fan of abstract bells and whistles. I very > > much prefer practical utility. And I would be happy to have reports > > like this: > > > > "I'm developing this very cool open source OpenGL ES game (or > > application) and it runs with X FPS using the r3p0 mali drivers, > > but can be improved to Y FPS with the r3p2 mali drivers" > > > > Instead of > > > > "I don't like the version number of your mali drivers. The other > > guys have it bigger, so you really need to catch up" > > > > > But..but..but why you so upset? I did not want to start a war, was just > > a > > > question. > > > > I'm not upset. I'm just explaining why I'm not eager to waste my time > > doing work, which has no clear purpose. > > > > The ball is basically on the OpenGL ES application developers' side. > > Before nitpicking about the drivers, they really need to show their > > commitment by contributing something useful to the free software > > community. Today the drivers are in a *much* better shape than the > > applications. > > There are some people interested in getting this updated It's not enough to be casually interested in a bigger version number. These people should show up in the mailing list and provide more convincing reasons. Just see my previous reply. > although this is not a trivial task. The kernel part is reasonably simple. Because, you know, it's fully open source. You can have a look at this branch: https://github.com/ssvb/linux-sunxi/commits/20140116-mali-r3p2-01rel2 It is split into 3 patches to make things clear and maintainable: 1. Just an unmodified copy of the GPL mali kernel driver from ARM 2. The sunxi adaptation part (mali hardware resources description and the code for enabling clocks). 3. A 2GB bugfix which is needed for the Cubietruck Anyone can do something similar with a newer version of the mali kernel driver if the need arises. > Kernel is tuned to server side, and the author has not seen any success > story yet, as a learning pourpose i will try and see if i can get to > somewhere. > https://github.com/dan-and/linux-sunxi It is up to dan-and to provide full support for this code and resolve any possible mali issues in it. I have nothing to do with it. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
