The 1000-traces-puzzle

[Exophase]

Compositing is another thing the 2D accelerator would be best used for, if that can be hooked up somehow.

 

[_wb_]

How efficient is MESA software rendering on the OMAP5? Is it as generic as can be, or does it use NEON to speed things up?

I'm starting to think that I may want to keep the Pyra's GPU just disabled all the time. I mean, it's a thing that consumes power, doesn't have decent drivers, let alone FOSS ones, and it can only do GL|ES anyway.

I don't understand why these hardware manufacturers sell hardware that is barely or not usable in practice because there is no (decent) documentation and no software support. They advertise a SoC with a CPU, 3D GPU, 2D GPU, DSP, M4s, but in practice, only the CPU can be used well.

 

[Bosbeetle]

I don't understand why these hardware manufacturers sell hardware that is barely or not usable in practice because there is no (decent) documentation and no software support. They advertise a SoC with a CPU, 3D GPU, 2D GPU, DSP, M4s, but in practice, only the CPU can be used well.

Indeed this just seems really weird, like selling a car with an airco that's turned off and no button to turn it on. Seems like a waste of resources. 

 

[_wb_]

I don't understand why these hardware manufacturers sell hardware that is barely or not usable in practice because there is no (decent) documentation and no software support. They advertise a SoC with a CPU, 3D GPU, 2D GPU, DSP, M4s, but in practice, only the CPU can be used well.

Indeed this just seems really weird, like selling a car with an airco that's turned off and no button to turn it on. Seems like a waste of resources. 

It's just like the display resolution spec wars I guess. People don't care about what the hardware actually does and whether it really makes a difference, they just want it to have the features. Even if the features don't work.

 

[Exophase]

How efficient is MESA software rendering on the OMAP5? Is it as generic as can be, or does it use NEON to speed things up?

I'm sure it's terrible.

I'm starting to think that I may want to keep the Pyra's GPU just disabled all the time. I mean, it's a thing that consumes power, doesn't have decent drivers, let alone FOSS ones, and it can only do GL|ES anyway.

I doubt it uses a meaningful amount of power if you're not doing anything with it.

I don't understand why these hardware manufacturers sell hardware that is barely or not usable in practice because there is no (decent) documentation and no software support. They advertise a SoC with a CPU, 3D GPU, 2D GPU, DSP, M4s, but in practice, only the CPU can be used well.

These SoCs are just not used in plain Linux configurations like Pyra very much. And OMAP5 is nearly a stillborn SoC.

But I think you're blowing it out of proportion. There's documentation and software for everything but the SGX, and that's not TI's fault. Just like with Pandora, I'm sure people will be able to use the DSP if they want to (and M4s), there's just not going to be any real incentive to.

The 2D GPU on the other hand, is something that should be very usable and will have real use cases. Something I've said several times in this thread now

 

[notaz]

All blobs are userspace, kernel parts are open (which also need porting but should not be as huge issue as the blobs). I don't remember the details, it's about a year since I've looked at it and situation has probably changed slightly with Debian 8 release anyway.

I understand that it's not something in the kernel that has to be changed, but I thought that the problem was that the blobs weren't compatible with interfaces in newer kernels.

TI's SGX driver build for OMAP3 was rather self-contained, mostly depends on glibc and that's all. It hooks with omapfb at the kernel level to be able to render to display.
For OMAP5 they took different approach for some reason, they linked the blobs with mesa and it's buffer object machinery (and something else I forgot), which itself is serviced by omapdrm. And this is where the problems come, mesa is a moving target and it's internal structures change all the time, however the SGX blobs are compiled for whatever mesa there was on Ubuntu 12.04 and got the ABI stuck to that. We also get the forced omapdrm dependency and can't use omapfb like we did on pandora.

 

[EvilDragon]

I doubt it That offer is already pretty cheap, I doubt I could get something cheaper, even with smaller traffic. Compared to other tariffs: O2 2 go Flat L: 12,49 EUR. You get 5GB, but only 7,2MBit speed - for 4 EUR per month more Telekom: Data Comfort S: 13,45 EUR (only first 12 months, 14,95 EUR after that). You get 1GB and 16MBit/s speed. AldiTalk: Internet Flatrate L: 9,99 EUR. You get 1,5GB/month, don't even know the speed. So... I guess I'm pretty good here

Wow, I wouldn't have thought that the differences were THAT high :blink:

