Age | Commit message (Collapse) | Author |
|
This should make things easier for drivers wanting to work with a
"subclass" of gl_framebuffer.
The complementary "_mesa_initialize_framebuffer" function is now
called "_mesa_initialize_window_framebuffer" for the sake of
symmetry.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
This is a very informal version number, but there have been enough
changes that a bump is appropriate at this time.
|
|
Compiler can't usually turn x/2.0f into x * 0.5f, though we're happy
with either.
|
|
This fixes a bug reported by Christoph Bumiller on mesa3d-dev.
When a texture is first created as RGBA, then re-defined with
glTexImage(internalFormat=GL_DEPTH_COMPONENT) we failed to deallocate
the original texture. When this texture was bound as a FBO surface,
the depth/Z surface format was RGBA instead of Z. Depending on the
driver this led to a failed assertion or FBO validation failure.
This patch does three things:
1. Remove ancient code that mysteriously tested if we were replacing
the smallest mipmap level and tested if the texture was not a cube map
texture. I can't see any reason for those tests.
2. Move the width=height=depth=0 test to after the code which frees
texture data. Calling glTexImage with width=height=depth=0 and data=NULL
is a way to free a single mipmap level.
3. Update the code comments.
There are no apparent conform, glean or piglit regressions from this change.
(cherry picked from commit 43e4b584227534e30e487e7fb7e99d6501cbcd85)
|
|
This was being calculated the same way in two different places.
Now just do it in st_translate_fragment_program().
|
|
Was being calculated and not used. Also was probably incorrect...
|
|
|
|
|
|
(cherry picked from commit 4d1234e22242529c8d85f5ef0cf826af41a91570)
Conflicts:
src/mesa/state_tracker/st_draw.c
|
|
Changes in v4;
- Implemented Brian Paul's style suggestions
Changes in v3:
- Use positive caps instead of negative ones
Changes in v2:
- Updated formatting
The state tracker will use the TGSI convention properties if the hardware
exposes the appropriate capability, and otherwise adjust WPOS itself.
This will also fix some drivers that were previously broken due to their
incorrect, inadvertent, use of conventions other than upper_left+half_integer.
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_screen.c
src/gallium/include/pipe/p_defines.h
|
|
|
|
|
|
minor code changes, style and comment fixes
|
|
Conflicts:
src/mesa/drivers/dri/intel/intel_screen.c
src/mesa/drivers/dri/intel/intel_swapbuffers.c
src/mesa/drivers/dri/r300/r300_emit.c
src/mesa/drivers/dri/r300/r300_ioctl.c
src/mesa/drivers/dri/r300/r300_tex.c
src/mesa/drivers/dri/r300/r300_texstate.c
|
|
uses the new gallium per-rt blend functionality
|
|
My commit eea6a7639f767b1d30b6ef1f91a9c49e3f3b78f0 does a memcpy of height
lines, but that's wrong because the texture has a block layout and we
must thus use the number of vertical blocks instead of the height.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Based on a patch by Xavier Chantry <chantry.xavier@gmail.com>:
If x+width or y+height is negative, then maxx or maxy will get a bogus value
when converting that to unsigned. Fix this by setting 0 as minimal value.
This was also triggered by teeworlds, but only with some combination of
resolution and map section. For example upper part of dm2 at 1280x1024.
|
|
commit 53174afeeb introduced a portability change that converted GLint x,y
to GLuint. That breaks when x and y are negative, which seems to be allowed,
and which at least one game uses : teeworlds.
Rather than simply reverting the change, it seems possible to convert the
16bit unsigned to GLint so that comparisons are made between signed integers
instead. This hopefully does not break anything while keeping MSVC happy.
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
These shaders are not st_vertex_shaders, but tgsi ureg shaders.
Fixes fd.o bug 25959.
|
|
Conflicts:
src/gallium/auxiliary/draw/draw_context.c
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
src/gallium/auxiliary/pipebuffer/Makefile
src/gallium/auxiliary/pipebuffer/SConscript
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/gallium/auxiliary/tgsi/tgsi_scan.c
src/gallium/drivers/i915/i915_surface.c
src/gallium/drivers/i915/i915_texture.c
src/gallium/drivers/llvmpipe/lp_setup.c
src/gallium/drivers/llvmpipe/lp_tex_sample_c.c
src/gallium/drivers/llvmpipe/lp_texture.c
src/gallium/drivers/softpipe/sp_prim_vbuf.c
src/gallium/state_trackers/xorg/xorg_dri2.c
src/gallium/winsys/drm/intel/gem/intel_drm_api.c
src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.c
src/gallium/winsys/drm/radeon/core/radeon_drm.c
src/gallium/winsys/drm/vmware/core/vmw_screen_dri.c
src/mesa/state_tracker/st_cb_clear.c
|
|
|
|
|
|
GL 3.0 (EXT_draw_buffers2) and other APIs allow independent blend enables and
write masks per render target, ARB_draw_buffers_blend (and other APIs) also
allow independent blend functions. Things like dithering, logic ops however
are not extended to be per rendertarget, that might be conceptually possible
however it doesn't look like any API wants to expose this.
|
|
We need to consider the user-requested formats, not the actual device-
chosen formats. See code comments for more details.
|
|
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Fixes gnome-shell on nouveau, as well as window resize with various
other applications.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
Shaders should at least have an END instruction.
|
|
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_draw_arrays.c
src/mesa/state_tracker/st_draw_feedback.c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|