https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #2 from Thierry Reding
2012-01-11 23:35:47 PST ---
(In reply to comment #1)
> Scons supports cross-compilation using approach 1). It builds the
> builtin_compiler and its dependencies twice. This works because each
> platform/machine
On 12-01-11 01:29 AM, Matt Turner wrote:
> On Wed, Jan 11, 2012 at 1:16 AM, Matt Turner wrote:
>> Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
>> easier while still specifically requiring bison and flex.
>>
>> Based on bison.m4 and flex.m4 found in LLVM's tree.
>>
>> Sig
On 12-01-11 01:16 AM, Matt Turner wrote:
> AC_PROG_PATH was used in the original configure.ac (dca1b796b) and I
> can't see any reason AC_PROG_SED wasn't used.
>
> Signed-off-by: Matt Turner
> ---
> configure.ac |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/config
On 12-01-11 01:16 AM, Matt Turner wrote:
> Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
> easier while still specifically requiring bison and flex.
>
> Based on bison.m4 and flex.m4 found in LLVM's tree.
>
> Signed-off-by: Matt Turner
> ---
> configure.ac |9 ---
Use a bitmask approach to compute gl_array_object::_MaxElement.
To make this work correctly depending on the shader type actually used,
make use of the newly introduced typed bitmask getters.
With this change I gain about 5% draw time on some osgviewer examples.
Signed-off-by: Mathias Fröhlich
--
Depending on the installed shader type, different arrays are used
from gl_array_object. Provide helper functions that compute
the bitmask of these arrays that are finally enabled for a given
shader type. The will be used in a followup change.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/arr
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/mtypes.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 9fdabf9..b381ad2 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -199,19 +199,19 @
Hi,
Thanks for the first review.
Following a short followup series to the gl_array_object change.
The most important change is the use ot an ffs based loop to compute
gl_array_object::_MaxElement. This change provides a noticable performance
improovement for my average workloads.
To implement t
Hi Eric,
Thanks for the review.
I will send shortly an updated patch.
... except:
On Friday, December 30, 2011 12:13:36 Eric Anholt wrote:
> Also, I think that helper would be easier to read as;
>
> + GLbitfield64 enabled = arrayObj->_Enabled;
> +
> + if (enabled & VERT_ATTRIB_GENERIC0)
>
On 11.01.2012 21:11, Brian Paul wrote:
On 01/11/2012 08:06 PM, Alexander von Gluck wrote:
On 11.01.2012 14:50, Brian Paul wrote:
Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
---
src/mesa/main/imports.c | 11 ++-
diff -
Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
v2: remove #ifdef _WIN32, __IBMC__, __IBMCPP_ tests inside ffs()
implementation. The #else clause was recursive.
---
src/mesa/drivers/dri/i965/brw_wm_emit.c | 12 ++--
src/
On 01/11/2012 08:06 PM, Alexander von Gluck wrote:
On 11.01.2012 14:50, Brian Paul wrote:
Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
---
src/mesa/main/imports.c | 11 ++-
diff --git a/src/mesa/main/imports.c b/src/mes
On 11.01.2012 14:50, Brian Paul wrote:
Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
---
src/mesa/main/imports.c | 11 ++-
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 2469e42.
only check ARB_fbo, add shader_texture_lod as a requirement
---
src/mesa/main/version.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 49cdc30..38ae1ce 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/ve
On 01/11/2012 01:17 AM, Yuanhan Liu wrote:
On Tue, Jan 10, 2012 at 08:43:18PM -0700, Brian Paul wrote:
On Tue, Jan 3, 2012 at 8:59 PM, Yuanhan Liu wrote:
On Wed, Jan 04, 2012 at 11:20:07AM +0800, Yuanhan Liu wrote:
On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:
Ah index
On 01/11/2012 06:06 PM, Anuj Phogat wrote:
Calling glXSwapBuffers with no bound context causes segmentation fault in
function intelDRI2Flush. All the gl calls should be ignored after setting the
current context to null. So the contents of framebuffer stay unchanged.
But the driver should not seg
There are 3 changes:
1) stride is specified for each buffer, not just one, so that drivers don't
have to derive it from the outputs
2) new per-output property dst_offset, which specifies the offset
into the buffer in dwords where the output should be stored,
so that drivers don't have to
Calling glXSwapBuffers with no bound context causes segmentation fault in
function intelDRI2Flush. All the gl calls should be ignored after setting the
current context to null. So the contents of framebuffer stay unchanged.
But the driver should not seg fault.
Bugzilla: https://bugs.freedesktop.or
On Thu, Jan 12, 2012 at 7:47 AM, Jakob Bornecrantz wrote:
> On Thu, Jan 12, 2012 at 12:37 AM, Matt Turner wrote:
>> ---
>> No one on IRC knows why an unshared glapi is useful.
>>
>> Does anyone have a use-case for this?
>>
>> If not, we can drop it to simplify automake work.
>
> I tried searching
Hi all
So after much building and testing I finally made the branch. I was planning on
doing a rc1 release now as well but it looks like historically we have opened
the branch and then made the first rc release a short time after, so I'm
holding of on it.
If people want a RC release ASAP I can
On 01/11/2012 03:40 PM, Eric Anholt wrote:
> Previously, we were saying that everything from the starting tile to
> region width+height was part of the limits of our depthbuffer, even if
> the tile was near the bottom of the depthbuffer. This mean that our
> range was not clipping to buffer buonds
2012/1/12 Matt Turner
> Fixes glsl-const-folding-01. inversesqrt(1.0) != 1.0 was evaluating as
> true.
>
> Signed-off-by: Matt Turner
> ---
> I think softpipe also had some problems recently due to -ffast-math?
>
> configure.ac |3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
>
Fixes glsl-const-folding-01. inversesqrt(1.0) != 1.0 was evaluating as
true.
Signed-off-by: Matt Turner
---
I think softpipe also had some problems recently due to -ffast-math?
configure.ac |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
in
On Thu, Jan 12, 2012 at 12:37 AM, Matt Turner wrote:
> ---
> No one on IRC knows why an unshared glapi is useful.
>
> Does anyone have a use-case for this?
>
> If not, we can drop it to simplify automake work.
I tried searching on gmail as to why this was added, but I turned up
nothing. Maybe Chi
On 01/11/2012 03:37 PM, Jakob Bornecrantz wrote:
Fix suggested by Kenneth Graunke.
Signed-off-by: Jakob Bornecrantz
---
Makefile |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 4a41948..1fa369a 100644
--- a/Makefile
+++ b/Makefile
@@ -191,6
Previously, we were saying that everything from the starting tile to
region width+height was part of the limits of our depthbuffer, even if
the tile was near the bottom of the depthbuffer. This mean that our
range was not clipping to buffer buonds if the start tile was anything
but the start of th
Fix suggested by Kenneth Graunke.
Signed-off-by: Jakob Bornecrantz
---
Makefile |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 4a41948..1fa369a 100644
--- a/Makefile
+++ b/Makefile
@@ -191,6 +191,8 @@ PACKAGE_NAME = MesaLib-$(PACKAGE_VERSION)
---
No one on IRC knows why an unshared glapi is useful.
Does anyone have a use-case for this?
If not, we can drop it to simplify automake work.
configs/autoconf.in |1 -
configure.ac| 24 +---
src/egl/drivers/dri2/Androi
https://bugs.freedesktop.org/show_bug.cgi?id=44561
--- Comment #6 from Stephane Marchesin 2012-01-11
15:16:09 PST ---
It should be fixed in git, please retest and close.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
On 01/11/2012 03:46 PM, Eric Anholt wrote:
Fixes some _mesa_problem()s in oglconform.
---
src/mesa/drivers/common/meta.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index ad289aa..e4aced4 100644
--
Fixes piglit EXT_framebuffer_multisample/negative-copypixels.
---
src/mesa/main/drawpix.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index 9f5b0b3..01983d9 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/
Fixes piglit EXT_framebuffer_multisample/negative-copyteximage.
---
src/mesa/main/teximage.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 9475e84..d5e462b 100644
--- a/src/mesa/main/teximage.c
+++ b
Fixes piglit EXT_framebuffer_multisample-negative-readpixels.
---
src/mesa/main/readpix.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 0c0e539..c1489d2 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/r
Fixes piglit EXT_framebuffer_multisample/renderbuffer-samples.
---
src/mesa/main/fbobject.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index aefcaf3..e6bab4b 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/mai
Fixes some _mesa_problem()s in oglconform.
---
src/mesa/drivers/common/meta.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index ad289aa..e4aced4 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/me
On Wed, Jan 11, 2012 at 3:30 PM, Matt Turner wrote:
> Signed-off-by: Matt Turner
FWIW, a number of these extensions are supported on older hw as well
(e.g., r300), although I guess that hw is not GL3 capable.
Alex
> ---
> docs/GL3.txt | 78
> +---
From: Neil Roberts
When using Mesa with a GLES API, calling _mesa_FramebufferRenderbuffer
with GL_DRAW_FRAMEBUFFER will report a 'user error' because
get_framebuffer_target validates that this enum from the framebuffer
blit extension is only used on GL. To work around it this patch makes
it use t
On 11.01.2012 15:19, Brian Paul wrote:
On 01/11/2012 02:14 PM, Kenneth Graunke wrote:
On 01/11/2012 12:50 PM, Brian Paul wrote:
Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
Looks great, Brian. Thanks!
Reviewed-by: Kenneth Gra
On 01/11/2012 03:02 PM, Jakob Bornecrantz wrote:
- Original Message -
Found this while preparing for the release, couldn't find
any users of this.
Signed-off-by: Jakob Bornecrantz
---
src/mesa/main/version.h | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
dif
- Original Message -
> Found this while preparing for the release, couldn't find
> any users of this.
>
> Signed-off-by: Jakob Bornecrantz
> ---
> src/mesa/main/version.h | 13 +
> 1 files changed, 1 insertions(+), 12 deletions(-)
>
> diff --git a/src/mesa/main/version.h b
Found this while preparing for the release, couldn't find
any users of this.
Signed-off-by: Jakob Bornecrantz
---
src/mesa/main/version.h | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/src/mesa/main/version.h b/src/mesa/main/version.h
index d288c4d..c1f4e8e
On 01/11/2012 02:14 PM, Kenneth Graunke wrote:
On 01/11/2012 12:50 PM, Brian Paul wrote:
Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
Looks great, Brian. Thanks!
Reviewed-by: Kenneth Graunke
I'm not going to push this until
This reverts commit bebc91f0f3a1f2d19d36a7f1a4f7c992ace064e9.
Fixes the following Piglit regressions on gen7:
spec/ARB_depth_buffer_float/fbo-clear-formats
spec/ARB_depth_texture/fbo-clear-formats
spec/EXT_packed_depth_stencil/fbo-clear-formats
I mistakenly thought that depth_rb->Widt
On 01/11/2012 12:50 PM, Brian Paul wrote:
Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
Looks great, Brian. Thanks!
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@
On 01/11/2012 12:06 PM, Paul Berry wrote:
We always access pull constant buffers using the message types "OWord
Block Read" or "OWord Dual Block Read". According to the Sandy Bridge
PRM, Vol 4 Part 1, pages 214 and 218, when using these messages:
"the surface pitch is ignored, the surface
On 01/11/2012 12:06 PM, Paul Berry wrote:
Commit 9bdc44a52804a64219a0ca1a061b18596863e524 (i965: Replace struct
with bit shifting for WM pull constant surfaces) accidentally
introduced off-by-one errors into the calculation of the surface
width, height, and depth. This patch restores the correct
Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
---
src/mesa/drivers/dri/i965/brw_wm_emit.c | 12 ++--
src/mesa/drivers/dri/i965/brw_wm_fp.c|4 ++--
src/mesa/drivers/dri/intel/intel_blit.c |2 +-
src/mesa/driv
On Wed, 11 Jan 2012 12:26:43 -0800, Paul Berry wrote:
> On 11 January 2012 12:23, Eric Anholt wrote:
>
> > On Wed, 11 Jan 2012 12:06:37 -0800, Paul Berry
> > wrote:
> > > We always access pull constant buffers using the message types "OWord
> > > Block Read" or "OWord Dual Block Read". Accordi
On 01/11/2012 01:13 PM, Kenneth Graunke wrote:
On 01/11/2012 12:02 PM, Eric Anholt wrote:
On Tue, 10 Jan 2012 23:08:51 -0600, Alexander von
Gluck wrote:
- Ensure mesa code uses the _mesa_ffs(l) functions
consistantly instead of jumping around between ffs
and _mesa_ffs
- This makes ffs/ffsl beh
On 01/11/2012 12:30 PM, Matt Turner wrote:
Signed-off-by: Matt Turner
Reviewed-by: Ian Romanick
---
docs/GL3.txt | 78 +-
1 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 0c67dce..0
On 01/10/2012 10:16 PM, Matt Turner wrote:
Signed-off-by: Matt Turner
Reviewed-by: Ian Romanick
---
configure.ac |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 08a0209..d36901b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -69,
On Wed, 11 Jan 2012 01:16:18 -0500, Matt Turner wrote:
> Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
> easier while still specifically requiring bison and flex.
>
> Based on bison.m4 and flex.m4 found in LLVM's tree.
Copying stuff from their tree without noting the li
On Wed, 11 Jan 2012 01:55:46 -0800, Kenneth Graunke
wrote:
> This rather rudely told the driver the moral equivalent of "Your shader
> code changed in an unimaginable way---don't assume anything; recompile!"
>
> The i965 driver used to rely on this in order to recompile the program
> when Sample
Signed-off-by: Matt Turner
---
docs/GL3.txt | 78 +-
1 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 0c67dce..069d36d 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -12,47 +12,47 @@ Featu
On 11 January 2012 12:23, Eric Anholt wrote:
> On Wed, 11 Jan 2012 12:06:37 -0800, Paul Berry
> wrote:
> > We always access pull constant buffers using the message types "OWord
> > Block Read" or "OWord Dual Block Read". According to the Sandy Bridge
> > PRM, Vol 4 Part 1, pages 214 and 218, wh
On Wed, 11 Jan 2012 12:06:37 -0800, Paul Berry wrote:
> We always access pull constant buffers using the message types "OWord
> Block Read" or "OWord Dual Block Read". According to the Sandy Bridge
> PRM, Vol 4 Part 1, pages 214 and 218, when using these messages:
>
> "the surface pitch is i
On Wed, 11 Jan 2012 12:06:36 -0800, Paul Berry wrote:
> Commit 9bdc44a52804a64219a0ca1a061b18596863e524 (i965: Replace struct
> with bit shifting for WM pull constant surfaces) accidentally
> introduced off-by-one errors into the calculation of the surface
> width, height, and depth. This patch r
On 01/11/2012 12:02 PM, Eric Anholt wrote:
On Tue, 10 Jan 2012 23:08:51 -0600, Alexander von Gluck
wrote:
- Ensure mesa code uses the _mesa_ffs(l) functions
consistantly instead of jumping around between ffs
and _mesa_ffs
- This makes ffs/ffsl behave more like the popcount code
- Bett
On Fri, 6 Jan 2012 13:00:36 -0800, Anuj Phogat wrote:
> glDrawBuffer(GL_FRONT_AND_BACK) results in to segmentation fault if
> intel->is_front_buffer_rendering is not enabled with GL_FRONT_AND_BACK.
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44153
Reviewed-by: Eric Anholt
pgpYNbO
We always access pull constant buffers using the message types "OWord
Block Read" or "OWord Dual Block Read". According to the Sandy Bridge
PRM, Vol 4 Part 1, pages 214 and 218, when using these messages:
"the surface pitch is ignored, the surface is treated as a
1-dimensional surface. A
Commit 9bdc44a52804a64219a0ca1a061b18596863e524 (i965: Replace struct
with bit shifting for WM pull constant surfaces) accidentally
introduced off-by-one errors into the calculation of the surface
width, height, and depth. This patch restores the correct
computation.
The reason this wasn't notice
On Tue, 10 Jan 2012 23:08:51 -0600, Alexander von Gluck
wrote:
>
> - Ensure mesa code uses the _mesa_ffs(l) functions
>consistantly instead of jumping around between ffs
>and _mesa_ffs
> - This makes ffs/ffsl behave more like the popcount code
> - Better detects and handles edge cases of
On 01/10/2012 11:36 PM, Kenneth Graunke wrote:
Both dri2_create_context_attribs and drisw_create_context_attribs call
dri2_convert_glx_attribs, expecting it to fill in *api on success.
However, when num_attribs == 0, it was returning true without setting
*api, causing the caller to use an uninit
On Wed, Jan 11, 2012 at 7:30 PM, Dave Airlie wrote:
> On Wed, Jan 11, 2012 at 7:30 PM, Dave Airlie wrote:
>> On Wed, Jan 11, 2012 at 7:20 PM, Jose Fonseca wrote:
>>> Test slaves are also reporting similar failures on glean:
>>>
>>> ./glean --run results --overwrite --quick --tests glsl1'
>>> w
On Wed, Jan 11, 2012 at 7:30 PM, Dave Airlie wrote:
> On Wed, Jan 11, 2012 at 7:20 PM, Jose Fonseca wrote:
>> Test slaves are also reporting similar failures on glean:
>>
>> ./glean --run results --overwrite --quick --tests glsl1'
>> warning: failed to translate tgsi opcode F2I to LLVM
>> warn
On Wed, Jan 11, 2012 at 7:20 PM, Jose Fonseca wrote:
> Test slaves are also reporting similar failures on glean:
>
> ./glean --run results --overwrite --quick --tests glsl1'
> warning: failed to translate tgsi opcode F2I to LLVM
> warning: failed to translate tgsi opcode IDIV to LLVM
> src/gal
On Wed, Jan 11, 2012 at 10:13, Jose Fonseca wrote:
> - Original Message -
>> Where else would the flush go?
>
> Maybe one of the callers already invoked glFlush, or something like that.
>
Not that I could see.
>> I'll look into fixing it differently
>> but if the flush is anywhere in the
Test slaves are also reporting similar failures on glean:
./glean --run results --overwrite --quick --tests glsl1'
warning: failed to translate tgsi opcode F2I to LLVM
warning: failed to translate tgsi opcode IDIV to LLVM
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:2232:emit_instructio
On Fri 06 Jan 2012 01:00:36 PM PST, Anuj Phogat wrote:
> glDrawBuffer(GL_FRONT_AND_BACK) results in to segmentation fault if
> intel->is_front_buffer_rendering is not enabled with GL_FRONT_AND_BACK.
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44153
>
> Reported-by: Yi Sun
> Signed-off
how did you get gallivm to get this opcode?
it shouldn't be possible yet, and gallivm needs a lot of work before
it can do integers.
Dave.
On Wed, Jan 11, 2012 at 6:23 PM, nobled wrote:
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c | 1 +
> src/gallium/auxiliary/gallivm/lp_bld_tgs
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c |1 +
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
index a021efd..88
- Original Message -
> Where else would the flush go?
Maybe one of the callers already invoked glFlush, or something like that.
> I'll look into fixing it differently
> but if the flush is anywhere in the makecurrent path, the same issue
> will happen. Again, none of the classic dri driv
Are you sure that the flush doesn't happen somewhere higher up in the
call chain, like in the common dri code, or glx code?
Cheers, Jakob.
- Ursprungligt meddelande -
> Where else would the flush go? I'll look into fixing it differently
> but if the flush is anywhere in the makecurrent pa
https://bugs.freedesktop.org/show_bug.cgi?id=44693
Bug #: 44693
Summary: [r600g,regression] Piglit: Four GL_SELECT tests fail
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Stat
Where else would the flush go? I'll look into fixing it differently
but if the flush is anywhere in the makecurrent path, the same issue
will happen. Again, none of the classic dri drivers do it.
Stéphane
2012/1/11 Jose Fonseca :
> Stephane,
>
> Although flushing the front buffer may be unnecess
On 10 January 2012 13:38, Christoph Bumiller
wrote:
> On 01/10/2012 10:09 PM, Dave Airlie wrote:
> > On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt wrote:
> >> On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie
> wrote:
> >>> From: Dave Airlie
> >>>
> >>> Things can get confused if you expose one wi
On Wed, Jan 11, 2012 at 1:49 AM, Kenneth Graunke wrote:
> On 01/10/2012 10:16 PM, Matt Turner wrote:
>>
>> Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
>> easier while still specifically requiring bison and flex.
>>
>> Based on bison.m4 and flex.m4 found in LLVM's tree.
On 11 January 2012 11:44, Kenneth Graunke wrote:
> The gen7_urb atom depends on CACHE_NEW_VS_PROG and CACHE_NEW_GS_PROG,
> causing gen7_upload_urb() to be called when switching to a new VS
> program.
>
> In addition to partitioning the URB space between the VS and GS,
> gen7_upload_urb() also all
On Wed, 2012-01-11 at 08:43 -0700, Brian Paul wrote:
> On 01/11/2012 08:13 AM, Adam Jackson wrote:
> > On Tue, 2012-01-10 at 19:46 -0700, Brian Paul wrote:
> >> From: Brian Paul
> >>
> >> This is a follow-on to the previous commits. It seems that
> >> XShmQueryVersion() can trigger an X error afte
https://bugs.freedesktop.org/show_bug.cgi?id=44618
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
--- Comment #1 from J
On 01/11/2012 08:13 AM, Adam Jackson wrote:
On Tue, 2012-01-10 at 19:46 -0700, Brian Paul wrote:
From: Brian Paul
This is a follow-on to the previous commits. It seems that
XShmQueryVersion() can trigger an X error after the first X
connection is closed and we start using a new connection.
I
On 01/11/2012 06:25 AM, Dave Airlie wrote:
From: Dave Airlie
This along with the TGSI support lets the piglit sampler-cube-shadow
test pass on softpipe.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |5 +++--
src/mesa/state_tracker/st_mesa_to_tgsi.c |1 +
On 01/11/2012 06:25 AM, Dave Airlie wrote:
From: Dave Airlie
This adds support for shadow cubemap texture sampling instructions.
This is required for GL 3.0.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi/tgsi_exec.c |2 ++
src/gallium/auxiliary/tgsi/tgsi_strings.c |
On Tue, 2012-01-10 at 19:46 -0700, Brian Paul wrote:
> From: Brian Paul
>
> This is a follow-on to the previous commits. It seems that
> XShmQueryVersion() can trigger an X error after the first X
> connection is closed and we start using a new connection.
I assume this is when you switch which
From: Dave Airlie
This along with the TGSI support lets the piglit sampler-cube-shadow
test pass on softpipe.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |5 +++--
src/mesa/state_tracker/st_mesa_to_tgsi.c |1 +
2 files changed, 4 insertions(+), 2 deletio
From: Dave Airlie
This adds support for shadow cubemap texture sampling instructions.
This is required for GL 3.0.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi/tgsi_exec.c |2 ++
src/gallium/auxiliary/tgsi/tgsi_strings.c |1 +
src/gallium/auxiliary/tgsi/tgsi_util.c
Stephane,
Although flushing the front buffer may be unnecessary, flushing itself is not,
as glXMakeCurrent mandates that the current must be flushed:
"Pending commands to the previous context, if any, are flushed before it is
released."
So this flush call can only be removed, if a flush is
The gen7_urb atom depends on CACHE_NEW_VS_PROG and CACHE_NEW_GS_PROG,
causing gen7_upload_urb() to be called when switching to a new VS
program.
In addition to partitioning the URB space between the VS and GS,
gen7_upload_urb() also allocated space for VS and PS push constants.
Unfortunately, this
I actually made this change locally when I found the issue with shader
recompilations, so this is:
Tested-by: Marek Olšák
On Wed, Jan 11, 2012 at 10:55 AM, Kenneth Graunke wrote:
> This rather rudely told the driver the moral equivalent of "Your shader
> code changed in an unimaginable way---do
https://bugs.freedesktop.org/show_bug.cgi?id=44666
--- Comment #2 from Dave Airlie 2012-01-11 02:54:51
UTC ---
already fixed in master.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the b
https://bugs.freedesktop.org/show_bug.cgi?id=44666
--- Comment #1 from Pete Beardmore 2012-01-11 02:34:54
PST ---
Created attachment 55413
--> https://bugs.freedesktop.org/attachment.cgi?id=55413
1x trivial patch
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=44666
Bug #: 44666
Summary: softpipe_screen struct member typos
Classification: Unclassified
Product: Mesa
Version: git
Platform: All
OS/Version: All
Status: NEW
S
Hi Chad,
I tracked down the Gen7 HiZ regression a little bit. It turns out it
isn't HiZ, since
$ INTEL_HIZ=0 ./bin/fbo-clear-formats GL_ARB_depth_texture
still fails. However, reverting commit bebc91f0f3a1f2d19d36a7
(i965: Replace references to stencil region size with buffer size) fixes
t
This rather rudely told the driver the moral equivalent of "Your shader
code changed in an unimaginable way---don't assume anything; recompile!"
The i965 driver used to rely on this in order to recompile the program
when SamplerUnits changed. It now properly listens to _NEW_PROGRAM and
_NEW_TEXTU
Since sampler unit information is encoded inside the sampler SEND
instruction, we need to create specialized shaders for different values
of the SamplerUnits array. In particular, we need to recompile whenever
SamplerUnits changes.
This is exactly what the program keys are for: when we need to ge
The whole reason I avoided this was because it might operate on a
brw_vertex_program or a brw_fragment_program. However, that isn't a
problem: all we need is the gl_program base type.
This avoids awkwardly passing the loop counter 'i' as a parameter,
simplifies both callers, and most importantly,
On Tue, Jan 10, 2012 at 08:43:18PM -0700, Brian Paul wrote:
> On Tue, Jan 3, 2012 at 8:59 PM, Yuanhan Liu
> wrote:
> > On Wed, Jan 04, 2012 at 11:20:07AM +0800, Yuanhan Liu wrote:
> >> On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:
> >> > Ah index scanning...
> >> > I don't l
97 matches
Mail list logo
