Post Reply Subscribe to Thread Email Thread

Making newer GPU drivers work

22nd October 2014, 05:41 PM |#71  
ScardracS's Avatar
Recognized Developer
Flag Lugo
Thanks Meter: 513
 
1,266 posts
Join Date:Joined: May 2012
More
Android 5.0 will be released on 3rh november via ota and in the next few days will be released AOSP version

Sent from my Galaxy Nexus using XDA Free mobile app
24th October 2014, 09:17 PM |#72  
Recognized Developer
Flag Green Bay, WI
Thanks Meter: 4,905
 
849 posts
Join Date:Joined: Dec 2010
Donate to Me
More
Quote:
Originally Posted by markitosd

When listening to music there seems to be a stutter seconds after locking the screen. Is that due to drivers, kernel, rom? I've tried several combinations of roms and kernels and the problem is still there. Any idea? I'm using Apollo and Play Music, and I'm having the issue with both.

The issue is, at least mostly, audio HAL related. The deep buffer path behaves differently for screen on and screen off. Screen off is... more relaxed, and basically says "we don't give a **** about latency if the screen is off, let the CPU take its time to save power". Which makes perfect sense, a delay is only going to be noticeable if you're interacting with something on the screen.
This might be fixable by making the difference between screen on and screen off smaller. I'll look into it.
The Following 6 Users Say Thank You to MWisBest For This Useful Post: [ View ]
27th October 2014, 05:06 PM |#73  
markitosd's Avatar
Member
Flag Reconquista
Thanks Meter: 6
 
46 posts
Join Date:Joined: Jul 2012
More
@MWisBest Great explanation, good luck finding a solution for this! Thanks for everything you are doing for the GNex
The Following User Says Thank You to markitosd For This Useful Post: [ View ]
7th November 2014, 07:22 AM |#74  
santi1993's Avatar
Senior Member
Flag Buenos Aires
Thanks Meter: 38
 
275 posts
Join Date:Joined: Mar 2012
More
i've readed there and here and see that the galaxy nexus just "slow" their vital signs to save power, if anyone could include and exception for audio processor maybe the problem will be gone, im not joking anyone, i know here are too much intelligent ppl but maybe focusing in this way make the audio works better with screen off, making an exception to slow everything except audio DSP
18th November 2014, 09:01 AM |#75  
n1kolaa's Avatar
Senior Member
Thanks Meter: 2,092
 
2,720 posts
Join Date:Joined: Oct 2011
Donate to Me
More
Quote:
Originally Posted by santi1993

i've readed there and here and see that the galaxy nexus just "slow" their vital signs to save power, if anyone could include and exception for audio processor maybe the problem will be gone, im not joking anyone, i know here are too much intelligent ppl but maybe focusing in this way make the audio works better with screen off, making an exception to slow everything except audio DSP

IT have some Tesla DSP-s for omap , but we think our board dont have it
9th February 2015, 08:32 AM |#76  
theBlackEnd's Avatar
Member
Thanks Meter: 150
 
89 posts
Join Date:Joined: Mar 2014
More
Hey guys,
I've been trying to switch to Hashcode's OMAP4-next repo.
Build finishes successfully, but I can't get one booting.
First builds were stuck at google's logo since pvrsinit bin was missing, now surfaceflinger can't locate composer file, so there's no video output.
Here's an extract from the logcat:

Code:
[...]
I/SurfaceFlinger(  669): SurfaceFlinger is starting
I/SurfaceFlinger(  669): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
D/libEGL  (  669): loaded /vendor/lib/egl/libEGL_POWERVR_SGX540_120.so
D/libEGL  (  669): loaded /vendor/lib/egl/libGLESv1_CM_POWERVR_SGX540_120.so
D/libEGL  (  669): loaded /vendor/lib/egl/libGLESv2_POWERVR_SGX540_120.so
I/ti_hwc  (  669): Expecting h/w vsync for tuna
E/ti_hwc  (  669): failed to open hdmi fb (2)
E/SurfaceFlinger(  669): composer device failed to initialize (No such file or directory)
I/SurfaceFlinger(  669): Using composer version 0.0
W/SurfaceFlinger(  669): no suitable EGLConfig found, trying a simpler query
I/SurfaceFlinger(  669): EGL information:
I/SurfaceFlinger(  669): vendor    : Android
I/SurfaceFlinger(  669): version   : 1.4 Android META-EGL
I/SurfaceFlinger(  669): extensions: EGL_KHR_get_all_proc_addresses EGL_ANDROID_presentation_time EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_ANDROID_image_native_buffer EGL_ANDROID_recordable 
I/SurfaceFlinger(  669): Client API: OpenGL_ES
I/SurfaceFlinger(  669): EGLSurface: 8-8-8-8, config=0x2
I/SurfaceFlinger(  669): OpenGL ES informations:
I/SurfaceFlinger(  669): vendor    : Imagination Technologies
I/SurfaceFlinger(  669): renderer  : PowerVR SGX 540
I/SurfaceFlinger(  669): version   : OpenGL ES-CM 1.1
I/SurfaceFlinger(  669): extensions: GL_EXT_debug_marker GL_OES_byte_coordinates GL_OES_fixed_point GL_OES_single_precision GL_OES_matrix_get GL_OES_read_format GL_OES_compressed_paletted_texture GL_OES_point_sprite GL_OES_point_size_array GL_OES_matrix_palette GL_OES_draw_texture GL_OES_query_matrix GL_OES_texture_env_crossbar GL_OES_texture_mirrored_repeat GL_OES_texture_cube_map GL_OES_blend_subtract GL_OES_blend_func_separate GL_OES_blend_equation_separate GL_OES_stencil_wrap GL_OES_extended_matrix_palette GL_OES_framebuffer_object GL_OES_rgb8_rgba8 GL_OES_depth24 GL_OES_stencil8 GL_OES_compressed_ETC1_RGB8_texture GL_OES_mapbuffer GL_OES_EGL_image GL_OES_EGL_image_external GL_EXT_multi_draw_arrays GL_OES_required_internalformat GL_IMG_read_format GL_IMG_texture_compression_pvrtc GL_IMG_texture_format_BGRA8888 GL_EXT_texture_format_BGRA8888 GL_OES_egl_sync GL_IMG_vertex_array_object GL_APPLE_texture_2D_limited_npot
I/SurfaceFlinger(  669): GL_MAX_TEXTURE_SIZE = 2048
I/SurfaceFlinger(  669): GL_MAX_VIEWPORT_DIMS = 2048
I/dex2oat (  253): Explicit concurrent mark sweep GC freed 43706(6MB) AllocSpace objects, 0(0B) LOS objects, 14% free, 23MB/27MB, paused 457us total 1.158s
E/cutils-trace(  669): Error opening trace file: Permission denied (13)
D/SurfaceFlinger(  669): Set power mode=2, type=0 flinger=0x40662000
F/libc    (  669): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 669 (surfaceflinger)
A\B comparison shows no missing files in /system dir (no more, lol).
The only difference from builds made with MWisBest and Ziyan's Franken-domx is that hwcomposer.*.so and camera.*.so libs have different names (omap4 instead of tuna), but this looks legit to me. (*)
Any hint?

Thank you in advance.


EDIT: Ok, after some digging in hardware/libhardware/hardware.c I think I found what's wrong. I'll let you know.
EDIT2: Meh, I made a few more attempts and set SELinux policy to permissive. (*) ro.board.platform is set to omap4, so hwc_open_1() should be able to load these modules.
I'm out of ideas now.

EDIT 3: Another final is gone and I've got a few hours to spend on this. I think I need do start to try easy solutions first. It's working fine now, I'm going to make a new clean build and test what's working (camera, sensors...).
Last edited by theBlackEnd; 12th February 2015 at 04:15 PM.
The Following User Says Thank You to theBlackEnd For This Useful Post: [ View ]
6th March 2015, 10:58 AM |#77  
theBlackEnd's Avatar
Member
Thanks Meter: 150
 
89 posts
Join Date:Joined: Mar 2014
More
Quote:
Originally Posted by zzpianoman

Ah but using CyanogenMod's LegacyCamera app, I am able to take perfect snapshots while recording video!! Actually, the LegacyCamera app works pretty flawlessly with Lollipop on Tuna - the Camera NEVER crashes, and I never have to reboot like I do with the stock Camera app or Google Camera. That's where the story gets even more complex and weird. The snapshots I take using that Camera app WHILE recording 1080p video are all high resolution (2592 x 1458) and NOT 1920x1080 like they SHOULD be.

