Rob Clark writes:
> On Tue, Jun 28, 2016 at 11:28 AM, Marek Olšák wrote:
>> On Mon, Jun 27, 2016 at 9:28 PM, Rob Clark wrote:
>>> On Mon, Jun 27, 2016 at 3:06 PM, Kenneth Graunke
>>> wrote:
On Monday,
Nicolai Hähnle writes:
> On 21.06.2016 16:50, Marek Olšák wrote:
>> On Tue, Jun 21, 2016 at 4:40 PM, Nicolai Hähnle wrote:
>>> On 21.06.2016 14:17, Marek Olšák wrote:
From: Marek Olšák
for debugging
---
Vedran Miletić writes:
> On 06/21/2016 03:13 AM, Michel Dänzer wrote:
>> On 21.06.2016 08:17, Vedran Miletić wrote:
[ ... ]
>>
>> P.S. I recommend adding your Signed-off-by for patches you want to be
>> applied.
>>
>
> Will do. Thanks for explaining what that is used for.
>
>
Andres Gomez writes:
> Hi,
>
> as part of the work done to "Add FP64 support to the i965 shader
> backends" at:
> https://bugs.freedesktop.org/show_bug.cgi?id=92760
>
> I've been working to add piglit tests that would check the new features
> added by this addition.
>
> Due to
Ian Romanick writes:
> From: Ian Romanick
>
> I don't understand why the old code was bad, but the new code is fine.
Probably because the *loop counter* can no longer overflow. Thus the
loop can be optimized. The fact that "i" might overflow has
Samuel Pitoiset writes:
> Nested functions are supported as an extension in GNU C, but Clang
> don't support them.
>
> This fixes compilation errors when (manually) building compute.c,
> or by setting --enable-gallium-tests to the configure script.
>
> Bugzilla:
Samuel Iglesias Gonsalvez writes:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92124
> Cc: Jose Fonseca
> ---
>
> I tested it on MSVC but not MinGW. I hope I did not something wrong.
>
> src/mesa/main/shader_query.cpp | 1 +
>
Ilia Mirkin writes:
> On Fri, Sep 11, 2015 at 10:45 PM, Ian Romanick wrote:
>> On 09/11/2015 10:55 AM, Ilia Mirkin wrote:
>>> On Fri, Sep 11, 2015 at 12:36 PM, Marius Predut
>>> wrote:
Comparison with a signed
Marius Predut writes:
> Comparison with a signed expression and unsigned value
> is converted to unsigned value, reason for minus value is interpreted
> as a big unsigned value. For this case the "for" loop
> is going into unexpected behavior.
>
> Bugzilla:
Ilia Mirkin writes:
> On Tue, Sep 1, 2015 at 12:15 PM, Ian Romanick wrote:
>> For a bunch of the small changes, I don't care too much what the
>> difference is. I just want to know whether after is better than before.
>
> And that gets back to my
Ilia Mirkin <imir...@alum.mit.edu> writes:
> On Tue, Sep 1, 2015 at 1:48 AM, Eirik Byrkjeflot Anonsen
> <ei...@eirikba.org> wrote:
>> Ian Romanick <i...@freedesktop.org> writes:
>>
>>> ping. :)
>>>
>>> On 08/10/2015 11:48 AM, Matt Tu
Ian Romanick writes:
> ping. :)
>
> On 08/10/2015 11:48 AM, Matt Turner wrote:
>> On Mon, Aug 10, 2015 at 10:12 AM, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> On many CPU-limited applications, this is *the* hot path.
Francisco Jerez curroje...@riseup.net writes:
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 4:01 PM, Francisco Jerez curroje...@riseup.net
wrote:
Davin McCall dav...@davmac.org writes:
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund kusmab
Davin McCall dav...@davmac.org writes:
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall dav...@davmac.org wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall dav...@davmac.org wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed by any other type than the
type of n itself. This value is then cast to a different pointer
Ilia Mirkin imir...@alum.mit.edu writes:
Hello,
There are a *ton* of branches in the upstream mesa git. Here is a full list:
[...]
is there
any reason to keep these around with the exception of:
master
$version (i.e. 9.0, 10.0, mesa_7_7_branch, etc)
Instead of outright deleting old
Ilia Mirkin imir...@alum.mit.edu writes:
Sure. Fix it in GCC :) disable the bogus warning, whatever. I really really
hate pandering to broken tools, sending the message that it's ok for the
tools to be broken.
While I largely agree with the sentiment, I'm not sure I agree with what
is a
Marek Olšák mar...@gmail.com writes:
I don't understand. Using size_t should prevent the integer overflow.
Is there anything else wrong other than no fail path for malloc? I
also don't understand how calloc can help here.
Marek
size * sizeof(int_attribs[0]) may overflow and thus wrap to a
Kenneth Graunke kenn...@whitecape.org writes:
On 05/31/2012 04:28 PM, Roland Mainz wrote:
On Fri, Jun 1, 2012 at 1:19 AM, Kenneth Graunkekenn...@whitecape.org
wrote:
switch (name) {
case GL_VENDOR:
- return (GLubyte *) Tungsten Graphics, Inc;
+ return (GLubyte *) Intel®
19 matches
Mail list logo