When we try to do a vrend transfer from a renderable texture, we end up
using glReadPixels to read the data. However, OpenGL ES has
restrictions on what formats are allowed to be used for glReadPixels.
In partcular, only GL_UNSIGNED_BYTE + GL_RGBA are guaranteed to be
supported (for OpenGL ES 2.0;
On Wed, 2019-03-06 at 13:39 +1000, Dave Airlie wrote:
> On Wed, 6 Mar 2019 at 01:01, Erik Faye-Lund
> wrote:
> > When we try to do a vrend transfer from a renderable texture, we
> > end up
> > using glReadPixels to read the data. However, OpenGL ES has
> > restrictio
On Mon, 2019-03-18 at 14:44 -0700, Lepton Wu wrote:
> virgl render complains about "Illegal resource" when running
> dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
> the reason is that a zero bind value was given for temp resource.
>
> Signed-off-by: Lepton Wu
> ---
> src/g
On Thu, Sep 3, 2015 at 6:05 PM, Chris Wilson wrote:
> If the user supplies a pixel format of GL_RGB + GL_UNSIGNED_SHORT_5_6_5
> and specifies a generic unsized GL_RGB internal format, match that to a
> texture format of MESA_FORMAT_B5G6R5 if supported by the hardware.
>
> Noticed while playing wit
On Wed, Sep 9, 2015 at 11:25 AM, Chris Wilson wrote:
> On Wed, Sep 09, 2015 at 11:11:59AM +0200, Erik Faye-Lund wrote:
>> On Thu, Sep 3, 2015 at 6:05 PM, Chris Wilson
>> wrote:
>> > If the user supplies a pixel format of GL_RGB + GL_UNSIGNED_SHORT_5_6_5
>> >
On Wed, Sep 9, 2015 at 12:41 PM, Chris Wilson wrote:
> On Wed, Sep 09, 2015 at 12:09:40PM +0200, Erik Faye-Lund wrote:
>> On Wed, Sep 9, 2015 at 11:25 AM, Chris Wilson
>> wrote:
>> > On Wed, Sep 09, 2015 at 11:11:59AM +0200, Erik Faye-Lund wrote:
>> >> O
On Mon, Sep 7, 2015 at 3:54 PM, Jose Fonseca wrote:
> On 07/09/15 10:17, Jean-Sébastien Pédron wrote:
>>
>> On 04.09.2015 01:37, Matt Turner wrote:
>>>
>>> You need to test for this support in configure.ac. It's as simple as
>>> adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
>
On Thu, Sep 10, 2015 at 7:58 PM, Ian Romanick wrote:
> On 09/10/2015 05:29 AM, Jose Fonseca wrote:
>> On 10/09/15 02:54, Ian Romanick wrote:
>>
>> It's not necessary to do it in several places, at least for the
>> destructor -- we could have a single C++ module inside src/util, which
>> provided a
On Thu, Sep 10, 2015 at 10:08 PM, Rob Clark wrote:
> From: Rob Clark
>
> Rather than make yet another copy of channel(), let's move it into nir.
>
> Signed-off-by: Rob Clark
> ---
> src/glsl/nir/nir_builder.h | 6 ++
> src/glsl/nir/nir_lower_tex_projector.c | 24 +
On Sun, Sep 13, 2015 at 5:51 PM, Rob Clark wrote:
> From: Rob Clark
>
> The vertex shader lowering adds calculation for CLIPDIST, if needed
> (ie. user-clip-planes), and the frag shader lowering adds conditional
> kills based on CLIPDIST value (which should be treated as a normal
> interpolated v
On Mon, Sep 14, 2015 at 11:53 AM, Erik Faye-Lund wrote:
> On Sun, Sep 13, 2015 at 5:51 PM, Rob Clark wrote:
>> From: Rob Clark
>>
>> The vertex shader lowering adds calculation for CLIPDIST, if needed
>> (ie. user-clip-planes), and the frag shader lowering adds co
On Tue, Sep 15, 2015 at 6:49 PM, Ilia Mirkin wrote:
> However having a piglit test that covers this would be neat... I guess
> you could clip a pixel in half and make sure that the resolved result
> is some in-between color? Lots of implementation-dependent stuff going
> on in there though.
I thi
On Tue, Sep 15, 2015 at 6:49 PM, Rob Clark wrote:
> On Tue, Sep 15, 2015 at 12:39 PM, Erik Faye-Lund wrote:
>> On Mon, Sep 14, 2015 at 11:53 AM, Erik Faye-Lund wrote:
>>> On Sun, Sep 13, 2015 at 5:51 PM, Rob Clark wrote:
>>>> From: Rob Clark
>>>
On Tue, Sep 15, 2015 at 6:49 PM, Ilia Mirkin wrote:
> On Tue, Sep 15, 2015 at 12:39 PM, Erik Faye-Lund wrote:
>> On Mon, Sep 14, 2015 at 11:53 AM, Erik Faye-Lund wrote:
>>> On Sun, Sep 13, 2015 at 5:51 PM, Rob Clark wrote:
>>>> From: Rob Clark
>>>
On Tue, Sep 15, 2015 at 7:12 PM, Ilia Mirkin wrote:
> On Tue, Sep 15, 2015 at 1:09 PM, Erik Faye-Lund wrote:
>> On Tue, Sep 15, 2015 at 6:49 PM, Ilia Mirkin wrote:
>>> However having a piglit test that covers this would be neat... I guess
>>> you could clip a pixel
On Wed, Sep 16, 2015 at 11:00 PM, Dave Airlie wrote:
> This reverts commit 48961fa3ba37999a6f8fd812458b735e39604a95.
> I also don't have a copy of this patch in my mail archive, which
> seems wierd, did it get posted to mesa-dev?
The same applies to 8200793 ("mesa/teximage: restrict GL_ETC1_RGB8
On Thu, Sep 17, 2015 at 11:15 AM, Erik Faye-Lund wrote:
> On Wed, Sep 16, 2015 at 11:00 PM, Dave Airlie wrote:
>> This reverts commit 48961fa3ba37999a6f8fd812458b735e39604a95.
>
>> I also don't have a copy of this patch in my mail archive, which
>> seems wierd,
On Thu, Sep 17, 2015 at 3:27 PM, Emil Velikov wrote:
> Hi Gottfried,
>
> On 17 September 2015 at 13:42, Gottfried Haider
> wrote:
>> I am getting this error on 7e286506 - comping mesa used to work fine
>> on this system a couple of weeks ago
>>
>> CXXnir/nir_lower_samplers.lo
>> CC ni
On Mon, Sep 28, 2015 at 4:39 PM, Roland Scheidegger wrote:
>
> In short, for simplicity, only things were sharable which were really
> required to be shared (pretty much just actual resources - and yes that
> doesn't work too well for GL neither as you can't share sampler/rt
> views, let's face it
On Tue, Sep 29, 2015 at 7:50 PM, Brian Paul wrote:
>
> I was actually thinking of expanding this change to cover _all_ color formats
> but wanted to take a small step first. What do you think?
>
I have some patches in this area sitting around here:
https://github.com/kusma/mesa/commits/color_r
On Fri, Oct 2, 2015 at 11:37 PM, Connor Abbott wrote:
> Now that we have three separate things we want to measure (instructions,
> cycles, and loops), it's impractical to keep adding special code for
> changes in each thing. Instead, for each program in before and after we
> store a table of measu
Ping?
On Wed, Dec 16, 2015 at 5:09 PM, Erik Faye-Lund wrote:
> Here's some trivial cleanups I found while diving into something else.
>
> Instead of them collecting dust in my tree, perhaps we could apply them to
> the central tree?
>
> Erik Faye-Lund (2):
> gallium/u
On Thu, Jan 7, 2016 at 11:49 PM, Ian Romanick wrote:
> On 01/07/2016 12:31 PM, Nicolai Hähnle wrote:
>> From: Nicolai Hähnle
>>
>> The piglit copyteximage check has recently been augmented to test this, but
>> apparently it hasn't been fixed in Mesa so far.
>> ---
>> src/mesa/main/teximage.c | 1
On Mon, Jan 11, 2016 at 11:50 PM, Timothy Arceri wrote:
> On Mon, 2016-01-11 at 16:35 +0100, Erik Faye-Lund wrote:
>> Ping?
>>
>
> The other patch is also now
> Reviewed-by: Timothy Arceri
>
> I take it you don't have commit access?
Thanks. Yeah, no commit
On Sat, Jan 9, 2016 at 3:59 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
>
> In OpenGL ES (all versions!) and OpenGL compatibility profile,
> applications don't have to call Gen functions. The GL spec is very
> clear ab
On Tue, Jan 12, 2016 at 5:44 PM, Ian Romanick wrote:
> On 01/12/2016 01:36 AM, Erik Faye-Lund wrote:
>> On Sat, Jan 9, 2016 at 3:59 AM, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> tl;dr: For many types of GL object, we can *NEVER* use the Gen function
On Wed, Jan 13, 2016 at 1:10 AM, Jason Ekstrand wrote:
> On Tue, Jan 12, 2016 at 3:52 PM, Matt Turner wrote:
>>
>> On Tue, Jan 12, 2016 at 3:35 PM, Jason Ekstrand
>> wrote:
>> > This opcode simply takes a 32-bit floating-point value and reduces its
>> > effective precision to 16 bits.
>> > ---
>
On Tue, Feb 2, 2016 at 4:02 PM, Roland Scheidegger wrote:
> Does anyone use these extensions?
> I suppose maybe to get the total amount of video memory?
I've used them in a commercial data-visualization application. The
purpose was to get the total amount of video memory, so we'd know
roughly how
When this extension was added, an underscore were mistakenly replaced
by a space. Let's correct this, so it's a tad easier to grep for this
extension.
Signed-off-by: Erik Faye-Lund
---
Just a tiny nit I noticed while reading docs...
docs/GL3.txt | 2 +-
1 file changed, 1 inser
On Thu, Apr 21, 2016 at 3:16 PM, Emil Velikov wrote:
> From: Emil Velikov
>
> Signed-off-by: Emil Velikov
> ---
> src/intel/vulkan/.gitignore | 1 -
> src/intel/vulkan/Makefile.am | 1 -
> src/intel/vulkan/dev_icd.json.in | 7 ---
> 3 files changed, 9 deletions(-)
> delete mode 10
On Thu, Apr 30, 2015 at 1:25 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
The title on this one doesn't seem quite right ("after previous"
should probably be "before next"), but that probably doesn't matter
because it will get squashed anyway...
_
On Mon, May 11, 2015 at 3:03 PM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> GLES 3.1 must be allowed to use multisampled
> frambuffer textures.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mesa/main/fbobject.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/
On Mon, May 11, 2015 at 4:57 PM, Ilia Mirkin wrote:
> On Mon, May 11, 2015 at 10:08 AM, Erik Faye-Lund wrote:
>> Shouldn't this be like this instead (and make sure
>> ARB_texture_multisample is enabled for ES3.1)?
>>
>> @@ -2756,8 +2756,9 @@ _mesa_Framebuffe
On Mon, May 11, 2015 at 5:21 PM, Ilia Mirkin wrote:
> On Mon, May 11, 2015 at 11:07 AM, Erik Faye-Lund wrote:
>> On Mon, May 11, 2015 at 4:57 PM, Ilia Mirkin wrote:
>>> On Mon, May 11, 2015 at 10:08 AM, Erik Faye-Lund
>>> wrote:
>>>> Shouldn
ding-01
Signed-off-by: Erik Faye-Lund
---
I noticed that glsl-const-folding-01 failed due to a pretty inaccurate
result for atan(1.0) * 4.0.
The result should be pi, but we only produce 3.141298. The new
approximation gets us to 3.141580, which is at least better than before.
I also tried usin
On Wed, Sep 24, 2014 at 12:39 AM, Erik Faye-Lund wrote:
> This fixes the following piglit test:
> shaders/glsl-const-folding-01
Forgot to mention: no piglit regressions seen on Ivybridge.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.or
On Wed, Sep 24, 2014 at 4:10 AM, Ian Romanick wrote:
> On 09/23/2014 03:39 PM, Erik Faye-Lund wrote:
>> Our current atan()-approximation is pretty inaccurate at 1.0, so
>> let's try to improve the situation by doing a direct approximation
>> without going th
On Wed, Sep 24, 2014 at 1:35 PM, Erik Faye-Lund wrote:
> Hm. Don't I need to expand this last immediate to a vector of
> type->components() size as well?
>
> If so, this patch should go on top:
>
> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_fun
On Thu, Sep 25, 2014 at 4:54 PM, Erik Faye-Lund wrote:
> On Wed, Sep 24, 2014 at 1:35 PM, Erik Faye-Lund wrote:
>> Hm. Don't I need to expand this last immediate to a vector of
>> type->components() size as well?
>>
>> If so, this patch should go
ding-01
Signed-off-by: Erik Faye-Lund
Reviewed-by: Ian Romanick
---
src/glsl/builtin_functions.cpp | 65 +++---
1 file changed, 55 insertions(+), 10 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 9be7f6d..c126b
On Fri, Sep 26, 2014 at 6:11 PM, Erik Faye-Lund wrote:
> Our current atan()-approximation is pretty inaccurate at 1.0, so
> let's try to improve the situation by doing a direct approximation
> without going through atan.
>
> This new implementation uses an 11th degree polyn
On Fri, Oct 10, 2014 at 12:22 PM, Timothy Arceri wrote:
> On Mon, 2014-10-06 at 17:03 +0200, Erik Faye-Lund wrote:
>> On Fri, Sep 26, 2014 at 6:11 PM, Erik Faye-Lund wrote:
>> > Our current atan()-approximation is pretty inaccurate at 1.0, so
>> > let's try to
On Fri, Oct 10, 2014 at 8:44 PM, Olivier Galibert wrote:
> Applied.
Thanks :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sun, Nov 2, 2014 at 7:32 PM, David Heidelberg wrote:
> v2: rename and extend support with code for C11 and MSVC (thanks to Brian)
>
> Signed-off-by: David Heidelberg
> ---
> src/gallium/auxiliary/util/u_dump.h | 6 ++
> src/gallium/auxiliary/util/u_dump_defines.c | 86
> +
On Tue, Nov 4, 2014 at 1:05 PM, Juha-Pekka Heikkila
wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/main/pixeltransfer.c | 62
> ++-
> 1 file changed, 43 insertions(+), 19 deletions(-)
>
> diff --git a/src/mesa/main/pixeltransfer.c b/src/mesa
On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov wrote:
> Hello all,
>
> This is an old question that I had laying around - why doesn't mesa use
> a more conventional numbering for the development/rc releases ?
>
> Eg.
> mesa 10.4.0-rc1 -> 10.3.99.901
> mesa 10.4.0-rc2 -> 10.3.99.902
> ...
> mesa 10.
On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner wrote:
> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote:
>> On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov
>> wrote:
>>> So when checking/building sse code we have three possibilities:
>>> 1 Old compiler, throws an error when using -msse*
>>>
On Mon, Nov 17, 2014 at 3:50 PM, Ilia Mirkin wrote:
> On Mon, Nov 17, 2014 at 9:44 AM, Erik Faye-Lund wrote:
>> On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner wrote:
>>> On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin wrote:
>>>> On Sat, Nov 15, 2014 at 12:04
On Sat, Feb 28, 2015 at 9:19 PM, Matt Turner wrote:
> On Sat, Feb 28, 2015 at 11:47 AM, Thomas Helland
> wrote:
>> On Feb 28, 2015 8:39 PM, "Jason Ekstrand" wrote:
>>>
>>> Both patches are
>>>
>>> Reviewed-by: Jason Ekstrand
>>
>> Could you commit them?
>> I don't have commit access.
>
> I'd li
-load time.
Signed-off-by: Erik Faye-Lund
---
Because of the recent discussion on libc++ and Mesa, I thought I'd
have a look into what parts of mesa depended on libc++, and I spotted
this file.
In this case, it was rather trivial to port the code to plain C, making
it dead obvious that it doesn&#
On Mon, Mar 16, 2015 at 10:13 PM, Emil Velikov wrote:
> On 15/03/15 19:05, Erik Faye-Lund wrote:
>> _mesa_strtod and _mesa_strtof are only used from the GLSL compiler,
>> so the locale doesn't need to be initialized before the first context
>> gets initiali
On Tue, Mar 17, 2015 at 12:32 AM, Ian Romanick wrote:
> On 03/15/2015 12:05 PM, Erik Faye-Lund wrote:
>> _mesa_strtod and _mesa_strtof are only used from the GLSL compiler,
>
> It's also used in the ARB_vertex_program / ARB_fragment_program
> assembler in src/prog.
Oh, rig
ader_images)
>return;
>
> + c = &st->ctx->Const.Program[shader->Stage];
> +
> for (i = 0; i < shader->NumImages; i++) {
>struct gl_image_unit *u = &st->ctx->ImageUnits[shader->ImageUnits[i]];
>struct st_texture_object *stObj = st_te
On Tue, May 24, 2016 at 8:42 AM, wrote:
> From: Mathias Fröhlich
>
> Replaces a loop that iterates all lights and test
> which of them is enabled by a loop only iterating over
> the bits set in the enabled bitmask.
This takes the code from something very obvious and easy to follow to
something
On Fri, May 27, 2016 at 11:59 AM, Mathias Fröhlich
wrote:
>
> Hi,
>
> On Wednesday, May 25, 2016 12:06:02 you wrote:
>> On Tue, May 24, 2016 at 8:42 AM, wrote:
>> > From: Mathias Fröhlich
>> >
>> > Replaces a loop that iterates all lights and test
>> > which of them is enabled by a loop only ite
On Tue, May 31, 2016 at 3:46 PM, Rob Clark wrote:
> On Tue, May 31, 2016 at 9:29 AM, Brian Paul wrote:
>> On 05/31/2016 07:10 AM, Brian Paul wrote:
>>>
>>> On 05/29/2016 10:32 AM, Rob Clark wrote:
From: Rob Clark
Another pipe_resource_usage vs pipe_transfer_usage mixup.
On Sat, May 28, 2016 at 12:31 PM, Mathias Fröhlich
wrote:
> So the xor mask handing is non local to the place where we do the
> computation of i.
>
> Brian pointed me to the u_bit_scan function heavily used in gallium. That
> definitely
>
> helps for the basic problem I personally have with this t
On Tue, May 31, 2016 at 6:14 PM, Roland Scheidegger wrote:
> Am 31.05.2016 um 16:33 schrieb Erik Faye-Lund:
>> On Tue, May 31, 2016 at 3:46 PM, Rob Clark wrote:
>>> On Tue, May 31, 2016 at 9:29 AM, Brian Paul wrote:
>>>> On 05/31/2016 07:10 AM, Brian Paul wrote:
&
On Wed, Jun 1, 2016 at 3:02 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> On Wed, Jun 1, 2016 at 2:19 PM, Marek Olšák wrote:
>> I'll let you figure it out by yourself.
>
> Why would you withhold information if you already have it? Are you a
> "bad person" or something?
The problem has been described
On Thu, Jun 2, 2016 at 8:25 PM, Anuj Phogat wrote:
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/drivers/common/meta_blit.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta_blit.c
> b/src/mesa/drivers/common/meta_blit.c
> index 20d3215..d
Now the subject no longer makes any sense.
On Thu, Jun 16, 2016 at 7:02 AM, wrote:
> From: Francesco Ansanelli
>
> ---
> src/mesa/state_tracker/st_cb_fbo.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_fbo.c
> b/src/mesa/state_tracker
On Mon, Jun 27, 2016 at 11:42 PM, Matt Turner wrote:
> Based on work by Davin McCall from last summer.
>
> The biggest change is to exec_list. Previously, the head and tail sentinels
> overlapped, saving the size of a pointer. Unfortunately this is not allowed by
> the aliasing rules.
>
> I have
Here's some trivial cleanups I found while diving into something else.
Instead of them collecting dust in my tree, perhaps we could apply them to
the central tree?
Erik Faye-Lund (2):
gallium/util: removed unused header-file
main: get rid of needless conditional
src/gallium/auxi
We already check if the driver changed the completeness, we don't
need to duplicate that check. Let's just early out there instead.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/fbobject.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git
This hasn't been in use since c476305 ("gallium/util: pregenerate
half float tables"), where the last bit of run-time init using this
was killed. So let's just get rid of the pointless header.
Signed-off-by: Erik Faye-Lund
---
src/gallium/auxiliary/Makefile.sources | 1 -
s
On Thu, Dec 17, 2015 at 10:09 AM, Giuseppe Bilotta
wrote:
> +# missing svn authors:
I'm not sure this is useful, but just for kicks, I decided to try to
track down these contributors, and this is what I came up with
(suspected contributors CC'ed, so they can confirm or deny if they
want):
> +pes
On Thu, Dec 17, 2015 at 10:39 AM, Erik Faye-Lund wrote:
> On Thu, Dec 17, 2015 at 10:09 AM, Giuseppe Bilotta
> wrote:
>> +# missing svn authors:
>
> I'm not sure this is useful, but just for kicks, I decided to try to
> track down these contributors, and this is what I
On Tue, Dec 22, 2015 at 12:47 PM, Thomas Tanner wrote:
> Hi,
> my primary email address for open source contributions is tan...@gmx.net
> cheers
>
OK, I think Giuseppe will want this info for his final version of the
patch (CC'ed), thanks :)
> On 17.12.15 10:39, Erik Faye-L
On Mon, Dec 28, 2015 at 12:23 PM, wrote:
> Should I be expecting to see myself on here?
>
Only if you have commits in mesa.git attributed to you using the same
name but different e-mail addresses...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.
On Tue, Aug 5, 2014 at 11:22 PM, Carl Worth wrote:
> Kenneth Graunke writes:
>> I agree that this is pretty bogus.
>
> I'm coming around to thinking it's totally bogus.
>
>> How about emitting a warning in the RETURN_TOKEN ('#') case?
>
> Thanks for the review, and thanks for suggesting the warni
On Fri, Aug 8, 2014 at 12:29 AM, Carl Worth wrote:
> Erik Faye-Lund writes:
>> Note that '$' is a bit different, as it's not a part of the
>> preprocessor's character set, so using it might be interpreted as
>> undefined behavior.
>
> Right. That
On Thu, Aug 7, 2014 at 10:31 AM, wrote:
> diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
> index c61a748..f414ea3 100644
> --- a/src/mesa/main/texformat.c
> +++ b/src/mesa/main/texformat.c
> case GL_ALPHA12:
> case GL_ALPHA16:
>RETURN_IF_SUPPORTED(MESA_FORMAT_A
On Fri, Aug 15, 2014 at 11:57 AM, Ville Syrjälä
wrote:
> On Fri, Aug 15, 2014 at 10:52:50AM +0200, Erik Faye-Lund wrote:
>> On Thu, Aug 7, 2014 at 10:31 AM, wrote:
>> > diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
>> > index c61a748..f414ea3 1006
On Tue, Sep 9, 2014 at 7:30 PM, Ian Romanick wrote:
> On 09/08/2014 01:10 AM, Tapani Pälli wrote:
>> From: Kalyan Kondapally
>>
>> According to GLSL-ES Spec(i.e. 1.0, 3.0), gl_Position value is undefined
>> after the vertex processing stage if we don't write gl_Position. However,
>> GLSL 1.10 Spe
On Thu, Sep 11, 2014 at 12:32 AM, Ian Romanick wrote:
> On 09/10/2014 01:53 PM, Erik Faye-Lund wrote:
>> On Tue, Sep 9, 2014 at 7:30 PM, Ian Romanick wrote:
>>> On 09/08/2014 01:10 AM, Tapani Pälli wrote:
>>>> From: Kalyan Kondapally
>>>>
&g
On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick wrote:
> diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
> index 609d94b..7b089fa 100644
> --- a/src/mesa/main/uniform_query.cpp
> +++ b/src/mesa/main/uniform_query.cpp
> @@ -266,30 +265,32 @@ validate_uniform_parameters(s
On Thu, Sep 11, 2014 at 1:27 PM, Erik Faye-Lund wrote:
> On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick wrote:
>> diff --git a/src/mesa/main/uniform_query.cpp
>> b/src/mesa/main/uniform_query.cpp
>> index 609d94b..7b089fa 100644
>> --- a/src/mesa/main/uniform_query
On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli wrote:
> On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
>> On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick wrote:
>>> diff --git a/src/mesa/main/uniform_query.cpp
>>> b/src/mesa/main/uniform_query.cpp
>>> index 609d94
On Thu, Aug 28, 2014 at 9:58 AM, Tapani Pälli wrote:
> Remap table for uniforms may contain empty entries when using explicit
> uniform locations. If no active/inactive variable exists with given
> location, remap table contains NULL.
>
> Signed-off-by: Tapani Pälli
> ---
> src/mesa/main/uniform
On Thu, Sep 11, 2014 at 8:35 PM, Ian Romanick wrote:
> On 09/11/2014 05:09 AM, Erik Faye-Lund wrote:
>> On Thu, Sep 11, 2014 at 2:00 PM, Tapani Pälli wrote:
>>> On 09/11/2014 02:27 PM, Erik Faye-Lund wrote:
>>>> On Sat, Aug 2, 2014 at 4:09 AM, Ian Romanick wrot
On Thu, Sep 11, 2014 at 8:39 PM, Ian Romanick wrote:
> On 08/28/2014 12:58 AM, Tapani Pälli wrote:
>> Remap table for uniforms may contain empty entries when using explicit
>> uniform locations. If no active/inactive variable exists with given
>> location, remap table contains NULL.
>>
>> Signed-o
On Sun, May 21, 2017 at 10:49 PM, Thomas Helland
wrote:
> From: Vladislav Egorov
>
> strcmp() is slow. Initiate comparison with "__LINE__" or "__FILE__"
> only if the identifier starts with '_', which is rare.
>
> Reviewed-by: Ian Romanick
> ---
> src/compiler/glsl/glcpp/glcpp-parse.y | 14
On Jun 1, 2017 15:06, "Samuel Pitoiset" wrote:
Signed-off-by: Samuel Pitoiset
---
src/mesa/main/varray.c | 108 --
---
1 file changed, 61 insertions(+), 47 deletions(-)
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 47528ba2a7..c2
Libunwind has some issues on some platforms, so let's allow people
who have issues to opt-out. This is similar to what we do in automake,
and the implementation is modelled after our opt-out for valgrind.
Signed-off-by: Erik Faye-Lund
---
This fixes a build-problem for me on Arch Linux fo
On Wed, Oct 25, 2017 at 8:10 AM, Gert Wollny wrote:
> Am Dienstag, den 24.10.2017, 16:44 +0200 schrieb Erik Faye-Lund:
>>
>> dep_unwind = dependency('libunwind', required : false)
>> -if dep_unwind.found()
>> +if dep_unwind.found() and with_libunwin
If we don't want to use these deps, there's no good reason to search
for them in the first place. This should shave a bit of time for the
initial build.
---
This would be a way of dealing with Gert's suggestion. Goes on top
of the previous patch.
Thoughts?
meson.build | 20 ++--
On Tue, Oct 24, 2017 at 11:48 PM, Dylan Baker wrote:
> Quoting Eric Engestrom (2017-10-24 10:32:36)
>> On Tuesday, 2017-10-24 09:40:22 -0700, Dylan Baker wrote:
>> > This seems reasonable, could you wrap the hanging indent like
>> > meson_options with
>> > the closing brace on it's own line and w
On Thu, Oct 26, 2017 at 11:49 AM, Gert Wollny wrote:
>
> Am Mittwoch, den 25.10.2017, 10:24 +0200 schrieb Erik Faye-Lund:
>> If we don't want to use these deps, there's no good reason to search
>> for them in the first place. This should shave a bit of t
This avoids the following build-error when building with emtpy
vulkan-drivers and without glx=dri:
Meson encountered an error in file src/vulkan/wsi/meson.build, line 30,
column 2:
Unknown variable "dep_xcb".
Signed-off-by: Erik Faye-Lund
---
src/meson.build | 4 +++-
1 file
Yeah, I kinda got that feeling. Your approach seems better.
On Oct 27, 2017 19:22, "Dylan Baker" wrote:
This just papers over the actual problem, that dep_xcb isn't declared as an
empty list with the other glx dependencies.
Dylan
Quoting Erik Faye-Lund (2017-10-27 04:55:25)
&g
On Fri, Oct 27, 2017 at 7:25 PM, Dylan Baker wrote:
> This is needed in cases where xcb isn't actually needed as a dependency,
> but may still be included somewhere.
>
> cc: Erik Faye-Lund
> cc: Eric Engestrom
> Signed-off-by: Dylan Baker
Te
The u_format_other.c users sqrtf, which on some systems require
a math-library. So let's make sure we link with it.
Signed-off-by: Erik Faye-Lund
---
I noticed this while debugging something else, thought I'd just send it
upstream directly.
src/gallium/auxiliary/meson.build | 2
This way users don't have to care if these options are boolean or
not, as they take the same values (apart from 'auto').
Signed-off-by: Erik Faye-Lund
---
I'm not quite sure about this patch. Yes, it cleans up the semantics, but
at the same time, it breaks backwards compa
If we don't want to use these deps, there's no good reason to search
for them in the first place. This should shave a bit of time for the
initial build.
Signed-off-by: Erik Faye-Lund
---
meson.build | 20 ++--
meson_options.txt | 14 --
2 files c
On Tue, Oct 31, 2017 at 10:31 AM, Eric Engestrom
wrote:
> On Monday, 2017-10-30 21:06:25 +0100, Erik Faye-Lund wrote:
>> The u_format_other.c users sqrtf, which on some systems require
>> a math-library. So let's make sure we link with it.
>>
>> Signed-off-by:
On Tue, Oct 31, 2017 at 11:33 AM, Erik Faye-Lund wrote:
> On Tue, Oct 31, 2017 at 10:31 AM, Eric Engestrom
> wrote:
>> On Monday, 2017-10-30 21:06:25 +0100, Erik Faye-Lund wrote:
>>> The u_format_other.c users sqrtf, which on some systems require
>>> a math-libra
On Tue, Oct 31, 2017 at 11:24 AM, Eric Engestrom
wrote:
> On Tuesday, 2017-10-31 08:29:28 +0100, Erik Faye-Lund wrote:
>> If we don't want to use these deps, there's no good reason to search
>> for them in the first place. This should shave a bit of time for the
>>
On Tue, Oct 31, 2017 at 12:04 PM, Eric Engestrom
wrote:
> On Tuesday, 2017-10-31 11:37:25 +0100, Erik Faye-Lund wrote:
>> On Tue, Oct 31, 2017 at 11:24 AM, Eric Engestrom
>> wrote:
>> > On Tuesday, 2017-10-31 08:29:28 +0100, Erik Faye-Lund wrote:
>> >> If we d
On Wed, Nov 8, 2017 at 1:07 AM, Brian Paul wrote:
> Use the proper enum types for various variables. Makes life in gdb
> a little nicer. Note that the size of enum bitfields must be one
> larger so the high bit is always zero (for MSVC).
You *could* also do something like this on MSVC to get un
On Sat, Aug 5, 2017 at 11:39 AM, Chris Wilson wrote:
> Map the user format of GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE to the
> internal format of MESA_FORMAT_S_UINT8.
> ---
> src/mesa/main/glformats.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/main/glformats.c b/src/mesa/m
201 - 300 of 768 matches
Mail list logo
