The values 2147483648.0 and 4294967294.0 are too larget to be stored in single
precision floats. Forcing these to be singles causes bits to be lost, which
results in errors in some pixel transfer tests.
This fixes bug #22344.
This fixes a regression in region read performance that came in with the
texture tiling changes. Ideally we'd have an access flag coming in so we
could also use bo_map_gtt for writing, like we do for buffer objects.
Bug #22190
The CALL_DrawArrays was leaking the clear's primitives into the display
list with GL_COMPILE_AND_EXECUTE. Use _mesa_DrawArrays instead, which
doesn't appear to leak. Fixes piglit dlist-clear test.
I was rather confused when mesa_print_display_list didn't show any of
my glBegin()..glEnd(). Nothing but print_list appears to call
this function, so matching its behavior seems like a good idea.
pbo might be system buffer based or attached to another region. Call
intel_bufferobj_buffer to make sure pbo has a buffer of its own.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
intel_bufferobj_subdata is called to migrate data from sys_buffer, and
it expects only one of buffer or sys_buffer is non-NULL.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
need to pass target parameter to radeon_teximage/radeon_subteximage functions
otherwise mipmap generation for cube maps can't work (assert/segfault in
_mesa_generate_mipmap)
Initialize all driver function hooks before calling _mesa_initialize_context(),
and handle all buffer objects in intel_buffer_object().
Fixes assertion failure when running glxinfo.
drm cmd checker would refuse cube emits
also fix an issue in the cs path which would calculate the register
offset off by one dword.
Only same testing done as original code (none except compile tested).
Just use the gl_buffer_object::Size field. Remove unnecessary size/offset
error checks. Core Mesa will have already done these checks before these
functions are called.
Since commit 6629a35559 "mesa: create/destroy
buffer objects via driver functions" this is no longer needed, and actually
was causing a crash during context tear-down.
Fixes#22181. R200 requires this since DP4 is used in hw tnl mode.
R300 prefers it (should be faster due to no instruction dependencies), but
both methods should be correct (when sw tcl is used though, MUL/MAD might
be faster). Probably doesn't make much difference for R100 since vertex progs
are executed in software anyway, but let's just keep it the same there too.
This is done when constructing the fbconfigs, and the result is saved
for window system framebuffer creation.
Note: For dri2 the server needs to have an identical format selection
logic. Otherwise the dri state-tracker and the xorg driver (state-tracker)
will disagree on which format to use for the attachments. Some more work
is needed in this area.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
The default values true and false will expand to "1" and "0" when
gcc -std=c99, causing bool option defaults to generate runtime failures.
One solution is to specify bool option defaults quoted as "true" and "false".
Add a macro to assist this.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
We were packing according to the pitch, while the hardware appears to base
it on the base level width.
With this and the previous commit, fbo-cubemap now matches untiled behavior.
3D rendering to tiled textures was being done with non-tile-aligned offsets.
The G4X hardware has fields to let us support it easily and correctly, while
the pre-G4X hardware requires a path full of suffering, so we just fall back.
