| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
The screenConfigs field of __DRIscreen points back to the containing
__GLXscreenConfigs struct. This is a serious abstraction violation; it
assumes that the loader is libGL and that there *is* a __GLXscreenConfigs
type in the loader.
Using the containerOf macro, we can get from the __DRIscreen pointer to
the containing __GLXscreenConfigs struct, at a place in the stack
where the above is a valid assumption. Besides, the __DRI* structs shouldn't
hold state other than the private pointer.
|
| |
|
|
|
|
|
|
| |
__glXinitialize() can't be called with the GLX lock held. Just
pass in the __GLXscreenConfigs pointer so we don't have to look it
up in __GLXdisplayPrivate.
|
|
|
|
|
|
|
|
|
|
| |
As for createDrawable and destroyDrawable, these functions immediately
upon entry to driCreateNewContext and immediately before exit from
driDestroyContext. Instead of passing function pointers back and forth
just obtain the drm_context_t prior to calling DRIscreen::createNewContext
and pass it as a parameter.
This change also lets us keep the DRI context XID in the libGL loader only.
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the DRI driver did was call the createDrawable callback immediately
upon entry to DRIscreen::createNewDrawable to get the drm_drawable_t.
We can just call that before calling into the DRI driver and pass the
returned drm_drawable_t as an argument to the DRI entry point.
Likewise for destroyDrawable.
Also, DRIdrawablePrivate::draw isn't used anywhere, and since the
driver no longer needs the XID of the drawable we can now drop that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many DRI entry points took a __DRInativeDisplay pointer and a screen
index as arguments. The only use for the native display pointer was to
pass it back to the loader when looking up the __DRIscreen for the given
screen index.
Instead, let's just pass in the __DRIscreen pointer directly, which
let's drop the __DRInativeDisplay type and the getScreen function.
The assumption is now that the loader will be able to retrieve context
from the __DRIscreen pointer when necessary.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
In the process, fix some alignment issues:
- Scratch space allocation was aligned into units of 1KB, while the allocation
wanted units of bytes, so we never allocated enough space for scratch.
- GRF register count was programmed as ALIGN(val - 1, 16) / 16 instead of
ALIGN(val, 16) / 16 - 1, which overcounted for val != 16n+1.
|
|
|
|
| |
This is in preparation for 965 TTM.
|
| |
|
|
|
|
|
| |
OUT_BATCH is far more amenable to the upcoming relocations being done for TTM
support.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Implementation guidance by Michel Dänzer, final testing by Timo Aaltonen.
|
| |
|
|
|
|
|
| |
EXT_blend_logic_op is slightly different from GL 1.1's RGBA logicop mode
and does not have to be supported. Per conversation with Roland.
|
|
|
|
|
| |
This field shouldn't have been renamed in the first place. Go back to using
the old name so that the tree is backward and forward compatible again.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit b2f1aa2389473ed09170713301b042661d70a48e.
Somehow I ended up with my branch's save-this-while-I-work-on-master commit
actually on master.
|
| |
|
|
|
|
|
| |
This code existed to dump logs of hardware access to be replayed in simulation.
Since we have real hardware now, it's not really needed.
|
| |
|
| |
|
| |
|
|
|
|
| |
max depth buffer value on 64bit system. fix bug #12095
|
| |
|
| |
|
|
|
|
|
| |
component with the largest absolute value before they are
delivered. fix bug #12421
|
|
|
|
| |
fd.o bug #12132
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
This branch replaces the DRM pool interface used by i915tex with a "dri_bufmgr"
interface in dri/common which may be set up to use either TTM or traditional
static memory management according to what is available. The i915tex TTM
code now requires an updated DDX which provides proper buffer objects for the
static front/back/depth, instead of using fake buffers. The driver is now
built as i915_dri.so, and should replace the old i915 driver shortly.
|
| |
| |
| |
| |
| | |
While here, remove the unnecessary fence type saving for the wait ioctl, as
a 0 argument for type means "use your other saved copy".
|
| |
| |
| |
| |
| |
| | |
Otherwise, for multiple references by the batchbuffer, the kernel would see
the buffer already on the unfenced list and wait for it to leave the list
before continuing, leading to hanging and eventual -EBUSY.
|
| | |
|
| | |
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/mesa/drivers/dri/common/dri_drmpool.c
src/mesa/drivers/dri/i915tex/i915_vtbl.c
src/mesa/drivers/dri/i915tex/intel_batchbuffer.c
src/mesa/drivers/dri/i915tex/intel_context.c
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
This removes the use of fake buffers from the driver, such that it could
probably be removed from the interface. It also should assist in proper
synchronization of access.
|