How are you even able to offer it at this price?

I got a VERY good deal, yes

Also, will the 4G version of the Pyra be available at launch ?

Yes.

Desktop compositing on a mobile device? That would eat your battery (like on Android, which does everything with GL).

It's simply false nowadays. Compositing is very efficient and I even turn it on by default on my laptop.
It was inefficient when it all started.


Android compositing doesn't kill battery, background services and virtual machine do. Sailfish uses compositing


and it doesn't kill battery as fast as Android (unless you run Android VM).

Well, without compositing, you can switch off the 3D chip, which certainly safes battery.

Yes, it might safe power if you move around Windows a lot - but honestly, who does that?

Even on my desktop, I usually have my taskbar and switch between tasks.

The only time I move around my windows is when I need multiple ones side by side (something that isn't even possible with normal Android), and even then I usually move those windows into position one time and that's it.

X even does selective rendering - it only updates the screen where it needs to be.

In my opinion, compositing is only really useful when you move windows around a lot... does someone do that? Especially on a mobile device?

I would be happy if Android would just do a hard switch when I rotate my unit. That rotation animation is just horrible (and slows things down).

Compositing isn't just for flashy effects. It used to be, but not any more. At least on a desktop. Try moving a large window quickly around with three 1920x1200 displays in software with a mouse. I have most effects disabled on my KDE desktop, but use compositing more as a necessity. The fancier graphics, like slight clarifying shadows for windows, are just a nice side effect.

Tried on my 1920x1080 laptop. Couldn't really feel a difference.

Yes, it was just one display... but how many 1920x1200 displays are you planning to connect to the Pyra?

I don't understand why these hardware manufacturers sell hardware that is barely or not usable in practice because there is no (decent) documentation and no software support. They advertise a SoC with a CPU, 3D GPU, 2D GPU, DSP, M4s, but in practice, only the CPU can be used well.

Automotive sector often uses QNX, multimedia devices Android.

I'm not sure there's anyone except ourselves using Linux on the OMAP5, so why should TI put any ressources into small orders like from us?

I'm sure if we ordered 1 Million OMAP5, we could get them to update the SGX driver for us.

 

[bzar]

Tried on my 1920x1080 laptop. Couldn't really feel a difference. Yes, it was just one display... but how many 1920x1200 displays are you planning to connect to the Pyra?

Hence the "At least on desktop" part. It may not become an issue on Pyra, but I just wanted to counter some misunderstandings that compositing was just for flashy effects.

I've seen some desktops slow down to slideshow crawl with modest CPU or I/O load and software rendering.

Anyway, that's beside the point. I'm more disappointed over not being able to do all the fun new stuff Qt5 has like shader-based effects for desktop applications (for better usability of course, not just eye candy).

EDIT:

I would be happy if Android would just do a hard switch when I rotate my unit. That rotation animation is just horrible (and slows things down).

Did you know that rotation animation is there for a reason other than to tell you the orientation just changed? AFAICT it's there so you don't accidentally press the wrong buttons when the device suddenly misinterprets your orientation. Without a transition you could very easily press wrong things on the screen as the orientation could change at an instant just as you're landing your finger on the screen. Now there's a short period of time your clicks don't count, so any sudden orientation changes don't cause such mistakes. Sometimes there's more to so called "eye candy" than meets the eye

 

[mrpalmtop]

Tried on my 1920x1080 laptop. Couldn't really feel a difference. Yes, it was just one display... but how many 1920x1200 displays are you planning to connect to the Pyra?

Hence the "At least on desktop" part. It may not become an issue on Pyra, but I just wanted to counter some misunderstandings that compositing was just for flashy effects.

I've seen some desktops slow down to slideshow crawl with modest CPU or I/O load and software rendering.

Anyway, that's beside the point. I'm more disappointed over not being able to do all the fun new stuff Qt5 has like shader-based effects for desktop applications (for better usability of course, not just eye candy).

EDIT:

I would be happy if Android would just do a hard switch when I rotate my unit. That rotation animation is just horrible (and slows things down).

Did you know that rotation animation is there for a reason other than to tell you the orientation just changed? AFAICT it's there so you don't accidentally press the wrong buttons when the device suddenly misinterprets your orientation. Without a transition you could very easily press wrong things on the screen as the orientation could change at an instant just as you're landing your finger on the screen. Now there's a short period of time your clicks don't count, so any sudden orientation changes don't cause such mistakes. Sometimes there's more to so called "eye candy" than meets the eye

Yes.

And compositing is really key to using the GNOME desktop environment in anything other than fallback mode. There are also many KDE features such as quarter tiling which do not work without it enabled.

I regularly use compositing to rapidly switch to any of my windows with just a single click. People who haven't tried it really are missing out now. Compositing is also very useful for transparency when comparing multiple windows simultaneously such as keeping an eye on multiple server logs or htop process listings.

 

[Foxgod]

Congratulation on the finished cpu board, almost there

 

[PowerGod]

I don't understand if there will be the possibility to run Compiz Fusion on it, I liked very much how it can manage many windows without having to run from a desktop to another in search for them.

The other effects like fire, exploding windows or the rotating cube can be used just as a show for friends...

 

[levi]

Compiz is a compositor, like what we've been talking about here.  It uses OpenGL, so you'll need a working 3D driver, and something like GLshim for someone to port it, so it won't be there from day 1 I'd suggest.

 

[Exophase]

Well, without compositing, you can switch off the 3D chip, which certainly safes battery.

The SGX really shouldn't be on between when it's being used... It's not like it'll have a turn on time in the hundreds of ms or something like that.

 

[Letalis Sonus]

It uses OpenGL, so you'll need a working 3D driver, and something like GLshim for someone to port it

OpenGL ES 2.0 support went mainline almost 3 years ago.
However, since Canonical took over they kept screwing up things, causing all sorts of bugs with Compiz on other DEs. I really can't recommend using it with anything other than Unity, which would be a rather bad choice for a handheld, anyway.

It's dead, Jim.

 

[PowerGod]

It uses OpenGL, so you'll need a working 3D driver, and something like GLshim for someone to port it

OpenGL ES 2.0 support went mainline almost 3 years ago.
However, since Canonical took over they kept screwing up things, causing all sorts of bugs with Compiz on other DEs. I really can't recommend using it with anything other than Unity, which would be a rather bad choice for a handheld, anyway.

It's dead, Jim.

:°(

 

[_wb_]

Well, without compositing, you can switch off the 3D chip, which certainly safes battery.

The SGX really shouldn't be on between when it's being used... It's not like it'll have a turn on time in the hundreds of ms or something like that.

But what does "being used" mean? If you have like a semi-transparent terminal on top of some other window (where the transparency is handled by the compositor, which uses the GPU to do the alpha blending), wouldn't the SGX be constantly on?

 

[fusion_power]

It uses OpenGL, so you'll need a working 3D driver, and something like GLshim for someone to port it

OpenGL ES 2.0 support went mainline almost 3 years ago.

However, since Canonical took over they kept screwing up things, causing all sorts of bugs with Compiz on other DEs. I really can't recommend using it with anything other than Unity, which would be a rather bad choice for a handheld, anyway.


It's dead, Jim.

I've heared the future is actualy "VULKAN", at least on paper it's possibilities sounds pretty nice.

 

[Letalis Sonus]

I've heared the future is actualy "VULKAN", at least on paper it's possibilities sounds pretty nice.

"The future" actually arrived already 6 years ago: While everyone points at Mantle, the whole idea behind Vulkan is much older - you could say that Vulkan has basically evolved from Gallium3D, it was the first project that has been using this approach on a large scale. The only difference is that Gallium was originally developed to implement higher level stuff like OpenGL on top of it instead of using it directly - there's even a working Direct3D9 state tracker by now, even though Wine still refuses to support it upstream (patches are available).
However, until we get a SGX driver that can be fed with a known IR command stream (SPIR, LLVM IR, TGSI IR...) it's pretty useless to talk about it.

 

[slimeycat]

Preorder, you say?  September, you say?  Where do I pay, I say!

 

[mrpalmtop]

It uses OpenGL, so you'll need a working 3D driver, and something like GLshim for someone to port it

OpenGL ES 2.0 support went mainline almost 3 years ago.

However, since Canonical took over they kept screwing up things, causing all sorts of bugs with Compiz on other DEs. I really can't recommend using it with anything other than Unity, which would be a rather bad choice for a handheld, anyway.


It's dead, Jim.

:°(

I wouldn't recommend Compiz going forward. But KWin has basically all the same major features plus many others which Compiz does not have, including the ability to disable compositing entirely.