| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Now trace always built.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This avoids exposing the ms driver structure to the winsys,
and nicely encapsulates driver customizable stuff.
In the future more things might be customizable by the winsys, like
throttling, 3D readback etc.
Signed-off-by: Thomas Hellstrom <[email protected]>
|
| |
|
|
|
|
| |
Set it to the same as 2d acceleration
|
|
|
|
| |
Signed-off-by: Thomas Hellstrom <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to the changes to reduce the round-trips in ximage
backend.
When the server supports DRI_InvalidateBuffers, the event is used to
update the server stamp (this path is not tested). Otherwise, the
server stamp is updated when flush_frontbuffer or swap_buffers is
called. This makes sure at least the client APIs get the new buffers
when a new frame is started while skipping all round-trips during the
drawing.
|
|
|
|
|
|
|
|
|
|
|
| |
ximage_surface_validate is called several times per frame. This commit
adds the client and server stamps to reduce the round-trips to the
server. The idea is to bump the server stamp when flush_frontbuffer or
swap_buffers is called, and to skip the round-trip when the client stamp
is equal to the server stamp. This makes sure the client APIs get the
new buffers when a new frame is started while skipping all round-trips
during the drawing. To make this work, egl_g3d_validate_context is no
longer called after swap_buffers.
|
|
|
|
|
| |
Add dri2_surface_process_drawable_buffers to process the buffers
returned by the server.
|
|
|
|
|
|
| |
src/glx/dri2.c will call dri2InvalidateBuffers when
DRI2_InvalidateBuffers event is received. This fixes a missing symbol
error, and paves the way for event-based validation.
|
|
|
|
|
| |
Actually ask the gallium screen what Z/stencil format is supported.
This will let us remove some hacks in the llvmpipe driver.
|
| |
|
|
|
|
|
| |
Add a new function egl_g3d_create_surface and use it to create window,
pixmap, buffer, and screen surfaces.
|
|
|
|
|
|
| |
With pipe_screen::update_buffer being called in st_validate_state, it is
likely that softpipe will flush tile caches to a detached SHM segment.
Disable SHM for now until a better solution is found.
|
|
|
|
|
| |
Some kernels have vrefresh = (refresh rate * 1000) while others don't.
Use some heuristics here.
|
|
|
|
|
|
|
| |
Configs are validated before added. The validation depends on the
extensions available. If configs are added before enabling extensions,
configs with EGL_SCREEN_SURFACE_MESA bit set will never pass the
validation for example.
|
|
|
|
|
| |
st/mesa was changed to call pipe_screen::update_buffer in
st_validate_state. In most cases there is no need to validate.
|
|
|
|
|
| |
Mainly to move the call to DRI2GetBuffers from dri2_surface_validate to
the new dri2_surface_update_buffers.
|
|
|
|
|
| |
Mainly to move buffer allocation code from ximage_surface_validate to
the new ximage_surface_update_buffers.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This may break the SUNOS4 build, but it's no longer relevant.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
We probably don't want to propagate this condition to the pipe driver,
this reverts commit f455ca6490fcb65781b21f81c7117bd923e250d1 and the
dri_update_buffer flush altogether until an agreement is reached.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My first reading of MS docs was wrong. It says:
All rendering contexts of a shared display list must use an identical
pixel format. Otherwise the results depend on the implementation of
OpenGL used.
That is, it is OK to share contexts with different pixel formats.
Adobe Premiere Pro tries to do that: share lists between a rgbx8 and a
rgba8 pixel format.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
When our DLL is unloaded, even if we leave the data structures in memory
for sake of future calls, the MS CRT will destroy the heap. Instead we
make all calls no-ops by setting stw_dev to NULL.
|
|
|
|
|
| |
without getBuffersWithFormat some visuals will just cause headaches (crashes),
so if we're running on an older system simply don't advertise them.
|
|
|
|
|
|
|
|
| |
we actually need to specify the formats for different attachements, otherwise
if the color buffer is 24bpp and the app asks for 16bpp depth buffer than
we end up fetching the depth from the drawable which is 24bpp and end up
creating the wrong depth buffer. use the new getBuffersWithFormat extension
to pass the depth correctly.
|