Hi Chia,
Thanks for your help untangling the web.
--Jeremy
On Jun 7, 2011, at 2:51 PM, Chia-I Wu wrote:
> On Wed, Jun 8, 2011 at 3:08 AM, Jeremy Huddleston wrote:
>>
>> On Jun 7, 2011, at 2:13 PM, Brian Paul wrote:
>>
Ok, I see what is happening. configs/darwin bitrotted and included t
https://bugs.freedesktop.org/show_bug.cgi?id=31949
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=36593
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, 7 Jun 2011 13:01:10 -0700, "Ian Romanick" wrote:
> From: Ian Romanick
>
> In an ES2 context (or if GL_ARB_ES2_compatibility) is supported, the
> framebuffer can be complete with some attachments be missing. In this
> case the _ColorDrawBuffers pointer will be NULL.
>
> Fixes the crash
On Tue, 07 Jun 2011 12:43:38 -0700, Chad Versace wrote:
> On Tue, 07 Jun 2011 10:33:44 -0700, Eric Anholt wrote:
> > On Sat, 4 Jun 2011 17:45:37 -0700, Chad Versace
> > wrote:
> > > ... which indicates if the X driver supports DRI2BufferHiz and
> > > DRI2BufferStencil.
> > >
> > > I'm placing
https://bugs.freedesktop.org/show_bug.cgi?id=31590
--- Comment #12 from Ian Romanick 2011-06-07 17:45:53
PDT ---
(In reply to comment #11)
> The patches I just attached fixes the problem with the molehill demo and fixes
> another bug/crash that I found with a new piglit test.
>
> No regressions
https://bugs.freedesktop.org/show_bug.cgi?id=37274
Marek Olšák changed:
What|Removed |Added
Summary|r300g: rs690, crash in |Crash in draw_llvm_shader23
I have the HW as well, but I see no reason this wouldn't work.
Sending from a mobile, pardon the brevity. ~ C.
On Jun 7, 2011 3:36 PM, "Brian Paul" wrote:
> On Tue, Jun 7, 2011 at 3:56 PM, Nicolas Kaiser wrote:
>> Tested on a Matrox G550 AGP. I noticed that the two piglit
>> VAO tests as well as
https://bugs.freedesktop.org/show_bug.cgi?id=37470
Marek Olšák changed:
What|Removed |Added
Component|Drivers/Gallium/r300|Mesa core
AssignedTo|dri-devel@lis
On 06/07/2011 01:13 PM, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We've accumulated a lot of fixes in the 7.10 branch, so it seems like we
should do a 7.10.3 release soon. How do Friday (6/10) or Monday (6/13)
sound?
There's also a huge number of changes sitting in mast
On Tue, Jun 7, 2011 at 3:56 PM, Nicolas Kaiser wrote:
> Tested on a Matrox G550 AGP. I noticed that the two piglit
> VAO tests as well as the vao_demo only test
> APPLE_vertex_array_object, which is already enabled on mga.
Signed-off-by: Brian Paul
You might very well be the only mga user/teste
https://bugs.freedesktop.org/show_bug.cgi?id=37911
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31590
--- Comment #11 from Brian Paul 2011-06-07 15:06:22 PDT ---
The patches I just attached fixes the problem with the molehill demo and fixes
another bug/crash that I found with a new piglit test.
No regressions found so I'll probably commit them i
https://bugs.freedesktop.org/show_bug.cgi?id=31590
--- Comment #10 from Brian Paul 2011-06-07 15:05:12 PDT ---
Created an attachment (id=47693)
View: https://bugs.freedesktop.org/attachment.cgi?id=47693
Review: https://bugs.freedesktop.org/review?bug=31590&attachment=47693
patch 2 of 2 to fix
https://bugs.freedesktop.org/show_bug.cgi?id=31590
--- Comment #9 from Brian Paul 2011-06-07 15:04:48 PDT ---
Created an attachment (id=47692)
View: https://bugs.freedesktop.org/attachment.cgi?id=47692
Review: https://bugs.freedesktop.org/review?bug=31590&attachment=47692
patch 1 of 2 to fix v
Tested on a Matrox G550 AGP. I noticed that the two piglit
VAO tests as well as the vao_demo only test
APPLE_vertex_array_object, which is already enabled on mga.
However, the bufferobj test appears to use the extension:
before:
$ tests/bufferobj
GL_RENDERER = Mesa DRI G400 AGP 1x
Using GL_ARB_
On Tue, Jun 7, 2011 at 4:28 PM, Benjamin Franzke
wrote:
> 2011/6/7 Ian Romanick :
>> 1. These files need to have license statements.
>
> Right, thanks.
>
>> 2. These files add some new dependencies (e.g., libudev.h), so updates
>> to configure.ac need to be made to account for that.
>
> libudev wa
On Wed, Jun 8, 2011 at 2:33 AM, Benjamin Franzke
wrote:
> x86_64_entry_start needs to be bound global, in order to have the
> correct address in entry_get_public (seems not to be needed on x86).
>
> Otherwise addresses needed for _glapi_proc_address will be computed
> from some random offset (0x64
On Wed, Jun 8, 2011 at 3:08 AM, Jeremy Huddleston wrote:
>
> On Jun 7, 2011, at 2:13 PM, Brian Paul wrote:
>
>>> Ok, I see what is happening. configs/darwin bitrotted and included the
>>> -lGL, but other configs have since removed that. It looks like I should
>>> just remove -lGL from OSMESA_L
On 06/07/2011 02:01 PM, Ian Romanick wrote:
From: Ian Romanick
In an ES2 context (or if GL_ARB_ES2_compatibility) is supported, the
framebuffer can be complete with some attachments be missing. In this
case the _ColorDrawBuffers pointer will be NULL.
Fixes the crash in piglit test fbo-missing-
On 06/07/2011 02:01 PM, Ian Romanick wrote:
From: Ian Romanick
The EXT_framebuffer_object spec (and later specs) say:
"If a buffer is specified in and does not exist in both
the read and draw framebuffers, the corresponding bit is silently
ignored."
Check for color, depth, a
https://bugs.freedesktop.org/show_bug.cgi?id=31590
--- Comment #8 from Brian Paul 2011-06-07 13:32:21 PDT ---
I've found the problem and have a fix. Just regression testing...
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because
2011/6/7 Ian Romanick :
> 1. These files need to have license statements.
Right, thanks.
> 2. These files add some new dependencies (e.g., libudev.h), so updates
> to configure.ac need to be made to account for that.
libudev was already used before, as pointed out in the other thread by
Jeff Chu
https://bugs.freedesktop.org/show_bug.cgi?id=31590
--- Comment #7 from José Fonseca 2011-06-07 13:28:20 PDT
---
(In reply to comment #5)
> Looks like there's a problem with NURBS and glBegin/End in a display list.
> Jaime, perhaps you could try an older version of Mesa and bisect? I'm pretty
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/07/2011 07:38 AM, Kristian Høgsberg wrote:
> Module: Mesa
> Branch: master
> Commit: 7f881c43dfb4f1aeeab3a84125b5c106c191a43f
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=7f881c43dfb4f1aeeab3a84125b5c106c191a43f
>
> Author: Benj
From: Ian Romanick
The EXT_framebuffer_object spec (and later specs) say:
"If a buffer is specified in and does not exist in both
the read and draw framebuffers, the corresponding bit is silently
ignored."
Check for color, depth, and stencil that the source and destination
FBOs
From: Ian Romanick
In an ES2 context (or if GL_ARB_ES2_compatibility) is supported, the
framebuffer can be complete with some attachments be missing. In this
case the _ColorDrawBuffers pointer will be NULL.
Fixes the crash in piglit test fbo-missing-attachment-clear.
Bugzilla: https://bugs.fre
https://bugs.freedesktop.org/show_bug.cgi?id=37476
--- Comment #3 from Sven Arvidsson 2011-06-07 12:50:02 PDT ---
Thanks for working on this. I can't comment on the patch, but the errors from
the game are indeed gone now.
It's still not rendering correctly, but it might just as well be some othe
https://bugs.freedesktop.org/show_bug.cgi?id=31590
--- Comment #6 from Jaime Rave 2011-06-07 12:46:04 PDT ---
(In reply to comment #5)
> With a debug build I'm seeing:
> Mesa: User error: GL_INVALID_OPERATION in glEnd
>
> Looks like there's a problem with NURBS and glBegin/End in a display list.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We've accumulated a lot of fixes in the 7.10 branch, so it seems like we
should do a 7.10.3 release soon. How do Friday (6/10) or Monday (6/13)
sound?
There's also a huge number of changes sitting in master, and quite a few
distros are shipping "7.11
On Jun 7, 2011, at 2:13 PM, Brian Paul wrote:
>> Ok, I see what is happening. configs/darwin bitrotted and included the
>> -lGL, but other configs have since removed that. It looks like I should
>> just remove -lGL from OSMESA_LIB_DEPS in addition to the other changes that
>> I've already se
On Tue, Jun 7, 2011 at 11:13 AM, Brian Paul wrote:
> On 06/07/2011 11:26 AM, Jeremy Huddleston wrote:
>>
>> On Jun 7, 2011, at 1:01 PM, Jeremy Huddleston wrote:
>>
>>>
>>> On Jun 7, 2011, at 12:01 PM, Jeremy Huddleston wrote:
>>>
So what is the proper fix here? How should libOSMesa be gettin
This is already pointing at 0 or Height - 1 and with an appropriate
pitch, so no need to recompute those values per customization of the
spans code. Cuts 3 out of 21kb of the compiled size.
---
src/mesa/drivers/dri/intel/intel_span.c | 11 ---
1 files changed, 4 insertions(+), 7 deletio
We were mapping the renderbuffer once, then walking over all the
buffers to map just the texture ones using the other texture mapping
function that handled the x/y offset to the image in the region. But
then we would go and overwrite *those* mappings with the original
mappings for depth/stencil, w
It was originally located in the region because the tracking of
depth/color buffers was on the regions, and getting back to the irb
would have been tricky. Now, we're keying off of the renderbuffer in
more places, which means we can move these fields where they belong.
This could fix potential re
The "newImage" isn't particularly new -- it might be the same texture
that was attached to the same attachment point before. This function
also gets called when just rebinding back to an FBO with a texture
attachment.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 16 ++--
1 files cha
https://bugs.freedesktop.org/show_bug.cgi?id=31590
--- Comment #5 from Brian Paul 2011-06-07 11:35:35 PDT ---
With a debug build I'm seeing:
Mesa: User error: GL_INVALID_OPERATION in glEnd
Looks like there's a problem with NURBS and glBegin/End in a display list.
Jaime, perhaps you could try an
x86_64_entry_start needs to be bound global, in order to have the
correct address in entry_get_public (seems not to be needed on x86).
Otherwise addresses needed for _glapi_proc_address will be computed
from some random offset (0x6400229a61058b48 in my case).
---
src/mapi/mapi/entry_x86-64_tls.h
https://bugs.freedesktop.org/show_bug.cgi?id=31590
Eric Anholt changed:
What|Removed |Added
Component|Drivers/DRI/i965|Mesa core
AssignedTo|e...@anholt.n
On 06/07/2011 11:26 AM, Jeremy Huddleston wrote:
On Jun 7, 2011, at 1:01 PM, Jeremy Huddleston wrote:
On Jun 7, 2011, at 12:01 PM, Jeremy Huddleston wrote:
So what is the proper fix here? How should libOSMesa be getting built?
Should libmesa.a be providing those stubs (rather than my chan
On Sat, 4 Jun 2011 17:45:40 -0700, Chad Versace wrote:
> It's the analog of intel_renderbuffer_set_region(), but for the hiz region
> of course.
intel_region_reference() should do the work of this helper function.
When we've got all this region frobbing code landed, let's make
intel_region_refer
On Sat, 4 Jun 2011 17:45:37 -0700, Chad Versace wrote:
> ... which indicates if the X driver supports DRI2BufferHiz and
> DRI2BufferStencil.
>
> I'm placing this in its own commit due to the large comment block.
>
> CC: Eric Anholt
> CC: Ian Romanick
> CC: Kenneth Graunke
> CC: Kristian Høgs
On Jun 7, 2011, at 1:01 PM, Jeremy Huddleston wrote:
>
> On Jun 7, 2011, at 12:01 PM, Jeremy Huddleston wrote:
>
>> So what is the proper fix here? How should libOSMesa be getting built?
>>
>> Should libmesa.a be providing those stubs (rather than my change which put
>> them in mesa/osmesa)?
On Jun 7, 2011, at 12:01 PM, Jeremy Huddleston wrote:
> So what is the proper fix here? How should libOSMesa be getting built?
>
> Should libmesa.a be providing those stubs (rather than my change which put
> them in mesa/osmesa)? Should the stubs be getting exported by libGL? Should
> GetHi
On Mon, 6 Jun 2011 19:08:06 -0700, Kenneth Graunke
wrote:
> Since Gen7 doesn't support packed depth/stencil, the stencil buffer
> can't possibly be relevant for determining the depth format.
>
> Signed-off-by: Kenneth Graunke
Looks good to me. Series is:
Reviewed-by: Eric Anholt
pgpMfLpK
On Mon, 6 Jun 2011 19:08:08 -0700, Kenneth Graunke
wrote:
> I'm not actually sure how anything worked without this.
add_validated_bo is just for the aperture space accounting. You
probably just weren't running anything that ran into aperture space
limits in accumulating one batchbuffer. (Now
On Jun 7, 2011, at 7:19 AM, Chia-I Wu wrote:
> In indirect rendering, glGenTextures and glGenTexturesEXT, for
> example, use different opcodes. However, those functions are assigned
> the same dispatch offset in glapi. If glapi defines both of them,
> they will be dispatched to the same function
On 06/07/2011 01:33 AM, Julien Cristau wrote:
On Mon, Jun 6, 2011 at 18:56:20 -0700, Kenneth Graunke wrote:
I'd make this an assertion. must_use_separate_stencil is only set for
gen>= 7, and I assert that try_separate_stencil ought to be true in
that case (old DDX doesn't support IVB, new DDX
Previously, we were errantly drawing some interior edges of clipped
polygons and quads. Also, we were introducing extra edges where
polygons intersected the view frustum clip planes.
The main problem was that we were ignoring the edgeflags encoded in
the primitive header's 'flags' field which are
On Tue, Jun 7, 2011 at 12:25 PM, Jeremy Huddleston wrote:
> I'm having trouble understanding why GLX_INDIRECT_RENDERING changes what is
> built into glapi. I assumed that glapi was agnostic to the actual
> implementation, so why does glapi care about GLX_INDIRECT_RENDERING?
> I'm trying to buil
On Mon, Jun 6, 2011 at 18:56:20 -0700, Kenneth Graunke wrote:
> I'd make this an assertion. must_use_separate_stencil is only set for
> gen >= 7, and I assert that try_separate_stencil ought to be true in
> that case (old DDX doesn't support IVB, new DDX requires new dri2proto
> to compile
On 06/06/2011 05:20 PM, James Jones wrote:
On 6/6/11 2:09 AM, "Thomas Hellstrom" wrote:
Hi!
While trying to improve the vmwgfx X driver to better cope with OpenGL
compositors, I noticed that compiz never calls glxWaitX() to make sure
the pixmaps that it textures from are updated.
Since w
52 matches
Mail list logo