OpenHandhelds.org

I third that!

cb88 > you were saying that the devs have said that it will be shipped with OGL-ES 2.0, do you have a link ?
Because yes, I still have no answer about where are the 2.0 driver for OMAP.

It has been mentioned in various places that the Pandora will have a binary blob driver for ES 2.0, just search the forums.

There will be at least ES 2.0 support, either at ship time or shortly thereafter. You'll have to take the devs' and my word on that one.
You won't find the driver sets for OMAP3 yet because it's not available from TI for general public consumption yet- YET.

ok, frankly, i'm not sure what i'm saying anymore (and for sure never claimed it can perform 4 32bit ops/clock ; )

the whole 'scatter/gather SIMD over 4 threads' point i've been promoting so far is clearly a no-go for floats (as maciek has been trying to hammer down my cortex : ), i.e. something like that may still be used for the lower-width data types, but apparently does not help for floats. so far everything indicates that the fp/clock powers of the SGX are not great - namely, 1 op per clock per shader unit. apropos, something has been bothering me since the beginning in that SCH datasheet, namely (9.1.1 3D Core Key Features): '— Vertex Rate: One Triangle 15 clocks (Transform Only)'.

so here the '1 tri/clock' is the typical PR speak used to imply 1 vertex/tri ratio, which is ok. what is bothering is the quote of 15 clocks/vertex (transform only). now, 'transform only' clearly implies a sole MVP (model-view-projection) transform operation. now, if we assume MAD (multiply-add) ops would be used to do that (and the shader units are entirely devoted to vertex work), that is 4x 4-wide MADs per vertex transformed, swizzles non-widthstanding (then again, we have 1 float/register, there's nothing to swizzle there). or IOW, these are 16 ops (ok, most/all of them fused, but that's not the point), carried in.. 15 clocks!? does anybody else find the ratio of ~1 op/clock rather bothersome? i do. let me explain why: because that means that only one shader unit can work on one thread at a time.

what follows from that? well, one of the following two things:

a) either SCH's SGX has one (1) shader unit in total (in which case i cannot see how threads can execute concurrently, at all), or
b) there's no 'scattering SIMD' in SGX, the way i've been expecting it, so multiple registers from one context cannot be dispatched to multple shader units at a time (in the example: there is only one shader working on the MVP transform at any time)

either way, there's something rotten in datasheetland. oh, well.

I'm assuming you're referring to 'Vertex / Triangle Ratio average = 1 vtx/tri, peak 0.5 vtx/tri'. Yup, I guess so too. And it means that they have transformed vertex cache.


I think the reality is 60 clocks/vertex, but there are 4 shader units, so in theoretical scenario when only vertex processing is done (all 4 shader units are doing VS) they'll get average of 15 clocks...
This corresponds nicely to information that SGX can do 13.5 mpolys/s [@200Mhz]. This would mean that vertex processing takes (200*mega [1/s] )*( 4 [shader_units ] )/( 13.5*mega [polys/s] ) = 59.259 [clocks].
I'm assuming that their 'transform only' includes clipping and division when projecting 3D->2D. They cannot do it in pixel shaders, because they tiled architecture has to have 2D triangles after VS to match triangles to specific tiles...

As a side note: Interesting if they have a HW division unit... but I'm betting that they have small ROM table for first steps of Newton-Raphson approximation and then do 2-3 software NR iterations.

I reckon it might just be counted as a 4x4 matrix transform - and if you're using triangle strips, do you only need to translate one point? so the first triangle in a polygon would be 3 vertices, but any subsequent triangles would be just one point.

My memory of all this stuff is very sketchy, so I'm happy to be wrong, but thinking about homogenous coordinates, you probably don't need all 16 multiplies - you can probably avoid 1 and just use it as the starting point to the add (maybe).

Of course, this benefits a lot higher from large polygons with lots of triangles, rather than single triangles, which will be more expensive. But until we actually get hardware and can play we won't know how powerful it is. The demos look good though, at least.

I remember reading elsewhere that apparently modern GPUs don't do SIMD FMAC anymore, because it's hard to actually keep them full, instead preferring to have more threads and have smaller units. I don't know how true this is. For 8bit colour (with an alpha channel) I imagine it's very easy to keep it full, but for floats its probably easier to have individual elements.

in retrospective, i think i jumped to concusions last night. the quoted 15 clocks/vertex could've been just as well under the assumption that all shader units are busy doing something (e.g. other vertices), so even if more than one shader unit can work on a single context at a time, that does not change the statistics. so i was jumping about nothing here.


the 4 units-60 clocks is another possible explanation, though i do have a question about it - what would take 60 clocks in a single vertex transform? that's 28 'unfused' fp ops (muls and adds). surely it does involve clipping and homogeneous division, but that's somewhere down the road, deeply pipelined (the tiling apparatus would be a good candidate for performing that). i can't see how a vertex shader would do clipping, given that's a 1-to-N operation. then again, these same units are used for geometry shaders (inherently 1-to-N), so they just as well may be used to do clipping, and likely w-division. *shrug*


i think everybody does it like this these days. FPUs included.


