Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
As with indexing the const buffer, the ADDR reg may have totally
different values for each element. Need to use a gather operation.
|
|
|
|
|
|
This used to be a somewhat packed struct, but no longer. Remove the
last remaining bitfield tag.
|
|
|
|
The previous code assumed that all elements of the address register
were the same. But it can vary from pixel to pixel or vertex to
vertex so we must use a gather operation when dynamically indexing
the constant buffer.
Still need to fix this for the temporary register file...
|
|
|
|
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
If max_index=0xffffffff and elt_bias > 0 the test for
elt_bias + max_index >= DRAW_PIPE_MAX_VERTICES
was wrong. Check earlier if max_index=0xffffffff and do the
"fail" case.
This fixes the piglit draw-elements-base-vertex test (and probably
some other things).
|
|
|
|
When defining mipmap level 'L' and level L-1 exists and the new level's
internalFormat matches level L-1's internalFormat, then use the same hw
format. Otherwise, do the regular ctx->Driver.ChooseTextureFormat() call.
This avoids a problem where we end up choosing different hw formats for
different mipmap levels depending on how the levels are defined (glTexImage
vs. glCopyTexImage vs. glGenerateMipmap, etc).
The root problem is the ChooseTextureFormat() implementation in some
drivers uses the user's glTexImage format/type parameters in the choosing
heuristic. Later mipmap levels might be generated with different calls
(ex: glCopyTexImage()) so we don't always have format/type info and the
driver may choose a different format.
For more background info see the July 2010 mesa-dev thread "Bug in
_mesa_meta_GenerateMipmap"
|
|
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=29162
|
|
Only refresh the fake front buffer if there is one, and only destroy the region
once.
Fixes X11 protocol errors reported by 'mcgreg' on IRC.
|
|
|
|
Mainly, the type of __GLXdisplayPrivateRec::screenConfigs has changed
from "__GLXscreenConfigs *" to "__GLXscreenConfigs **".
|
|
The extension has been removed in
22266c391fbe17603b15a83d4ccf5fa9455ccf8d.
|
|
We do this in the X server for DRI2.
|
|
|
|
The XIDs are display wide so the natural location of the hash is here.
This way we don't have to lookup in each of the screen hashes.
|
|
|
|
The DRI2 protocol for ust, msc and sbc are unsigned but the extensions
talk about int64_t. Do a little dance to make the compiler shut up.
|
|
|
|
The extension never worked, the implementation returns GLX_BAD_CONTEXT
when enabling the frame tracking.
|
|
|
|
|
|
|
|
Only r200 implemented it.
|
|
GLXscreenConfigs is badly named and a dumping ground for a lot of stuff.
This patch creates private screen structs for the dri drivers and moves
some of their fields over there.
|
|
Enough is enough.
|
|
|
|
This saves a superfluous flush and a create/destryo region.
|
|
There was confusion on both the size of message we can send, and on
what the URB destination offset means.
The remaining problems appear to be due to spilling of regs in the
fragment shader being broken.
|
|
|
|
This cleans up some chipset dependency sprinkled around, and fixes a
potential overflow of the attribute offset array for many vertex
results.
|
|
|
|
|
|
|
|
|
|
The problem is destroy_context is almost NEVER called.
The only test for destroy_context I know is compiz.
Reported by Vinson Lee.
FDO bug #29150.
|
|
It should allocate less memory now.
|
|
The Mac OS X SCons build failed on 32-bit CPUs starting with commit
2f6d47a7c8d6e69e5154de44115aab9ba35a41d2 during linking of graw-null.
The build succeeds though on a 64-bit CPU. See FDO bug 29117.
This was the compiler error.
scons: building associated VariantDir targets: build/darwin-x86-debug
Linking build/darwin-x86-debug/gallium/targets/graw-null/libgraw.dylib ...
Undefined symbols:
"_lp_swizzled_cbuf", referenced from:
_lp_swizzled_cbuf$non_lazy_ptr in libllvmpipe.a(lp_rast.os)
_lp_swizzled_cbuf$non_lazy_ptr in libllvmpipe.a(lp_rast_tri.os)
(maybe you meant: _lp_swizzled_cbuf$non_lazy_ptr)
"_lp_dummy_tile", referenced from:
_lp_dummy_tile$non_lazy_ptr in libllvmpipe.a(lp_rast.os)
_lp_dummy_tile$non_lazy_ptr in libllvmpipe.a(lp_rast_tri.os)
_lp_dummy_tile$non_lazy_ptr in libllvmpipe.a(lp_setup.os)
(maybe you meant: _lp_dummy_tile$non_lazy_ptr)
The patch adds -fno-common to all Mac OS X builds to work around this issue.
|
|
Empty structure types aren't allowed with MSVC.
I haven't tested this change. Hope I haven't broken it...
|
|
|