Godot version:
v3.2.2.beta.custom_build.443437058
OS/device including version:
Android mobile with GLES2 VideoCore IV GPU
GLES: Broadcom, VideoCore IV HW, OpenGL ES 2.0
GL_EXT_debug_marker GL_OES_compressed_ETC1_RGB8_texture GL_OES_compressed_paletted_texture GL_OES_texture_npot GL_OES_depth24 GL_OES_vertex_half_float GL_OES_EGL_image GL_OES_EGL_image_external GL_EXT_discard_framebuffer GL_OES_rgb8_rgba8 GL_OES_depth32 GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_APPLE_rgb_422
EGL:
EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_vg_parent_image EGL_KHR_lock_surface EGL_ANDROID_image_native_buffer EGL_ANDROID_swap_rectangle EGL_ANDROID_image_native_buffer
Android mobile with GLES2 PowerVR SGX 540 GPU
GLES: Imagination Technologies, PowerVR SGX 540, OpenGL ES 2.0
GL_EXT_debug_marker GL_OES_rgb8_rgba8 GL_OES_depth24 GL_OES_vertex_half_float GL_OES_texture_float GL_OES_texture_half_float GL_OES_element_index_uint GL_OES_mapbuffer GL_OES_fragment_precision_high GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_required_internalformat GL_OES_depth_texture GL_OES_get_program_binary GL_OES_packed_depth_stencil GL_OES_standard_derivatives GL_OES_vertex_array_object GL_OES_egl_sync GL_OES_surfaceless_context GL_EXT_discard_framebuffer GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_multisampled_render_to_texture GL_EXT_shader_texture_lod GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_IMG_shader_binary GL_IMG_texture_compression_pvrtc GL_IMG_texture_npot GL_IMG_texture_format_BGRA8888 GL_IMG_read_format GL_IMG_program_binary GL_IMG_uniform_buffer_object GL_IMG_multisampled_render_to_texture GL_KHR_debug
EGL
EGL_IMG_client_api_ogl 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_vg_parent_image EGL_IMG_cl_image EGL_ANDROID_blob_cache EGL_ANDROID_image_native_buffer EGL_ANDROID_framebuffer_target EGL_ANDROID_native_fence_sync EGL_ANDROID_recordable EGL_KHR_fence_sync EGL_IMG_context_priority EGL_IMG_hibernate_process EGL_IMG_image_plane_attribs EGL_KHR_surfaceless_context EGL_KHR_wait_sync EGL_KHR_create_context
Issue description:
creating viewport larger than 2048 and then drawing on it in _draw() drops error
example
func _draw():
draw_rect( Rect2(0, 0, 512, 512), 0xFFFFFFFF )
error
W 0:00:01.765 _render_target_allocate: Could not create framebuffer!!
<C++ Source> drivers\gles2\rasterizer_storage_gles2.cpp:4756 @ _render_target_allocate()
It works on PC and on mobiles with GLES2 mali GPU's
Steps to reproduce:
draw-bug-test.zip
I know next to nothing about viewports in Godot but I noticed the viewport size was quite large in the project (3750 x 630). I had a look for the caps for some hardware using videocore IV:
https://opengles.gpuinfo.org/displayreport.php?id=3703
GL_MAX_VIEWPORT_DIMS is 2048. So you could try reducing the width to 2048 to see if this fixes it. This should really be queried in Godot prior to making calls to create frame buffer.
GL_MAX_VIEWPORT_DIMS is 2048
@lawnjelly
can confirm, decreasing viewport size to 2048 fixes it, so its hardware limitation not a bug.
will leave this issue open and let @lawnjelly , @clayjohn , @akien-mga to decide if it can be closed or should need some checks for GL_MAX_VIEWPORT_DIMS
i wonder if it could be related to https://github.com/godotengine/godot/issues/37975 directional light shadows. We stuck there on
OpenGL ES 2.0 Renderer: VideoCore IV HW
**ERROR**: Directional shadow framebuffer status invalid
At: drivers\gles2\rasterizer_scene_gles2.cpp:4026:initialize() - Directional shadow framebuffer status invalid
could it be that the framebuffer size > 2048 ?
found the same issue on PowerVR SGX 540 and it also have GL_MAX_VIEWPORT_DIMS
== 2048
can confirm that when i set viewport size to <= 2048 then it works.
Should be easy enough to store max size in config
do an WARN_PRINT
if size is too big and then force the size to max size
We can test GL_MAX_VIEWPORT_DIMS at runtime, and reduce it as @clayjohn says. However this may be problematic in some games that have assumed a certain pixel size.
One of the problems in general with having lots of customization is that users can very easily create scenes that won't work on all hardware.
This comes up a lot for mobile, and we should brainstorm for features that would make this easier. One idea is to have a list of warnings when exporting to certain platforms. On android for instance common problems:
You could also argue that this stage is too late as the developer may have spent some time assuming a certain workflow, and it would be nice to have warnings as you create a feature. On the other hand this could become annoying if not wanted.
@lawnjelly I have thought about that too, it will be especially handy as we move to Vulkan as the split between low end and high end gets even wider.
I think at this point we should have a document outlining common issues that arise.
Users need to take some responsibility as well. It is up to users to research and choose their target platform, we will never be able to anticipate exactly what hardware they target. For example, some people are making games in GLES2 that are still targeting high-end mobile. However, we also have users using GLES2 to exclusively target low-end Android and raspberry pi. The difference between the hardware capabilities between the two is huge. So I think we should maintain a list of things that commonly vary between hardware, and then the users can have a checklist of sorts so they at least know what to look for.
i wonder if it could be related to #37975 directional light shadows. We stuck there on
OpenGL ES 2.0 Renderer: VideoCore IV HW **ERROR**: Directional shadow framebuffer status invalid At: drivers\gles2\rasterizer_scene_gles2.cpp:4026:initialize() - Directional shadow framebuffer status invalid
could it be that the framebuffer size > 2048 ?
Could well be. Try it. :+1:
That would presumably be your rendering/quality/directional_shadow/size.mobile
and rendering/quality/shadow_atlas/size.mobile
.
Actually looking at your min reproduction project these are set to 1024, so less likely to be the problem.
Most helpful comment
I know next to nothing about viewports in Godot but I noticed the viewport size was quite large in the project (3750 x 630). I had a look for the caps for some hardware using videocore IV:
https://opengles.gpuinfo.org/displayreport.php?id=3703
GL_MAX_VIEWPORT_DIMS is 2048. So you could try reducing the width to 2048 to see if this fixes it. This should really be queried in Godot prior to making calls to create frame buffer.