| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't use the "fstoi" instruction like this.
Unlike other floating point instructions, "fstoi" always rounds
towards zero no matter what rounding mode the FPU has been set to.
This was validated using the following test program:
--------------------
static inline int iround(float f)
{
int r;
__asm__ ("fstoi %1, %0" : "=f" (r) : "f" (f));
return r;
}
#define IROUND(x) iround(x)
#define IROUND_REF(f) ((int) (((f) >= 0.0F) ? ((f) + 0.5F) : ((f) - 0.5F)))
int main(void)
{
float f = -2.0;
while (f < 3.0f) {
int sparc_val = IROUND(f);
int ref_val = IROUND_REF(f);
if (sparc_val != ref_val)
printf("DIFFERENT[%f]: REF==%d SPARC==%d\n",
f, ref_val, sparc_val);
f += 0.1f;
}
return 0;
}
--------------------
which prints out things like:
--------------------
DIFFERENT[-1.900000]: REF==-2 SPARC==-1
DIFFERENT[-1.800000]: REF==-2 SPARC==-1
DIFFERENT[-1.700000]: REF==-2 SPARC==-1
DIFFERENT[-1.600000]: REF==-2 SPARC==-1
DIFFERENT[-1.000000]: REF==-1 SPARC==0
DIFFERENT[-0.900000]: REF==-1 SPARC==0
DIFFERENT[-0.800000]: REF==-1 SPARC==0
DIFFERENT[-0.700000]: REF==-1 SPARC==0
DIFFERENT[-0.600000]: REF==-1 SPARC==0
DIFFERENT[0.500000]: REF==1 SPARC==0
DIFFERENT[0.600000]: REF==1 SPARC==0
...
--------------------
So we have to remove Sparc's IROUND() definition, it's wrong.
Signed-off-by: David S. Miller <[email protected]>
|
|
|
|
| |
Fixed point is only used in swrast and sw-based drivers.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
I should just stop using "git stash" altogether.
|
| |
|
|
|
|
| |
Core mesa now unmaps the buffers if needed in these cases.
|
|
|
|
| |
Plus add some comments.
|
| |
|
|
|
|
| |
Nothing really of note, unfortunately.
|
| |
|
|
|
|
| |
Match the rest of Gallium.
|
|
|
|
| |
Also, ctx->Driver.UnmapBuffer can never be null, so remove conditional.
|
| |
|
| |
|
|
|
|
|
|
| |
If glBufferDataARB() is called while a buffer object is currently mapped
we're supposed to unmap the current buffer, then replace it. Don't generate
an error.
|
|
|
|
|
| |
Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
Don't print the meaningless and confusing CONSTANT interpolation
attribute after everything else.
|
|
|
|
| |
This is still icky, and only compile-tested.
|
| |
|
|
|
|
|
| |
Using a tab of inputs should work, but I keep getting bad results.
If only Rawhide's GDB wasn't broken...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i965 doesn't natively support GL_CLAMP; it treats it like
GL_CLAMP_TO_EDGE, which fails conformance tests.
This fix adds a clause to the check_fallbacks() test to check
whether GL_CLAMP is in use on any enabled 2D texture. If so,
and if strict conformance is required (via INTEL_STRICT_CONFORMANCE),
a software fallback is mandated.
In addition, validate textures *before* checking for fallbacks,
rather than after; otherwise, the texture state is never validated
and can't be trusted. (In particular, if texturing is enabled and
the sampler would access any level beyond level 0 of a texture, the
sampler will segfault, because texture validation sets the firstLevel
and lastLevel fields of a texture object so that the valid levels
will be mapped and accessed correctly. If texture validation doesn't
occur, only level 0 is accessed correctly, and that only because
firstLevel and lastLevel happen to be set to 0.)
|
|
|
|
|
|
|
|
| |
Need to check ctx->DrawBuffer->Visual.stencilBits not ctx->Visual.stencilBits
because the later only applies to the window system buffers, not user-created
FBOs.
This, plus the previous commit, fixes progs/tests/fbotexture.c
|
|
|
|
|
|
| |
Gallium only supports combined depth/stencil buffers, not separate ones.
If the user tries to create create a FBO with separate depth/stencil
renderbuffers mark the FBO as unsupported.
|
|
|
|
| |
(cherry picked from commit 1350f2efba5eeceebe0e711db6152c29e9889ce7)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fix a bug reported in 2003 :-)
The output vector has 4 entries, not 3.
Unconditionally emit .register directives.
Signed-off-by: David S. Miller <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop using register %g7 since that is used by the "system" (ie. the
pthread implementation makes use of it).
Also, the projection vector can be NULL and we shouldn't try to access
it at all in _mesa_sparc_cliptest_points4_np(). ioquake3 would crash
due to this bug.
Finally, unconditionally emit the register directives and re-enable in
_mesa_init_all_sparc_transform_asm().
Signed-off-by: David S. Miller <[email protected]>
|
|
|
|
| |
Also fix minor drm api change
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Need to use '__asm__' instead of plain 'asm'.
math/m_debug_clip.c: In function ‘test_cliptest_function’:
math/m_debug_clip.c:253: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘asm’
math/m_debug_clip.c:253: warning: implicit declaration of function ‘asm’
Signed-off-by: David S. Miller <[email protected]>
|
|
|
|
| |
It doesn't have to do anything. See comments for more details.
|
|
|
|
|
|
|
|
|
| |
We can't render into any texture format; only certain formats.
Check that render-to-texture's format is renderable in the
intel_validate_framebuffer()
There seems to be a bug somewhere that causes rendering to rgb565 textures
to be corrupted so disallow that for now. This will be revisted.
|
| |
|
|
|
|
| |
Be a little more specific about what these are.
|
|
|
|
| |
Only call this driver function when we really need to bind different buffers.
|
|
|
|
|
| |
This doesn't seem to really effect anything but seeing width=0 in drawing
regions was confusing.
|
|
|
|
|
|
| |
The i965 driver needs an extra instruction field for color output information.
It was using the Sampler field for this. Use the Aux field instead. This
will probaby be revisited at some point...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rewrites the sparc GLAPI code so that it's PIC friendly and works
with all of the TLS/PTHREADS/64-bit/32-bit combinations properly.
As a result we can turn SPARC asm back on. Currently it's only
enabled on Linux, as that's the only place where I can test this
stuff out.
For the moment the cliptest SPARC asm routines are disabled as they
are non-working. The problem is that they use register %g7 as a
temporary which is where the threading libraries store the thread
pointer on SPARC. I will fix that code up in a future change as it's
a pretty important routine to optimize.
Like x86 we do the runtime patch as a pthread once-invoked initializer
in init_glapi_relocs().
Unlike x86, however, our GLAPI stubs on SPARC are just two instruction
sequences that branch to a trampoline and put the GLAPI offset into a
register. The trampoline is what we run-time patch. The stubs thus
all look like:
glFoo:
ba __glapi_sparc_foo_stub
sethi GLAPI_OFFSET(glFOO) * PTR_SIZE, %g3
This actually makes generate_entrypoint() a lot simpler on SPARC. For
this case in generate_entrypoint() we generate stubs using a 'call'
instead of the 'ba' above to make sure it can reach.
In order to get a proper tail call going here, in the unpatched case,
we do several tricks. To get the current PC, for example, we save the
return address register into a temporary, do a call, save the return
address register written by the call to another temporary, then
restore the original return address register value. This is to
avoid having to allocate a stack frame.
This is necessary for PIC address formation.
This new GLAPI scheme lets us get rid of the ugly SPARC GLAPI hacks in
__glXInitialize() and one_time_init().
Signed-off-by: David S. Miller <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
The script generates code like:
pixels = (const GLvoid *) (ptr_is_null != 0) ? NULL : (pc + 80);
which causes the above mentioned warning. Add parenthesis around the
whole expression to fix it.
Signed-off-by: Tomas Carnecky <[email protected]>
|