On 08/25/2014 07:19 PM, Eric Anholt wrote:
Tapani Pälli writes:
commit 4e64cfbb4 changed how gl_constant_value bool gets interpreted
with drivers, for swrast driver true should be 1.
Signed-off-by: Tapani Pälli
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82978
Everywhere else in
https://bugs.freedesktop.org/show_bug.cgi?id=82585
Michel Dänzer changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=82585
--- Comment #5 from pa...@klacansky.com ---
Created attachment 105268
--> https://bugs.freedesktop.org/attachment.cgi?id=105268&action=edit
Valgrind output
This is output from valgrind, mesa is from here
https://launchpad.net/~oibaf/+archive/ub
https://bugs.freedesktop.org/show_bug.cgi?id=82585
--- Comment #6 from Michel Dänzer ---
Created attachment 105270
--> https://bugs.freedesktop.org/attachment.cgi?id=105270&action=edit
GLSL dump and backtrace
--
You are receiving this mail because:
You are the assignee for the bug.
__
Am 26.08.2014 um 03:54 schrieb Rob Clark:
On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke wrote:
we've already had problems where distros refused to ship newer Mesa
releases because radeon depended on a version of LLVM newer than the
one they were shipping, [...]
That's news to me, can you be
On 26/08/14 08:41, Tapani wrote:
> On 08/25/2014 07:19 PM, Eric Anholt wrote:
>> Tapani Pälli writes:
>>
>>> commit 4e64cfbb4 changed how gl_constant_value bool gets interpreted
>>> with drivers, for swrast driver true should be 1.
>>>
>>> Signed-off-by: Tapani Pälli
>>> Bugzilla: https://bugs.fr
On 08/26/2014 02:29 PM, Emil Velikov wrote:
On 26/08/14 08:41, Tapani wrote:
On 08/25/2014 07:19 PM, Eric Anholt wrote:
Tapani Pälli writes:
commit 4e64cfbb4 changed how gl_constant_value bool gets interpreted
with drivers, for swrast driver true should be 1.
Signed-off-by: Tapani Pälli
Bu
On 23.08.2014 02:57, Ian Romanick wrote:
> Patches 2, 3, 4, 5, 6, 9, 10, 11, 12, 15, and 17 are
>
> Reviewed-by: Ian Romanick
>
> (Additional question below.)
>
> On 08/18/2014 05:17 AM, Abdiel Janulgue wrote:
>> v3 of clamp and saturate optimizations
>>
>> Changes since v1:
>> - Only remove
https://bugs.freedesktop.org/show_bug.cgi?id=75315
--- Comment #12 from Fabio Pedretti ---
I tried the workaround in 1., adding " -fsanitize=address" to CC and CXX, now
it links with it, however for some reason it still fails with the same error:
https://launchpadlibrarian.net/183204096/buildlog_
Great find Roland.
Patch looks good.
Jose
On 25/08/14 21:05, srol...@vmware.com wrote:
From: Roland Scheidegger
The base instance needs to be passed to the jited function, otherwise the
instanced data fetch will only work with the same start instance when the
jit function was created (and ba
Wrong list(s)? I don't see libclc-dev on the cc list.
Also:
Tested-by: Aaron Watry
On Mon, Aug 25, 2014 at 10:53 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
> utils/prepare-builtins.cpp | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --
https://bugs.freedesktop.org/show_bug.cgi?id=75315
--- Comment #13 from Emil Velikov ---
(In reply to comment #12)
> I tried the workaround in 1., adding " -fsanitize=address" to CC and CXX,
> now it links with it, however for some reason it still fails with the same
> error:
> https://launchpadl
https://bugs.freedesktop.org/show_bug.cgi?id=80561
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 26/08/14 10:04, Christian König wrote:
Am 26.08.2014 um 03:54 schrieb Rob Clark:
On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke
wrote:
we've already had problems where distros refused to ship newer Mesa
releases because radeon depended on a version of LLVM newer than the
one they were shi
Am 26.08.2014 um 18:00 schrieb Jose Fonseca:
On 26/08/14 10:04, Christian König wrote:
Am 26.08.2014 um 03:54 schrieb Rob Clark:
On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke
wrote:
we've already had problems where distros refused to ship newer Mesa
releases because radeon depended on a ve
On 15/08/14 19:33, Emil Velikov wrote:
> On 14/08/14 10:59, Christian König wrote:
>> From: Christian König
>>
>> Correctly handle that the source_surface is only optional.
>>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80561
> Cc: mesa-sta...@lists.freedesktop.org
>
> Would be nice
On 08/25/2014 06:58 PM, Rob Clark wrote:
> On Fri, Aug 22, 2014 at 11:13 AM, Connor Abbott wrote:
>>> Importing/forking the llvm IR code with a different symbol set, and
>>> trying to not intentionally
>>> be incompatible with their llvm.
>>
>> That sounds like a huge amount of work, possibly even
On Tue, Aug 26, 2014 at 12:50 PM, Emil Velikov wrote:
> On 15/08/14 19:33, Emil Velikov wrote:
>> On 14/08/14 10:59, Christian König wrote:
>>> From: Christian König
>>>
>>> Correctly handle that the source_surface is only optional.
>>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80
On 08/25/2014 06:54 PM, Rob Clark wrote:
> tbh, it sounds a lot to me like if we start using LLVM more
> heavily/widely in mesa we should import LLVM (or at least the parts we
> need) into the mesa src tree.. as it is, the logistical/distro issues
> of LLVM have been what has scared me off the most
On 26/08/14 18:01, Ilia Mirkin wrote:
> On Tue, Aug 26, 2014 at 12:50 PM, Emil Velikov
> wrote:
>> On 15/08/14 19:33, Emil Velikov wrote:
>>> On 14/08/14 10:59, Christian König wrote:
From: Christian König
Correctly handle that the source_surface is only optional.
>>> Bugzill
On Tue, Aug 26, 2014 at 1:18 PM, Emil Velikov wrote:
> On 26/08/14 18:01, Ilia Mirkin wrote:
>> On Tue, Aug 26, 2014 at 12:50 PM, Emil Velikov
>> wrote:
>>> On 15/08/14 19:33, Emil Velikov wrote:
On 14/08/14 10:59, Christian König wrote:
> From: Christian König
>
> Correctly ha
Am 26.08.2014 um 18:50 schrieb Emil Velikov:
On 15/08/14 19:33, Emil Velikov wrote:
On 14/08/14 10:59, Christian König wrote:
From: Christian König
Correctly handle that the source_surface is only optional.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80561
Cc: mesa-sta...@lists.f
On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca wrote:
> If LLVM was a useless piece of junk, we wouldn't have any trouble adding it
> as a dependency, as we would be the sole user. But precisely because LLVM
> is successful in so many use cases, hence several packages depend on it, we
> shouldn't
On 26/08/14 18:32, Christian König wrote:
> Am 26.08.2014 um 18:50 schrieb Emil Velikov:
>> On 15/08/14 19:33, Emil Velikov wrote:
>>> On 14/08/14 10:59, Christian König wrote:
From: Christian König
Correctly handle that the source_surface is only optional.
>>> Bugzilla: https:
On 08/23/2014 07:51 AM, Micael wrote:
> On second thought, the glsl_type::uniform_locations() method comment in
> the header file says:
> /**
> * Calculate the number of unique values from glGetUniformLocation for the
> * elements of the type.
> */
>
> Which makes me believe that maybe we shoul
Hello list,
As you may have noticed there are some changes coming in Mesa's releases.
Namely, I will be taking over from Ian and Carl as Mesa's major and stable
release manager.
This will allow us to have timely releases, and will give Ian and Carl more
time to focus on other parts of Mesa.
My i
On 06/08/14 17:16, Alex Deucher wrote:
> On Mon, Aug 4, 2014 at 6:48 AM, Andreas Boll
> wrote:
>> The initial firmware for hawaii does not support type3 nop packet.
>> Detect the new hawaii firmware with query RADEON_INFO_ACCEL_WORKING2.
>> If the returned value is 3, then the new firmware is use
On 01/08/14 17:06, Emil Velikov wrote:
> When the compiler is not capable/does not accept -msse4.1 while the target
> has the instruction set we'll blow up as _mesa_streaming_load_memcpy is
> going to be undefined.
>
> To make sure that never happens, wrap the runtime cpu check+caller in an
> ifde
On 08/08/14 15:16, Tom Stellard wrote:
> CC: "10.2"
> ---
> src/gallium/drivers/r600/r600_pipe.c | 11 ++-
> src/gallium/drivers/radeonsi/si_pipe.c | 7 +++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/r600_pipe.c
> b/src/gallium/dr
While I haven't heard about those projects, there's also GlassyMesa.
Greg from LunarG (CC'd) posted about this to the mailing list. [1]
However it looks like the github activity has stopped,
and there's no new info on the projects website since its announcement.
While it's not exactly the same as
On 08/08/14 15:16, Tom Stellard wrote:
> We were leaking the input buffer used for kernel arguments and since
> we were allocating it using si_upload_const_buffer() we were leaking
> 1 MB per kernel invocation.
>
> CC: "10.2"
> ---
> src/gallium/drivers/radeonsi/si_compute.c | 22 ++-
From: Stefan Dirsch
Let's handle LIBGL_DEBUG env. variable in Mesa in a consistent way.
Fixes: https://bugzilla.novell.com/show_bug.cgi?id=892896
---
To: mesa-dev@lists.freedesktop.org
Cc: "10.3"
openSUSE maintainers: Why can't you forward your applied u_* patches to upstream
On 18/08/14 22:52, Marek Olšák wrote:
> From: Marek Olšák
>
Hi Marek,
Going through the mesa 10.2 patches queue and I cannot see this one ever
making to the list despite the Cc tag. Are you sending the patches with
--suppress-cc by any chance ?
Thanks
Emil
> Cc: mesa-sta...@lists.freedesktop.or
On Tue, Aug 26, 2014 at 4:34 PM, Thomas Helland
wrote:
> While I haven't heard about those projects, there's also GlassyMesa.
> Greg from LunarG (CC'd) posted about this to the mailing list. [1]
> However it looks like the github activity has stopped,
> and there's no new info on the projects webs
On 17/06/14 14:41, Brian Paul wrote:
> On 06/16/2014 07:34 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Previously, calling
>>
>> glGenTextures(1, &t);
>> glBindTexture(GL_TEXTURE_2D, t);
>> glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, 0xDEADBEEF, &value);
>>
>> would not gener
On Tue, Aug 26, 2014 at 12:00 PM, Jose Fonseca wrote:
> On 26/08/14 10:04, Christian König wrote:
>>
>> Am 26.08.2014 um 03:54 schrieb Rob Clark:
>>>
>>> On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke
>>> wrote:
>>
>> we've already had problems where distros refused to ship newer Mesa
>
On 04/07/14 01:57, Carl Worth wrote:
> Fredrik Höglund writes:
>> Cc: "10.1"
>
> (And "10.2" as pushed to master)
>
> Hi Fredrik,
>
Hi Fredrik,
Can you please provide more information about the commit to justify it landing
in the 10.2 stable branch ? AFAICS the original reporter states that
=
> actually we already do the opposite thing in fedora..
>
> you are right, normally distro's prefer to unbundle things.. LLVM is
> kinda "special" (which really should be a warning sign right there)
>
In Fedora we unbundle llvm, in RHEL we create a special package of
llvm for mesa to use, but t
On Tuesday, August 19, 2014 07:37:33 PM Matt Turner wrote:
> On Mon, Aug 18, 2014 at 5:17 AM, Abdiel Janulgue
> wrote:
> > + /* If the last instruction from our accept() generated our
> > +* src, just set the saturate flag instead of emmitting a separate mov.
>
> emitting.
>
> > */
>
On 21/06/14 02:00, Ian Romanick wrote:
> From: Ian Romanick
>
Hello Ian,
Looking at this series and it appears that only patches 1-4 (inclusive) made
it in master. Has the rest of it been super-seeded by other patches or did it
slip through the cracks ?
Imho most (all?) of the series does not a
On 26/08/14 22:23, Emil Velikov wrote:
> On 17/06/14 14:41, Brian Paul wrote:
>> On 06/16/2014 07:34 PM, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> Previously, calling
>>>
>>> glGenTextures(1, &t);
>>> glBindTexture(GL_TEXTURE_2D, t);
>>> glGetTexLevelParameteriv(GL_TEXTURE_
On 08/26/2014 02:56 PM, Emil Velikov wrote:
> On 21/06/14 02:00, Ian Romanick wrote:
>> From: Ian Romanick
>>
> Hello Ian,
>
> Looking at this series and it appears that only patches 1-4 (inclusive) made
> it in master. Has the rest of it been super-seeded by other patches or did it
> slip throug
On 25/08/14 07:51, Thierry Vignaud wrote:
> On 21 August 2014 17:54, Carl Worth wrote:
>> I have verified building from the .tar.bz2 file by doing the following
>> on a Debian (unstable) system:
>>
>> tar xjf MesaLib-10.3.0-rc1.tar.bz2
>> cd Mesa-10.3.0-rc1
>> ./configure --enable-gallium-llvm
>>
On Friday, August 22, 2014 12:59:57 PM Samuel Iglesias Gonsálvez wrote:
> On Thu, 2014-08-14 at 14:28 +0200, Iago Toral Quiroga wrote:
> [...]
> > At this point I'd like to hear suggestions for things we could try next
> > to confirm whether this is a hardware problem or a driver problem, or,
> > i
On 26 August 2014 05:55, wrote:
> From: Roland Scheidegger
>
> The docs were never really up to date for them, missing just about everything.
> So mark them off as all done for GL 3.3 (though softpipe is in fact quite
> broken for some newer things especially wrt texturing, and both don't have
>
On Tue, Aug 26, 2014 at 3:37 PM, Emil Velikov wrote:
> On 25/08/14 07:51, Thierry Vignaud wrote:
>> On 21 August 2014 17:54, Carl Worth wrote:
>>> I have verified building from the .tar.bz2 file by doing the following
>>> on a Debian (unstable) system:
>>>
>>> tar xjf MesaLib-10.3.0-rc1.tar.bz2
>
Apparently guardband clipping doesn't work like we thought: objects
entirely outside fthe guardband are trivially rejected, regardless of
their relation to the viewport. Normally, the guardband is larger than
the viewport, so this is not a problem. However, when the viewport is
larger than the gu
On Monday, August 25, 2014 04:38:53 PM Ian Romanick wrote:
> On 08/14/2014 09:09 AM, Topi Pohjolainen wrote:
> > From: Topi Pohjolainen
> >
> > Fixes gles3 conformance tests:
> >
> > framebuffer_blit_functionality_negative_height_blit
> > framebuffer_blit_functionality_negative_width_blit
> > fr
On Tuesday, August 26, 2014 10:05:35 AM Ian Romanick wrote:
> On 08/25/2014 06:54 PM, Rob Clark wrote:
> > tbh, it sounds a lot to me like if we start using LLVM more
> > heavily/widely in mesa we should import LLVM (or at least the parts we
> > need) into the mesa src tree.. as it is, the logistic
The GlassyMesa effort is ongoing despite the lack of recent activity. We
continue to embrace LLVM as a basis for shader compilation in Mesa and
elsewhere.
We agree that translating from LLVM back "up" to GLSL IR is problematic and
that an architecture that supports LLVM backends would be desirable
On Tuesday, August 26, 2014 06:45:42 PM Greg Fischer wrote:
> The GlassyMesa effort is ongoing despite the lack of recent activity. We
> continue to embrace LLVM as a basis for shader compilation in Mesa and
> elsewhere.
>
> We agree that translating from LLVM back "up" to GLSL IR is problematic a
On 27.08.2014 05:57, Emil Velikov wrote:
On 18/08/14 22:52, Marek Olšák wrote:
From: Marek Olšák
Hi Marek,
Going through the mesa 10.2 patches queue and I cannot see this one ever
making to the list despite the Cc tag. Are you sending the patches with
--suppress-cc by any chance ?
IMO it d
Am 27.08.2014 00:55, schrieb Dave Airlie:
> On 26 August 2014 05:55, wrote:
>> From: Roland Scheidegger
>>
>> The docs were never really up to date for them, missing just about
>> everything.
>> So mark them off as all done for GL 3.3 (though softpipe is in fact quite
>> broken for some newer t
It doesn't seem to support field based decode after testing.
Signed-off-by: Alex Deucher
---
src/gallium/drivers/radeon/radeon_video.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_video.c
b/src/gallium/drivers/radeon/radeon_video.c
index 6dcee45..2e683c4
On Sun, Aug 24, 2014 at 8:32 AM, Christian König
wrote:
> From: Christian König
>
> The first UVD generation can only do frame based output.
>
> Signed-off-by: Christian König
Can someone pick this up for stable?
> ---
> src/gallium/drivers/radeon/radeon_video.c | 7 +--
> 1 file changed,
On 26.08.2014 23:57, Aaron Watry wrote:
Wrong list(s)? I don't see libclc-dev on the cc list.
That's because I didn't know about that list before. :) Submitted there
now, thanks.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast
My apologies for a too-brief response to this question.
GlassyMesa links LLVM statically into Mesa. I believe that previous posters
to this thread have already done a pretty good job of arguing that this is
at least a workable approach.
Best regards,
Greg
On Tue, Aug 26, 2014 at 7:14 PM, Kenne
I think Tom cc'ed the wrong stable maybe, not sure,
10.2 doesn't have PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE, so this
doesn't even build.
You might want to get a build system that builds all the drivers
before applying and fixing up patches.
Dave.
On 27 August 2014 06:24, Emil Velikov wrote:
>
58 matches
Mail list logo
