Androïd/x86 port of Mesa drivers https://git.hiegel.fr/cgit/android-x86-mesa.git/atom?h=froyo-x86 2011-03-24T19:30:43Z 2011-03-24T19:30:43Z Chia-I Wu olvaffe@gmail.com 2011-03-19T13:20:49Z urn:sha1:f84d94632227ace654d3f9e7e0e4a686ef906483 2011-03-16T12:18:40Z Chia-I Wu olv@lunarg.com 2010-10-11T08:07:09Z urn:sha1:9a3759c3ddeee2ba4b2215074df3d21d24e65c5c 2011-03-06T09:10:03Z José Fonseca jose.r.fonseca@gmail.com 2011-03-06T09:10:03Z urn:sha1:5e1b31066b44713971e2770b3c8fe9e5eea286bf 2011-02-11T00:07:25Z Marek Olšák maraeo@gmail.com 2010-12-23T09:40:54Z urn:sha1:6ccab620a0e7364ab6c0d902b3ddf58ee988f7fa Based on Dave's branch. The majority of this commit is a cleanup, mainly renaming things. There wasn't much code to import, just ioctl calls. Also done: - implemented unsynchronized bo_map (important optimization!) - radeon_bo_is_referenced_by_cs is no longer a refcount hack - dropped the libdrm_radeon dependency I'm surprised that this has resulted in less code in the end. 2011-02-07T13:01:16Z Benjamin Franzke benjaminfranzke@googlemail.com 2011-02-04T11:32:05Z urn:sha1:381ea0d67a6d84a34d23571c49bbf4339ffda364 2011-01-31T18:17:10Z Kenneth Graunke kenneth@whitecape.org 2011-01-24T18:35:48Z urn:sha1:8aac5d123c4636fad5e9d70c3a6706aaa6f1f240 2011-01-25T15:32:32Z Roland Scheidegger sroland@vmware.com 2011-01-25T15:32:32Z urn:sha1:7acb98c67c680a0c8fb24a28d215622f396531a2 2011-01-22T03:59:05Z Chia-I Wu olv@lunarg.com 2011-01-14T09:50:29Z urn:sha1:bb770af3a59e5935c108c05ee45490fc5668d4a3 GLES can be enabled by running scons with $ scons gles=yes When gles=yes is given, the build is changed in three ways. First, libmesa.a will be built with FEATURE_ES1 and FEATURE_ES2. This makes DRI drivers and libEGL support and advertise GLES support. Second, GLES libraries will be created. They are libGLESv1_CM, libGLESv2, and libglapi. Last, libGL or opengl32 will link to libglapi. This change is required as _glapi_* will be declared as __declspec(dllimport) in libmesa.a on windows. libmesa.a expects those symbols to be defined in another DLL. Due to this change to GL, GLES support is marked experimental. Note that GLES requires libxml2-python to generate some of its sources. 2011-01-20T20:37:26Z Brian Paul brianp@vmware.com 2011-01-20T20:32:35Z urn:sha1:4ef955a12a526dcad388133b6dc8426a51054cdd The loop to choose a pixel format for the window was incrementing 'i' after we succeeded in creating the window so if we chose format[0] for graw_create_window_and_screen() we were putting format[1] in the pipe_resource template for creating the render target. This only worked because of the order of the elements in the formats[] array. The graw_xlib.c code now properly compares the requested gallium pixel format against the visual's color layout. Update all the graw demos to fix the off-by-one-i error. 2011-01-20T09:15:50Z Chia-I Wu olv@lunarg.com 2010-12-26T10:24:13Z urn:sha1:e8c7d7598fb48237508f566204c71ba8f74d544f When --enable-shared-glapi is specified, libGL will share libglapi with OpenGL ES instead of defining its own copy of glapi. This makes sure an app will get only one copy of glapi in its address space. The new option is disabled by default. When enabled, libGL and libglapi must be built from the same source tree and distributed together. This requirement comes from the fact that the dispatch offsets used by these libraries are re-assigned whenever GLAPI XMLs are changed. For GLX, indirect rendering for has_different_protocol() functions is tricky. A has_different_protocol() function is assigned only one dispatch offset, yet each entry point needs a different protocol opcode. It cannot be supported by the shared glapi. The fix to this is to make glXGetProcAddress handle such functions specially before calling _glapi_get_proc_address. Note that these files are automatically generated/re-generated src/glx/indirect.c src/glx/indirect.h src/mapi/glapi/glapi_mapi_tmp.h