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
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=83195
Kenneth Graunke changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
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=79662
meng changed:
What|Removed |Added
CC||mengmeng.m...@intel.com
--
You are receiving thi
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.
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 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
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
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
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
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.
_
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 #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:
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
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
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
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
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
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_
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.*
https://bugs.freedesktop.org/show_bug.cgi?id=83723
Emil Velikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=83735
Evangelos Foutras changed:
What|Removed |Added
CC||evange...@foutrelis.com
--
You are
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
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.
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 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
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 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
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
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
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
--
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
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
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
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
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
> ++
>
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(+),
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
> > _
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 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
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 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
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
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.
___
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
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
Tested-by: Nick Tenney
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
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/
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
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
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 #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
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
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
61 matches
Mail list logo
