Age | Commit message (Collapse) | Author |
|
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.
|
|
Currently, shader constants are stored in the GRF (loaded from the CURBE
prior to shader execution). This severly limits the number of constants
and temps that we can support.
This new code will support (practically) unlimited size constant buffers
and free up registers in the GRF. We allocate a new buffer object for the
constants and read them with "Read" messages/instructions. When only a
small number of constants are used, we can still use the old method.
The code works for fragment shaders only (and is actually disabled) for now.
Need to do the same thing for vertex shaders and need to add the necessary
code-gen to fetch the constants which are referenced by the shader
instructions.
|
|
|
|
i965 can either do SRGBA8_REV format or SARGB8 format, but not SRGBA8.
Could add SRGBA8_REV support to mesa, but simply use SARGB8 for now.
While here, also add true srgb luminance / luminance_alpha support -
unfortunately the published docs fail to mention which asics support
this, tested on g43 so assume this works on any g4x.
|
|
|
|
This requires upgrading the interface so that the argument to
glXBindTexImageEXT isn't just dropped on the floor. Note that this only
fixes the accelerated path on Intel, as Mesa's texture format support is
missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as a8r8gb8,
but in this case we're not doing the upload so we can't really work around it
that way).
Fixes bugs with compositors trying to use shaders that use alpha channels, on
windows without a valid alpha channel. Bug #19910 and likely others as well.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
Be a little more specific about what these are.
|
|
We were asking for something illegal (write_domain != 0 && read_domains !=
write_domain) because at the time of writing the region surfaces were used
for texturing occasionally as well, and we weren't really clear on the model
GEM was going to use.
This reliably triggered a kernel bug with domain handling, resulting in
oglconform mustpass.c failure. Of course, it only became visible after
01bc4d441fd6821ad9fc20d5e9544e4e587e4ff0 cleaned up some gratuitous flushing.
|
|
Note that I24X8 vs. A24X8 vs. L24X8 doesn't seem to make any difference
for texture/shadow compare, however.
|