| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
NOTE: untested, needs a testing tool!
|
|
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.
|
|
s/kms/drm/, s/kdpy/drmdpy/, and so forth.
|
|
The main use of the backend is to support EGL_MESA_drm_display. drm
should be a better name.
|
|
The modeset code supports now obsolete EGL_MESA_screen_surface. Move it
to a file of its own.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
Signed-off-by: Jakob Bornecrantz <wallbraker@gmail.com>
|
|
Signed-off-by: Jakob Bornecrantz <wallbraker@gmail.com>
|
|
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.
|
|
|
|
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)
|
|
If the caller requests a GLES context, don't silently create
a desktop GL context in its place.
|
|
|
|
Free the buffers before the visuals. Fixes valgrind warning
reported in fd.o bug 29919.
|
|
|
|
|
|
|
|
It should be called DRM backend now.
|
|
When the kernel driver name is radeon, ask the loader for r300 or r600
depending on the PCI ID.
|
|
|
|
Make st/wgl include only main/core.h from core mesa.
|
|
Make st/glx include only main/core.h from core mesa.
|
|
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.
|
|
With this change, xmesa_get_window_size still does one round trip, but
that's better than doing two.
|
|
Try to eliminate some unnecessary X server round trips.
|
|
|
|
|
|
Add new source files to SConscripts.
|
|
The extension is implemented by pipe_fence_handle.
|
|
The extension is implemented by pipe_condvar.
|
|
|
|
This is based on a patch by nobled <nobled@dreamwidth.org> and allows the TFP
extension to be enabled for DRISW also. This patch does not enable TFP for DRISW
though, because testing on xephyr segfaults here (for both classic and gallium):
Program received signal SIGSEGV, Segmentation fault.
0x00786a4a in _mesa_GenTextures (n=1, textures=0xbfffee4c) at main/texobj.c:788
788 ASSERT_OUTSIDE_BEGIN_END(ctx);
(gdb)
(gdb) where
\#0 0x00786a4a in _mesa_GenTextures (n=1, textures=0xbfffee4c) at main/texobj.c:788
\#1 0x0817a004 in __glXDisp_GenTextures ()
\#2 0x08168498 in __glXDispatch ()
\#3 0x0808b6ce in Dispatch ()
\#4 0x08084435 in main ()
The TFP code is generic except for the teximage call. We need to verify that
DRISW correclty implements whatever hook teximage finally calls.
|
|
|
|
|
|
It's easily reproducible with Compiz with its Resize window mode
set to Normal (which is usually not the default mode).
https://bugs.freedesktop.org/show_bug.cgi?id=28658
https://bugs.freedesktop.org/show_bug.cgi?id=29303
This is actually a workaround to prevent Compiz crashes.
Instead, a completely white titlebar might show up during resizing
transparent windows (a rare case).
The underlying cause should be fixed by someone who has more knowledge
about the code. (dri2_drawable_get_buffers should not return NULL)
Acked-By: Jakob Bornecrantz <jakob@vmware.com>
|
|
This allows Mesa EGL to be compiled with eglext.h that does not define
EGL_MESA_screen_surface.
|
|
|
|
|
|
|
|
|
|
This is only compile tested.
|
|
Update u_draw_quad, st/vega, and st/mesa to use pipe_context::draw_vbo.
|
|
|
|
There seem to be a problem with this path and freeglut where
the window wont open if SWRAST_NO_PRESENT is set to true.
|
