On Wed, 2014-11-19 at 11:57 -0800, Jason Ekstrand wrote:
> A couple of general comments on this patch:
>
>
> 1) The prerequisites should be moved to before the first patch in the
> series and it should be squashed into the patch that introduces the
> function. There are one or two more patches w
On Wed, 2014-11-19 at 11:43 -0800, Jason Ekstrand wrote:
> A couple of specific comments are below. More generally, why are you
> only considering the base format on two cases? Do we never use it for
> anything else?
I thought about that too but when I looked at the original code it
seemed that
Hi Jason,
we discussed this some weeks ago actually, the detailed explanation is
here:
https://bugs.freedesktop.org/show_bug.cgi?id=84566#c5
the short answer is that this is necessary because there is a normalized
parameter to _mesa_swizzle_and_convert, and when we deal with float
types we want t
> The $64,000 question: What do other GLSL compilers (including,
> perhaps,glslang) do?
:) Shouldn't this be the "$1e6f question"?
Jose
From: mesa-dev on behalf of Iago Toral
Sent: 20 November 2014 07:08
To: Ian Romanick
Cc: mesa-dev@lists.freedesktop.
On Wed, 2014-11-19 at 01:15 +, Emil Velikov wrote:
> Hi Iago,
>
> On 18/11/14 08:43, Iago Toral Quiroga wrote:
> [snip]
> > Summary of the patches:
> > * Patches 1-7 are general fixes to the current code that were found while
> >working on this.
> Have you noticed if any of those fixes re
On Tue, 2014-11-18 at 10:34 -0800, Jason Ekstrand wrote:
> In general, I like this patch. However, if we are going to claim to
> follow the GL rule of "Colors are clampped to their representable
> range, then there still seem to be quite a few cases missing. For
> instance, when going from signed
On Tue, 2014-11-18 at 11:05 -0800, Jason Ekstrand wrote:
>
>
> On Tue, Nov 18, 2014 at 12:44 AM, Iago Toral Quiroga
> wrote:
> From: Samuel Iglesias Gonsalvez
>
> We will use this later on to handle uint conversion scenarios
> in a master
> convert funct
On Tue, 2014-11-18 at 11:08 -0800, Jason Ekstrand wrote:
>
>
> On Tue, Nov 18, 2014 at 12:44 AM, Iago Toral Quiroga
> wrote:
> From: Samuel Iglesias Gonsalvez
>
> Signed-off-by: Samuel Iglesias Gonsalvez
>
> ---
> src/mesa/main/format_pack.c.ma
> Does anyone remember if there was a reason that the TGSI_OPCODE_ tokens are
> #defines instead of an enumeration?
I think it was because enums are not allowed in struct bit fields, furthermore
C++ will complain about enum<->int conversion without cast. (IIRC this is the
reason many things in
On Wed, 2014-11-19 at 10:27 -0800, Ian Romanick wrote:
> On 11/19/2014 03:47 AM, Iago Toral Quiroga wrote:
> > Hi,
> >
> > I came across a GLSL test that checks that doing something like this in
> > a shader should fail:
>
> Is this one of the dEQP tests?
Yes.
> > float value = 1f;
>
> It seem
On Wed, Nov 19, 2014 at 10:40:56PM -0800, Ben Widawsky wrote:
> On Wed, Nov 19, 2014 at 09:18:54PM -0800, Kenneth Graunke wrote:
> > On Wednesday, November 19, 2014 02:13:03 PM Ian Romanick wrote:
> > > On 11/18/2014 09:11 PM, Chad Versace wrote:
> > > > This patch should diminish the likelihood of
On Wed, Nov 19, 2014 at 09:18:54PM -0800, Kenneth Graunke wrote:
> On Wednesday, November 19, 2014 02:13:03 PM Ian Romanick wrote:
> > On 11/18/2014 09:11 PM, Chad Versace wrote:
> > > This patch should diminish the likelihood of pointer arithmetic overflow
> > > bugs, like the one fixed by b69c7c5
Hello,
I've been wondering about the best approach to handle UBO values as push
constants. Right now, we always treat them as pull constants, which means
sending messages and hitting memory (or at least the sampler cache) - it's
quite inefficient.
3DSTATE_CONSTANT_* can read a contiguous block o
On Wednesday, November 19, 2014 02:13:03 PM Ian Romanick wrote:
> On 11/18/2014 09:11 PM, Chad Versace wrote:
> > This patch should diminish the likelihood of pointer arithmetic overflow
> > bugs, like the one fixed by b69c7c5dac.
> >
> > Change the type of parameter 'out_stride' from int to ptrdi
https://bugs.freedesktop.org/show_bug.cgi?id=86480
bigtall...@gmail.com changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=86480
Bug ID: 86480
Summary: Mesa 10.4.0-devel implementation error: unexpected
format GL_DEPTH24_STENCIL8 in
_mesa_choose_tex_format()
Product: Mesa
Version: unspecifi
https://bugs.freedesktop.org/show_bug.cgi?id=79039
Bug 79039 depends on bug 78770, which changed state.
Bug 78770 Summary: [SNB bisected]Webglc
conformance/textures/texture-size-limit.html fails
https://bugs.freedesktop.org/show_bug.cgi?id=78770
What|Removed |A
On 11/18/2014 09:11 PM, Chad Versace wrote:
> This patch should diminish the likelihood of pointer arithmetic overflow
> bugs, like the one fixed by b69c7c5dac.
>
> Change the type of parameter 'out_stride' from int to ptrdiff_t. The
> logic is that if you call intel_miptree_map() and use the valu
> The patch attached should do it.
just small nitpick, please drop "/* for radeons */" comment from DP2ADD,
thanks
Reviewed-by: David Heidelberg
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/m
On Wed 19 Nov 2014, Matt Turner wrote:
On Wed, Nov 19, 2014 at 3:35 AM, Kristian Høgsberg wrote:
On Tue, Nov 18, 2014 at 9:02 PM, Chad Versace
wrote:
If a pointer points to raw, untyped memory and is never dereferenced,
then declare it as 'void*' instead of casting it to 'void*'.
Signed-off-
On Wed, Nov 19, 2014 at 3:45 PM, Jose Fonseca wrote:
> On 19/11/14 19:45, Ilia Mirkin wrote:
>>
>> On Wed, Nov 19, 2014 at 2:32 PM, Eric Anholt wrote:
>>>
>>> Eric Anholt writes:
>>>
This series removes a bunch of unused opcodes, mostly from TGSI. It
doesn't go as far as we could poss
On 11/19/2014 11:23 AM, jfons...@vmware.com wrote:
From: José Fonseca
Avoids "warning: command line option ‘-W...’ is valid for Ada/C/ObjC but not for
C++".
---
CMakeLists.txt | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c3e
On 19/11/14 19:45, Ilia Mirkin wrote:
On Wed, Nov 19, 2014 at 2:32 PM, Eric Anholt wrote:
Eric Anholt writes:
This series removes a bunch of unused opcodes, mostly from TGSI. It
doesn't go as far as we could possibly go -- while I welcome discussion
for future patch series deleting more, I
Am 19.11.2014 um 18:21 schrieb Jon TURNEY:
> On 19/11/2014 15:25, Jose Fonseca wrote:
>> No idea. But the impression I generally have is MinGW has come a long
>> way since then (3 years ago.)
>
> I think there was at least one bug in mesa which prevented this from
> working, see commit cedfd79b
A
Some small nitpick below, but otherwise the series is:
Reviewed-by: Roland Scheidegger
Am 19.11.2014 um 19:23 schrieb jfons...@vmware.com:
> From: José Fonseca
>
> I suddenly started seeing many simple GL apps, including wglinfo,
> choosing Microsoft GDI OpenGL implementation, even though hard
On 19/11/14 19:32, Eric Anholt wrote:
Eric Anholt writes:
This series removes a bunch of unused opcodes, mostly from TGSI. It
doesn't go as far as we could possibly go -- while I welcome discussion
for future patch series deleting more, I hope that discussion doesn't
derail the review process
On Wednesday, November 19, 2014 09:15:32 AM Ben Widawsky wrote:
> On Wed, Nov 19, 2014 at 01:28:25AM -0800, Kenneth Graunke wrote:
> > On Tuesday, November 18, 2014 12:35:55 PM Ben Widawsky wrote:
> > > Add support for decoding the new branch control bit. I saw two things
> > > wrong with
> > > th
On Tue, Nov 18, 2014 at 3:23 AM, Iago Toral Quiroga
wrote:
> We have _mesa_swap{2,4} but these do in-place byte-swapping only. The new
> functions receive an extra parameter so we can swap bytes on a source
> input array and store the results in a (possibly different) destination
> array.
>
>
If
General comment: Maybe this would be better in gltypes rather than in
mesa_formats
On Tue, Nov 18, 2014 at 1:23 AM, Iago Toral Quiroga
wrote:
> ---
> src/mesa/main/formats.c | 285
>
> src/mesa/main/formats.h | 3 +
> 2 files changed, 288 inse
Can you remind me again as to what formats hit these paths? I remember you
hitting them, but I'm still not really seeing how it happens.
--Jason
On Tue, Nov 18, 2014 at 1:23 AM, Iago Toral Quiroga
wrote:
> We can have conversions from non-integer types to integer types, so remove
> the assertio
Any reason why you added 2 new functions, instead of just altering the ones
we have and updating where they are used?
On Tue, Nov 18, 2014 at 1:23 AM, Iago Toral Quiroga
wrote:
> We have _mesa_swap{2,4} but these do in-place byte-swapping only. The new
> functions receive an extra parameter so w
A couple of general comments on this patch:
1) The prerequisites should be moved to before the first patch in the
series and it should be squashed into the patch that introduces the
function. There are one or two more patches which also modify it and those
should also be squashed in.
2) I wonder
On Wed, Nov 19, 2014 at 2:32 PM, Eric Anholt wrote:
> Eric Anholt writes:
>
>> This series removes a bunch of unused opcodes, mostly from TGSI. It
>> doesn't go as far as we could possibly go -- while I welcome discussion
>> for future patch series deleting more, I hope that discussion doesn't
>
A couple of specific comments are below. More generally, why are you only
considering the base format on two cases? Do we never use it for anything
else?
On Tue, Nov 18, 2014 at 1:23 AM, Iago Toral Quiroga
wrote:
> Add a dst_internal_format parameter to _mesa_format_convert, that
> represents
Eric Anholt writes:
> This series removes a bunch of unused opcodes, mostly from TGSI. It
> doesn't go as far as we could possibly go -- while I welcome discussion
> for future patch series deleting more, I hope that discussion doesn't
> derail the review process for these changes.
>
> I haven't
I'm not sure what I think about this. Does it make a functional change
other than consistancy?
--Jason
On Tue, Nov 18, 2014 at 1:23 AM, Iago Toral Quiroga
wrote:
> In order to check if a format is normalized Mesa does something like this:
> normalized = !_mesa_is_enum_format_integer(srcFormat);
By and large, this looks good to me. Most of my comments are cosmetic or
suggestions for added documentation. There is one issue that I think is
subtly wrong with integer format conversion but that should be easy to fix.
--Jason
On Tue, Nov 18, 2014 at 1:23 AM, Iago Toral Quiroga
wrote:
> From
This patch is
Reviewed-by: Ian Romanick
On 11/16/2014 05:52 PM, Thomas Helland wrote:
> ---
> src/glsl/opt_minmax.cpp | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
> index 49a816e..466db8c 100644
> --- a/src/glsl/opt_minmax.c
Same whitespace comments as patch 10. With those fixed,
Reviewed-by: Ian Romanick
On 11/16/2014 05:51 PM, Thomas Helland wrote:
> ---
> src/glsl/opt_minmax.cpp | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
> index 0638a12..
On 11/16/2014 05:51 PM, Thomas Helland wrote:
> The spec states that pow is undefined for x < 0.
> Just set the range to correspond to a constant 0
> if this is the case.
It is technically undefined, but I think all hardware either follows the
SM2.0 rules[1] or the SM5 rules[2]. Since a lot of th
On 11/16/2014 05:51 PM, Thomas Helland wrote:
> ---
> src/glsl/opt_minmax.cpp | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
> index 1aa4611..9852dd9 100644
> --- a/src/glsl/opt_minmax.cpp
> +++ b/src/glsl/opt_minmax.cpp
> @@ -3
On 11/16/2014 05:51 PM, Thomas Helland wrote:
> Also handle undefined behaviour for sqrt(x) where x < 0
> and rsq(x) where x <= 0.
>
> This gives us some reduction in instruction count on some
> Dungeon Defenders shaders as they are doing: max(exp(x), 0)
> ---
> src/glsl/opt_minmax.cpp | 17 +
On 11/16/2014 05:51 PM, Thomas Helland wrote:
> ---
> src/glsl/opt_minmax.cpp | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
> index b925aaa..a48d4d8 100644
> --- a/src/glsl/opt_minmax.cpp
> +++ b/src/glsl/opt_minmax.cpp
> @@
On Wed, Nov 19, 2014 at 10:43 AM, Ian Romanick wrote:
> On 11/16/2014 05:51 PM, Thomas Helland wrote:
> > They are bound between -1 and 1, so report that.
> > ---
> > src/glsl/opt_minmax.cpp | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/src/glsl/opt_minmax.cpp b/s
On 11/16/2014 05:51 PM, Thomas Helland wrote:
> We can use the intersection function to reduce the range
> even further if the operand has bounds between 0.0 and 1.0.
> ---
> src/glsl/opt_minmax.cpp | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/glsl/opt_minmax.cpp b/src/glsl
On 11/16/2014 05:51 PM, Thomas Helland wrote:
> They are bound between -1 and 1, so report that.
> ---
> src/glsl/opt_minmax.cpp | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
> index 111d183..341006e 100644
> --- a/src/gl
From: José Fonseca
Avoids "warning: command line option ‘-W...’ is valid for Ada/C/ObjC but not for
C++".
---
CMakeLists.txt | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c3e217f..57a46f8 100644
--- a/CMakeLists.txt
+++ b/CMakeLi
On 11/16/2014 05:51 PM, Thomas Helland wrote:
> This will make expansion easier and less cluttered.
> ---
> src/glsl/opt_minmax.cpp | 19 ++-
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
> index 89970d5..111d
On 11/16/2014 07:41 PM, Matt Turner wrote:
> On Sun, Nov 16, 2014 at 5:51 PM, Thomas Helland
> wrote:
>> Add functions:
>> is_greater_than_one
>> is_less_than_zero
>>
>> Add variations like greater_than_or_equal_zero.
>> ---
>> This is not ideal computation-wise, as we are doing two
>> iterati
On 11/16/2014 05:51 PM, Thomas Helland wrote:
> This will allow for less code duplication.
> I'll be using this in opt_minmax in the coming commits.
> ---
> src/glsl/ir_constant_util.h | 122
>
> src/glsl/opt_algebraic.cpp | 88 +-
From: José Fonseca
Prevents warnings on MinGW due to conflicting linkage types for errno.
---
src/fp/fp-tri.c | 8
src/tests/arbfpspec.c| 14 +++---
src/tests/arbfptest1.c | 8
src/tests/arbvptest1.c |
On 11/19/2014 03:47 AM, Iago Toral Quiroga wrote:
> Hi,
>
> I came across a GLSL test that checks that doing something like this in
> a shader should fail:
Is this one of the dEQP tests?
> float value = 1f;
It seems like we have a test related to this in piglit somewhere... it
looks like tests/
From: José Fonseca
I suddenly started seeing many simple GL apps, including wglinfo,
choosing Microsoft GDI OpenGL implementation, even though hardware
accelerated pixel formats were available.
It turned out that:
- the screen was in 16bpp mode (some WHCK tests have the nasty habit
of doing th
On Wed, Nov 19, 2014 at 12:42:45PM -0500, Ilia Mirkin wrote:
> On Wed, Nov 19, 2014 at 12:28 PM, Damien Lespiau
> wrote:
> > On Wed, Nov 19, 2014 at 12:13:41PM -0500, Ilia Mirkin wrote:
> >> Hey guys,
> >>
> >> Just got around to looking at the Coverity email about newly
> >> introduced bugs, and
On Wed, Nov 19, 2014 at 12:28 PM, Damien Lespiau
wrote:
> On Wed, Nov 19, 2014 at 12:13:41PM -0500, Ilia Mirkin wrote:
>> Hey guys,
>>
>> Just got around to looking at the Coverity email about newly
>> introduced bugs, and this seems like a legit issue. Based on the
>> context of the code, I'm gue
On Wed, Nov 19, 2014 at 3:35 AM, Kristian Høgsberg wrote:
> On Tue, Nov 18, 2014 at 9:02 PM, Chad Versace
> wrote:
>> If a pointer points to raw, untyped memory and is never dereferenced,
>> then declare it as 'void*' instead of casting it to 'void*'.
>>
>> Signed-off-by: Chad Versace
>> ---
>>
On Wed, Nov 19, 2014 at 12:13:41PM -0500, Ilia Mirkin wrote:
> Hey guys,
>
> Just got around to looking at the Coverity email about newly
> introduced bugs, and this seems like a legit issue. Based on the
> context of the code, I'm guessing you meant to do (input_index - 16)
> << 1.
Oh my. The pr
On 19/11/2014 15:25, Jose Fonseca wrote:
No idea. But the impression I generally have is MinGW has come a long
way since then (3 years ago.)
I think there was at least one bug in mesa which prevented this from
working, see commit cedfd79b
___
mesa-d
On Wed, Nov 19, 2014 at 01:28:25AM -0800, Kenneth Graunke wrote:
> On Tuesday, November 18, 2014 12:35:55 PM Ben Widawsky wrote:
> > Add support for decoding the new branch control bit. I saw two things wrong
> > with
> > the existing code.
> >
> > 1. It didn't bother trying to decode the bit.
>
Hey guys,
Just got around to looking at the Coverity email about newly
introduced bugs, and this seems like a legit issue. Based on the
context of the code, I'm guessing you meant to do (input_index - 16)
<< 1.
Cheers,
-ilia
** CID 1251308: Bad bit shift operation (BAD_SHIFT)
/src/mesa/driv
No idea. But the impression I generally have is MinGW has come a long
way since then (3 years ago.)
I just noticed this while doing `git grep MINGW`. Because ideally we
should have very little things that depend on __MINGW32__ -- _WIN32 (ie.
platform), or __GNUC__ or _MSC_VER (ie compiler) ma
Reviewed-by: Roland Scheidegger
Do you know if that's due to MinGW changes or something else why it no
longer causes crashes?
Roland
Am 19.11.2014 um 13:10 schrieb jfons...@vmware.com:
> From: José Fonseca
>
> This reverts f4dd0991719ef3e2606920c5100b372181c60899.
>
> The src/gallium/tests/u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/11/14 19:54, Jason Ekstrand wrote:
> On Tue, Nov 18, 2014 at 12:43 AM, Iago Toral Quiroga
> wrote:
>
>> From: Jason Ekstrand
>>
>> We were auto-generating it before. The problem was that the autogeneration
>> tool we were using was called "co
On 19 November 2014 01:55, Marek Olšák wrote:
> Before we start discussing what we can do about the OpenGL API
> overhead, we must get rid of the on-demand shader compilation. It's
> unacceptable to compile shaders when we should be rendering. This is
> one of the things that Nine fixes. I assume
On 19 November 2014 00:26, Emil Velikov wrote:
> From a quick look at MSDN it seems to me that going the DDI (like) route
> would require substantial rework on the wine side. How much contribution
> from wine can we expect ? Would you have the chance to help with
> design/coding, or would you be (
From: José Fonseca
This reverts f4dd0991719ef3e2606920c5100b372181c60899.
The src/gallium/tests/unit/translate_test.c gives the same results on
MinGW 64-bits as on Linux 64-bits. And since MinGW is often used for
development/testing due to its convenience, it's better not to have this
sort of d
Hi,
I came across a GLSL test that checks that doing something like this in
a shader should fail:
float value = 1f;
However, this works fine in Mesa. Checking the spec I see:
Floating-point constants are defined as follows.
floating-constant:
fractional-constant exponent-part(o
On Tue, Nov 18, 2014 at 9:02 PM, Chad Versace
wrote:
> If a pointer points to raw, untyped memory and is never dereferenced,
> then declare it as 'void*' instead of casting it to 'void*'.
>
> Signed-off-by: Chad Versace
> ---
> src/mesa/drivers/dri/i965/intel_copy_image.c | 8
> 1 file
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/11/14 09:28, Michel Dänzer wrote:
> On 18.11.2014 17:43, Iago Toral Quiroga wrote:
>> From: Jason Ekstrand
>
> The commit short log (first line of the commit log) should at least say
> 'snorm_to_float' instead of 'one of the format helper fu
Am 18.11.2014 um 23:31 schrieb Emil Velikov :
> Hmm the binaries do not seem to match the source. Am I missing something ?
Not sure. As you can see I've last touched them in January. It is possible that
I have changed some things in the code and not updated the binaries on the
server. I recommen
The hardware only supports 0..15 constant buffers, but
R600_GS_RING_CONST_BUFFER has index 16, which isn't really a constant
buffer. Maybe that's related to GS stability issues somehow?
Marek
On Wed, Nov 19, 2014 at 7:18 AM, Dave Airlie wrote:
> Hey,
>
> I got piglit to run on my laptop rv635,
>
This patch should diminish the likelihood of pointer arithmetic overflow
bugs, like the one fixed by b69c7c5dac.
Change the type of parameter 'out_stride' from int to ptrdiff_t. The
logic is that if you call intel_miptree_map() and use the value of
'out_stride', then you must be doing pointer arit
The pointer arithmetic overflow bug that led me to make commit b69c7c5dac, in
addition to crashing Google Chrome, had another side-effect: It filled me with
paranoia that i965 may be riddled with pointer arithmetic overflow.
So I went on a witch hunt. I grepped i965 for "->virtual\>" and
"intel_mi
This patch reduces the likelihood of pointer arithmetic overflow bugs in
gather_oa_results(), like the one fixed by b69c7c5dac.
I haven't yet encountered any overflow bugs in the wild along this
patch's codepath. But I get nervous when I see code patterns like this:
(void*) + (int) * (int)
I
This patch reduces the likelihood of pointer arithmetic overflow bugs in
gather_oa_results(), like the one fixed by b69c7c5dac.
I haven't yet encountered any overflow bugs in the wild along this
patch's codepath. But I get nervous when I see code patterns like this:
(void*) + (int) * (int)
I
The pointer arithmetic overflow bug that led me to make commit b69c7c5dac, in
addition to crashing Google Chrome, had another side-effect: It filled me with
paranoia that i965 may be riddled with pointer arithmetic overflow.
So I went on a witch hunt. I grepped i965 for "->virtual\>" and
"intel_mi
This patch should diminish the likelihood of pointer arithmetic overflow
bugs, like the one fixed by b69c7c5dac.
Change the type of parameter 'out_stride' from int to ptrdiff_t. The
logic is that if you call intel_miptree_map() and use the value of
'out_stride', then you must be doing pointer arit
If a pointer points to raw, untyped memory and is never dereferenced,
then declare it as 'void*' instead of casting it to 'void*'.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/intel_copy_image.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/dri
If a pointer points to raw, untyped memory and is never dereferenced,
then declare it as 'void*' instead of casting it to 'void*'.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/intel_copy_image.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/dri
On Tuesday, November 18, 2014 12:35:55 PM Ben Widawsky wrote:
> Add support for decoding the new branch control bit. I saw two things wrong
> with
> the existing code.
>
> 1. It didn't bother trying to decode the bit.
> - While we do not *intentionally* emit this bit today, I think it's
> inter
On 19/11/14 08:29, Iago Toral wrote:
On Wed, 2014-11-19 at 17:09 +0900, Michel Dänzer wrote:
On 18.11.2014 17:43, Iago Toral Quiroga wrote:
For software drivers we worked with a trimmed set of piglit tests (related to
format conversion), ~5700 tests selected with the following filter:
-t form
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/11/14 09:25, Iago Toral wrote:
> On Tue, 2014-11-18 at 13:41 -0800, Jason Ekstrand wrote:
>> Iago,
>>
>> Most of this looks pretty good to me. The one primary concern I have
>> is in the handling of integer formats. I made the comment in a co
On Wed, 2014-11-19 at 17:09 +0900, Michel Dänzer wrote:
> On 18.11.2014 17:43, Iago Toral Quiroga wrote:
> >
> > For software drivers we worked with a trimmed set of piglit tests (related
> > to
> > format conversion), ~5700 tests selected with the following filter:
> >
> > -t format -t color -t t
On 18.11.2014 17:43, Iago Toral Quiroga wrote:
> From: Jason Ekstrand
The commit short log (first line of the commit log) should at least say
'snorm_to_float' instead of 'one of the format helper functions'. It could
probably have a more informative summary of what the change does as well.
>
On Tue, 2014-11-18 at 13:41 -0800, Jason Ekstrand wrote:
> Iago,
>
> Most of this looks pretty good to me. The one primary concern I have
> is in the handling of integer formats. I made the comment in a couple
> of patches, but I'll make it in general here. In a lot of the code,
> when you conv
On 18.11.2014 17:43, Iago Toral Quiroga wrote:
For software drivers we worked with a trimmed set of piglit tests (related to
format conversion), ~5700 tests selected with the following filter:
-t format -t color -t tex -t image -t swizzle -t clamp -t rgb -t lum -t pix
-t fbo -t frame
Any part
86 matches
Mail list logo
