| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
They are only used by the r200 driver now.
|
|
|
|
|
| |
With DRI2, textures are always resident and using the DRI texmem helper
here is broken anyway, since nothing else uses it.
|
| |
|
|
|
|
| |
drirenderbuffer.[ch] is going bye-bye.
|
| |
|
| |
|
| |
|
|
|
|
| |
DRI2 is always enabled now.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also DRI1-only.
|
|
|
|
| |
DRI1-only as well.
|
|
|
|
| |
Another DRI1-only extension.
|
|
|
|
| |
All DRI2 drivers support setting a separate read drawable.
|
|
|
|
| |
There are no DRI1 drivers left.
|
|
|
|
| |
Signed-off-by: Jeremy Huddleston <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Yuanhan Liu <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Perhaps the easiest implementation, nouveau can directly map buffers
even if tiled, and uses separate surfaces for its texture
renderbuffers so we don't have to worry about that offset.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike intel, we do a blit to/from GTT memory in order to
untile/retile the renderbuffer data, since we don't have fence
registers for accessing it.
(There is software tiling code in radeon_tile.c, but it's unused and
doesn't support macro tiling)
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
v2: Add separate stencil S8 W-tile swizzling/deswizzling. Tested for
the swizzling case with env INTEL_SEPARATE_STENCIL=1 INTEL_HIZ=1
./bin/hiz-depth-stencil-test-fbo-d24-s8
v3: Apply Chad's fix for S8 window system buffers.
Reviewed-by: Chad Versace <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Mesa core's is generic for things like osmesa.
For swrast_dri.so, we have to do Y flipping. The front-buffer path
isn't actually tested, though, because both before and after it fails
with a BadMatch in XGetImage.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39.
The assertion I made was that "the zero-copy code in validation" would
zero copy. Of course, I deleted that check back in January because
the two sites that would trigger it (glTexImage() and this one) both
immediately bound their mt to the object, making the other check
pointless.
Removes two extra blits in glx-tfp. Also fixed the Android home
screen, which wasn't rendering because the extra copy broke the
relationship between the texture and the eglimage.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42152
Tested-by: Chad Versace <[email protected]>
Tested-by: Eugeni Dodonov <[email protected]>
|
|
|
|
|
|
|
| |
Add support for NV_fog_distance to the NV10 and NV20 drivers.
[ Francisco Jerez: Fix fog coord. signedness for
GL_EYE_RADIAL_NV/GL_EYE_PLANE on nv20 ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the vertex and fragment shader back-ends assumed that all
varyings were floats. In GLSL 1.30 this is no longer true--they can
also be of integral types provided that they have an interpolation
qualifier of "flat".
This required two changes in each back-end: assigning the correct type
to the register that holds the varying value during shader execution,
and assigning the correct type to the register that ties the varying
value to the rest of the graphics pipeline (the message register in
the case of VS, and the payload register in the case of FS).
Fixes piglit tests fs-int-interpolation and fs-uint-interpolation.
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i965 graphics hardware has two floating point modes: ALT and IEEE. In
ALT mode, floating-point operations never generate infinities or NaNs,
and MOV instructions translate infinities and NaNs to finite values.
In IEEE mode, infinities and NaNs behave as specified in the IEEE 754
spec.
Previously, we used ALT mode for all vertex and fragment programs,
whether they were GLSL programs or ARB programs. The GLSL spec is
sufficiently vague about how infs and nans are to be handled that it
was unclear whether this mode was compliant with the GLSL 1.30 spec or
not, and it made it very difficult to test the isinf() and isnan()
functions.
This patch changes i965 GLSL programs to use IEEE floating-point mode,
which is clearly compliant with GLSL 1.30's inf/nan requirements. In
addition to making the Piglit isinf and isnan tests pass, this paves
the way for future support of the ARB_shader_precision extension.
Unfortunately we still have to use ALT floating-point mode when
executing ARB programs, because those programs require 0^0 == 1, and
i965 hardware generates 0^0 == NaN in IEEE mode.
Fixes piglit tests "isinf-and-isnan fs_fbo", "isinf-and-isnan vs_fbo",
and {fs,vs}-{isinf,isnan}-{vec2,vec3,vec4}.
|
|
|
|
|
|
|
|
| |
This drops all the old drmSupports* checks since KMS does them all, and it
also drop R300_CLASS and R600_CLASS.
Signed-off-by: Dave Airlie <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
| |
They were called back-to-back at this point.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
It caught one possible bug I recall in my time working on the driver,
and we haven't been setting it for non-fixed-function since the new FS
backend came along. The bug it caught was likely a confusion about
sampler mappings, which we have tests for these days.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
| |
This was the last prepare() function, and it's the first state atom,
so it must be ready to move.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
| |
It's consumed by the brw_emit_index_buffer() code at emit() time.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
| |
I don't really want to touch this impenetrable code in this series, so
just call the one function from the other, since no other atom cares
about them.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
| |
It's used for program compile.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
| |
Only 4 other prepare() functions are left, which don't rely on this.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
| |
This is consumed by the unit state.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
| |
While other units need to know about our constant buffer offsets,
nothing else cared about which particular BO other than the emit() half.
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|