| Age | Commit message (Collapse) | Author |
|---|
|
This moves a big chunk of the space checking code into libdrm so
it can be shared by the DDX.
|
|
half stealing the code without taking the intel regions
|
|
Tested with glean/texture_srgb and wine/d3d9 tests on RV535
|
|
In r300SetTexBuffer2(), if the passed in text glx_texture_format
is GLX_TEXTURE_FORMAT_RGB_EXT, then we should use an RGB-only
texture format, even if the DRI buffer has four channels.
https://bugs.freedesktop.org/show_bug.cgi?id=21609
|
|
Fixes piglit/texdepth
|
|
|
|
this make gnome shell run
|
|
This fixes up the buffer validation scheme, so that we keep a list
of buffers to validate so cmdbuf flushes during a pipeline get
all the buffers revalidated on the next emit.
This also fixes radeonFlush to not flush unless we have something
useful to send to the GPU, like a DMA buffer or something not state
|
|
This might trip up some serious FBO users, will have to see, but
it avoids the slow paths for all the demos I have.
|
|
|
|
also fixup old interface, gets rid of white boxes in compiz
|
|
|
|
this is a step towards fbos and should fix pageflipping, but
I think the first flip seems broken.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This merges lots of the hw state atom emission and firevertices code.
it also removes a lot of the extra radeon crap from r300
and merge scissor
|
|
This fixes a few regression in piglit, and adds some debug to the mipmap code
|
|
|
|
we now get texrect + trivial textures working
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This abstract memory management and command stream building so we
can use different backend either legacy one which use old pathway
or a new one like with a new memory manager. This works was done by :
Nicolai Haehnle
Dave Airlie
Jerome Glisse
|
|
Makefile.template
|
|
|
|
|
|
The texture layout calculations for mipmapped cubemaps used to be completely
wrong, since the GPU expects images to be grouped by miplevel instead of by
face number.
This has been fixed now, though the memory layout is still slightly incorrect
for the smaller miplevels. Unfortunately, the docs are lacking in that area.
|
|
This variable was only ever written to, but nobody used its value.
|
|
|
|
|
|
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.
|
|
|
|
Currently only GL_DEPTH_COMPONENT16 are supported. I don't know what the
hardware bits are to select the other formats, but it shouldn't be too hard
to figure out.
|
|
|
|
This was broken by the unification of the texture format table.
|
|
|
|
|
|
I think this is correct, assuming no endian issues. See commmit
59a08923f51d4ed83effbfcd91473c9ee86465f1.
|
|
|
|
|
|
|
|
|
