| Age | Commit message (Collapse) | Author |
|---|
|
What bugs me is that the YUV444 format somehow worked properly. :3
|
|
|
|
Will fix with better constant refactoring later.
|
|
|
|
|
|
|
|
|
|
Conflicts:
Makefile
src/gallium/drivers/softpipe/sp_screen.c
src/mesa/main/version.h
|
|
the driver used to overwrite grf0 then use implicit move by send instruction
to move contents of grf0 to mrf1. However, we must not overwrite grf0 since
it's still used later for fb write.
Instead, do the move directly do mrf1 (we could use implicit move from another
grf reg to mrf1 but since we need a mov to encode the data anyway it doesn't
seem to make sense).
I think the dp_READ/WRITE_16 functions may suffer from the same issue.
While here also remove unnecessary msg_reg_nr parameter from the dataport
functions since always message register 1 is used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This also involves adding a gl_array_object::VBOonly field. For the
ARB extension, all arrays in the object must reside in a VBO. This flag
keeps track of that requirement.
|
|
|
|
The ARB version requires VAOs to be per-context while the Apple extension
was ambiguous.
|
|
|
|
|
|
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).
|
|
These functions may be called from the VBO code (not just user GL calls)
so do some parameter sanity checking.
|
|
drm cmd checker rightfully fell over any cube emit
|
|
|
|
|
|
|
|
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.
|
|
wrapper
Since commit 6629a35559ff7e3b993966f697f7c7f68e5a38d9 "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.
|
|
Plug them in via _mesa_init_query_object_functions().
|
|
Plug them in via _mesa_init_buffer_object_functions().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
docs/relnotes-7.6.html
progs/tests/Makefile
src/gallium/drivers/softpipe/sp_prim_vbuf.c
src/glx/x11/indirect.c
src/mesa/glapi/Makefile
src/mesa/glapi/dispatch.h
src/mesa/glapi/glapioffsets.h
src/mesa/glapi/glapitable.h
src/mesa/glapi/glapitemp.h
src/mesa/glapi/glprocs.h
src/mesa/main/dlist.c
src/mesa/main/enums.c
src/mesa/sparc/glapi_sparc.S
src/mesa/x86-64/glapi_x86-64.S
src/mesa/x86/glapi_x86.S
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
