| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
This format is allowed by the GL_EXT_texture_type_2_10_10_10_REV
extension.
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Call Driver.AllocTextureImageBuffer rather than calling
Driver.TexImage with NULL data, format=GL_NONE and type=GL_NONE.
This avoids setting ctx->Unpack, which can lead to incorrectly
trying to upload data.
The GLES3 GTF program's packed_pixels_pbo test was triggering
an error for i965 with the previous code.
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes issues with gles3-gtf
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This returns the current read renderbuffer for the specified
format type.
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This function checks for ES3 compatible
format/type/internalFormat/dimension combinations.
[[email protected]: additional tweaks for gles3-gtf]
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
v2:
* Only allow on GL Legacy contexts
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Add API debug trace message for:
* glRenderbufferStorage
* glRenderbufferStorageMultisample
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes a runtime error:
glxgears: symbol lookup error: /home/brian/mesa/lib/gallium/libGL.so.1: undefined symbol: clock_gettime
v2: use $(CLOCK_LIB) and $(PTHREAD_LIBS) per Andreas Boll.
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Andreas Boll <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hardware does not support a render target without an alpha channel.
So when the user creates a render buffer with no alpha channel, there actually
is storage available for alpha internally. It requires special care to
avoid these unwanted alpha bits from causing any problems.
Specifically, when blending, and when the blend factors would read the
destination alpha values, this commit coerces the blend factors to instead be
either 0 or 1 as appropriate.
A similar fix was made for pre-gen6 hardware in commit eadd9b8e and this
commit shares the fixup function written by Ian then.
This commit the following es3conform test:
rgb8_rgba8_rgb
As well as the following piglit (sub) tests:
EXT_framebuffer_object/fbo-blending-formats/3
EXT_framebuffer_object/fbo-blending-formats/GL_RGB
EXT_framebuffer_object/fbo-blending-formats/GL_RGB8
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to keep the color buffers in the dri_buffers array and
swap __DRI_BUFFER_BACK_LEFT and __DRI_BUFFER_FRONT_LEFT around there
and swap third_buffer in in case we needed to triple buffer. That
gets a little fidgety with all the swaps, so lets use the
color_buffers pool like the gbm platform does. We track the color buffers,
their corresponding wl_buffer and locked status here and just plug
a free one into dri2_surf->buffers when we need to.
This is a nice clean-up in itself, but it also sets us up to track
buffer age in the color_buffers structs.
Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
|
|
|
|
|
|
| |
This is a work-around until configure.ac stops touching CFLAGS.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Damien Lespiau <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
so that the driver doesn't crash if an app doesn't set any vertex buffers.
|
|
|
|
|
| |
RB3D_DEBUG_CTL doesn't help, so I resolve to a tiled temporary texture and
then blitting it to the destination one, which we also do in other situations.
|
|
|
|
| |
It seems to be working just fine.
|
|
|
|
|
|
|
|
| |
The handling of the CAP is broken in st/mesa anyway. Let's just kill it.
This commit pretty much enables fast Z clear for FBOs with Z24S8.
The driver falls back to clearing with a quad if the fast clear cannot be
used. It can still do fast color clear, for example.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This won't ever be made default and we don't need it anyway.
We should also consider doing this for other drivers.
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Andreas Boll <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Andreas Boll <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Effectively this path would always assert. Move the break statement to
the (probable) intended place.
Note: This is a candidate for the stable branches.
Signed-off-by: Adam Jackson <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Include LLVM_LDFLAGS when building with LLVM. Fixes the following build
errors:
CXXLD swrast_dri.la
/usr/bin/ld: cannot find -lLLVMR600CodeGen
/usr/bin/ld: cannot find -lLLVMR600Desc
/usr/bin/ld: cannot find -lLLVMR600Info
/usr/bin/ld: cannot find -lLLVMR600AsmPrinter
Reviewed-by: Andreas Boll <[email protected]>
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59282
|
|
|
|
|
|
|
|
| |
Glapi gets generated at build time.
See commit:
0ce0f7c0c8fa9902678af7f3ecad2541be5808d2
mesa: Remove the generated glapi from source control, and just build it.
|
|
|
|
|
|
|
|
|
|
|
| |
v2: Andreas Boll <[email protected]>
- don't remove compatibility with scripts for the old build system
v3: Andreas Boll <[email protected]>
- remove more obsolete hacks
v4: Andreas Boll <[email protected]>
- add a previously removed TOP variable to fix vgapi build
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to bug #54524, I regressed oglconform's multicontext test
when I reenabled the fragment shader precompile.
However, these test cases only passed by miraculous coincedence. We
assign each fragment program a unique ID (brw_fragment_program::id which
becomes brw_wm_prog_key::program_string_id) which we obtain by storing a
per-context counter.
The test case uses GLX context sharing to access the same fragment
program from two different contexts. This means that we share a program
cache. Before the precompile, if both contexts happened to use the same
shaders in the same order, we'd obtain the same program_string_ids (by
virtue of doing the same computation twice). However, the more likely
scenario is that they completely disagree on program_string_id.
This meant that we'd have two completely different fragment shaders in
the cache with the same ID, tricking us to think they were the same
(aside from NOS), so we'd render using the wrong program.
This patch implements a simple fix suggested by Eric: it moves the
global counter out of brw_context and into intel_screen, which is shared
across all contexts. A mutex protects it from concurrent access.
This is also the first direct usage of pthreads in the i965 driver.
Fixes 10 subcases of oglconform's multicontext test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54524
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Technically, variable sized arrays are a required feature of C99,
redacted to be optional in C11, and not actually part of C++ whatsoever.
Gcc allows using them in C++ unless you specify -pedantic, and Clang
appears to allow them for simple/POD types.
exec_list is arguably POD, since it doesn't have virtual methods, but I
can see why Clang would be like "meh, it's a C++ struct, say no", seeing as
it's meant to support C99.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58970
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The simulator gets very angry about our i2b code:
cmp.ne(16) g3<1>D g2<0,1,0>D 0F
We can't mix integer DWord and float types. The only reason to use 0F
here was to share code with f2b. Split it and use 0D instead.
While we don't believe anything bad will actually happen because of
this, it's nice to fix the warnings and easy enough to do.
Reviewed-by: Paul Berry <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Often when debugging, I don't want to see SIMD16 shaders. It makes
INTEL_DEBUG=vs/fs output much easier to read, especially when a program
dumps many shaders. Plus, I also want to verify that SIMD8 works before
even considering SIMD16.
v2: Fix the likeliness check (caught by Chris and Eric).
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
Fixes a regression caused by b587a7595e7aae0809a8e7392e89c39df0c955b1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59261
Reviewed-by: Andreas Boll <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
| |
This is required to make libnv50 independent of libnvc0.
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59281
Reviewed-by: Andreas Boll <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Choose MESA_FORMAT_ARGB2101010 when storing
GL_RGBA + GL_UNSIGNED_INT_2_10_10_10_REV or
GL_RGB + GL_UNSIGNED_INT_2_10_10_10_REV.
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
| |
Note: This is a candidate for the stable branches.
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The ARB_get_program_binary spec says "OpenGL 3.0 is required." The
nearly identical OES_get_program_binary extension is available for
OpenGL ES 2.0, so I don't see how / why OpenGL 3.0 is a requirement for
the ARB version. Let's just enable whenever GL_ARB_shader_objects is
available.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|