https://bugs.freedesktop.org/show_bug.cgi?id=61821
Andreas Boll changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
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
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
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
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
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.
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
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
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 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 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 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 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
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
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
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 +-
>>>
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
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
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 +++
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/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
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 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
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
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
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
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'
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 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
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
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=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
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,
> >
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
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
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
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
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 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 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
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,
> >
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
Laurent carlier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
++
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
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 | 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.
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
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
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
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
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
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.
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
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
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,
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
_
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
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
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
61 matches
Mail list logo
