So far we have been using CL_INVOCATION_COUNT to resolve this query but this
is no good with streams, as only stream 0 reaches the clipping stage.
>From ARB_transform_feedback3:
"When a generated primitive query for a vertex stream is active, the
primitives-generated count is incremented every t
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
This might help for investigating DMA related bugs.
src/gallium/drivers/radeonsi/si_dma.c | 103 ++
1 file changed, 41 insertions(+), 62 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_dma.c
b/src
https://bugs.freedesktop.org/show_bug.cgi?id=83669
--- Comment #4 from Marc Dietrich ---
the gcc info page reports
Link-time optimization does not work well with generation of debugging
information. Combining -flto with -g is currently experimental and
expected to produce unexpected re
https://bugs.freedesktop.org/show_bug.cgi?id=83669
--- Comment #5 from Emil Velikov ---
How do you detect/fix the following examples
* export CFLAGS="-g" && ./configure --enable-lto --disable-debug && make
* ./configure --enable-lto --disable-debug && make CFLAGS="-g"
While the first one is ver
https://bugs.freedesktop.org/show_bug.cgi?id=83669
--- Comment #6 from Marc Dietrich ---
anyone who specifies special CFLAGS is on his own anyway. This also includes
CFLAGS="-flto" even now. So we can only support configure options and ignore
user specified CFLAGS (ok, configure could check this
Also fixes two sided lighting which was broken at least
on pre-evergreen by commit b1eb00.
Signed-off-by: Glenn Kennard
---
Changes since patch v2:
Added workarounds for known hardware issues on R600 and RV770 when
sample shading is used together with hyperz, thanks Marek.
Changes since patch v1
From: Michel Dänzer
Fixes GPUVM faults when running the piglit test "getteximage-formats
init-by-rendering" with R600_DEBUG=forcedma on SI.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/si_dma.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/
On Sat, 06 Sep 2014 04:00:01 +0200, Alexandre Demers
wrote:
Thanks Marek, you were right.
So, on cayman, after comparing results from both runs, it seems there is
only one regression which is gs-atan-vec2 under glsl-1.50:
piglit/bin/shader_runner
/home/ademers/projects/display/piglit/gen
Tested-by: Nick Tenney
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 09/10/2014 09:32 AM, Francisco Jerez wrote:
Tapani Pälli writes:
Patch modifies is_loop_constant() to take advantage of 'read_only' bit
in ir_variable to detect a loop constant. Variables marked read-only
are loop constant like mentioned by a comment in the function.
Signed-off-by: Tapani
https://bugs.freedesktop.org/show_bug.cgi?id=83669
--- Comment #7 from Marc Dietrich ---
turns out that we need to specify -msse4.1 to certain LDFLAGS (patch below),
but I guess this crashes on platforms not supporting sse4.1.
diff --git a/src/gallium/targets/dri/Makefile.am
b/src/gallium/target
https://bugs.freedesktop.org/show_bug.cgi?id=83669
--- Comment #8 from Marc Dietrich ---
ok, it doesn't crash here (athlon II) which does not support it. Otherwise
compiles file with -flto and heaven 4.0 test run.
--
You are receiving this mail because:
You are the assignee for the bug.
___
Hello all,
The original plan from Ian was to have four release candidates prior to the
final release. From what I can see there has been no serious amount of patches
nominated for 10.3-rc4, so I'm planning to keep with the plan and release 10.3
this Friday.
If you know of any serious issues that
On Wed, Sep 10, 2014 at 12:03 AM, Michel Dänzer wrote:
> On 10.09.2014 01:28, Alex Deucher wrote:
>>
>> On Mon, Sep 8, 2014 at 9:15 PM, Michel Dänzer wrote:
>>>
>>> On 09.09.2014 09:47, Michel Dänzer wrote:
On 09.09.2014 02:36, Alex Deucher wrote:
>
>
> Updated version with
Reviewed-by: Marek Olšák
Marek
On Wed, Sep 10, 2014 at 10:54 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
>
> This might help for investigating DMA related bugs.
>
> src/gallium/drivers/radeonsi/si_dma.c | 103
> ++
>
On Tue, Sep 9, 2014 at 11:38 PM, Michel Dänzer wrote:
> On 10.09.2014 05:08, Tom Stellard wrote:
>>
>> v2:
>>- Write RASTER_CONFIG for all SEs.
>>
>> v3:
>>- Set GRBM_GFX_INDEX.INSTANCE_BROADCAST_WRITES bit.
>>- Set GRBM_GFX_INFEX.SH_BROADCAST_WRITES bit when done setting
>> PA_SC
v2:
- Write RASTER_CONFIG for all SEs.
v3:
- Set GRBM_GFX_INDEX.INSTANCE_BROADCAST_WRITES bit.
- Set GRBM_GFX_INFEX.SH_BROADCAST_WRITES bit when done setting
PA_SC_RASTER_CONFIG.
- Get num_se and num_sh_per_se from kernel.
v4:
- Get correct value for num_se
- Remove loop for setti
On Tue, Sep 09, 2014 at 10:00:47PM +0100, Emil Velikov wrote:
> > I didn't try to upstream this yet, since I wasn't convinced about the full
> > correctness of the patch. It doesn't make use of a threshold and a verbose
> > level which is done in src/glx/dri_common.c:dri_message(). Looking at
> > _
MSVC replaces the "F" in "255.0F" with the macro argument which leads
to an error. s/F/FLT/ to avoid that.
It turns out we weren't using this macro at all on MSVC until the
recent "mesa: Drop USE_IEEE define." change.
---
src/mesa/main/macros.h |9 +
1 file changed, 5 insertions(+),
LGTM, but I have a comments below.
Grigori
On 10.09.2014 10:54, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
>
> This might help for investigating DMA related bugs.
>
> src/gallium/drivers/radeonsi/si_dma.c | 103
> ++
>
On Wed, 2014-09-10 at 16:11 +1000, Jonathan Gray wrote:
> 181581280bd430d122d416e308c1de82db82da04 changed the way the
> llvm-config version is read from sed to grep and introduced
> a requirement for gnu grep extension that treats BREs as EREs.
>
> Avoid this by calling egrep instead of grep whic
On Wed, Sep 10, 2014 at 04:11:25PM +1000, Jonathan Gray wrote:
> 181581280bd430d122d416e308c1de82db82da04 changed the way the
> llvm-config version is read from sed to grep and introduced
> a requirement for gnu grep extension that treats BREs as EREs.
>
I've pushed this, thanks.
-Tom
> Avoid t
Reviewed-by: Roland Scheidegger
Am 10.09.2014 16:21, schrieb Brian Paul:
> MSVC replaces the "F" in "255.0F" with the macro argument which leads
> to an error. s/F/FLT/ to avoid that.
>
> It turns out we weren't using this macro at all on MSVC until the
> recent "mesa: Drop USE_IEEE define." ch
https://bugs.freedesktop.org/show_bug.cgi?id=83723
Priority: low
Bug ID: 83723
Assignee: mesa-dev@lists.freedesktop.org
Summary: megadriver hardlinks problems
Severity: normal
Classification: Unclassified
OS: All
Re
https://bugs.freedesktop.org/show_bug.cgi?id=83669
--- Comment #9 from Fabio Pedretti ---
Debug packages on distributions, at least on Debian and Ubuntu, are not
properly working anyway since megadrivers. I added a bug to document this here:
https://bugs.freedesktop.org/show_bug.cgi?id=83723
--
Could someone take a short look?
It should be possible to validate it by looking at the other similar code
paths:
i.e look at intel_from_planar and intel_create_image_from_renderbuffer and
intel_create_image_from_name
each of those contain this call...
On Wed, Aug 27, 2014 at 9:36 AM, Andreas Pok
On Wed, Sep 10, 2014 at 5:45 AM, Emil Velikov wrote:
> Hello all,
>
> The original plan from Ian was to have four release candidates prior to the
> final release. From what I can see there has been no serious amount of patches
> nominated for 10.3-rc4, so I'm planning to keep with the plan and rel
On 09/10/2014 07:21 AM, Brian Paul wrote:
> MSVC replaces the "F" in "255.0F" with the macro argument which leads
> to an error. s/F/FLT/ to avoid that.
>
> It turns out we weren't using this macro at all on MSVC until the
> recent "mesa: Drop USE_IEEE define." change.
> ---
> src/mesa/main/macr
From: Christian König
This allows us to clear the video buffers using the gfx engine(s).
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c| 46 +++---
src/gallium/drivers/radeon/radeon_vce.c| 17 +
src/gallium/drivers/radeon/rade
On Wednesday, September 10, 2014 10:16:13 AM Iago Toral Quiroga wrote:
> So far we have been using CL_INVOCATION_COUNT to resolve this query but this
> is no good with streams, as only stream 0 reaches the clipping stage.
>
> From ARB_transform_feedback3:
>
> "When a generated primitive query for
On Wed, Sep 10, 2014 at 2:23 PM, Christian König
wrote:
> From: Christian König
>
> This allows us to clear the video buffers using the gfx engine(s).
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/radeon_uvd.c| 46 +++
On 09/10/2014 12:02 PM, Ian Romanick wrote:
On 09/10/2014 07:21 AM, Brian Paul wrote:
MSVC replaces the "F" in "255.0F" with the macro argument which leads
to an error. s/F/FLT/ to avoid that.
It turns out we weren't using this macro at all on MSVC until the
recent "mesa: Drop USE_IEEE define.
https://bugs.freedesktop.org/show_bug.cgi?id=83735
Priority: medium
Bug ID: 83735
Assignee: mesa-dev@lists.freedesktop.org
Summary: [mesa-10.2.x] broken with llvm-3.5 and old CPUs
Severity: blocker
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=83735
Evangelos Foutras changed:
What|Removed |Added
CC||evange...@foutrelis.com
--
You are
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 10/09/14 18:16, Kristian Høgsberg wrote:
> On Wed, Sep 10, 2014 at 5:45 AM, Emil Velikov
> wrote:
>> Hello all,
>>
>> The original plan from Ian was to have four release candidates prior to the
>> final release. From what I can see there has been no serious amount of
>> patches
>> nominated f
Sorry, the function is too confusing for me to understand it, but it looks good.
I think it would be cleaner to convert all parameters of the
compressed texture copy into a non-compressed texture copy at the
beginning of si_dma_copy, with the box being (x/4, y/4, w/4, h/4),
i.e. blitting whole blo
On Wed, Sep 10, 2014 at 2:39 PM, Emil Velikov wrote:
> On 10/09/14 18:16, Kristian Høgsberg wrote:
>> On Wed, Sep 10, 2014 at 5:45 AM, Emil Velikov
>> wrote:
>>> Hello all,
>>>
>>> The original plan from Ian was to have four release candidates prior to the
>>> final release. From what I can see
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
>>>
>>> According to GLSL-ES Spec(i.e. 1.0, 3.0), gl_Position value is undefined
>>> after the vertex processing stage if
https://bugs.freedesktop.org/show_bug.cgi?id=83723
Emil Velikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
This series fixes some of the bugs that I have recently found via my UBO
test generator. These are basically all cases where lower_ubo_reference
and the linker disagree about the layout of the UBO (and the linker was
correct).
No regressions on a run of
./glcts --deqp-case=ES3-CTS.gtf.GL3Tests.*
From: Ian Romanick
Per rule #9, the size of the structure is vec4 aligned. The MAX2 in the
loop ensures that sizes >= 16 bytes are vec4 aligned. The new MAX2
after the loop ensures that sizes < 16 bytes are vec4 aligned.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_
From: Ian Romanick
Whether or not the field is row-major (because it might be a bvec2 or
something) does not affect the array itself. We need to know whether an
array element in its entirety is row-major.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83506
From: Ian Romanick
Previously the linker would correctly calculate the layout, but the
lower_ubo_reference pass would not apply correct alignment to fields
following small (less than 16-byte) nested structures.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=8
From: Ian Romanick
If the thing being dereferenced is a record or an array of records, it
should be treated as row-major. The ir_type_derference_record path
already does this, and I think I intended to do the same for this path
in b17a4d5d.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.fr
In the non-indirect draw case, we call intel_upload_data to upload
gl_BaseVertex. It makes brw->draw.draw_params_bo point to the upload
buffer, and increments the upload BO reference count.
So, we need to unreference it when making brw->draw.draw_params_bo point
at something else, or else we'll r
We always uploaded them together, mostly out of laziness - both required
an additional vertex element. However, gl_VertexID now also requires an
additional vertex buffer for storing gl_BaseVertex; for non-indirect
draws this also means uploading (a small amount of) data. This is extra
overhead we
https://bugs.freedesktop.org/show_bug.cgi?id=83735
--- Comment #1 from Evangelos Foutras ---
Created attachment 106091
--> https://bugs.freedesktop.org/attachment.cgi?id=106091&action=edit
[PATCH 1/2] gallivm: Disable workaround for PR12833 on LLVM 3.2+
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=83735
--- Comment #2 from Evangelos Foutras ---
Created attachment 106092
--> https://bugs.freedesktop.org/attachment.cgi?id=106092&action=edit
[PATCH 2/2] gallivm: set mcpu when initializing llvm execution engine
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=83735
--- Comment #3 from Evangelos Foutras ---
I have attached patches from the master branch. The second patch is slightly
modified to apply to the 10.2 branch.
--
You are receiving this mail because:
You are the assignee for the bug.
_
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
According to GLSL-ES Spec(i.e. 1.0, 3.0), gl_Positio
Reviewed-by: Marek Olšák
Marek
On Tue, Sep 9, 2014 at 6:03 PM, Brian Paul wrote:
> If the glx/wgl state tracker requested a core profile but the gallium
> driver did not support some feature of GL 3.1 or later, we were setting
> ctx->Version=0 and then failing the assertion in
> _mesa_initializ
https://bugs.freedesktop.org/show_bug.cgi?id=83570
--- Comment #12 from rcond...@hotmail.com ---
Roland,
Perhaps you can help me here. I'm looking at udiv_emit_cpu and I'm just not
getting it. The comment says:
/* udiv by zero is guaranteed to return 0x */
but the way I read it, udiv b
On 11.09.2014 03:23, Christian König wrote:
From: Christian König
This allows us to clear the video buffers using the gfx engine(s).
Please split up this patch:
1. Use more common buffer infrastructure, otherwise no (intended)
change in functionality
2. Clear video buffers with the GPU in
From: Ian Romanick
If the source is not a GRF, it could have a register >= virtual_grf_count.
Accessing virtual_grf_end with such a register would lead to
out-of-bounds access. Make sure the source is a GRF before accessing
virtual_grf_end.
Fixes gles3conform failure in:
ES3-CTS.shaders.struct
On 09/10/2014 06:01 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> If the source is not a GRF, it could have a register >= virtual_grf_count.
> Accessing virtual_grf_end with such a register would lead to
> out-of-bounds access. Make sure the source is a GRF before accessing
> virtual_grf_end.
https://bugs.freedesktop.org/show_bug.cgi?id=79662
meng changed:
What|Removed |Added
CC||mengmeng.m...@intel.com
--
You are receiving thi
With GLES we don't give any kind of warning in case we don't
write to gl_position. This patch makes changes so that we
generate a warning in case of GLES (VER < 300) and an error
in case of GL.
Signed-off-by: Kalyan Kondapally
---
src/glsl/linker.cpp | 11 +--
1 file changed, 9 inserti
https://bugs.freedesktop.org/show_bug.cgi?id=83195
Kenneth Graunke changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
Ian,
I will shortly send a changeset incorporating the changes, thanks for
summarizing.
On Tuesday, September 09, 2014 16:11:45 Ian Romanick wrote:
> I also second Marek's comment about testing. My recollection from
> Khronos meetings is that at least AMD GL 3.x-class hardware can only
> handl
https://bugs.freedesktop.org/show_bug.cgi?id=79662
lu hua changed:
What|Removed |Added
Summary|[DRI3 all Bisected] Many|[DRI3 all Bisected] Many
|web
61 matches
Mail list logo
