Since its not used by anything anymore and no release has gone out
where it was being used.
Tested-by: Scott Moreau <oreaus@gmail.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Unlike 1.x to 2.0, OpenGL ES 3.0 is backwards compatible with 2.0. Use the
same API flag for both. Applications that specifically want 3.0 will specify
this using the major / minor version attributes.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The additions in version 5 enables creating EGLImages for different planes
of a YUV buffer. createImageFromName is still used to create the containing
__DRIimage, and createSubImage can then be used no that __DRIimage to create
__DRIimages that correspond to the y, u, and v planes (__DRI_IMAGE_FORMAT_R8)
or the uv planes (__DRI_IMAGE_FORMAT_RG88) for formats such as NV12 where
the u and v components are interleaved. Packed formats such as YUYV etc
doesn't require any special treatment, we just sample those as a regular
ARGB texture.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Add the infrastructure required for this extension. There is no
xserver support and no driver support yet. Drivers can enable this be
advertising DRI2 version 4 and accepting the
__DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS flag and the
__DRI_CTX_ATTRIB_RESET_STRATEGY attribute in create context.
Some additional Mesa infrastructure is needed before drivers can do
this. The GL_ARB_robustness spec, which all Mesa drivers already
advertise, requires:
"If the behavior is LOSE_CONTEXT_ON_RESET_ARB, a graphics reset
will result in the loss of all context state, requiring the
recreation of all associated objects."
It is necessary to land this infrastructure now so that the related
infrastructure can land in the xserver. The xserver has very long
release schedules, and the remaining Mesa parts should land long, long
before the next xserver merge window opens.
v2: Expose robustness as a DRI2 extension rather than bumping
__DRI_DRI2_VERSION.
v3: Add a comment explaining why dri2->base.version >= 3 is also
required for GLX_ARB_create_context_robustness.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This new gbm entry point allows writing data into a gbm bo. The bo has
to be created with the GBM_BO_USE_WRITE flag, and it's only required to
work for GBM_BO_USE_CURSOR_64X64 bos.
The gbm API is designed to be the glue layer between EGL and KMS, but there
was never a mechanism initialize a buffer suitable for use with KMS
hw cursors. The hw cursor bo is typically not compatible with anything EGL
can render to, and thus there's no way to get data into such a bo.
gbm_bo_write() fills that gap while staying out of the efficient
cpu->gpu pixel transfer business.
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Add new format __DRI_IMAGE_FORMAT_XBGR8888 to __DRI_IMAGE.
HAL_PIXEL_FORMAT_RGBX_8888 now maps to __DRI_IMAGE_FORMAT_XBGR8888.
Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
GBM needs the buffer format in order to communicate with DRM and clients
for things like scanout.
So track the DRI format requested in the various back ends and use it to
return the DRI format back to GBM when requested. GBM will then map
this into the GBM surface type (which is in turn based on the DRM fb
format list).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The X server has limited throttle support on the server side,
but doing this in the client has some benefits:
1) X server throttling is per client. Client side throttling can be done
per drawable.
2) It's easier to control the throttling based on what client is run,
for example using "driconf".
3) X server throttling requires drm swap complete events.
So implement a dri2 throttling extension intended to be used by direct
rendering clients.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Add a new format token, __DRI_IMAGE_FORMAT_ABGR8888, to __DRI_IMAGE. It
maps to MESA_FORMAT_RGBA8888_REV in core mesa or
PIPE_FORMAT_R8G8B8A8_UNORM in gallium. The format is used by
translucent surfaces on Android.
CC: Ian Romanick <idr@freedesktop.org>
CC: Kristian Høgsberg <krh@bitplanet.net>
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad@chad-versace.us>
This new interface could set up context for OpenGL,
OpenGL ES1 and OpenGL ES2. It will be used by egl_dri2
driver.
Signed-off-by: Haitao Feng <haitao.feng@intel.com>
Add release function for texture_from_pixmap extension.
Some platform need to release texture image for texture_from_pixmap
extension, add this interface for those platforms.
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 <yu.dai@intel.com>
The presence of this extension indicates to the DRI driver that the
loader will call invalidate in the __DRI2_FLUSH extension, whenever
the needs to query for new buffers. This means that the DRI driver
can drop the polling in glViewport().
__NOT_HAVE_DRM_H is a like a feature, defined by default on specific platforms
and allows to be defined externally as well.
__NOT_HAVE_DRM_H should only be used by xserver and mesa swrast_dri drivers
When a buffer invalidation event is received from the X server, the
"invalidate" hook of the DRI2 flush extension is executed: A generic
implementation (dri2InvalidateDrawable) is provided that just bumps
the "pStamp" sequence number in __DRIdrawableRec.
For old servers not supporting buffer invalidation events, the
invalidate hook will be called before flushing the fake front/back
buffer (that's typically once per frame -- not a lot worse than the
situation we were in before).
No effort has been made on preserving backwards compatibility with
version 2 of the flush extension, but I think it's acceptable because
AFAIK no released stack is making use of it.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
This used to take GLX tokens, but the DRI interface can't depend on GLX
defines. We fix this by introducing DRI tokens that have the same value
as the GLX texture format tokens.
Support the new DRI2 protocol request, DRI2SwapBuffers, in both direct
and indirect rendering context. This request allows the display server
to optimize back->front swaps (e.g. through page flipping) and allows us
to more easily support other GLX features like swap interval and the OML
sync extension in DRI2.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Here is a couple of fixes for GNU/Hurd:
- dri_interface.h: no libdrm support either.
- configure.ac:
- GNU/Hurd is a GNU OS with _GNU_SOURCE and PTHREADS.
- GNU needs a couple of flags like other OSes
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
This requires upgrading the interface so that the argument to
glXBindTexImageEXT isn't just dropped on the floor. Note that this only
fixes the accelerated path on Intel, as Mesa's texture format support is
missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as a8r8gb8,
but in this case we're not doing the upload so we can't really work around it
that way).
Fixes bugs with compositors trying to use shaders that use alpha channels, on
windows without a valid alpha channel. Bug #19910 and likely others as well.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Add DRI2 direct rendering support to libGL and add DRI2 client side
protocol code. Extend the GLX 1.3 create drawable functions in
glx_pbuffer.c to call into the DRI driver when possible.
Introduce __DRIconfig, opaque struct that represents a DRI driver
configuration. Get's rid of the open coded __GLcontextModes in the
DRI driver interface and the context modes create and destroy
functions that the loader was requires to provide. glcore.h is no
longer part of the DRI driver interface. The DRI config is GL binding
agnostic, that is, not specific to GLX, EGL or other bindings.
The core API is now also an extension, and the driver exports a list
of extensions as the symbol __driDriverExtensions, which the loader
must dlsym() for. The list of extension will always include the DRI
core extension, which allows creating and manipulating DRI screens,
drawables and contexts. The DRI legacy extension, when available,
provides alternative entry points for creating the DRI objects that
work with the XF86DRI infrastructure.
Change DRI2 client code to not use drm drawables or contexts. We
never used drm_drawable_t's and the only use for drm_context_t was as
a unique identifier when taking the lock. We now just allocate a
unique lock ID out of the DRILock sarea block. Once we get rid of the
lock entirely, we can drop this hack.
Change the interface between dri_util.c and the drivers, so that the
drivers now export the DriverAPI struct as driDriverAPI instead of the
InitScreen entry point. This lets us avoid dlsym()'ing for the DRI2
init screen function to see if DRI2 is supported by the driver.
This fixes a problem where texturing from the same Pixmap more than
once per batchbuffer would hang the DRI driver. We just use the region
associated with the front left renderbuffer of the __DRIdrawable for
texturing, which avoids creating different regions for the same BO.
This change also make GLX_EXT_texture_from_pixmap work for direct
rendering, since tracking the __DRIdrawable -> BO handle now uses
the standard DRI2 event buffer. Of course, DRI2 direct rendering
doesn't exist yet.
Finally, this commit bumps the DRI interface version again, accounting
for the change in the DRI_TEX_BUFFER extension and the change in
commit 0bba0e5be7 to pass in the
event buffer head index on drawable creation.
When the DRI doesn't parse the event buffer for a while, the X server
may overwrite data that the driver didn't get a chance to look at. The
reemitDrawableInfo callback requests that the X server reemit all info
for the specified drawable. To make use of this, the drive needs to know
the new tail pointer so it know where to start reading from.