| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In eglCreateContext there is a check for whether the config parameter is zero
and in this case it will avoid reporting an error if the
EGL_KHR_surfacless_context extension is supported. However there is nothing in
that extension which says you can create a context without a config and Mesa
breaks if you try this so it is probably better to leave it reporting an
error.
The original check was added in b90a3e7d8b1bc based on the API-specific
extensions EGL_KHR_surfaceless_opengl/gles1/gles2. This was later changed to
refer to EGL_KHR_surfacless_context in b50703aea5. Perhaps the original
extensions specified a configless context but the new one does not.
Reviewed-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under GLES 3 it is not valid to pass GL_FRONT to glDrawBuffers. Instead,
GL_BACK has a magic interpretation which means it will render to the front
buffer on single-buffered contexts and the back buffer on double-buffered. We
were incorrectly setting the initial value to GL_FRONT for single-buffered
contexts. This probably doesn't really matter at the moment except that
presumably it would be exposed in the API via glGetIntegerv.
When we switch to configless contexts this is more important because in that
case we always want to rely on the magic interpretation of GL_BACK in order to
automatically switch between the front and back buffer when a new surface with
a different number of buffers is bound. We also do this for GLES 1 and 2
because the internal value doesn't matter in that case and it is convenient to
use the same code to have the magic interpretation of GL_BACK.
Reviewed-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In GLES 3 it is not possible to select rendering to the front buffer and
instead selecting GL_BACK has the magic interpretation that it is either the
front buffer on single-buffered configs or the back buffer on double-buffered.
GLES 1 and 2 have no way of selecting the draw buffer at all. In that case we
were initialising the draw buffer to either GL_FRONT or GL_BACK depending on
the context's config and then leaving it at that.
When we switch to having configless contexts we ideally want Mesa to
automatically switch between the front and back buffer whenever a double-
or single-buffered surface is bound. To make this happen we can just allow
the magic behaviour from GLES 3 in GLES 1 and 2 as well. It shouldn't matter
what the internal value of the draw buffer is in GLES 1 and 2 because there
is no way to query it from the external API.
Reviewed-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
|
|
| |
Remove extra "any" and re-word-wrap the comment.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
Commit 6e8d04a caused a leak by allocating ctx->Debug but never freeing it.
Release the memory in _mesa_free_errors_data when destroying a context.
Use FREE to match CALLOC_STRUCT from _mesa_get_debug_state.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
Multiply the dw value by 4 in order to map the complete buffer.
Reviewed-by: Tom Stellard <[email protected]>
Signed-off-by: Niels Ole Salscheider <[email protected]>
|
|
|
|
|
|
|
|
| |
The few paths that were playing with framebuffers and renderbuffer were
saving and restoring them.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This was being applied in a subset of the places that
intel_prepare_render() was called, to set the same flag that
intel_prepare_render() was setting.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The flag wasn't getting updated correctly when the ctx->DrawBuffer or
ctx->ReadBuffer changed. It usually ended up working out because most
apps only have one window system framebuffer, or if they have more than
one and they have any front read/drawing, they will have called
glReadBuffer()/glDrawBuffer() on it when they get started on the new
buffer.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's the ctx->ReadBuffer that gets read from, not the ctx->DrawBuffer.
So, if you happened to have a ctx->ReadBuffer that was the winsys buffer,
and it had previously been intel_prepare_render()ed but not invalidated
since then, and you called glReadBuffer() to switch to front buffer
instead of back buffer reading on the winsys fbo while your drawbuffer was
a user FBO, you'd never get the front buffer's miptree fetched, and
segfault.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75061
v2: minimize the window where cs_buf != new_buf
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
| |
v2: - allow byte-aligned DMA buffer copies on Evergreen
- fix piglit/texsubimage regression
- use the fallback for 3D copies (depth > 1) as well
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
| |
I think these are all equivalent to vertex buffer fetches which should be
dword-aligned. Scalar loads are also dword-aligned.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Buffers are disabled by VGT_STRMOUT_BUFFER_CONFIG, but the query only works
if VGT_STRMOUT_CONFIG.STREAMOUT_0_EN is enabled.
This moves VGT_STRMOUT_CONFIG to its own state. The register is set to 1
if either streamout or the primitives-generated query is enabled.
However, the primitives-emitted query is also incremented, so it's disabled
by setting VGT_STRMOUT_BUFFER_SIZE to 0 when there is no buffer bound.
This fixes piglit:
ARB_transform_feedback2/counting with pause
EXT_transform_feedback/primgen-query transform-feedback-disabled
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
| |
It's already added in need_cs_space.
Also don't calculate anything if there are no buffers.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
|
| |
CB_COLORi_VIEW.SLICE_MAX can be at most 2047.
This fixes the maxlayers piglit test.
Cc: [email protected]
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
| |
This fixes piglit/fbo-sys-blit with fast clear on radeonsi.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
| |
This works for both multi-sample and single-sample color buffers.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
When doing fast clear for single-sample color buffers for the first time,
a CMASK buffer has to be allocated and the CMASK state in all pipe_surfaces
referencing the color buffer must be updated. Updating all surfaces is kinda
silly, so let's move the values to r600_texture instead.
This is only for Evergreen and later. R600-R700 don't have fast clear.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This looks like r600g. The shared Cayman MSAA code is used here.
The real motivation for this is that I need the ability to change values
of color registers after the framebuffer state is set. The PM4 state cannot
be modified easily after it's generated. With this, I can just change
r600_surface::cb_color_xxx and set framebuffer.atom.dirty=true and it's done.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
| |
I will use this in radeonsi.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
| |
|
|
|
|
| |
This updates all occurences of cs_add_reloc.
|
|
|
|
|
| |
The cs_add_reloc change is commented out not to break compilation.
The highest priority of all cs_add_reloc calls is send to the kernel.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the following build error on OpenBSD:
./.libs/libglsl.a(builtin_functions.o)(.text+0x973): In function `mtx_lock':
../../include/c11/threads_posix.h:195: undefined reference to `pthread_mutex_lock'
./.libs/libglsl.a(builtin_functions.o)(.text+0x9a5): In function `mtx_unlock':
../../include/c11/threads_posix.h:248: undefined reference to `pthread_mutex_unlock'
Signed-off-by: Jonathan Gray <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Cc: "10.0" "10.1" <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Static and shared builds were possible in the good old days
of static makefiles. Currently the build system does not
distinguish nor does anything special when one requests a
static build.
Print a warning message for the packager that static builds
are not supported and continue building shared libs.
Currently only Debian and derivatives use static build, and
they use it for building a Xlib powered libGL. This patch
will only change the warning message they are seeing but
the binaries produced will be identical.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
| |
Prevent build issues on systems lacking libdrm.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
- xf86dri.h is the old dri1 header, not required by dri2 nor dri3
- fold xf86drm.h inclusiong inside dri2.h
- dri3_glx does not have any drm specific dependencies
- glapi.h is not required by the dri2 and dri3 codepaths
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent commit fixed build issues in dri2_query_renderer.c by
wrapping in defined(direct_rendering) && !defined(applegl)
This patch targets the query_renderer tests, so that make check
passes on platforms such as hurd and cygwin.
v2: (Emil)
- Rebase and update commit message.
Signed-off-by: Jon TURNEY <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The primary users of these are linux developers, although
it can be extended for *BSD and others if needed.
Fixes make install for Cygwin and OpenBSD at least.
v2:
- Wrap vdpau targets as well.
v3:
- Fold HAVE_COMPAT_SYMLINKS conditional within install*links.mk
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63269
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]> (v1)
Reviewed-by: Christian König <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some platforms different library extension - dll, dylib, a.
Honor that when we are creating the required links.
Rename LIB_EXTENSION to LIB_EXT while we're here.
With libglapi linking aside, building classic drivers on
non-linux platforms should be possible now.
v2: Resolve conflicts.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the cases where one links against the static glapi.la there
is no need to create temporary variables only to explicitly
link agaist it.
Instead use SHARED_GLAPI_LIB to explicitly indicate when one
is building and linking with the shared glapi provider.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the variables were used before the automake conversion
and do not make sense (nor are used) currently.
Replace GL_LIB_NAME with lib$(GL_LIB).$(LIB_EXTENSION) for
apple-glx. The build has been broken for ages, but this will
ease the recovery process as it happens.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All three (xvmc and omx) do not have an alternative loading
similar to the dri modules. Thus one needs to explicitly install
them in order to use/test them.
v2:
- Keep vdpau targets, as an equivalent of LIBGL_DRIVERS_PATH
is being worked on.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
| |
Drop the duplication across all vdpau targets.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Christian König <[email protected]>
|
|
|
|
|
|
|
| |
Drop the duplication across all dri targets.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
| |
Use the handy script and minimise the boilerplate in the makefiles.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
| |
v2: Resolve rebase conflicts.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
There is little gain in printing whenever a folder is created.
v2:
- Use $(AM_V_at) over @ to have control in verbose builds.
Suggested by Erik Faye-Lund.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
| |
Use the automake predefined macro over hardcoding mkdir -p everywhere.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix build error introduced with commit
dfa25ea5cd19d5a050a1c94bd7370a2259b9f007.
CC r600_streamout.lo
r600_streamout.c:108:6: error: conflicting types for 'r600_set_streamout_targets'
void r600_set_streamout_targets(struct pipe_context *ctx,
^
./r600_pipe_common.h:413:6: note: previous declaration is here
void r600_set_streamout_targets(struct pipe_context *ctx,
^
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76009
Signed-off-by: Vinson Lee <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D3D10 allows setting of the internal offset of a buffer, which is
in general only incremented via actual stream output writes. By
allowing setting of the internal offset draw_auto is capable
of rendering from buffers which have not been actually streamed
out to. Our interface didn't allow. This change functionally
shouldn't make any difference to OpenGL where instead of an
append_bitmask you just get a real array where -1 means append
(like in D3D) and 0 means do not append.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
The non-ARB versions take GLuint ids, not GLhandleARB.
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|