Add __sh__ cpu arch support #1095

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants

This Patch adds the sh cpu arch to xbmc (--host=sh4-linux).

Note: Even with this patch you wont be able to compile a runnable version of xbmc for sh4, as for that you will need the OpenGL ESv1 patch which I am currently still trying to merge in a clean way with xbmc.

And of course the patch to access the video and audio hardware decoder by using gstreamer and bypassing paplayer and dvdplayer is also still in merging process.

looks fine, will get merged in next merge window.

Member

theuni commented Jun 21, 2012

We decided quite a while back that glesv1 wouldn't be supported in mainline. Is there v2 path forward? It'd be a pretty hard sell imo to add the support burden of such an outdated spec.

Hm, I think the killer argument is shader. There is no way to support such a feature on the current chip.
But ESv1 is be pretty similar to ES2 with the only real differences is that there are no shaders and therefore the loading and drawing of textures is different. Currently I wrote around each shader call a #if HAS_GLES == 2
and replaced the drawing functions in TextureGL GUITextureGLES and GUIFontTTFGL.
I will just open a pull request and then you can see what changes would be necessary to add ESv1 support, then you can better decide if it is a reasonably effort to maintain this.

But anyway, ESv1 is easy. The hard part is that for videodecoding the frames are directly rendered into the videolayer which is below the framebuffer. So the way to display video is quite different to the way it is currently handled.
I still have to figure out how I can merge this back cleanly.

Member

theuni commented Jun 21, 2012

Well, beyond the fixed-function pipeline problem, there's also the fact that glesv1 devices are quite unlikely to keep up with the demand of rendering our gui. But I'll wait to see some numbers.

As for video decode, we have a 'bypass mode' flag in the gles renderer for decoders that handle their own presentation on a separate plane.

That is the current state of my port
http://www.youtube.com/watch?v=wByCsZzr6sA
I would say that for the current progress its already quite usable.

As for video decode, we have a 'bypass mode' flag in the gles renderer for decoders that handle their own presentation on a separate plane.
Thanks I will take a look at this mode.

Member

jmarshallnz commented Jun 23, 2012

By the looks you don't have blending enabled for diffuse textures (or no multitexturing enabled?) This may push things even more. The current speed is pretty slow (animations etc. really clunky) but perhaps this has to do with the capturing rate not just the frame rate?

Schischu commented Jul 2, 2012

@theuni : You wrote "As for video decode, we have a 'bypass mode' flag in the gles renderer for decoders that handle their own presentation on a separate plane."
Can you elaborate this ? I tried setting
#if HAS_GLES == 1
m_renderMethod = RENDER_BYPASS;
#else
m_renderMethod = RENDER_GLSL;
#endif
in the LinuxRenderGLES constructor. But the experience I get is fast switching between a black screen and the old ui.

I am cross compile the XBMC to SH4 based on following URL:
Schischu/xbmc@37777e4

even though it is not compile to SH4. Any other patches i have to apply?

Member

jmarshallnz commented Apr 8, 2013

Closing - unlikely suitable hardware will be available. If there is, we can reopen and work can continue.

jmarshallnz closed this Apr 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment