| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
This looks like it's a small win on blender.
|
|
|
|
|
| |
We would end up with the offset from the start of the mapping rather than
the offset from the start of the buffer.
|
|
|
|
|
| |
Passes glean's bufferObject test, and should provide good performance in the
cases applications are expected to use.
|
|
|
|
|
| |
Previously we blocked because I hadn't added the libdrm function. Now it's
there, so update your libdrm.
|
|
|
|
|
|
| |
Problem was to find the correct place to run prediction. Only place that is
called for every primitive is ALLOC_VERTS so we have to do prediction there
before allocation.
|
|
|
|
| |
DRI1 has to set scissors in framebuffer coordinates.
|
|
|
|
| |
DRI1 didn't have support for command buffer emit for stripple.
|
| |
|
|
|
|
|
| |
Polygon stipple has to go to command buffer because special ioctl is disabled.
Piglit doesn't like HyperZ warning so disable it for kms.
|
|
|
|
| |
I forgot about r600 being here.
|
|
|
|
| |
this makes gnome-shell work on r300 for me
|
|
|
|
| |
Passes glean's bufferObject test for this extension.
|
| |
|
|\ |
|
| |
| |
| |
| | |
See bug 16866.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
The fragment program native limits are actually higher on R4xx
as reported by Alex Deucher, but using those requires some
bit-twiddling changes to program handling.
Signed-off-by: Nicolai Hähnle <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Nicolai Hähnle <[email protected]>
|
| |
| |
| |
| |
| | |
Swtcl calls flush everytime primitive changes so prediction has to made again
after flushing.
|
| | |
|
| |
| |
| |
| |
| |
| | |
For non-FBOs we need to invert, for FBOs the scissors are non-inverted.
no matter what we need to clamp them to the buffer sizes.
|
| |
| |
| |
| |
| | |
Increase the number of native program parameters to the same values
exposed by GLSL.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several changes are made to program parameter limits. Several of the
non-NATIVE limits are set higher. All of the NATIVE limits are set to
zero in the core Mesa code. Each driver must set the actual value in
its context creation routine. If the NATIVE value remains zero, this
indicates that hardware shaders may not be supported.
Each of the preceeding changes matches the bahavior of Apple's shader
assembler, so it seems safe.
Finally, we limit the value of MaxEnvParams to be no greater than
MaxNativeAttribs. At least one case has been found where an
application does the wrong thing if MaxNativeAttribs < MaxEnvParams.
See also bugzilla #23490.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Only use the macro variant of MAD when absolutely necessary.
Apparently it cannot deal with relative addressing.
Signed-off-by: Nicolai Hähnle <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
Find used temporaries even if they are only written to in dead code.
This fixes a bug in the NQSSADCE stage.
Signed-off-by: Nicolai Hähnle <[email protected]>
|
|\ \ |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
We were check command buffer sizes too alte so allocated dma regions
were freed before relocations so space checking failed.
|
|\ \ \
| | |/
| |/| |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The instructions we're translating already went through the brw_wm_pass_fp()
function which does the sampler->texture unit mapping. We were applying
the sample->unit mapping a second time in the GLSL texture emitters.
Often, this made no difference but other times it could lead to accessing
an invalid texture and could cause a GPU lockup.
|
| | | |
|
| |/
|/|
| |
| |
| | |
Remove redunant type check for samplers (assert instead).
Move some local vars. Update comments.
|
| |
| |
| |
| |
| | |
Check that all the textures needed by the current fragment program
actually exist and are valid.
|
| |
| |
| |
| | |
We'll use this for debug/sanity checking.
|
| | |
|
| | |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Need to add the 'offset' parameter when indexing the parameter array.
Before, if we were setting arrays of samplers, we were actually only
setting the 0th sampler's value.
Because of how progs/glsl/samplers.c is constructed, this wasn't showing
up as a failure in the samplers_array output.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a fragment program only parameter was queried of a vertex program
(e.g., GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB) no error would be set and
a random value would be returned. This caused 'glxinfo -l' to show
the same values for GL_MAX_PROGRAM_ALU_INSTRUCTIONS_ARB,
GL_MAX_PROGRAM_TEX_INSTRUCTIONS_ARB, GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB,
GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB,
GL_MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB,
GL_MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB as for
GL_MAX_PROGRAM_ENV_PARAMETERS_ARB. This is confusing and incorrect.
(cherry picked from master, commit 4bccd693a72a0b42dffc849034263a68e779ca91)
|
| |
| |
| |
| | |
Fixes bug 23489.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
When adding a new bitmap to the cache we have to check if the Z value is
changing and flush first if it is.
This is a modified version of a patch from Justin Dou <[email protected]>
|
| | |
|