| Age | Commit message (Collapse) | Author |
|---|
|
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 0bba0e5be7a4a7275dad1edc34bdcc134ea1f424 to pass in the
event buffer head index on drawable creation.
|
|
__dri2ParseEvents() would determine the kind of event, but then call
UpdateBuffer() in either case, and UpdateBuffer() would then have to
figure that out again to dispatch to HandleBufferAttach() or
HandleDrawableConfig(). Pretty pointless.
|
|
Makes a lot more sense, since the screen is always implicit in the
DRI drawable, but it may not be possible to track down a context from
just a drawable.
|
|
The DRI driver needs to know where in the buffer to start reading.
|
|
regression)
|
|
|
|
|
|
|
|
|
|
After commit 6fd82f6fbd208dc7b1839ea408a5fb28589ee622, we would
overwrite the libPath default value with NULL if libGL was running
non-setuid and none of the env vars were set.
Thanks to Magnus Kessler <Magnus.Kessler@gmx.net> for spotting it.
|
|
|
|
|
|
|
|
Also drop isDirect flag; if gc->driContext is non-NULL, it's direct.
|
|
|
|
Temporarily rename the __DRIscreen member to __driScreen. Eventually,
we'll move that into __GLXDRIscreen and only access it in dri_glx.c.
|
|
|
|
We avoid leaking the symbols and will be able to replace them with
DRI2 implementation later on.
|
|
This patch moves __DRIdisplayPrivateRec definition into dri_glx.c and
let's dri_glx.c allocate the __DRIdisplay struct pointer to from
__GLXdisplayPrivate.
A small step towards moving more of the dri functionality into dri_glx.c.
|
|
|
|
|
|
|
|
No need to jump through hoops to track __DRIdrivers and avoid dlopening the
same .so more than twice, dlopen() does this internally. Besides, we
were already bypassing this and dlopening drivers for each screen,
whether or not they were already dlopened.
|
|
Move a lot of code over from glx_ext.c.
|
|
Rather than constructing the GCC include path from `-print-search-dirs',
we can get the path directly from `-print-file-name=include'. This is
used in the Linux kernel build, for example. If no output is returned
from the command, then we don't append a -I path the the makedepend
options.
|
|
Fixes #14799.
|
|
1. Follow EXT_texture_rectangle with YCbCr texture
2. swap UV component for MESA_FORMAT_YCBCR
|
|
|
|
|
|
is created with mode GLUT_SINGLE|GLUT_RGB|GLUT_DEPTH.
This issue is introduced by 20b8bff49cba3e8246e29004c5ff38f231d589ff
|
|
This is defaulted off as it has potentially large memory costs for a modest
performance gain. Ideally we will improve DRM performance to the point where
this optimization is not worth the memory cost in any case, or find some
middle ground in caching only limited numbers of certain buffers. For now,
this provides a modest 4% improvement in openarena on GM965 and 10% in openarena
on GM945.
|
|
|
|
|
|
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.
|
|
This also fixes the problem where the X server does multiple resizes before
the DRI driver gets the events. The obsolete buffer attach events then
reference already destroyed buffer objects.
|
|
|
|
|
|
|
|
|
|
|
|
Instead of passing in a fixed struct, the loader now passes in a list
of __DRIextension structs, to advertise the functionality it can provide
to the driver. Each extension is individually versioned and can be
extended or phased out as the interface develops.
|
|
Right now the DRI2 screen constructor takes 3 different versions:
DRI, DDX and DRM. This is mostly useless, though:
DRI: The DRI driver doesn't actually care about the DRI protocol,
it only talks to the loader, which in turn speaks DRI protocol. Thus,
the DRI protocol version is of not interest to the DRI driver, but it
needs to know what functionality the loader provides. At this point
that's reflected in the __DRIinterfaceMethods struct and the
internal_version integer.
DDX: The DDX version number is essentially used to track extensions
to the SAREA. With DRI2 the SAREA consists of a number of versioned,
self-describing blocks, so the DDX version is no longer interesting.
DRM: We have the fd, lets just ask the kernel ourselves.
|
|
Another regression from the intel_context.c merge.
|
|
fix double free issue(bug#14710). It also corrects glsl/bitmap demo behavior.
|
|
Previously the frame_buffer_texobj case would have been bound as a normal
texture, at best resulting in no surface data being associated with it.
|
|
Otherwise, we would assertion error when doing the final unreference of the
buffer with an outstanding map (catching the memory leak).
|
|
These changes are taken from the xf86-video-ati driver. They update the header
file accordingly and also remove some UNKOWN variables.
|
|
|
|
|
|
|