Which is actually how I came to the conclusion that perhaps the camera is stuck in snapshot mode. It looks like OMX makes several calls to the CameraHAL, and maybe one of them is not setting recordingHint to true? I really have no idea. I have been rattling my brain over this as well trying to understand how all of this works. It's pretty complicated.

EDIT: I wish there was some kind of flowchart available to see exactly how the camera interfaces with the software.

I'm sorry for the late answer, I've been busy with an exam. Better move this here, at least we can keep track of posts.
I'm going to re-enable snapshot capability during video recording in DOMX just to verify if it happens here too. I had to disable a few features as Ducati crashed on capability\compatibilty request for some of them. EDIT: This has been disabled by MWisBest for some reason, I'm re-enabling it and check if it works.

While updating domx and camera, before realizing that Ducati was crashing, I wrote down a flowchart to try to understand what was causing capabilities arrays to have all NULL entries.
In short, there are more than 10 functions calling each other just to get camera properties, set them visible to camera apps and then display them in logs. I don't think there could be any usable flowchart for the whole camera/domx software interface.

All we can do to check your theory is to log camera status for each call, I guess. Anyway, 2592 x 1458 is still 16:9 multiple, this doesn't explain green bands in just a part of the video IMHO. Also, if I recall correctly, you're still using old pvr, domx and camera on your ROM and still get green lines, right? If so, why the same source is working fine on KK? What's changed in encoding and camera handling since then?

EDIT: Just built and installed LegacyCamera. WHAT A BAD LOOKING UI D: Yeah, this looks really stable. However, I'm not experiencing other cameras FCs (during usage, I mean) lately.
Meh, these lines seem to be camera dependent (?). I mean, in video recorded with Google Camera there's a green line on the left, same with Camera2 but that is gray most of the time, in LegacyCamera there's just a small pink band on the bottom, so small that I didn't notice it at first, but it's there even during preview. The more I try to locate the problem and the more I get confused. No good.

EDIT 2:
Code:
D/CameraHal(  137): (40f438a8)     hardware/ti/omap4/camera/CameraParameters.cpp:227 dump - prop-video-snapshot-supported = false
Code:
W/CAM_VideoModule( 2249): Cannot take a video snapshot - not supported by hardware
... I have no words.

This looks interesting:
Code:
D/CAM_VideoModule( 2249): Video snapshot size is Size: (1920 x 1080)
But then, loads of lines bellow (I guess I launched Legacy Camera by then)
Code:
V/videocamera( 3754): Video snapshot size is 2592x1458
EDIT 3: Googling for an error I just found out there's a camera_test bin from TI, I'm going to give it a try. I think this could help to find what's wrong.

EDIT 4: OUCH. I have to figure out why OpenGL compatibility is stuck at 1.1 version on my builds instead of 2.0 as CM 12. Any hint? I don't have any valid idea to be honest.
Last edited by theBlackEnd; 7th March 2015 at 03:04 PM.
The Following User Says Thank You to theBlackEnd For This Useful Post: [ View ]
6th March 2015, 03:26 PM |#78  
Senior Member
Flag New York
Thanks Meter: 485
 
441 posts
Join Date:Joined: Jun 2008
Donate to Me
More
Quote:
Originally Posted by theBlackEnd

I'm sorry for the late answer, I've been busy with an exam. Better move this here, at least we can keep track of posts.
I'm going to re-enable snapshot capability during video recording in DOMX just to verify if it happens here too. I had to disable a few features as Ducati crashed on capability\compatibilty request for some of them. EDIT: This has been disabled by MWisBest for some reason, I'm re-enabling it and check if it works.

While updating domx and camera, before realizing that Ducati was crashing, I wrote down a flowchart to try to understand what was causing capabilities arrays to have all NULL entries.
In short, there are more than 10 functions calling each other just to get camera properties, set them visible to camera apps and then display them in logs. I don't think there could be any usable flowchart for the whole camera/domx software interface.

