| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
buffers."
This reverts commit 4598942b1b88a2a7d5af7febae7e79eedf00e385.
XRGB8888 doesn't work as intended. Revert this for now, and we'll revisit it
for 7.8 or something.
|
|
|
|
| |
Make sure that minimal width, height and depth of texture image is 1.
|
|
|
|
| |
memcpy would give incorrect results if src rowstride != dst rowstride
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This change enabled gallium dri drivers by default under the
configure build system. Xorg drivers are built automaticaly
if a Xorg dev enviroment is installed and the Xorg version
is higher then 1.6.0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using a hack in the configure script the gallium intel
drivers have 3 options. Off, nothing is built. On, the
driver and binaries are built. Auto, only the driver but
not the binaries and winsys is built.
Since the i915g driver builds everywhere its can enable
the driver per default, so we can get build coverage.
But building the binaries per default is a pain for
distributions and testers since they conflict on the
install target with the old mesa drivers. Which are more
stable/faster/better.
So this change gives us the best of both worlds.
|
|
|
|
| |
Fixes #21501
|
|
|
|
| |
Fixes #25355
|
|\
| |
| |
| |
| | |
Conflicts:
src/mesa/main/version.h
|
| |
| |
| |
| |
| |
| | |
fixes fdo bug 25354
Signed-off-by: Alex Deucher <[email protected]>
|
| |
| |
| |
| | |
(cherry picked from commit 2c307c775018e5b9680de8022ddf0ce3b6f560be)
|
| |
| |
| |
| | |
(cherry picked from commit b98db7bf697c3ed6e6df303e9dd66f7ac31eb3e2)
|
| |
| |
| |
| | |
(cherry picked from commit 4b3ec2acf2cc2830b0907e4fb4db8bd1ff4a18e3)
|
| |
| |
| |
| | |
(cherry picked from commit 0d31990b4742eccdf6ae6a3b3e16c81cc863085d)
|
| |
| |
| |
| | |
(cherry picked from commit 7dfea5c0722e9da101805c15b9dd26352816bca9)
|
| |
| |
| |
| | |
(cherry picked from commit d4dc2e30dada1be425e95ba270920db6eb210982)
|
| |
| |
| |
| | |
(cherry picked from commit 43080e40aa0d34423e10f1d50aad15289b2b9aec)
|
| |
| |
| |
| | |
(cherry picked from commit 04442841fb7e9138eb50ff692952ad7e8c3877d8)
|
| |
| |
| |
| |
| |
| | |
Fixes compilation errors on platforms with insufficient older installed
GL headers.
(cherry picked from commit d17af7d1e19e637e29db47bd8f6e3e579760c530)
|
| |
| |
| |
| | |
(cherry picked from commit 4df2f7af5e9b2c00ead92fe0ae49ed8491aef1d0)
|
| |
| |
| |
| | |
(cherry picked from commit a420056750908f7c2f9a7c18b3ab20f04e49711d)
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Borrow an idiom from the GNU build system which can handle `for'
loops over empty lists.
|
| |
| |
| |
| |
| |
| |
| | |
i830 does not (and cannot!) support the any of the non-default
GL_POINT_SPRITE_R_MODE_NV settings. i915 and i965 could, but
currently do not. In both cases it would require mucking about with
the fragment shader.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
By using the hooks st/xorg provides us we can create a driver
specific implementation that uses the svga overlay engines.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
bcbfda71b03303d3f008a6f3cf8cb7d9667bf8d2 left out many blit paths.
This fixes up more of them to get Blender to work again.
Bug #25030.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This will get single buffer, double buffer, and
joint single/double buffer (typical in CAD applications) done right,
at least as far as the frambuffer is concerned.
There are still problems with multiple contexts using the same
framebuffer because st_framebuffer_* calls assume the framebuffer
is bound to a single context.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
state in KMM mode"
This reverts commit 286bf89e5a1fc931dbf523ded861b809859485e2.
This doesn't appear to be correct, regression so revert it.
http://bugs.freedesktop.org/show_bug.cgi?id=25193
|
| |
| |
| |
| | |
This fixes invalid failed assertions when running multi-threaded apps.
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
progs/util/shaderutil.c
src/mesa/drivers/dri/r600/r600_context.c
src/mesa/main/version.h
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Support still isn't completely correct, but it's better. piglit
point-sprite now passes. However, glean's pointSprite test fails. In
that test the texture on the sprite is somehow inverted as though
GL_POINT_SPRITE_COORD_ORIGIN were set to GL_LOWER_LEFT. i915 hardware
shouldn't be able to do that!
I believe there are also problems when not all texture units have
GL_COORD_REPLACE set. The hardware enable seems to be all or nothing.
Fixes bug #25313.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This enum is only supported for OpenGL 2.0. If a driver supports
OpenGL 1.4 and GL_ARB_point_sprite, using this enum should generate an
error. This is important because, for example, i915 and i830 can
support GL_ARB_point_sprite, but they cannot support
GL_POINT_SPRITE_COORD_ORIGIN.
This commit just removes the check for NV_point_sprite, which is
completely wrong, and add some comments describing what the code
should do. I don't see an easy way to check for version >= 2.0 from
inside Mesa. Perhaps we should add an extension
GL_MESA_point_sprite_20 (like Intel's old GL_EXT_packed_pixels_12) to
indicate that this added bit of functionality is available.
Also note that glean's pointSprite test only checks for
GL_ARB_point_sprite before trying to use
GL_POINT_SPRITE_COORD_ORIGIN. Naturally, that fails on
non-2.0 implementations (i.e., Mac OS X on GMA 950).
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Thanks to Intel code which I've just stolen pretty much as usual.
This fixes fdo bug 22851 which is a dri1 regression since rewrite.
Tested by: fpiobaf (Fabio) on #radeon
Signed-off-by: Dave Airlie <[email protected]>
|