| Age | Commit message (Collapse) | Author |
|---|
|
The new API makes so much more sense, I'd like to forget how the old
one worked.
|
|
The slightly less mechanical change of converting the emit_reloc calls
will follow.
|
|
|
|
Fixes assertion failure in fbo-generatemipmap-npot.
|
|
The pitch is not really an inherent part of the miptree, since it's
not part of any of the layout calculations, and it's dictated by the
libdrm-allocated region pitch now.
|
|
|
|
|
|
|
|
|
|
Everything has been constant-sized until now, but constant buffer
handling changes will make us want some additional variable sized
array.
|
|
|
|
Conflicts:
docs/relnotes.html
src/gallium/drivers/llvmpipe/lp_tex_sample_c.c
src/gallium/drivers/r300/r300_cs.h
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
src/mesa/main/enums.c
|
|
If we ever had a non-tile-aligned tiled renderbuffer, the math was all
off. Use the existing x,y coordinates instead of trying to
reconstruct them from an incorrectly-calculated offset value.
|
|
This is part of the GL_EXT_draw_buffers2 extension and part of GL 3.0.
The ctx->Color.ColorMask field is now a 2-D array. Until drivers are
modified to support per-buffer color masking, they can just look at
the 0th color mask.
The new _mesa_ColorMaskIndexed() function will be called by
glColorMaskIndexedEXT() or glColorMaski().
|
|
Saves ~2KB of code.
|
|
Use the currently bound draw buffer instead of the visual from the
drawable used to create the context. This cause problems generating
mipmaps for an RGBA texture in an RGB context.
This fixes the failure in piglit's glsl-lod-bias test reported in bug #25614.
|
|
Now that XRGB is supported, we don't need to hack around cases of an RGBA
format buffer with an internal format of GL_RGB.
|
|
It turns out that 965 and friends cannot actually render to an xRGB
surfaces. Instead, the surface has to be RGBA with writes to alpha
disabled and the blend function modified to always use 1.0 for
destination alpha.
|
|
Since the texformat branch merge, the value of intel_renderbuffer::texformat
is just a copy of gl_renderbuffer::Format.
|
|
|
|
|
|
Pass a gl_format to intel_create_renderbuffer() instead of GLenum.
Add cases for MESA_FORMAT_XRGB8888 textures and renderbuffers.
However, we don't yet create any renderbuffers or textures with that
format. It seems the default alpha value is zero instead of one.
Need to investigate that first.
|
|
i965 might support more than 4 color draw buffers. But if not, this protects
from breakage if the Mesa limit is raised.
|
|
Conflicts:
src/mesa/drivers/dri/radeon/radeon_fbo.c
src/mesa/drivers/dri/s3v/s3v_tex.c
src/mesa/drivers/dri/s3v/s3v_xmesa.c
src/mesa/drivers/dri/trident/trident_context.c
src/mesa/main/debug.c
src/mesa/main/mipmap.c
src/mesa/main/texformat.c
src/mesa/main/texgetimage.c
|
|
|
|
|
|
|
|
And remove other unneeded #includes while we're at it.
|
|
|
|
Now gl_texture_image::TexFormat is a simple MESA_FORMAT_x enum.
ctx->Driver.ChooseTexture format also returns a MESA_FORMAT_x.
gl_texture_format will go away next.
|
|
|
|
This was a regression in 0f328c90dbc893e15005f2ab441d309c1c176245.
Bug #23688
Bug #23254
|
|
|
|
For drawing to lower mipmap levels, the region size makes the renderbuffer
be the size of the lowest level, instead of the current level. On DRI1,
Brian previously found that the RB size was incorrect, so leave this broken
there.
|
|
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.
|
|
This snuck in with the multi-draw-buffers commit, and is a major penalty
to performance. It doesn't appear to be required, as the only dependency
the surface BO has is on the state key (and if there's some other dependency,
it should just be in the key).
This brings openarena performance up to almost 2% faster than Mesa 7.4.
|
|
This was a leftover from the brw_wm_constant_buffer change.
|
|
This can avoid re-uploading constant data when it isn't necessary, and is
a step towards not updating other surfaces just because constants change.
It also brings the upload of the constant buffer next to the creation.
This brings openarena performance up another 4%, to 91% of the Mesa 7.4 branch.
|
|
Also, only create VS surface state if there's a VS constant buffer to be
uploaded, and set the contents of the buffer at the same time as creation.
|
|
Really, the creation and upload of constants should be in the same place,
since they should only happen together, and a state flag should be
triggered by them so that we don't thrash state around so much for just
updating constants. But this still recovers openarena performance by
another 19%, leaving us 16% behind Mesa 7.4 branch.
|
|
Conflicts:
src/mesa/drivers/dri/i965/brw_curbe.c
src/mesa/drivers/dri/i965/brw_vs_emit.c
src/mesa/drivers/dri/i965/brw_wm_glsl.c
|
|
Also fixes drawing to 3D texture depth levels.
|
|
|
|
When program constants change we create a new VS constant buffer
instead of re-using the old one. This allows us to have several
const buffers in flight with vertex rendering.
|
|
Fixes a regression from commit 2c30fd84dfa052949a117c78d932b58c1f88b446
seen with DRI1.
|
|
Also enable them all regardless of screen bpp, as 32 bpp what I've been
testing against, and haven't been able to detect any screen bpp-specific
troubles with them.
|
|
Hook up a constant buffer, binding table, etc for the VS unit.
This will allow using large constant buffers with vertex shaders.
The new code is disabled at this time (use_const_buffer=FALSE).
|
|
|
|
Plus, begin the new code for vertex shader const buffers.
|
|
Used to map drawables, textures and constant buffers to surface binding
table indexes.
|
