On 10/12/14 15:54, Victor Rodriguez wrote:
[snip]
Hi thanks a lot for the help
My Mesa is working more than fine , however I was wondering if you
think that could be better to just include the correct *drm.h instead
on the specific function that requires , ie:
static int
On 11.12.2014 14:50, Jason Ekstrand wrote:
On Dec 10, 2014 8:13 PM, Michel Dänzer mic...@daenzer.net
mailto:mic...@daenzer.net wrote:
On 11.12.2014 01:08, Jason Ekstrand wrote:
On Tue, Dec 9, 2014 at 10:53 PM, Michel Dänzer mic...@daenzer.net
mailto:mic...@daenzer.net
On 11.12.2014 07:08, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This fixes incorrect rendering in Unreal Engine demos.
I don't know why it's called dx10 clamp mode. MSDN doesn't mention it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83510
Assuming this doesn't
On 11.12.2014 07:49, Roland Scheidegger wrote:
Odd indeed. Maybe it was really meant for d3d10level9 shaders or
something (would allow to share more code compiling d3d9 or d3d10
shaders that way I guess, you could use all the same instructions and
just set that bit, and you said newer chips
On 08/12/14 02:57, Matt Turner wrote:
I've finished fixing up make distcheck.
git://people.freedesktop.org/~mattst88/mesa make-dist
I've seen some (sporadic?) failures of the glcpp/tests/glcpp-test. I
think it's because it's trying to write out files into the
distribution directory,
Hi,
there are a bunch of dEQP tests that check precision of trigonometric
functions and float qualifiers that fail on i965. The way these tests
usually operate is that they define a float (with a lowp, mediump or
highp precision qualifier) and assign the result of a trigonometric
function to it.
On 11/12/14 09:02, Emil Velikov wrote:
On 08/12/14 02:57, Matt Turner wrote:
I've finished fixing up make distcheck.
git://people.freedesktop.org/~mattst88/mesa make-dist
I've seen some (sporadic?) failures of the glcpp/tests/glcpp-test. I
think it's because it's trying to write out
On 12/11/2014 11:59 AM, Iago Toral wrote:
That said, I also noticed that most of the errors reported are for
fairly big numbers, so I played a bit with some examples and noticed
that trigonometric functions lose more precision as their argument gets
bigger. If I pass arguments of a few thousand
Am 11.12.2014 um 09:55 schrieb Michel Dänzer:
On 11.12.2014 07:49, Roland Scheidegger wrote:
Odd indeed. Maybe it was really meant for d3d10level9 shaders or
something (would allow to share more code compiling d3d9 or d3d10
shaders that way I guess, you could use all the same instructions and
Hi Jose,
jfyi I've picked this fix alongside the commit that introduced the
pointer arithmetic.
-Emil
On 05/12/14 14:16, Jose Fonseca wrote:
From: José Fonseca jfons...@vmware.com
Matches what u_vbuf_get_minmax_index() does.
---
src/gallium/auxiliary/indices/u_primconvert.c | 3 ++-
1
Hi Alexander,
For a follow up patches, can you include the Cc: mesa-stable... line
within the commit message. I guess that prefixing the commit with
haiku/swrast: (as your earlier patch) wouldn't be bad either :)
Cheers,
Emil
On 11/12/14 03:38, Alexander von Gluck IV wrote:
* Resolves missing
https://bugs.freedesktop.org/show_bug.cgi?id=84124
--- Comment #7 from Emil Velikov emil.l.veli...@gmail.com ---
commit ac319d94d38cf3145990002c8216426fe297cd28
Author: Marek Olšák marek.ol...@amd.com
Date: Wed Dec 10 19:59:53 2014 +0100
docs/relnotes: document the removal of GALLIUM_MSAA
---
src/gallium/auxiliary/util/u_prim.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/util/u_prim.h
index cf1a18f..b2dd44d 100644
--- a/src/gallium/auxiliary/util/u_prim.h
+++ b/src/gallium/auxiliary/util/u_prim.h
@@ -280,4
---
src/mesa/program/ir_to_mesa.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 68e2597..5196545 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2943,7 +2943,6 @@
I already fixed the it_to_mesa typo locally.
-Brian
On 12/11/2014 08:45 AM, Brian Paul wrote:
---
src/mesa/program/ir_to_mesa.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 68e2597..5196545 100644
---
On 11/12/14 08:40, Emil Velikov wrote:
Hi Jose,
On 10/12/14 14:18, Jose Fonseca wrote:
I never tried, but it doesn't surprise that ?USE_MGL_NAMESPACE doesn't work
properly on Windows.
At very least the src/mesa/drivers/windows/gdi and
src/gallium/targets/libgl-gdi targets will fail because
Overall I think this is a great cleanup.
Just a remark about the chosen names.
On 10/12/14 21:22, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Plus a new PIPE_CAP_VERTEXID_NOOFFSET query.
Vertex offset and base vertex are difference concepts, so I'd rather
not
On 12/11/14 01:02 AM, Emil Velikov wrote:
* Don't ship anything but a tar.xz tarball.
Linux, *BSD and WindowsXP+ have/ship programs that support the format
for more than 5 years.
Solaris 11 has been shipping xz support for the past 3 years, so that's
fine with us too.
P.S. Graduation day
On Thu, Dec 11, 2014 at 11:39 AM, Jose Fonseca jfons...@vmware.com wrote:
Overall I think this is a great cleanup.
Just a remark about the chosen names.
On 10/12/14 21:22, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Plus a new PIPE_CAP_VERTEXID_NOOFFSET query.
Am 11.12.2014 um 17:49 schrieb Ilia Mirkin:
On Thu, Dec 11, 2014 at 11:39 AM, Jose Fonseca jfons...@vmware.com wrote:
Overall I think this is a great cleanup.
Just a remark about the chosen names.
On 10/12/14 21:22, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Iago,
This doesn't matter for GL conformance -- but the impression I get is
that dEQP is aiming at something more.
In any case, the usual problem with this is inaccurate range
reduction, which is fixable in software at some performance cost. The
C library does this, for example.
- Chris
On
On Thu, Dec 11, 2014 at 2:10 PM, Chris Forbes chr...@ijw.co.nz wrote:
Iago,
This doesn't matter for GL conformance -- but the impression I get is
that dEQP is aiming at something more.
In any case, the usual problem with this is inaccurate range
reduction, which is fixable in software at
On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
From: Jason Ekstrand jason.ekstr...@intel.com
An array format is a 32-bit integer format identifier that can represent
any format that can be represented as an array of standard GL datatypes.
Whie the MESA_FORMAT
On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
It is now a hard dependency because of the autogeneration of
format pack and unpack functions.
Update the documentation to reflect this change.
v2:
- Inline
On Tue, Dec 9, 2014 at 7:06 AM, Iago Toral Quiroga ito...@igalia.com wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
It is now a hard dependency because of the autogeneration of
format pack and unpack functions.
Update the documentation to reflect this change.
v2:
- Inline
On Tue, Dec 9, 2014 at 4:07 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
This will be used to unify code in pack.c.
v2:
- Modify pack_int_*() function generator to use c.datatype() and
f.datatype()
Signed-off-by: Samuel Iglesias
The unreachable macro has the advantage (for modern compilers) of
hinting to the compiler that this code is actually unreachable. This
allows us to drop things like return statements or assignments that
existed only to quiet compiler warnings.
Also, this version is a bit easier to type correctly
Let's squash this in to patch 14.
On Tue, Dec 9, 2014 at 4:07 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
v2:
- Add clamping for non-normalized integer formats in pack_ubyte*()
Signed-off-by: Samuel Iglesias Gonsalvez
On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
[snip]
new file mode 100644
index 000..5f6809e
--- /dev/null
+++ b/src/mesa/main/format_pack.py
@@ -0,0 +1,907 @@
+#!/usr/bin/env python
+
+from mako.template import Template
+from sys import argv
+
This new interface allows for writing a series of objects to a chunk
of memory (a blob).. The allocated memory is maintained within the
blob itself, (and re-allocated by doubling when necessary).
There are also functions for reading objects from a blob as well. If
code attempts to read beyond the
Here are two patches that add some functions for serializing and
deserializing simple data structures, (integers of various sizes,
pointers, and strings).
This code will be used by my upcoming shader-cache work. I'm
submitting it here now because it is self-contained and documented, so
it should
From: Tapani Pälli tapani.pa...@intel.com
These functions are useful when serializing an unknown number of items
to a blob. The caller can first save the current offset, write a
placeholder uint32, write out (and count) the items, then use
blob_overwrite_uint32 with the saved offset to replace
On Tue, Dec 9, 2014 at 4:07 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
---
src/mesa/main/format_utils.c | 9 -
1 file changed, 9 deletions(-)
diff --git
I may have brought this up before (I'm starting to not remember things) but
shouldn't we also be clamping float-to-integer as well?
--Jason
On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Fix various conversion
Iago,
These are looking really good. I had a few comments on 3 or 4 of them but
only one or two major things (float-to-int clampping in a couple of
places). All of the patches I didn't reply to are
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On Tue, Dec 9, 2014 at 4:12 AM, Iago Toral
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
---
src/util/register_allocate.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c
index 1cfd66f..af7a20c 100644
--- a/src/util/register_allocate.c
+++
We support MOCS on both gen8 and gen9, so the message seems meaningless. Remove
it to avoid confusion.
Trivial.
Cc: Kristian Høgsberg k...@bitplanet.net
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/gen8_misc_state.c | 3 ---
1 file changed, 3 deletions(-)
diff
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 12/11/2014 07:45 AM, Brian Paul wrote:
---
src/mesa/program/ir_to_mesa.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 68e2597..5196545 100644
---
Including system's headers inside extern C { ... } is not safe, as system
headers may have C++ code in them, and C++ code inside extern C { .. }
doesn't work.
This is because putting code inside extern C won't make __plusplus define go
away, that is, the headers being included thinks is free
From: Kristian Høgsberg k...@bitplanet.net
The upcoming shader cache uses the SHA-1 algorithm for cryptographic
naming. These new mesa_sha1 functions are implemented with the nettle
library.
---
This patch is another in support of my upcoming shader-cache work. Thanks to
Kritian for coding this
On 12/11/2014 02:51 PM, Carl Worth wrote:
From: Kristian Høgsberg k...@bitplanet.net
The upcoming shader cache uses the SHA-1 algorithm for cryptographic
naming. These new mesa_sha1 functions are implemented with the nettle
library.
---
This patch is another in support of my upcoming
On 12/11/2014 02:32 PM, Jose Fonseca wrote:
Including system's headers inside extern C { ... } is not safe, as system headers may
have C++ code in them, and C++ code inside extern C { .. } doesn't work.
This is because putting code inside extern C won't make __plusplus define go
away, that
From: José Fonseca jfons...@vmware.com
This is just to help repro and fixing these issues with any C++ compiler --
commiting this will of course wait until all issues are addressed.
$ scons src/glsl/
scons: Reading SConscript files ...
Checking for GCC ... yes
Checking for Clang ... no
OK. I found a way to make it easier to trap this sort of issues going forward,
regardless of compiler. See patch I just posted.
Jose
From: Brian Paul bri...@vmware.com
Sent: 11 December 2014 22:05
To: mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca
Hello,
This is the second series of patches fixing over 90 (unrelated) dEQP failing
tests.
Again, the test failures were gathered on i965 (gen8) against 10.3.3, but there
are several driver and version agnostic fixes.
A GIT tree with these patches based on git-ff96537 is available at:
The range's min and max, and the precision value are not set correctly for the
vertex shader constants.
Fixes 1 dEQP test:
dEQP-GLES3.functional.state_query.shader.precision_vertex_highp_int
---
src/mesa/drivers/dri/i965/brw_context.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
Hello,
This is the second series of patches fixing over 90 (unrelated) dEQP failing
tests.
Again, the test failures were gathered on i965 (gen8) against 10.3.3, but there
are several driver and version agnostic fixes.
A GIT tree with these patches based on git-ff96537 is available at:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
When a vec has more elements than row components in a matrix, the
code could end up failing an assert inside assign_to_matrix_column().
This patch makes sure that when there is still room in the matrix for
more elements (but in other columns
From: Iago Toral Quiroga ito...@igalia.com
For code such as this in a vertex or fragment shader:
uniform float in0;
flat out float out0;
...
out0 = ceil(in0)
We generate this IR:
(assign (x) (var_ref packed:out0)
(expression int bitcast_f2i
(expression float ceil (var_ref in0) ) ) )
Stencil value masks values (ctx-Stencil.ValueMask[]) stores GLuint values
which are initialized with max unsigned integer (~0u). When these values
are queried by glGet* (GL_STENCIL_VALUE_MASK or GL_STENCIL_BACK_VALUE_MASK),
they are converted to a signed integer. Currently, these values overflow
From: Iago Toral Quiroga ito...@igalia.com
From the OpenGL ES3 spec:
9.4. FRAMEBUFFER COMPLETENESS
...
Depth and stencil attachments, if present, are the same image.
...
Notice that this restriction is not included in the OpenGL ES2 spec.
Fixes 18 dEQP tests in:
Per GLES3 manual for glDeleteRenderbuffers
https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteRenderbuffers.xhtml,
GL_INVALID_VALUE is generated if n is negative.
Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.buffer.delete_renderbuffers
---
src/mesa/main/fbobject.c | 5 +
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Previously, a cast was done to convert from float to int but there
were rounding errors.
The spec specificies in Data Conversion chapter that Floating-point values are
rounded to the nearest integer.
This patch fixes the following 8 dEQP
From: Iago Toral Quiroga ito...@igalia.com
According to the OpenGL and OpenGL ES specs (sections
FRAMEBUFFER COMPLETENESS and Whole Framebuffer Completeness),
the image for color, depth or stencil attachments must be renderable,
otherwise the attachment is considered incomplete and we should
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Previously, a cast was done to convert from float to int but there
were rounding errors.
The spec specificies in Data Conversion chapter that Floating-point values are
rounded to the nearest integer.
This patch fixes the following 2 dEQP
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Return the proper value for two-dimensional array texture and three-dimensional
textures.
From OpenGL ES 3.0 spec, chapter 6.1.13 Framebuffer Object Queries,
page 234:
If pname is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER and the texture
object
Per GLES3 specification, section 4.4 Framebuffer objects page 198, If
internalformat is a signed or unsigned integer format and samples is greater
than zero, then the error INVALID_OPERATION is generated..
Fixes 1 dEQP test:
*
Fixes 1 dEQP test: dEQP-GLES3.functional.negative_api.buffer.draw_buffers
---
src/mesa/main/buffers.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 1ee2009..0f40739 100644
---
From GLES3 specification (page 123), The currently bound sampler may be
queried by calling GetIntegerv with pname set to
SAMPLER_BINDINGGL_SAMPLER_BINDING.
Fixes 4 dEQP tests:
* dEQP-GLES3.functional.state_query.integers.sampler_binding_getboolean
*
Per GLES3 manual for glDeleteFramebuffers
https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteFramebuffers.xhtml,
GL_INVALID_VALUE is generated if n is negative.
Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.buffer.delete_framebuffers
---
src/mesa/main/fbobject.c | 5 +
1
Per GLES3 manual for glDeleteTextures
https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteTextures.xhtml,
GL_INVALID_VALUE is generated if n is negative.
Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.texture.deletetextures
---
src/mesa/main/texobj.c | 5 +
1 file changed, 5
Per GLES specification, the family of functions glGetSamplerParameter(iv/fv)
and glSamplerParameter(i/f/iv/fv) return an INVALID_OPERATION error if
sampler is not the name of a sampler object previously returned from a call
to GenSamplers.
In desktop GL, an GL_INVALID_VALUE is returned instead.
On Thu, Dec 11 2014, Brian Paul wrote:
We'll need a solution for Windows too. I don't have time right now to
do any research into that.
The code from xserver seems to cover that. I'll follow up with a
(largely untested) patch that I ported over from xserver.
If people can give some
From: Kristian Høgsberg k...@bitplanet.net
The upcoming shader cache uses the SHA-1 algorithm for cryptographic
naming. These new mesa_sha1 functions are implemented with the nettle
library.
---
configure.ac | 119 +++
src/util/Makefile.am | 3 +
Prior to copying in code from the xserver configure.ac file, it makes
sense to have the license of this file clearly marked, (to show that
it's licensed identically to the configure.ac file from the xserver
repository).
And since the text of the license refers to the above copyright
notice it
On Thursday, December 11, 2014 12:42:08 PM Ben Widawsky wrote:
We support MOCS on both gen8 and gen9, so the message seems meaningless.
Remove
it to avoid confusion.
Trivial.
Cc: Kristian Høgsberg k...@bitplanet.net
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
On Thursday, December 11, 2014 11:33:52 PM Eduardo Lima Mitev wrote:
The range's min and max, and the precision value are not set correctly for the
vertex shader constants.
Fixes 1 dEQP test:
dEQP-GLES3.functional.state_query.shader.precision_vertex_highp_int
---
On Thursday, December 11, 2014 11:34:11 PM Eduardo Lima Mitev wrote:
From: Iago Toral Quiroga ito...@igalia.com
For code such as this in a vertex or fragment shader:
uniform float in0;
flat out float out0;
...
out0 = ceil(in0)
We generate this IR:
(assign (x) (var_ref packed:out0)
On Tue, 9 Dec 2014 15:39:26 +0100
Luc Verhaegen l...@skynet.be wrote:
On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote:
Hi,
At FOSDEM on the 31st of january and the 1st of February 2015, there
will be another graphics DevRoom. URL: https://fosdem.org/2015/
Slots will
On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
From: Iago Toral Quiroga ito...@igalia.com
From the OpenGL ES3 spec:
9.4. FRAMEBUFFER COMPLETENESS
...
Depth and stencil attachments, if present, are the same image.
...
Notice that this restriction is not included in the OpenGL
On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Return the proper value for two-dimensional array texture and
three-dimensional
textures.
From OpenGL ES 3.0 spec, chapter 6.1.13 Framebuffer Object Queries,
page 234:
If pname is
This patch is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
Previously, a cast was done to convert from float to int but there
were rounding errors.
The spec specificies in Data
This patch is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
It seems like we could use some refactoring so there isn't so much
duplicated code between GetSamplerParameter* and GetTexParameter*.
On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
From: Samuel Iglesias Gonsalvez
This patch is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
From GLES3 specification (page 123), The currently bound sampler may be
queried by calling GetIntegerv with pname set to
SAMPLER_BINDINGGL_SAMPLER_BINDING.
Fixes 4 dEQP tests:
This patch is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
The range's min and max, and the precision value are not set correctly for the
vertex shader constants.
Fixes 1 dEQP test:
On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
Stencil value masks values (ctx-Stencil.ValueMask[]) stores GLuint values
which are initialized with max unsigned integer (~0u). When these values
are queried by glGet* (GL_STENCIL_VALUE_MASK or GL_STENCIL_BACK_VALUE_MASK),
they are converted
This patch and patch 12 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Are there other 'delete' functions that should generate this same error
(but don't)?
On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
Per GLES3 manual for glDeleteFramebuffers
On 12/11/2014 06:21 PM, Ian Romanick wrote:
This patch and patch 12 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Are there other 'delete' functions that should generate this same error
(but don't)?
I see patch 14 now. :)
One other comment...
On 12/11/2014 02:34 PM, Eduardo
Am 11.12.2014 um 23:51 schrieb Marek Olšák:
What radeonsi does is:
basevertex = info-indexed ? info-index_bias : info-start;
This is also what the hardware does for indirect draws and we cannot
change it. The basevertex shader system value must contain start,
because it's used to fetch
On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
Per GLES3 specification, section 4.4 Framebuffer objects page 198, If
internalformat is a signed or unsigned integer format and samples is greater
than zero, then the error INVALID_OPERATION is generated..
Fixes 1 dEQP test:
*
On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
From: Iago Toral Quiroga ito...@igalia.com
According to the OpenGL and OpenGL ES specs (sections
FRAMEBUFFER COMPLETENESS and Whole Framebuffer Completeness),
the image for color, depth or stencil attachments must be renderable,
otherwise
From: Roland Scheidegger srol...@vmware.com
Plus a new PIPE_CAP_VERTEXID_NOBASE query. The idea is that drivers not
supporting vertex ids with base vertex offset applied (so, only support
d3d10-style vertex ids) will get such a d3d10-style vertex id instead -
with the caveat they'll also need to
On 11 December 2014 at 06:45, Marek Olšák mar...@gmail.com wrote:
It uses the libdrm surface allocator and FMASK is 2D tiled. Maybe the
rounding of bpp affects the pitch in a bad way.
I found this sentence hidden in tcore fmask allocator.
// Note that pitch_tile_max is shared with the color
Hey Carl,
Yeah, this looks nifty. I've got some comments on the implementation
though.
On Dec 11, 2014 11:55 AM, Carl Worth cwo...@cworth.org wrote:
This new interface allows for writing a series of objects to a chunk
of memory (a blob).. The allocated memory is maintained within the
blob
On Dec 11, 2014 11:55 AM, Carl Worth cwo...@cworth.org wrote:
From: Tapani Pälli tapani.pa...@intel.com
These functions are useful when serializing an unknown number of items
to a blob. The caller can first save the current offset, write a
placeholder uint32, write out (and count) the items,
On Dec 11, 2014 11:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Dec 11, 2014 at 2:10 PM, Chris Forbes chr...@ijw.co.nz wrote:
Iago,
This doesn't matter for GL conformance -- but the impression I get is
that dEQP is aiming at something more.
In any case, the usual problem
On Thu, 2014-12-11 at 16:52 -0800, Kenneth Graunke wrote:
On Thursday, December 11, 2014 11:34:11 PM Eduardo Lima Mitev wrote:
From: Iago Toral Quiroga ito...@igalia.com
For code such as this in a vertex or fragment shader:
uniform float in0;
flat out float out0;
...
out0 =
On Thu, 2014-12-11 at 11:24 -0800, Jason Ekstrand wrote:
On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
From: Jason Ekstrand jason.ekstr...@intel.com
An array format is a 32-bit integer format identifier that can
represent
On Fri, 2014-12-12 at 08:21 +0100, Iago Toral wrote:
On Thu, 2014-12-11 at 11:24 -0800, Jason Ekstrand wrote:
On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
From: Jason Ekstrand jason.ekstr...@intel.com
An array format is a
On Thursday, December 11, 2014 11:28:04 AM Jason Ekstrand wrote:
On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
It is now a hard dependency because of the autogeneration of
format pack and unpack
On Thursday, December 11, 2014 02:35:00 PM Ilia Mirkin wrote:
On Tue, Dec 9, 2014 at 7:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
It is now a hard dependency because of the autogeneration of
format pack and unpack functions.
91 matches
Mail list logo