All we can do to check your theory is to log camera status for each call, I guess. Anyway, 2592 x 1458 is still 16:9 multiple, this doesn't explain green bands in just a part of the video IMHO. Also, if I recall correctly, you're still using old pvr, domx and camera on your ROM and still get green lines, right? If so, why the same source is working fine on KK? What's changed in encoding and camera handling since then?

EDIT: Just built and installed LegacyCamera. WHAT A BAD LOOKING UI D: Yeah, this looks really stable. However, I'm not experiencing other cameras FCs (during usage, I mean) lately.
Meh, these lines seem to be camera dependent (?). I mean, in video recorded with Google Camera there's a green line on the left, same with Camera2 but that is gray most of the time, in LegacyCamera there's just a small pink band on the bottom, so small that I didn't notice it at first, but it's there even during preview. The more I try to locate the problem and the more I get confused. No good.

EDIT 2:

Code:
D/CameraHal(  137): (40f438a8)     hardware/ti/omap4/camera/CameraParameters.cpp:227 dump - prop-video-snapshot-supported = false
Code:
W/CAM_VideoModule( 2249): Cannot take a video snapshot - not supported by hardware
... I have no words.

This looks interesting:
Code:
D/CAM_VideoModule( 2249): Video snapshot size is Size: (1920 x 1080)
But then, loads of lines bellow (I guess I launched Legacy Camera by then)
Code:
V/videocamera( 3754): Video snapshot size is 2592x1458
EDIT 3: Googling for an error I just found out there's a camera_test bin from TI, I'm going to give it a try. I think this could help to find what's wrong.

EDIT 4: OUCH. I have to figure out why OpenGL compatibility is stuck at 1.1 version on my builds instead of 2.0 as CM 12. Any hint? I don't have any valid idea to be honest.

This is what I get when I try to record video @ 720p:

Code:
D/OMXCodec(  137): Successfully allocated OMX node 'OMX.TI.DUCATI1.VIDEO.DECODER'
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] AVC profile = 100 (High), level = 41
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 1280 x 720
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 1280 x 720 @ (0, 0)
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 2 buffers of size 921600 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a301a0 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30100 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 3 buffers of size 1723392 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a300b0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30150 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x4210d6a0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 1408 x 816
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 1280 x 720 @ (0, 0)
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 7 buffers of size 1723392 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x4210d6a0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x4210d920 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30150 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30240 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30290 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a302e0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30330 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 1408 x 816
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 1280 x 720 @ (32, 24)
And now for 480p:

Code:
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] AVC profile = 100 (High), level = 41
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 720 x 480
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 720 x 480 @ (0, 0)
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 2 buffers of size 345600 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a301a0 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30100 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 3 buffers of size 774144 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a300b0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30150 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x423115b0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 896 x 576
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 720 x 480 @ (0, 0)
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 7 buffers of size 774144 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x423115b0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x42311560 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30150 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30290 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a302e0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30330 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30380 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 896 x 576
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 720 x 480 @ (32, 24)
It looks like the first call made to video decoder passes the correct video dimension but then two subsequent calls pass dimensions that are larger than the target video size. Also, it seems as if one dimension from each of these larger dimensions, is from the list of supported jpeg sizes - i.e. one of the supported still image capture resolutions from getsupportpicturesizes.

I've also tried forcing the video dimensions at several locations in the source code with no success. All that happens is that the software codec thinks I'm requesting that particular size, and merely sets the crop dimensions to the forced values. Perhaps the cameraHAL is stuck in preview mode and never actually goes into recording mode, and the logic that determines the video dimensions "thinks" it is in recording mode and therefore sets the video size based on the preview size, which is actually one of the still-capture dimensions?

I even tried adding some of the supported jpeg sizes to the supported preview resolutions in OMXCapabilities, and the decoder is still choosing video size dimensions that are larger than the requested video dimensions.

I am using old pvr, so it looks like whatever is causing this issue is something in frameworks_av that changed from KitKat to Lollipop - which is actually quite a bit. I've been meticulously going through the code trying to pinpoint what has been changed and how it could be affecting this particular issue, but with no success.

Just to add some more confusion to the mix, apps that stream video such as Skype actually work perfectly so it appears that it's just encoding and saving video that is the problem.

The Following User Says Thank You to zzpianoman For This Useful Post: [ View ]
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes