On Fri, Jun 7, 2013 at 12:37 AM, Marek Olšák wrote:
> There are bugs in both piglit and DRI2. I haven't looked into the
> issue, but Paul Berry seems to be working on it.
>
> See:
> http://lists.freedesktop.org/archives/piglit/2013-May/005880.html
> http://lists.freedesktop.org/archives/mesa-dev/2
Fixes "Logically dead code" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/glsl/ir_reader.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ir_reader.cpp b/src/glsl/ir_reader.cpp
index b366712..51534ca 100644
--- a/src/glsl/ir_reader.cpp
+++ b/src/g
Signed-off-by: Chia-I Wu
---
src/gallium/auxiliary/util/u_vbuf.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_vbuf.c
b/src/gallium/auxiliary/util/u_vbuf.c
index 244b04d..5936f74 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++ b/src/gallium/auxiliar
On 06/06/2013 02:56 PM, Eric Anholt wrote:
Part of fixing piglit OpenGL ES 3.0/minmax.
---
src/mesa/main/get.c | 3 ++-
src/mesa/main/get_hash_params.py | 8
2 files changed, 6 insertions(+), 5 deletions(-)
Series looks good to me.
Reviewed-by: Kenneth Graunke
_
On 06/06/2013 05:32 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
These functions must clear all bound layers, not just the first.
---
src/gallium/auxiliary/util/u_surface.c | 190 +--
src/gallium/auxiliary/util/u_transfer.c |1 +
2 files changed,
From: Roland Scheidegger
These functions must clear all bound layers, not just the first.
---
src/gallium/auxiliary/util/u_surface.c | 190 +--
src/gallium/auxiliary/util/u_transfer.c |1 +
2 files changed, 104 insertions(+), 87 deletions(-)
diff --git a/src/ga
From: Roland Scheidegger
Believe it or not but these two are actually the first two functions which
really belong in this file nowadays.
---
src/gallium/drivers/llvmpipe/lp_surface.c | 59 -
src/gallium/drivers/llvmpipe/lp_texture.c | 59 +-
From: Roland Scheidegger
Transfers always use z/depth for layers no matter if it's a 1d or 2d array
texture, we don't follow OpenGL's crazyness there. Luckily this appears to
only be a doc bug, everyone doing the right thing already.
While here also document z/depth parameter for cube map arrays.
On Thu, Jun 6, 2013 at 2:56 PM, Eric Anholt wrote:
> Part of fixing piglit OpenGL ES 3.0/minmax.
> ---
> src/mesa/main/get.c | 3 ++-
> src/mesa/main/get_hash_params.py | 8
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/main/get.c b/src/mesa/ma
There are bugs in both piglit and DRI2. I haven't looked into the
issue, but Paul Berry seems to be working on it.
See:
http://lists.freedesktop.org/archives/piglit/2013-May/005880.html
http://lists.freedesktop.org/archives/mesa-dev/2013-May/039985.html
Marek
On Fri, Jun 7, 2013 at 12:04 AM, Ma
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced()
---
v5: combined patches together
src/gallium/auxiliary/draw/draw_context.h | 11 -
src/gallium/auxiliary/draw/draw_pt.c | 40 ---
src/mesa/state_tracker/st_draw_feedback.c | 24
I get random results when I run the spec/!OpenGL 1.1/read-front test.
Sometimes it passes and sometimes it failes, it mostly fails though.
When it fails the observed values are random. I have an AMD 6950,
running mesa git ce67fb4715e0c2fab01de33da475ef4705622020 and kernel
3.10-rc4.
If I insert a
Brian Paul writes:
> On 06/06/2013 11:16 AM, Eric Anholt wrote:
>> Just like we produce from inside the Intel driver, this can help provide
>> information quickly about FBO incompatibility problems (particularly when
>> using apitrace replay).
>>
>> Currently, in driver-marked incompleteness case
Part of fixing piglit OpenGL ES 3.0/minmax.
---
src/mesa/main/get.c | 6 ++
src/mesa/main/get_hash_params.py | 6 --
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 316d453..b14c9f7 100644
--- a/src/mesa/main/get.
piglit OpenGL ES 3.0/minmax now passes. This was also one of the subcase
failures in OpenGL 3.2/minmax (and still is, because our value is too low
for 3.2, but at least we report what it is).
---
src/mesa/main/get.c | 7 +++
src/mesa/main/get_hash_params.py | 3 +++
2 files chang
Part of fixing piglit OpenGL ES 3.0/minmax.
---
src/mesa/main/get.c | 3 ++-
src/mesa/main/get_hash_params.py | 8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 593c75b..316d453 100644
--- a/src/mesa/main/get.c
Noticed by inspection when reviewing the next commit.
---
src/mesa/main/get_hash_params.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 7dfc9db..8b5985a 100644
--- a/src/mesa/main/get_hash_params.py
++
One thing you work on if you're interested in that would be the softpipe
driver. This is generally easier than other drivers as it doesn't
require any knowledge of the hw and it is easier to debug, though you'd
need more knowledge about gallium rather than OpenGL directly. The
problem with it is th
https://bugs.freedesktop.org/show_bug.cgi?id=65426
Laurent carlier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #10 from Dan Allen ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #5)
> > > Is this really a problem? Mesa might not always reuse buffer names, but
> > > that
> > > does not mean the buffer wasn't pr
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #9 from Brian Paul ---
(In reply to comment #8)
> (In reply to comment #5)
> > Is this really a problem? Mesa might not always reuse buffer names, but that
> > does not mean the buffer wasn't properly deleted. As far as I can see,
> >
On 5 June 2013 10:14, Eric Anholt wrote:
> This will get reused shortly.
> ---
> src/mesa/drivers/dri/intel/intel_blit.c | 70
> +
> 1 file changed, 36 insertions(+), 34 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_blit.c
> b/src/mesa/drivers/dri
On 06/06/2013 12:28 PM, Arnas Milasevicius wrote:
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced()
---
v2: removed draw_arrays_instanced() function and modified draw_arrays()
v3: improved commit massage
message
v4: removed startInstance and instanceCount pa
On 06/05/2013 10:14 AM, Eric Anholt wrote:
Intel had brokenness here, and I'd like to continue moving Mesa toward
hiding 1D_ARRAY's ridiculousness inside of the core, like we did with
MapTextureImage. Fixes copyteximage 1D_ARRAY on intel.
There's still an impedance mismatch in meta when falling
On 5 June 2013 10:14, Eric Anholt wrote:
> Intel had brokenness here, and I'd like to continue moving Mesa toward
> hiding 1D_ARRAY's ridiculousness inside of the core, like we did with
> MapTextureImage. Fixes copyteximage 1D_ARRAY on intel.
>
> There's still an impedance mismatch in meta when
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #8 from Dan Allen ---
(In reply to comment #5)
> Is this really a problem? Mesa might not always reuse buffer names, but that
> does not mean the buffer wasn't properly deleted. As far as I can see,
> OpenGL does not require name reus
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced()
---
v2: removed draw_arrays_instanced() function and modified draw_arrays()
v3: improved commit massage
v4: removed startInstance and instanceCount parameters from draw_arrays()
src/mesa/state_tracker/st_draw_feedbac
On 06/06/2013 11:16 AM, Eric Anholt wrote:
Just like we produce from inside the Intel driver, this can help provide
information quickly about FBO incompatibility problems (particularly when
using apitrace replay).
Currently, in driver-marked incompleteness cases, you'll get both the
driver messa
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #7 from Brian Paul ---
(In reply to comment #6)
> (In reply to comment #5)
> > Is this really a problem? Mesa might not always reuse buffer names, but that
> > does not mean the buffer wasn't properly deleted. As far as I can see,
> >
https://bugs.freedesktop.org/show_bug.cgi?id=65475
Priority: medium
Bug ID: 65475
Assignee: mesa-dev@lists.freedesktop.org
Summary: Inconsistent use of both stderr and stdout for debug
output
Severity: normal
Classificati
Just like we produce from inside the Intel driver, this can help provide
information quickly about FBO incompatibility problems (particularly when
using apitrace replay).
Currently, in driver-marked incompleteness cases, you'll get both the
driver message and the core message on Intel. Until the
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #6 from José Fonseca ---
(In reply to comment #5)
> Is this really a problem? Mesa might not always reuse buffer names, but that
> does not mean the buffer wasn't properly deleted. As far as I can see,
> OpenGL does not require name r
On 06/06/2013 09:59 AM, Eric Anholt wrote:
Kenneth Graunke writes:
On 06/05/2013 10:14 AM, Eric Anholt wrote:
This will get reused shortly.
---
src/mesa/drivers/dri/intel/intel_blit.c | 70
+
1 file changed, 36 insertions(+), 34 deletions(-)
diff --git a
Kenneth Graunke writes:
> On 06/05/2013 10:14 AM, Eric Anholt wrote:
>> This will get reused shortly.
>> ---
>> src/mesa/drivers/dri/intel/intel_blit.c | 70
>> +
>> 1 file changed, 36 insertions(+), 34 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/intel
On Sat, May 25, 2013 at 2:13 AM, Kenneth Graunke wrote:
> On 05/24/2013 06:28 PM, Matt Turner wrote:
>>
>> From: Todd Previte
>>
>> v2 [mattst88]
>>- Split infrastructure into separate patch.
>>- Add preprocessor #define.
>
>
> Patches 1-5 and 7 are:
> Reviewed-by: Kenneth Graunke
>
> I'
https://bugs.freedesktop.org/show_bug.cgi?id=62647
--- Comment #22 from Eric Anholt ---
The debug=wm output looks reasonable to me. Only funky thing I see at the
moment is the gl_FogFragCoord output from the VS not getting dead code
eliminated, but that should be fine (looks like output/input ma
Am 06.06.2013 17:56, schrieb Brian Paul:
> From: Brian Paul
>
> This change came from the discovery that the STATIC_ASSERT to check that
> the number of register file strings didn't actually work.
>
> Similar changes could be make for the other string arrays in tgsi_string.c
> ---
> src/gallium
From: Brian Paul
This change came from the discovery that the STATIC_ASSERT to check that
the number of register file strings didn't actually work.
Similar changes could be make for the other string arrays in tgsi_string.c
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c |2 +-
src/ga
On Wed, Jun 5, 2013 at 10:11 PM, Roland Scheidegger wrote:
> Am 06.06.2013 04:16, schrieb Roland Scheidegger:
> > Am 06.06.2013 02:52, schrieb Brian Paul:
> >> On 06/05/2013 05:44 PM, srol...@vmware.com wrote:
> >>> From: Roland Scheidegger
> >>>
> >>> Also report if a shader writes the layer sem
On Wed, Jun 5, 2013 at 11:45 PM, Eric Anholt wrote:
> Having figured out what was going on with piglit fbo-depth copypixels
> GL_DEPTH_COMPONENT32F (falling all the way back to swrast on CopyPixels to
> a float depth buffer), I'm not inclined to fix the problem currently but
> it seems worth savin
On 06/05/2013 11:05 PM, Vinson Lee wrote:
Fixes "Out-of-bounds access" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/mesa/main/dlist.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index abc8665..8900c89
Looks good to me. Is there a piglit test for this?
--Aaron
On Wed, Jun 5, 2013 at 7:12 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover
On 06/06/2013 05:40 AM, Arnas Milasevicius wrote:
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced()
---
v2: removed draw_arrays_instanced() function and modified draw_arrays()
v3: improved commit massage
src/mesa/state_tracker/st_draw_feedback.c | 26 +++
On Don, 2013-06-06 at 14:21 +0200, Michel Dänzer wrote:
> On Don, 2013-06-06 at 21:23 +1000, Jonathan Gray wrote:
> > On Thu, Jun 06, 2013 at 11:30:50AM +0200, Michel Dänzer wrote:
> > > On Mit, 2013-06-05 at 15:00 +1000, Jonathan Gray wrote:
> > > > RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mes
This is a v2 version, by the way.
On Thu, Jun 6, 2013 at 11:56 AM, Arnas Milasevicius wrote:
>
> Because draw_arrays() is only sued in state_tracker's st_draw_feedback.c
> file, I moved it from draw_pt.c to there and mate it static.
> ---
> v2: removed draw_arrays_instanced() function and modif
So, should I resend it with `git mv` or we will leave this file's name as
it is?
On Thu, Jun 6, 2013 at 3:23 AM, Brian Paul wrote:
> On 06/05/2013 03:25 PM, Kenneth Graunke wrote:
>
>> On 06/05/2013 12:09 PM, Arnas Milasevicius wrote:
>>
>>> ---
>>> src/mesa/Makefile.sources | 2 +-
>>>
Christoph Bumiller writes:
> On 06.06.2013 10:34, Richard Sandiford wrote:
>> Michel Dänzer writes:
>>> On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
(2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
mesa-like ones with msb first. (I'm happy to ch
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced()
---
v2: removed draw_arrays_instanced() function and modified draw_arrays()
v3: improved commit massage
src/mesa/state_tracker/st_draw_feedback.c | 26 +++---
1 file changed, 7 insertions(+), 19 de
On Thu, Jun 6, 2013 at 4:56 AM, Arnas Milasevicius wrote:
>
> Because draw_arrays() is only sued in state_tracker's st_draw_feedback.c
> file, I moved it from draw_pt.c to there and mate it static.
A couple of typos:
sued -> used
mate -> made
Also, please try and make your commit messages wrap
On Don, 2013-06-06 at 21:23 +1000, Jonathan Gray wrote:
> On Thu, Jun 06, 2013 at 11:30:50AM +0200, Michel Dänzer wrote:
> > On Mit, 2013-06-05 at 15:00 +1000, Jonathan Gray wrote:
> > > RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
> > > uses it with drmCommandWriteRead instead of drmCommandWr
On Mon, Jun 3, 2013 at 5:59 PM, Brian Paul wrote:
> I seem to recall that this "choose a gallium format for a given GL
> format/type" code appears elsewhere in the state tracker (but haven't
> double-checked). In any case, it would be nicer if this code was moved into
> a separate function.
Ther
On Thu, Jun 06, 2013 at 11:30:50AM +0200, Michel Dänzer wrote:
> On Mit, 2013-06-05 at 15:00 +1000, Jonathan Gray wrote:
> > RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
> > uses it with drmCommandWriteRead instead of drmCommandWrite
> > which leads to the ioctl being unmatched and returning a
On Thu, Jun 6, 2013 at 10:44 AM, Arnas Milaševičius wrote:
> It seems that you didn't understand me or I didn't undrstand you. For
> example gl_enums.py has all the 3 functions. How do I deal with that
> file? I don't thing it's the right way to change for example
> _mesa_lookup_prim_by_nr() there,
On 06.06.2013 10:34, Richard Sandiford wrote:
> Michel Dänzer writes:
>> On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
>>> (2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
>>> mesa-like ones with msb first. (I'm happy to change the names to
>>> somethin
https://bugs.freedesktop.org/show_bug.cgi?id=65426
--- Comment #5 from Grigori Goronzy ---
Is this really a problem? Mesa might not always reuse buffer names, but that
does not mean the buffer wasn't properly deleted. As far as I can see, OpenGL
does not require name reuse.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=65426
Michel Dänzer changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |mesa-dev@lists.freedesktop.
On Mit, 2013-06-05 at 15:00 +1000, Jonathan Gray wrote:
> RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
> uses it with drmCommandWriteRead instead of drmCommandWrite
> which leads to the ioctl being unmatched and returning an
> error on at least OpenBSD.
>
> Problem originally noticed in libdr
Because draw_arrays() is only sued in state_tracker's st_draw_feedback.c file,
I moved it from draw_pt.c to there and mate it static.
---
v2: removed draw_arrays_instanced() function and modified draw_arrays()
src/mesa/state_tracker/st_draw_feedback.c | 26 +++---
1 file cha
It seems that you didn't understand me or I didn't undrstand you. For
example gl_enums.py has all the 3 functions. How do I deal with that
file? I don't thing it's the right way to change for example
_mesa_lookup_prim_by_nr() there, then send this patch, then change
back from _mesa_prim_string() to
Michel Dänzer writes:
> On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
>>
>> (2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
>> mesa-like ones with msb first. (I'm happy to change the names to
>> something else though.)
>>
>> The patch isn't in a subm
https://bugs.freedesktop.org/show_bug.cgi?id=61821
Andreas Boll changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
61 matches
Mail list logo
