| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We no longer have any classic drivers, so we no longer need
libmesa_classic
Reviewed-by: Emma Anholt <emma@anholt.net>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153>
|
|
Rename _mesa_framebuffer_renderbuffer to _mesa_FramebufferRenderbuffer_sw in
preparation for adding the ARB_direct_state_access backend function for
FramebufferRenderbuffer and NamedFramebufferRenderbuffer to share.
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
Signed-off-by: Fredrik Höglund <fredrik@kde.org>
|
|
Acked-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Mark Janes <mark.a.janes@intel.com>
|
|
Acked-by: Eric Anholt <eric@anholt.net>
|
|
s/\bgl_format\b/mesa_format/g. Use better name for Mesa Formats enum
|
|
Now that the rb has a reference to the teximage, we didn't need anything
else out of the attachment.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
We keep having to pass the attachments around with our gl_renderbuffers
because that's the only way to find what the gl_renderbuffer actually
refers to. This is a step toward removing that (though drivers still need
the Zoffset as well).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Everyone was doing effectively the same thing, except for some funky code
reuse in Intel, and swrast mistakenly recomputing _BaseFormat instead of
using the texture's _BaseFormat. swrast's sRGB handling is left in place,
though it should be done by using _mesa_get_render_format() at render time
instead (as-is, it will miss updates to GL_FRAMEBUFFER_SRGB).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Every driver did the same thing.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
This is a step toward allowing drivers to use their normal mapping paths,
instead of requiring that all slice mappings come from an aligned offset
from the first slice's map.
This incidentally fixes missing slice handling in FXT1 swrast.
v2: Use slice height helper function.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
We sometimes need a rendering context when deleting renderbuffers.
Pass it explicitly instead of trying to grab a current context
(which might be NULL). The next patch will make use of this.
Note: this is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
|
|
|
|
|
|
|
|
To better indicate that this pointer to the malloc'd memory.
|
|
|
|
|
|
|
|
No longer used anywhere.
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
The former was only used for clearing buffers. The later wasn't used
anywhere! Remove them and all implementations of those functions.
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=42635
|
|
Mesa core's is generic for things like osmesa.
For swrast_dri.so, we have to do Y flipping. The front-buffer path
isn't actually tested, though, because both before and after it fails
with a BadMatch in XGetImage.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
In the past, swrast_texture_image::Data has been overloaded. It could
either point to malloc'd memory storing texture data, or it could point
to a current mapping of GPU memory.
Now, Buffer always points to malloc'd memory (if we're not using GPU
memory) and Data always points to mapped memory. The next step would
be to rename Data -> Map.
This change also involves adding swrast functions for mapping textures
and renderbuffers prior to rendering to setup the Data pointer. Plus,
corresponding functions to unmap texures and renderbuffers. This is
very much like similar code in the dri drivers.
|
|
Only swrast and the drivers that fall back to swrast need these fields now.
This removes the last of the fields related to software rendering from
gl_texture_image.
|
|
|
|
This also involves passing swrast_texture_image instead of gl_texture_image
into all the fetch functions.
|
|
It's only used by swrast now so move it out of core Mesa.
|
|
This stuff is really for software rendering, it's not core Mesa.
A small step toward pushing the FetchTexel() stuff down into swrast.
Reviewed-by: Eric Anholt <eric@anholt.net>
|
