| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
r400 fragment shaders now support up to 64 temporary registers,
512 ALU instructions, and 512 TEX instructions.
|
|
|
|
|
|
|
|
|
|
|
| |
But we have to cheat and peek at the GENERIC semantic indices the
state tracker uses for TEXn.
Only outputs from 0x300 to 0x37c can be replaced, and so we have to
know on shader compilation which ones to put there in order to keep
doing separate shader objects properly.
At some point I'll probably create a patch that makes gallium not
force us to discard the information about what is a TexCoord.
|
| |
|
|
|
|
|
|
| |
We are not required to do the linear->sRGB conversion if ARB_framebuffer_sRGB
is unsupported. However I think the conversion should work in hw except
for blending, which matches the D3D9 behavior.
|
|
|
|
|
| |
The hw can't do it and the code was useless anyway (it's lowered
in the GLSL compiler).
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes negative relative branch offsets.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we read/write image tiles we need to use the format specified
in the pipe_surface, not the pipe_transfer format (which comes from
the underlying texture/resource format).
This comes up when rendering to sRGB surfaces (via OpenGL render to
texture). Ignoring the new GL_ARB/EXT_framebuffer_sRGB extension
for now, when we render to a sRGB surface we need to treat it like
a regular, linear colorspace RGB surface. Before, when we read/wrote
tiles to sRGB surfaces we were inadvertantly doing the color space
conversion.
|
| |
|
|
|
|
| |
Implement it in terms of pipe_get_tile_rgba_format()
|
|
|
|
|
|
| |
The new function, pipe_get_tile_rgba_format(), no longer takes a
swizzle (we weren't actually using it anywhere). Rename it to
indicate that the format is passed explicitly.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLES can be enabled by running scons with
$ scons gles=yes
When gles=yes is given, the build is changed in three ways. First,
libmesa.a will be built with FEATURE_ES1 and FEATURE_ES2. This makes
DRI drivers and libEGL support and advertise GLES support. Second, GLES
libraries will be created. They are libGLESv1_CM, libGLESv2, and
libglapi. Last, libGL or opengl32 will link to libglapi. This change
is required as _glapi_* will be declared as __declspec(dllimport) in
libmesa.a on windows. libmesa.a expects those symbols to be defined in
another DLL. Due to this change to GL, GLES support is marked
experimental.
Note that GLES requires libxml2-python to generate some of its sources.
|
| |
|
|
|
|
|
| |
Even tho st/mesa use user buffers for constants align buffers
other state trackers doesn't use user buffers.
|
| |
|
|
|
|
| |
Also remove unused i915_transfer struct
|
| |
|
| |
|
|
|
|
| |
Add missing evergreen FLT_TO_INT_FLOOR instruction.
|
|
|
|
|
|
| |
See http://bugs.freedesktop.org/show_bug.cgi?id=32309
Apparently, malloc() is failing during context creation. Not
checking for nulls here led to crashes elsewhere.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The loop to choose a pixel format for the window was incrementing
'i' after we succeeded in creating the window so if we chose format[0]
for graw_create_window_and_screen() we were putting format[1] in
the pipe_resource template for creating the render target.
This only worked because of the order of the elements in the formats[]
array.
The graw_xlib.c code now properly compares the requested gallium pixel
format against the visual's color layout.
Update all the graw demos to fix the off-by-one-i error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When --enable-shared-glapi is specified, libGL will share libglapi with
OpenGL ES instead of defining its own copy of glapi. This makes sure an
app will get only one copy of glapi in its address space.
The new option is disabled by default. When enabled, libGL and libglapi
must be built from the same source tree and distributed together. This
requirement comes from the fact that the dispatch offsets used by these
libraries are re-assigned whenever GLAPI XMLs are changed.
For GLX, indirect rendering for has_different_protocol() functions is
tricky. A has_different_protocol() function is assigned only one
dispatch offset, yet each entry point needs a different protocol opcode.
It cannot be supported by the shared glapi. The fix to this is to make
glXGetProcAddress handle such functions specially before calling
_glapi_get_proc_address.
Note that these files are automatically generated/re-generated
src/glx/indirect.c
src/glx/indirect.h
src/mapi/glapi/glapi_mapi_tmp.h
|
|
|
|
| |
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
| |
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
| |
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=33284
|
|
|
|
| |
This fixes Bug 33262
|
| |
|
|
|
|
|
|
| |
According to R700 ISA we have only two channels for cfile constants.
This patch makes piglit tests "glsl1-constant array with constant
indexing" happy on RV710.
|
|
|
|
|
|
|
| |
This fixes a potential failure when a begin/end_query is the first
thing to happen after flushing the scene.
NOTE: This is a candidate for the 7.10 and 7.9 branches.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This shouldn't really be needed but it may help with
http://bugs.freedesktop.org/show_bug.cgi?id=32309
|
|
|
|
| |
Just to be more consistant with the vertex and geometry tex cache fields.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The driver was saying that independend blend functions was not supported,
but it really was. The driver was using the per-target independend blend
factors but the state tracker was only setting the 0th one (per the
Gallium spec).
Fixes a piglit fbo-drawbuffers2-blend regression.
See https://bugs.freedesktop.org/show_bug.cgi?id=33215
|
|
|
|
|
|
| |
For doing builds against a separated libdrm these cflags are needed.
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
| |
|