https://bugs.freedesktop.org/show_bug.cgi?id=39017
--- Comment #9 from Diego Viola 2012-02-01 22:36:56 PST
---
Created attachment 56498
--> https://bugs.freedesktop.org/attachment.cgi?id=56498
mupen64plus gdb backtrace
I've managed to get a backtrace.
See the file attached.
--
Configure bu
https://bugs.freedesktop.org/show_bug.cgi?id=45420
--- Comment #7 from Vinson Lee 2012-02-01 22:20:26 PST
---
(In reply to comment #4)
> Created attachment 56422 [details] [review]
> Proposed fix for LLVM-2.7
>
> I don't really know how to properly fix this for all targets, because
> LLVM_NATIV
https://bugs.freedesktop.org/show_bug.cgi?id=45420
--- Comment #6 from Vinson Lee 2012-02-01 22:12:50 PST
---
(In reply to comment #5)
>
> The ability to build with LLVM-2.6 is still useful for now, as it is one of
> the
> most stable LLVM releases for us ever.
>
> But the ability to disassem
https://bugs.freedesktop.org/show_bug.cgi?id=39017
--- Comment #8 from Diego Viola 2012-02-01 22:07:21 PST
---
BTW I use nouveau, and my card is: GeForce 9500 GT
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You
https://bugs.freedesktop.org/show_bug.cgi?id=39017
--- Comment #7 from Diego Viola 2012-02-01 22:05:57 PST
---
I seem to be getting this issue as well, mupen64plus crashes on my machine as
soon as I start a game.
Mupen64Plus Console User-Interface Version 1.99.4
UI-console: attached to core lib
From: Ian Romanick
GL_RG_INTEGER only has two components, not three. I'll be surprised
if anyone ever tries to glReadPixels(..., GL_SHORT, GL_RG_INTEGER,
...). This was found by inspection.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick
---
src/mesa/main/pack.c |
On 02/ 1/12 08:52 PM, Alexandre Demers wrote:
Hi,
I've been trying all day to sync sources from anongit.freedesktop.org
(dri and mesa) and it always ends up by a time out. Is there a problem
with the server or the address?
Yes. Others have reported on IRC that it works if you force the hostna
Hi,
I've been trying all day to sync sources from anongit.freedesktop.org
(dri and mesa) and it always ends up by a time out. Is there a problem
with the server or the address?
Cheers,
--
Alexandre Demers
___
mesa-dev mailing list
mesa-dev@lists.free
On 02/01/2012 09:31 AM, Ian Romanick wrote:
From: Ian Romanick
FBOs differ from textures in a significant way. With textures, we can
strip the border and get correct rendering except when the application
fetches texels outside [0,1].
With an FBO, the pixel at (0,0) is in the border. The
ARB_f
On 02/01/2012 11:29 AM, Ian Romanick wrote:
From: Ian Romanick
A similar check was removed in 05ab8fc. The check is not complete
redundand because some paths, such as
_mesa_meta_check_generate_mipmap_fallback, can get to
intel_renderbuffer_update_wrapper but not get to
intel_validate_framebuffe
On 02/01/2012 01:21 PM, Ian Romanick wrote:
From: Ian Romanick
Several of the half-float cases used 4 as the texel size when it
should have been some smaller value.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43324
Bugzilla: https://bugs.freedesktop.org/sh
On 02/01/2012 01:07 PM, Eugeni Dodonov wrote:
Rely on libdrm HAS_LLC parameter to verify if hardware supports it. In
case the libdrm version does not supports this check, fallback to older
way of detecting it which assumed that GPUs newer than GEN6 have it.
Signed-off-by: Eugeni Dodonov
Looks
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_defines.h|2 +-
src/gallium/auxiliary/vl/vl_mc.h |2 +-
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 20 ++--
src/gallium/auxiliary/vl/vl_mpeg12_decoder.h |8
src/gallium/au
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_decoder.c|4 +-
src/gallium/auxiliary/vl/vl_defines.h|8 ++--
src/gallium/auxiliary/vl/vl_idct.c | 34 +++---
src/gallium/auxiliary/vl/vl_mc.c | 20 ++--
src/ga
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_defines.h|1 +
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c |3 ++-
src/gallium/auxiliary/vl/vl_video_buffer.h |2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_def
It's perfectly valid to ask for an unknown
profile and get unknown code as a result.
Signed-off-by: Christian König
---
src/gallium/auxiliary/util/u_video.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_video.h
b/src/gallium/auxiliary/util
Signed-off-by: Christian König
---
src/gallium/state_trackers/xorg/xvmc/surface.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xvmc/surface.c
b/src/gallium/state_trackers/xorg/xvmc/surface.c
index f1c3271..024612e 100644
--- a/src/
Recreate video buffer if need arises.
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/decode.c | 10 +-
src/gallium/state_trackers/vdpau/surface.c |6 ++
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/decode
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_compositor.c | 204 +-
src/gallium/auxiliary/vl/vl_compositor.h |2 +
2 files changed, 173 insertions(+), 33 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c
b/src/gallium/auxiliary
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/surface.c | 48 +++
1 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/surface.c
b/src/gallium/state_trackers/vdpau/surface.c
index 85ce4c3..00c64ee 100644
Let the driver control interlaced or progressive
format of video buffers.
Signed-off-by: Christian König
---
src/gallium/drivers/nouveau/nouveau_video.c |6 ++
src/gallium/drivers/nvfx/nvfx_screen.c |6 ++
src/gallium/drivers/r300/r300_screen.c |6 ++
src/galliu
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 249124f..f7134a5 100644
--- a/s
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 021e81e..249124f 100644
--- a/src/gallium/
The following series of patches completes the my general work on interlaced
video playback. It implements everything necessary for video playback using
interlaced buffers, including a simple weave deinterlacer.
Still missing are the changes necessary for interlaced mpeg2 decoding, this
will hav
On 02/01/2012 02:38 PM, Ian Romanick wrote:
From: Ian Romanick
This is a hack, and it will result in incorrect rendering. However,
it does eliminate spurious warnings in several piglit CopyPixels tests
that involve floating-point depth buffers.
The real solution is to add a zf field to SWspan
https://bugs.freedesktop.org/show_bug.cgi?id=41700
--- Comment #1 from Kevin DeKorte 2012-02-01 13:41:13 PST
---
Patch in Bug #45466 fixes this on Fedora 16 x86_64
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=45466
Kevin DeKorte changed:
What|Removed |Added
CC||i...@freedesktop.org
--
Configure bugma
From: Ian Romanick
This is a hack, and it will result in incorrect rendering. However,
it does eliminate spurious warnings in several piglit CopyPixels tests
that involve floating-point depth buffers.
The real solution is to add a zf field to SWspan to store float Z
values. When a float depth
https://bugs.freedesktop.org/show_bug.cgi?id=45466
--- Comment #1 from Kevin DeKorte 2012-02-01 13:38:57 PST
---
Created attachment 56473
--> https://bugs.freedesktop.org/attachment.cgi?id=56473
Improved version of the patch that touches mklib as well
I found that mesa would not compile after
On 02/01/2012 02:28 PM, Brian Paul wrote:
On 02/01/2012 02:21 PM, Ian Romanick wrote:
From: Ian Romanick
Several of the half-float cases used 4 as the texel size when it
should have been some smaller value.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=4332
On 02/01/2012 02:21 PM, Ian Romanick wrote:
From: Ian Romanick
Several of the half-float cases used 4 as the texel size when it
should have been some smaller value.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43324
Bugzilla: https://bugs.freedesktop.org/sh
From: Ian Romanick
Several of the half-float cases used 4 as the texel size when it
should have been some smaller value.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43324
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43325
---
src/mesa/main/mipma
This checks for advertised LLC support by the GPU instead of relying on
the GPU generation for detection.
Signed-off-by: Eugeni Dodonov
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mi
Rely on libdrm HAS_LLC parameter to verify if hardware supports it. In
case the libdrm version does not supports this check, fallback to older
way of detecting it which assumed that GPUs newer than GEN6 have it.
Signed-off-by: Eugeni Dodonov
---
src/mesa/drivers/dri/intel/intel_context.c |1
- Original Message -
> On 01/28/2012 04:04 AM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> width, height parameter of glTexImage2D() includes: texture image
> >> width + 2 * border (if any). So when doing the texture size check
> >> in _mesa_test_proxy_teximage() wid
On 01/28/2012 04:04 AM, Jose Fonseca wrote:
- Original Message -
width, height parameter of glTexImage2D() includes: texture image
width + 2 * border (if any). So when doing the texture size check
in _mesa_test_proxy_teximage() width and height should not exceed
maximum supported size
On 02/01/2012 08:52 AM, Brian Paul wrote:
The node_attrsz[] array is initially copied from the node->attrsz[]
array but some values get rewritten. Thereafter, we need to use the
node_attrsz[] values.
Fixes a bug when replaying a display list that uses generic vertex
array[16] (at least).
NOTE:
From: Ian Romanick
A similar check was removed in 05ab8fc. The check is not complete
redundand because some paths, such as
_mesa_meta_check_generate_mipmap_fallback, can get to
intel_renderbuffer_update_wrapper but not get to
intel_validate_framebuffer. This occurs when trying to generate
mipma
On 01/02/2012 15:59, Matt Turner wrote:
> On Wed, Feb 1, 2012 at 9:41 AM, Jon TURNEY wrote:
>> Note that glean is calling glGenPrograms, but we are ending up in
>> glProgramParameters4fvNV.
>>
>> It seems the indirect dispatch table isn't being built correctly. The
>> dispatch table layouts in gla
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/01/2012 10:40 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> There are cases where a buffer can be mapped while another buffer is
> flushed. This can happen in the CopyPixels meta-op path for piglit's
> fbo-mipmap-copypix. After some discus
From: Ian Romanick
There are cases where a buffer can be mapped while another buffer is
flushed. This can happen in the CopyPixels meta-op path for piglit's
fbo-mipmap-copypix. After some discussion with Eric, it seems this
assertion is no longer necessary, and it has always been too strict.
N
On Wednesday 1 February 2012, Michel Dänzer wrote:
> On Mit, 2012-02-01 at 15:01 +, Simon Farnsworth wrote:
> > + if (sleep_bo) {
> > + unsigned reloc_index;
> > + /* Create a dummy BO so that fence_finish without a timeout can
> > sleep waiting for completion */
> > +
From: Ian Romanick
FBOs differ from textures in a significant way. With textures, we can
strip the border and get correct rendering except when the application
fetches texels outside [0,1].
With an FBO, the pixel at (0,0) is in the border. The
ARB_framebuffer_object spec says:
"If the att
[ Dropping dri-devel list ]
On Mit, 2012-02-01 at 15:01 +, Simon Farnsworth wrote:
> r300g is able to sleep until a fence completes rather than busywait because
> it creates a special buffer object and relocation that stays busy until the
> CS containing the fence is finished.
>
> Copy the i
https://bugs.freedesktop.org/show_bug.cgi?id=38970
Ian Romanick changed:
What|Removed |Added
Blocks|42993 |
--- Comment #17 from Ian Romanick 2012-
On Tue, Jan 31, 2012 at 6:07 PM, Mike Frysinger wrote:
> The current gen_matypes logic assumes that the host compiler will produce
> information that is useful for the target compiler. Unfortunately, this
> is not the case whenever cross-compiling.
>
> When we detect that we're cross-compiling an
On Wed, Feb 1, 2012 at 9:41 AM, Jon TURNEY wrote:
>
> This is with git master, but the same issue exists since at least mesa-7.11.2.
>
> ./configure --enable-shared-glapi --disable-driglx-direct --with-driver=dri
> --with-dri-drivers=swrast --with-gallium-drivers=swrast
>
> $ gdb --args ./glean -r
The node_attrsz[] array is initially copied from the node->attrsz[]
array but some values get rewritten. Thereafter, we need to use the
node_attrsz[] values.
Fixes a bug when replaying a display list that uses generic vertex
array[16] (at least).
NOTE: This is a candidate for the 8.0 branch.
---
On 01.02.2012 16:21, Brian Paul wrote:
> On 02/01/2012 08:14 AM, Christoph Bumiller wrote:
>> On 01.02.2012 15:23, Brian Paul wrote:
>>> On 02/01/2012 03:40 AM, Jose Fonseca wrote:
Silences warnings and fixes potential bugs due to buffer overflow.
The nv50 maintainers could benefit f
On 02/01/2012 08:14 AM, Christoph Bumiller wrote:
On 01.02.2012 15:23, Brian Paul wrote:
On 02/01/2012 03:40 AM, Jose Fonseca wrote:
Silences warnings and fixes potential bugs due to buffer overflow.
The nv50 maintainers could benefit from sprinkling a few asserts to
catch this early in the fu
On 01.02.2012 15:23, Brian Paul wrote:
> On 02/01/2012 03:40 AM, Jose Fonseca wrote:
>> Silences warnings and fixes potential bugs due to buffer overflow.
>>
>> The nv50 maintainers could benefit from sprinkling a few asserts to
>> catch this early in the future, as it is bound to happen again.
>
On Wednesday 1 February 2012, Simon Farnsworth
wrote:
> This is a userspace only fix for my problem, as suggested by Mark Olšák. It
My apologies, Marek; my typing appears to have failed me, and renamed you to
Mark. I shall try not to make that mistake again.
--
Simon Farnsworth
Software Enginee
---
tests/shaders/CMakeLists.gl.txt |1 +
tests/shaders/glsl-max-varyings-2.c | 413 +++
2 files changed, 414 insertions(+), 0 deletions(-)
create mode 100644 tests/shaders/glsl-max-varyings-2.c
diff --git a/tests/shaders/CMakeLists.gl.txt b/tests/shaders
r300g is able to sleep until a fence completes rather than busywait because
it creates a special buffer object and relocation that stays busy until the
CS containing the fence is finished.
Copy the idea into r600g, and use it to sleep if the user asked for an
infinite wait, falling back to busywai
This is with git master, but the same issue exists since at least mesa-7.11.2.
./configure --enable-shared-glapi --disable-driglx-direct --with-driver=dri
--with-dri-drivers=swrast --with-gallium-drivers=swrast
$ gdb --args ./glean -r foo -o -t vertProg1 --quick
...
(gdb) b __indirect_glProgramP
On 02/01/2012 03:40 AM, Jose Fonseca wrote:
Silences warnings and fixes potential bugs due to buffer overflow.
The nv50 maintainers could benefit from sprinkling a few asserts to catch this
early in the future, as it is bound to happen again.
Good point. I'll add a couple asserts.
-Brian
_
- Original Message -
> On Wed, 1 Feb 2012 05:03:21 -0800 (PST)
> Jose Fonseca wrote:
>
> > I wonder if people have use any tools to facility applying patches
> > posted to mesa, as for me locate, save, and applying them takes a
> > lot of time, and more often than not fails due to white s
On Wed, 1 Feb 2012 05:03:21 -0800 (PST)
Jose Fonseca wrote:
> I wonder if people have use any tools to facility applying patches posted to
> mesa, as for me locate, save, and applying them takes a lot of time, and more
> often than not fails due to white space munging. I barely can keep up with
- Original Message -
> On Tue, Jan 31, 2012 at 8:32 PM, Brian Paul
> wrote:
> > On 01/31/2012 02:44 PM, Zack Rusin wrote:
> >>
> >> On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:
>
> $ make>log
> ar: creating libglapi.a
> ar: creating libmesa.a
> ar: l
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth
---
There's debate ongoing
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
If the new kernel interface is unavailable, fall back to busywaiting.
Signed-off-by: Simon Farnsworth
---
This is simply addressing Michel's review comments against the v1 patch.
The
https://bugs.freedesktop.org/show_bug.cgi?id=45420
--- Comment #5 from José Fonseca 2012-02-01 03:45:04 PST
---
(In reply to comment #4)
> Created attachment 56422 [details] [review]
> Proposed fix for LLVM-2.7
>
> I don't really know how to properly fix this for all targets, because
> LLVM_NAT
On Tuesday 31 January 2012, Michel Dänzer wrote:
> On Die, 2012-01-31 at 17:02 +, Simon Farnsworth wrote:
> > Instead of busywaiting for the GPU to finish a fence, use the new kernel
> > interface to wait for fence completion.
> >
> > If the new kernel interface is unavailable, fall back to
Silences warnings and fixes potential bugs due to buffer overflow.
The nv50 maintainers could benefit from sprinkling a few asserts to catch this
early in the future, as it is bound to happen again.
Jose
- Original Message -
> The warnings were:
> nv50_pc_regalloc.c: In function ‘pass_
Looks good. Good find!
Jose
- Original Message -
> This fixes a dangling texture object pointer bug hit via
> wglShareLists().
> When we push the GL_TEXTURE_BIT state we may push references to the
> default
> texture objects which are owned by the gl_shared_state object. We
> don't
> wan
Looks solid to me Brian.
Jose
- Original Message -
> This cleans up the reference counting of shared context state.
> The next patch will use this to fix an actual bug.
>
> NOTE: This is a candidate for the 8.0 branch.
> ---
> src/mesa/main/context.c | 28 --
>
I'm not familiar with with autotools to comment on those bits, but I think this
is a pretty neat idea.
This could be also when when cross compiling for windows w/ mingw.
Jose
- Original Message -
> The current gen_matypes logic assumes that the host compiler will
> produce
> information
https://bugs.freedesktop.org/show_bug.cgi?id=42386
Andreas Betz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=34261
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=42386
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com,
|
https://bugs.freedesktop.org/show_bug.cgi?id=42649
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com,
|
On Die, 2012-01-31 at 21:26 -0500, Matt Turner wrote:
> On Tue, Jan 31, 2012 at 8:32 PM, Brian Paul wrote:
> > On 01/31/2012 02:44 PM, Zack Rusin wrote:
> >>
> >> Could you maybe revert all of this and do it in a branch where we could
> >> iron
> >> out those issues?
> >
> > Yeah, I was thinking
72 matches
Mail list logo