i think that not so much because there are not enough 3/4-wide MADs in modern shaders (there are plenty) to keep those SIMD units busy, but because when you do your wide MADs on individual scalars you don't have to worry about swizzles/packing. in shaders you sometimes need your vectors as SoA (structure-of-arrays), and sometimes as AoS (array-of-structures) - a true SIMD unit would have to swizzle excessively to handle that. the same problem just does not stand with 'scattered vectors' when your vector elements are kept separately.

I agree, but all figures I've found on net quoting those 13.5 mpolys/s were in polys/s. So I'm guessing they've wrote some benchmark rendering flat-shaded triangles o the screen and measured results. So clipping might be involved.
And I disagree - tiling unit would not be good place to do it, because two triangles sharing the same vertex would perform '1/z=w' calculation twice in tiling unit for this vertex (or it would cache it somehow - what's not impossible). And then it should be stored in triangle context to calculate dw/dx, dw/dy for perspective-correct interpolation. But again - weirder things happened in HW land...


Sadly... not everybody. Some architectures (like G945 I'm babbling about constantly) has dedicated (shadred by all shader units) math unit.

Heh - I found something.

SGX incorporated in Intel SCH (System Communiation Hub) is called US15W. There are drivers for it for Windows, Windows C & Linux. I found those drivers in package called Intel Embedded Graphics drivers which can be found here(link). After 'installation' (on Windows) it creates directory 'c:\IEGD\IEGD_9_0_2' in which there's a 'funky' java-based tool to generate driver for particular OS.
In directory 'c:\IEGD\IEGD_9_0_2\plugins\com.intel.iegd.drivers_9.0.0\Linux' there is very interesting file called 'IEGD_9_0_2_Linux.tgz'. It has graphic driver for SGX integrated into SCH in form of patches for kernel, source code of kernel module and binary of user-space module.
Kernel module works for kernels above 2.6.5 and in its sources we can find:

• that SGX can address either 128MB or 256MB of memory, no more, no less(?)
• that GTT (graphic translation table) is 1-level and occupies 5 or 6 physically continuous pages
• there's a code for:
  
  • GTT initialization
  • SGX MMU enable, disable, flush
  • SGX MMU GTT directory cache invalidate

Thanks to this info - we can dump contents of memory visible via SGX MMU, and thanks to MMIO trace(link) we can log all operations done on SGX MMIO registers.

Seems that deciphering SGX will be a bit easier...

THX everyone for participating and keep the thread alive.

nice! glad to see you starting off ; )

just a note: if the linux driver from the IEGD902 package is similar to the XP IEGD902 counterpart, you may not find any GL code in there - the XP version is DX-only. then again, they may be totally different, so it pays to check. for starter, what does glxinfo report after installation?

I don't know. I do not own Atom mainboard... I'm just analyzing contents of installer.

This post is updated.

I (probably) found out which OGL extensions are supported in SGX OpenGL driver on x86 Linux.

GL_3DFX_texture_compression_FXT1 GL_APPLE_client_storage GL_APPLE_packed_pixels GL_APPLE_vertex_array_object GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_shading_language_120 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_blend_equation_separate GL_ATI_fragment_shader GL_ATI_separate_stencil GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_cull_vertex GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_shared_texture_palette GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_set GL_IBM_multimode_draw_arrays GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESAX_texture_float GL_MESA_pack_invert GL_MESA_packed_depth_stencil GL_MESA_program_debug GL_MESA_resize_buffers GL_MESA_texture_array GL_MESA_window_pos GL_MESA_ycbcr_texture GL_NV_blend_square GL_NV_fragment_program GL_NV_light_max_exponent GL_NV_point_sprite GL_NV_texgen_reflection GL_NV_texture_rectangle GL_NV_vertex_program GL_NV_vertex_program1_1 GL_OES_read_format GL_S3_s3tc GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SGIX_shadow_ambient GL_SGI_color_matrix GL_SGI_color_table GL_SGI_texture_color_table GL_SUN_multi_draw_arrays

This is one of the few threads worth following. It has action, suspense, drama...it should be made into a hollywood blockbuster

Maciek, that set of extentions raises a few questions:

* it has GL_ARB_fragment_program, but not GL_ARB_vertex_program
* GL_ATI_fragment_shader and GL_NV_fragment_program are both in - two fairly proprietary extensions, which i'd be surprised to see anywhere outside of their proprietors' drivers, and surely not in the competition's drivers.
* GL_ARB_fragment_shader is there but GL_ARB_vertex_shader is not - another strange gap.

leaving aside the fact that not all of those may have entry points, and thus be actually implemented extensions, the above points incline me to think that this ICD may not be a proper DRI one, but rather some sw contraption. can you, please, check if the string "DRI" can be found in there? another string to look for is "Tungsten".

ps: i don't have access to an atom board anymore either.

Sorry, guys, this was my mistake, I've missed some strings. I've updated list above and it should be more complete.


Both 'Tungsten Graphics, Inc.' and abundance of calls prefixed with 'dri' are present.

*bosbeetle grabs popcorn

I've posted on the other board, that you need someone with an atom-device. I hope someone helps.

Thanks gerd, but I think I need it locally... I was thinking about remote-debugging driver, since I use kernel-mode WinDbg often - this way should be faster than the alternatives.

So far I only read 2 pages of this thread, but let me just say YES

don't let the man keep you down!

Having those drivers open source would be awesome