summaryrefslogtreecommitdiffstats
path: root/src/gallium/state_trackers
Commit message (Collapse)AuthorAgeFilesLines
* dri: Pass the __DRIscreen and the __DRIscreen private back to image lookupKristian Høgsberg2010-09-224-13/+11
| | | | | We will typically have a current context when we need to lookup the image, but the lookup implementation don't need it so drop it.
* d3d1x: add Wine dlls (tri, tex working, but no other testing)Luca Barbieri2010-09-2216-0/+386
|
* d3d1x: define GUIDs in the normal wayLuca Barbieri2010-09-223-16/+0
|
* d3d1x: fix API nameLuca Barbieri2010-09-221-1/+1
|
* d3d1x: redesign the HWND resolver interfaceLuca Barbieri2010-09-225-105/+250
| | | | This one should be powerful enough to hook up Wine.
* d3d1x: fix GUID declarationsLuca Barbieri2010-09-221-4/+5
|
* d3d1x: destroy native_display on adapter destructionLuca Barbieri2010-09-221-0/+1
|
* dri2: Make createImageFromName() take a __DRIscreen instead of __DRIcontextKristian Høgsberg2010-09-221-2/+2
| | | | | | | We can't expect to have a context when this is called, and we don't need one so just require a __DRIscreen instead. Reported by Yu Dai <[email protected]>
* d3d1x: fix segfault when hashingLuca Barbieri2010-09-221-1/+1
|
* d3d1x: fix warningLuca Barbieri2010-09-221-1/+1
|
* d3d1x: fix cf analysisLuca Barbieri2010-09-221-1/+1
|
* d3d1x: link with CXXFLAGSLuca Barbieri2010-09-221-1/+1
| | | | Otherwise, -m32 doesn't make it there.
* d3d1x: add missing memory barrierLuca Barbieri2010-09-221-2/+6
|
* d3d1x: don't build progs automaticallyLuca Barbieri2010-09-221-1/+1
| | | | | | | | | | progs requires winsys, which hasn't yet been built by the time we go into state_trackers. It may be a good idea to also move it into tests. After a normal build, run make in src/gallium/state_trackers/d3d1x/progs to build them.
* glx: decouple dri2.c and GLX, fixing Gallium EGL and d3d1x buildLuca Barbieri2010-09-221-0/+11
| | | | | | | | | | | | | | | The Gallium EGL state tracker reuses dri2.c but not the GLX code. Currently there is a bit of code in dri2.c that is incorrectly tied to GLX: instead, make it call an helper that both GLX and Gallium EGL implement, like dri2InvalidateBuffers. This avoids a link error complaining that dri2GetGlxDrawableFromXDrawableId is undefined. Note that we might want to move the whole event translation elsewhere, and probably stop using non-XCB DRI2 altogether, but this seems to be the minimal fix.
* d3d1x: attempt to fix/workaround bug #30322Luca Barbieri2010-09-221-1/+1
| | | | | | | | | This may just be hiding some other bug though, since the types are supposed to be the same (and it compiles for me). Anyway, this interface will likely need to changed, since it seems Wine needs a more powerful one capable of expressing window subregions and called at every Present.
* d3d1x: ignore errors while building docsLuca Barbieri2010-09-211-0/+1
| | | | Some versions of dot apparently lack pdf output.
* d3d1x: fix GCC 4.1/4.2 buildLuca Barbieri2010-09-211-1/+11
|
* d3d1x: add template parameters to base class ctor calls for GCC 4.4Luca Barbieri2010-09-214-18/+20
| | | | | GCC 4.5 is fine without them, but GCC 4.4 requires them. Should fully fix the build on GCC 4.4
* d3d1x: fix build with compilers other than GCC 4.5Luca Barbieri2010-09-211-7/+33
| | | | | | There was some libstdc++-specific code that would only build with GCC 4.5 Now it should be much more compatible, at the price of reimplementing the generic hash function.
* d3d1x: actually enable and fix blob apisLuca Barbieri2010-09-212-6/+7
|
* d3d1x: add missing fileLuca Barbieri2010-09-211-0/+87
|
* d3d1x: fix compilation with recent Wine versions installedLuca Barbieri2010-09-211-1/+1
| | | | | | | Recent Wine versions provide a d3d11shader.h, which is however empty and was getting used instead of our non-empty one. Correct the include path order to fix this.
* d3d1x: add blob and signature extraction APIsLuca Barbieri2010-09-217-13/+116
| | | | NOTE: untested, needs a testing tool!
* d3d1x: add new Direct3D 10/11 COM state tracker for GalliumLuca Barbieri2010-09-21108-0/+26335
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a new implementation of the Direct3D 11 COM API for Gallium. Direct3D 10 and 10.1 implementations are also provided, which are automatically generated with s/D3D11/D3D10/g plus a bunch of #ifs. While this is an initial version, most of the code is there (limited to what Gallium can express), and tri, gears and texturing demos are working. The primary goal is to realize Gallium's promise of multiple API support, and provide an API that can be easily implemented with just a very thin wrapper over Gallium, instead of the enormous amount of complex code needed for OpenGL. The secondary goal is to run Windows Direct3D 10/11 games on Linux using Wine. Wine dlls are currently not provided, but adding them should be quite easy. Fglrx and nvidia drivers can also be supported by writing a Gallium driver that talks to them using OpenGL, which is a relatively easy task. Thanks to the great design of Direct3D 10/11 and closeness to Gallium, this approach should not result in detectable overhead, and is the most maintainable way to do it, providing a path to switch to the open Gallium drivers once they are on par with the proprietary ones. Currently Wine has a very limited Direct3D 10 implementation, and completely lacks a Direct3D 11 implementation. Note that Direct3D 10/11 are completely different from Direct3D 9 and earlier, and thus warrant a fully separate implementation. The third goal is to provide a superior alternative to OpenGL for graphics programming on non-Windows systems, particularly Linux and other free and open systems. Thanks to a very clean and well-though design done from scratch, the Direct3D 10/11 APIs are vastly better than OpenGL and can be supported with orders of magnitude less code and development time, as you can see by comparing the lines of code of this commit and those in the existing Mesa OpenGL implementation. This would have been true for the Longs Peak proposal as well, but unfortunately it was abandoned by Khronos, leaving the OpenGL ecosystem without a graphics API with a modern design. A binding of Direct3D 10/11 to EGL would solve this issue in the most economical way possible, and this would be great to provide in Mesa, since DXGI, the API used to bind Direct3D 10/11 to Windows, is a bit suboptimal, especially on non-Windows platforms. Finally, a mature Direct3D 10/11 implementation is intrinsically going to be faster and more reliable than an OpenGL implementation, thanks to the dramatically smaller API and the segregation of all nontrivial work to object creation that the application must perform ahead of time. Currently, this commit contains: - Independently created headers for Direct3D 10, 10.1, 11 and DXGI 1.1, partially based on the existing Wine headers for D3D10 and DXGI 1.0 - A parser for Direct3D 10/11 DXBC and TokenizedProgramFormat (TPF) - A shader translator from TokenizedProgramFormat to TGSI - Implementation of the Direct3D 11 core interfaces - Automatically generated implementation of Direct3D 10 and 10.1 - Implementation of DXGI using the "native" framework of the EGL st - Demos, usable either on Windows or on this implementation - d3d11tri, a clone of tri - d3d11tex, a (multi)texturing demo - d3d11gears, an improved version of glxgears - d3d11spikysphere, a D3D11 tessellation demo (currently Windows-only) - A downloader for the Microsoft HLSL compiler, needed to recompile the shaders (compiled shader bytecode is also included) To compile this, configure at least with these options: --with-state-trackers=egl,d3d1x --with-egl-platforms=x11 plus some gallium drivers (such as softpipe with --enable-gallium-swrast) The Wine headers (usually from a wine-dev or wine-devel package) must be installed. Only x86-32 has been tested. You may need to run "make" in the subdirectories of src/gallium/winsys/sw and you may need to manually run "sudo make install" in src/gallium/targets/egl To test it, run the demos in the "progs" directory. Windows binaries are included to find out how demos should work, and to test Wine integration when it will be done. Enjoy, and let me know if you manage to compile and run this, or which issues you are facing if not. Using softpipe is recommended for now, and your mileage with hardware drivers may vary. However, getting this to work on hardware drivers is also obviously very important. Note that currently llvmpipe is buggy and causes all 3 gears to be drawn with the same color. Use export GALLIUM_DRIVER=softpipe to avoid this. Thanks to all the Gallium contributors and especially the VMware team, whose work made it possible to implement Direct3D 10/11 much more easily than it would have been otherwise.
* st/egl: s/kms/drm/ on the drm backend.Chia-I Wu2010-09-193-303/+303
| | | | s/kms/drm/, s/kdpy/drmdpy/, and so forth.
* st/egl: Rename kms backend to drm.Chia-I Wu2010-09-196-19/+19
| | | | | The main use of the backend is to support EGL_MESA_drm_display. drm should be a better name.
* st/egl: Split modeset code support to modeset.c.Chia-I Wu2010-09-193-587/+647
| | | | | The modeset code supports now obsolete EGL_MESA_screen_surface. Move it to a file of its own.
* st/xlib: Notify the context when the front/back buffers are swapped.Chia-I Wu2010-09-163-4/+21
| | | | | | | | The current context should be notified when the the front/back buffers of the current drawable are swapped. The notification was skipped when xmesa_strict_invalidate is false (the default). This fixes fdo bug #29774.
* st/egl: Use profiles to create OpenGL ES contexts.Chia-I Wu2010-09-104-48/+26
| | | | | | | Replace all uses of ST_API_OPENGL_ES{1,2} by profiles. Having 3 st_api's to provide OpenGL, OpenGL ES 1.1, and OpenGL ES 2.0 is not a sane abstraction, since all of them share glapi for current context/dispatch management.
* st/dri: Use profiles to create OpenGL ES contexts.Chia-I Wu2010-09-104-46/+14
| | | | | | Having 3 st_api's to provide OpenGL, OpenGL ES 1.1, and OpenGL ES 2.0 is not a sane abstraction, since all of them share glapi for current context/dispatch management.
* gallium: Add context profile support to st_api.Chia-I Wu2010-09-105-9/+50
| | | | | | | | | | | | | | | Add struct st_context_attribs to describe context profiles and attributes. Modify st_api::create_context to take the new struct instead of an st_visual. st_context_attribs can be used to support GLX_ARB_create_context_profile and GLX_EXT_create_context_es2_profile in the future. But the motivation for doing it now is to be able to replace ST_API_OPENGL_ES1 and ST_API_OPENGL_ES2 by profiles. Having 3 st_api's to provide OpenGL, OpenGL ES 1.1, and OpenGL ES 2.0 is not a sane abstraction, since all of them share glapi for current context/dispatch management.
* st/dri: support EGL_MESA_image_drm: queryImageben2010-09-091-0/+30
| | | | Signed-off-by: Jakob Bornecrantz <[email protected]>
* st/dri: support EGL_MESA_image_drm: createImageben2010-09-091-0/+58
| | | | Signed-off-by: Jakob Bornecrantz <[email protected]>
* st/dri: Call dri_init_extensions only for API_OPENGL.Chia-I Wu2010-09-081-1/+9
| | | | | | | | libmesagallium.a that this state tracker will be linked to expects OpenGL's _glapi_table. That is, it expects libGL.so instead of libGLESv1_CM.so or libGLESv2.so. As there is no clean way to know the shared library the app links to, use the api as a simple check. It might be as well to simply remove this function call though.
* st/dri: Use enum st_api_type internally.Chia-I Wu2010-09-085-27/+39
|
* st/dri: Add multi-api supportnobled2010-09-085-13/+46
| | | | | | | | | | Make st/dri screens capable of creating OpenGL ES and OpenGL ES2 contexts. TODO: Figure out the "get_current" problem with multiple st_api's for real. (s/API_OPENGLES1/API_OPENGLES/ by Chia-I Wu)
* st/dri: Make clear which API's are supportednobled2010-09-081-1/+4
| | | | | If the caller requests a GLES context, don't silently create a desktop GL context in its place.
* st/glx: added some commentsBrian Paul2010-09-031-0/+8
|
* st/glx: re-order destruction of buffers, visualsBrian Paul2010-09-011-1/+1
| | | | | Free the buffers before the visuals. Fixes valgrind warning reported in fd.o bug 29919.
* st/egl: Enable EGL_MESA_drm_display.Chia-I Wu2010-08-311-1/+3
|
* st/egl: Add support for EGL_MESA_image_drm.Chia-I Wu2010-08-264-0/+260
|
* st/egl: Add support for EGL_KHR_surfaceless_*.Chia-I Wu2010-08-262-9/+16
|
* st/egl: Make KMS support optional in KMS backend.Chia-I Wu2010-08-261-22/+24
| | | | It should be called DRM backend now.
* st/egl: Fix r300/r600 support in KMS backend.Chia-I Wu2010-08-242-3/+32
| | | | | When the kernel driver name is radeon, ask the loader for r300 or r600 depending on the PCI ID.
* st/dri: Remove unnecessary main/mtype.h.Chia-I Wu2010-08-241-1/+0
|
* st/wgl: Include main/core.h.Chia-I Wu2010-08-244-7/+3
| | | | Make st/wgl include only main/core.h from core mesa.
* st/glx: Include main/core.h.Chia-I Wu2010-08-245-21/+38
| | | | Make st/glx include only main/core.h from core mesa.
* glx/xlib: configurable strict/non-strict buffer size invalidateKeith Whitwell2010-08-223-4/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new configuration option XMESA_STRICT_INVALIDATE to switch between swapbuffers-based and glViewport-based buffer invalidation. Default strict invalidate to false, ie glViewport-based invalidation, aka ST_MANAGER_BROKEN_INVALIDATE. This means we will not call XGetGeometry after every swapbuffers, which allows swapbuffers to remain asynchronous. For apps running at 100fps with synchronous swapping, a 10% boost is typical. For gears, I see closer to 20% speedup. Note that the work of copying data on swapbuffers doesn't disappear - this change just allows the X server to execute the PutImage asynchronously without us effectively blocked until its completion. This applies even to llvmpipe's threaded rasterization as the swapbuffers operation was a large part of the serial component of an llvmpipe frame. The downside of this is correctness - applications which don't call glViewport on window resizes will get incorrect rendering, unless XMESA_STRICT_INVALIDATE is set. The ultimate solution would be to have per-frame but asynchronous invalidation. Xcb almost looks as if it could provide this, but the API doesn't seem to quite be there.
* glx/xlib: remove another XSyncKeith Whitwell2010-08-221-1/+0
| | | | | With this change, xmesa_get_window_size still does one round trip, but that's better than doing two.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-20 08:47:06 +0000