On Mit, 2011-05-04 at 11:22 -0700, Tristan Schmelcher wrote:
> Interestingly I have just found out that this issue only happens after
> the machine has done a suspend/resume. On a fresh boot prior to the
> suspend/resume the performance is good. So I guess somehow the driver
> is "forgetting" that
2011/5/5 Mathias Fröhlich :
>
> Hi all,
>
> On Thursday, May 05, 2011 04:32:03 you wrote:
>> Okay my guess at the problem is that:
>>
>> the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
>> on the base in the CB being the same as the texture BASE which it won't
>> be in the case
Hi all,
On Thursday, May 05, 2011 04:32:03 you wrote:
> Okay my guess at the problem is that:
>
> the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
> on the base in the CB being the same as the texture BASE which it won't
> be in the case where we are rendering to mip sublevel
On Thu, May 5, 2011 at 12:46 AM, Patrick Baggett
wrote:
> All,
> Is the ATI Rage128 DRI (r128) driver still supported? Does anyone happen to
> know of the status?
> Patrick
It's supported in that patches are accepted and that it _probably_
still compiles.
Rage128s aren't capable enough to really
2011/5/5 Dave Airlie :
>>> So to be honset I do not understand where the data sticks and what I need to
>>> do to get it out.
>>> May be that observations make sense for somebody else?
>>>
>>
>> I've been staring at this I'm running out of good ideas, and even bad ideas.
>>
>> It really does seem l
All,
Is the ATI Rage128 DRI (r128) driver still supported? Does anyone happen to
know of the status?
Patrick
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Yeah... so considering the comments in mesa-dev earlier today, I was really
surprised to see that glproto and dri2proto were tagged today. I think we need
to brownbag retract and rethink this.
These changes break API. I'm all for fixing the structs, but anything that
breaks API (or worse, pro
>> So to be honset I do not understand where the data sticks and what I need to
>> do to get it out.
>> May be that observations make sense for somebody else?
>>
>
> I've been staring at this I'm running out of good ideas, and even bad ideas.
>
> It really does seem like the TC has some invalid lin
2011/5/3 Mathias Fröhlich :
>
> Marek,
>
> On Tuesday, May 03, 2011 01:33:17 you wrote:
>> 2011/5/2 Mathias Fröhlich :
>> > I have again spent some more tries with different kinds of flushes on the
>> > rv635. What helps for the mipmap problem here is emitting a
>> > texture_barrier as well as flus
On Thu, 5 May 2011 11:17:02 +1000
Dave Airlie wrote:
> So I wasn't watching and glproto broke its interface, and I think its bad.
>
> Why?
>
> You can no longer bisect things across this point without now moving glproto.
> glxproto.h:xGLXBufferSwapComplete was a released header file
> definitio
So I wasn't watching and glproto broke its interface, and I think its bad.
Why?
You can no longer bisect things across this point without now moving glproto.
glxproto.h:xGLXBufferSwapComplete was a released header file
definition, you cannot go back and change history.
This should have been hand
On Wed, 4 May 2011 17:49:37 -0700
Jesse Barnes wrote:
> How about you look at git and see what happened last time?
>
> We added some dri2 proto requests, and people wanted to build with old
> versions w/o the new requests. So they added some ifdefs but didn't
> check all the combos (now not just
On Thu, 05 May 2011 09:32:46 +1000
Dave Airlie wrote:
> On Wed, 2011-05-04 at 16:16 -0700, Jesse Barnes wrote:
> > On Wed, 04 May 2011 15:17:31 -0700
> > Ian Romanick wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > On 05/03/2011 12:21 PM, Jesse Barnes wrote:
>
Reduce duplication of code and make the MESA_DEBUG
environment variable turn on GL_ARB_debug_output by default,
and use the same logic to determine whether to print
debugging output to the command-line.
---
src/mesa/main/errors.c | 71 ++-
1 files chan
Store client-defined message IDs in a hash table,
and sort them by severity into three linked lists
so they can be selected by severity level later.
---
src/mesa/main/context.c |2 +
src/mesa/main/errors.c | 267 ++-
src/mesa/main/errors.h |3
On Tue, May 3, 2011 at 7:33 PM, Brian Paul wrote:
> On 05/02/2011 04:59 PM, nobled wrote:
>>
>> git repo:
>> https://github.com/nobled/mesa.git
>> (branch: arb_debug_output, rebased on
>> bd661a933b18fccd7102d05932774ee61a90ec9e)
>>
>> web interface:
>> https://github.com/nobled/mesa/commits/arb_d
On Wed, 2011-05-04 at 16:16 -0700, Jesse Barnes wrote:
> On Wed, 04 May 2011 15:17:31 -0700
> Ian Romanick wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> > > We only spec a 32 bit swap count, so drop the high sbc field.
> > >
On Wed, 4 May 2011 16:16:37 -0700
Jesse Barnes wrote:
> On Wed, 04 May 2011 15:17:31 -0700
> Ian Romanick wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> > > We only spec a 32 bit swap count, so drop the high sbc field.
> > >
On Wed, 04 May 2011 15:17:31 -0700
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> > We only spec a 32 bit swap count, so drop the high sbc field.
> >
> > Signed-off-by: Jesse Barnes
>
> Is there any way we could do this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> Ian reminded me that we changed the spec to fit within an XEvent, but we
> never updated the code to match. This set of patches (much simpler than
> the last) does just that. Wrapping support can be added
On May 4, 2011, at 11:04, Jesse Barnes wrote:
> libGL is missing the change and version requirement bump, so you'll
> have to use the last glproto release until I land the Mesa fix along
> with a new glproto release. Sorry for the trouble; I pushed glproto
> yesterday assuming I'd be able to pus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2011 12:21 PM, Jesse Barnes wrote:
> We only spec a 32 bit swap count, so drop the high sbc field.
>
> Signed-off-by: Jesse Barnes
Is there any way we could do this and NOT break building older versions
of Mesa? I'd like to be able to buil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2011 02:08 PM, Jesse Barnes wrote:
> On Tue, 3 May 2011 14:02:31 -0700
> Jesse Barnes wrote:
>
>> On Tue, 03 May 2011 13:54:38 -0700
>> Keith Packard wrote:
>>
>>> On Tue, 3 May 2011 12:21:24 -0700, Jesse Barnes
>>> wrote:
>>>
We on
... and clean up if it didn't.
Signed-off-by: Adam Jackson
---
src/glx/glx_pbuffer.c | 76 -
src/glx/glxcmds.c | 74 +++-
2 files changed, 98 insertions(+), 52 deletions(-)
diff --git a/src/glx/g
On Wed, May 4, 2011 at 3:25 PM, Matt Turner wrote:
> On Thu, Dec 2, 2010 at 8:20 PM, Matt Turner wrote:
>> On Wed, Dec 1, 2010 at 11:24 PM, Ian Romanick wrote:
>>> On 12/01/2010 01:40 PM, Matt Turner wrote:
1/ln(2) is equivalent to log2(e), so define it as such.
log2(e) = ln(e)/ln
From: Chad Versace
That is, update brw_context.state.stencil_region and set the dirty bit
BRW_NEW_STENCIL_BUFFER.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_vtbl.c |8 +++-
src/mesa/drivers/dri/intel/intel_buffers.c |8 ++--
2 files changed, 13 insertio
From: Chad Versace
Add additional parameter 'struct intel_region *stencil_region'.
A subsequent patch uses the new parameter to update
brw_context.state.stencil_region.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i915/i915_vtbl.c |3 +++
src/mesa/drivers/dri/i965/brw_vtbl.c
From: Chad Versace
- Add field brw_context.state.stencil_region.
- Define dirty bit BRW_NEW_STENCIL_BUFFER, which signals that
brw_context.state.stencil_region has changed.
- Define 'struct brw_tracked_state brw_stencil_buffer' and add it to
gen4_atoms.
Signed-off-by: Chad Versace
---
src/
From: Chad Versace
... when a HiZ region is present. Also change the hiz bits and depth
format in 3D_STATE_DEPTH_BUFFER.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 47 +---
1 files changed, 42 insertions(+), 5 deletions(-)
diff --git
From: Chad Versace
Rename variable 'region' to 'depth_region'. This removes naming ambiguity
introduced by the next commit, which introduces the variable 'hiz_region'.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 26 +-
1 files changed,
From: Chad Versace
The update of the wrapping renderbuffer's region was done in
intel_renderbuffer_texture(). Move the update into intel_update_wrapper(),
which is a more logical location for updates.
The next commits allocates and updates the texture's hiz region in
intel_update_wrapper(), and
From: Chad Versace
When HiZ is enabled, hardware allows rendering to a separate stencil
region and does not allow rendering to a combined depth/stencil region.
So we need to:
1. Set an FBO's status to GL_FRAMEBUFFER_UNSUPPORTED when HiZ is enabled
and its depth and stencil attachments are ide
From: Chad Versace
When a depth texture is attached to an FBO, that texture's hiz surface
must be stored in the texture and not in the wrapping renderbuffer. If it
were stored in the renderbuffer, then inconsistent rendering would occur
when the depth texture was simultaneously attached to multip
From: Chad Versace
A hiz surface must be supplied to the hardware when rendering to a depth
buffer with hiz. There are three potential places to store that surface:
1. Allocate a larger intel_region for the depthbuffer, and let the
region's tail be the hiz surface.
2. Allocate a se
From: Chad Versace
In table intel_contex.ctx.TextureFormatsSupported, enable support for
X8_Z24 unconditionally and enable support for S8 when hardware supports
HiZ. These formats are necessary because HiZ requires separate depth and
stencil buffers.
Signed-off-by: Chad Versace
---
src/mesa/dr
From: Chad Versace
Prefer MESA_FORMAT_X8_Z24 over MESA_FORMAT_S8_Z24 for textures with
internal format GL_DEPTH_COMPONENT*.
i965 needs MESA_FORMAT_X8_Z24 for HiZ.
Signed-off-by: Chad Versace
---
src/mesa/main/texformat.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
From: Chad Versace
Given a format, is_hiz_depth_format() indicates if HiZ can be enabled on
a depthbuffer of that format.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i915/i915_vtbl.c |9 +
src/mesa/drivers/dri/i965/brw_vtbl.c | 11 +++
src/mesa/drivers
From: Chad Versace
Valid values for INTEL_HIZ are "0" or "1".
Overriding HiZ is useful for performance profiling and testing.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_context.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --g
From: Chad Versace
Currently, it is always set it to false. Once the HiZ implementation is
complete, it needs to be enabled on Gen >= 5.
Even though HiZ support is present only on gen >= 5, the field belongs
in intel_context, not brw_context, because the functions that interact
with DRI2 and cho
From: Chad Versace
With this patch series, depth writes, tests, and reads all work when rendering
to an FBO with renderbuffer attachments. I have not yet tested the same when
rendering to an FBO with texture attachments.
This series differ from my first hiz series in that hiz enablement is a
pr
On 05/04/2011 09:35 AM, Dan McCabe wrote:
> I followed the installation/build directions described here:
> http://wiki.x.org/wiki/ModularDevelopersGuide
> and I grabbed the src from git last night (early evening).
As a first step, I would check if Mesa builds successfully independently
of a
On Thu, Dec 2, 2010 at 8:20 PM, Matt Turner wrote:
> On Wed, Dec 1, 2010 at 11:24 PM, Ian Romanick wrote:
>> On 12/01/2010 01:40 PM, Matt Turner wrote:
>>> 1/ln(2) is equivalent to log2(e), so define it as such.
>>>
>>> log2(e) = ln(e)/ln(2) = 1/ln(2)
>>>
>>> M_PI is updated to add some precision
https://bugs.freedesktop.org/show_bug.cgi?id=36738
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
--- Comment #4 from J
Interestingly I have just found out that this issue only happens after
the machine has done a suspend/resume. On a fresh boot prior to the
suspend/resume the performance is good. So I guess somehow the driver
is "forgetting" that it can take a faster path that doesn't go through
_mesa_texstore. Whi
libGL is missing the change and version requirement bump, so you'll
have to use the last glproto release until I land the Mesa fix along
with a new glproto release. Sorry for the trouble; I pushed glproto
yesterday assuming I'd be able to push the other bits right away too,
but I'm still waiting f
On Wed, 4 May 2011 10:37:03 -0700
Jesse Barnes wrote:
> On Wed, 04 May 2011 10:01:28 -0700
> Ian Romanick wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 05/04/2011 09:40 AM, Dan McCabe wrote:
> > > Hi all,
> > >
> > > Apologies if this is a stupid n00b question, but
Well, it's not building correctly on my tinderbox which uses master glproto and
master libGL, so either libGL has bad C, or libGL is using the system's glproto
instead of the one it queries out of PKG_CONFIG_PATH. Either way, it's a mesa
bug happening on both of my linux tinderboxes (gentoo ppc
On Wed, 04 May 2011 10:01:28 -0700
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/04/2011 09:40 AM, Dan McCabe wrote:
> > Hi all,
> >
> > Apologies if this is a stupid n00b question, but I'm getting errors
> > building glxext.c in mesa/mesa/src/glx.
> >
> > Spe
On Mon, 02 May 2011 16:44:21 -0500, Bryan Cain wrote:
> On 05/02/2011 11:55 AM, Ian Romanick wrote:
> > On 04/27/2011 08:23 PM, Brian Paul wrote:
> > > On Tue, Apr 26, 2011 at 12:26 AM, Bryan Cain
> > wrote:
> > >> Hi,
> > >>
> > >> In the last week or so, I've been working on a direct translator
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/04/2011 09:40 AM, Dan McCabe wrote:
> Hi all,
>
> Apologies if this is a stupid n00b question, but I'm getting errors
> building glxext.c in mesa/mesa/src/glx.
>
> Specific error msg is:
> glxext.c: In function ‘__glXWireToEvent’:
>
Hi all,
Apologies if this is a stupid n00b question, but I'm getting errors
building glxext.c in mesa/mesa/src/glx.
Specific error msg is:
glxext.c: In function ‘__glXWireToEvent’:
glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member
named ‘sbc_hi’
glxext
Hi all,
Apologies if this is a stupid n00b question, but I'm getting errors
building glxext.c in mesa/mesa/src/glx.
Specific error msg is:
glxext.c: In function ‘__glXWireToEvent’:
glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member
named ‘sbc_hi’
glxext
On Wed, May 4, 2011 at 4:18 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This seems more in line with what the documentation suggests we should be
> doing. It doesn't fix the rv635 regression, though I thought it might,
> so it means I've no idea whats actually going wrong there.
Patch looks g
- Original Message -
> Hi,
>
> Looking at the Symbol table of a recent
> (66b66295d0bc856c69fd22575580c7ecee16 ) libEGL.dll. I get the
> following mangled names:
>
> eglBindAPI
> _eglBindContext
> _eglBindTexImage
> eglBindTexImage
> _eglBindWaylandDisplayWL@8
> _eglCheckResource
>
Hi,
Looking at the Symbol table of a recent
(66b66295d0bc856c69fd22575580c7ecee16 ) libEGL.dll. I get the
following mangled names:
eglBindAPI
_eglBindContext
_eglBindTexImage
eglBindTexImage
_eglBindWaylandDisplayWL@8
_eglCheckResource
eglChooseConfig
That is stdcall and cdecl calling conven
From: Dave Airlie
This seems more in line with what the documentation suggests we should be
doing. It doesn't fix the rv635 regression, though I thought it might,
so it means I've no idea whats actually going wrong there.
Signed-off-by: Dave Airlie
---
src/gallium/winsys/r600/drm/r600_hw_conte
56 matches
Mail list logo
