On 07/12/2011 04:36 PM, Eric Anholt wrote:
> On Tue, 12 Jul 2011 15:44:12 -0500, Bryan Cain wrote:
>> It appears that the copy propagation pass in the GLSL compiler (in
>> opt_copy_propagation.cpp) doesn't do copy propagation when the
>> components of a variable are initialized separately, like th
- Original Message -
> Hi Jose,
>
> On Sat, Jul 9, 2011 at 6:03 AM, Jose Fonseca
> wrote:
> > I heard no concerns so I went ahead and made a branch where:
> > - I removed GLUT
> > - derived Mesa tarballs' file list from git ls-files.
> >
> > http://cgit.freedesktop.org/mesa/mesa/log/?h=
This is useful for shadow map generation. Tested with glsl-bug-22603,
which rendered the depth textures with fallbacks before.
---
src/mesa/drivers/dri/i915/i915_vtbl.c | 98 +
1 files changed, 50 insertions(+), 48 deletions(-)
diff --git a/src/mesa/drivers/dri/
We were updating our new viewport using the old buffers' _WindowMap.m.
We can do less math and avoid using that deprecated matrix by just
folding the viewport calculation right in to the driver.
Fixes piglit fbo-depthtex.
---
src/mesa/drivers/dri/i915/i915_state.c | 43 ++---
---
src/mesa/drivers/dri/i915/i830_vtbl.c | 46 +++-
src/mesa/drivers/dri/i915/i915_vtbl.c | 47 +++--
2 files changed, 20 insertions(+), 73 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
b/src/mesa/drivers/dri/i915/i83
i915_update_draw_buffers() already handles the fallback bit for
missing stencil region, so here we just need to handle whether the GL
thinks we have stencil data or not (and disable the test if so).
---
src/mesa/drivers/dri/i915/i915_state.c | 32 +++-
src/mesa/driver
We were disabling it once at the moment we changed draw buffers, but
later enabling of depth test could turn it back on. Fixes
fbo-nodepth-test.
Note that ctx->DrawBuffer has to be checked because during context
create we get called while it's still unset. However, we know we'll
get an intel_dra
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 48 --
1 files changed, 11 insertions(+), 37 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 831c3e0..55dbd4f 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
The 965 driver doesn't use these for deciding on fallbacks.
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index ef1d4f6..1609938 100644
-
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 62 +
1 files changed, 2 insertions(+), 60 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 5f67239..831c3e0 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 1609938..5f67239 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drive
---
src/mesa/drivers/dri/intel/intel_fbo.c | 31 +++
1 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 1669af2..55bcc75 100644
--- a/src/mesa/drivers/dri/intel/intel_
We were missing out on all the relocation changes by dumping what we
subdata()ed in instead of what's there after the kernel finished with
it.
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/i
The illusion of shared code here wasn't fooling anybody. It was
tempting to keep i830 and i915 still shared, but I think I actually
want to make them diverge shortly.
---
src/mesa/drivers/dri/i915/i830_vtbl.c | 202
src/mesa/drivers/dri/i915/i915_vtbl.c |
On Tue, 12 Jul 2011 15:44:12 -0500, Bryan Cain wrote:
> It appears that the copy propagation pass in the GLSL compiler (in
> opt_copy_propagation.cpp) doesn't do copy propagation when the
> components of a variable are initialized separately, like this:
>
> (declare (temporary ) vec4 vec_ctor)
>
Am 12.07.2011 21:44, schrieb Bryan Cain:
On 07/11/2011 11:53 AM, Egon Ashrafinia wrote:
Hello guys.
1 month ago, we talked about merging glsl-to-tgsi to master but it
still not happend. What about now? I could compile and test it a bit.
It works.
Anyone who could do it? What does Bryan Cain say
It appears that the copy propagation pass in the GLSL compiler (in
opt_copy_propagation.cpp) doesn't do copy propagation when the
components of a variable are initialized separately, like this:
(declare (temporary ) vec4 vec_ctor)
(assign (w) (var_ref vec_ctor) (constant float (1.00)) )
(ass
On 07/11/2011 11:53 AM, Egon Ashrafinia wrote:
> Hello guys.
>
> 1 month ago, we talked about merging glsl-to-tgsi to master but it
> still not happend. What about now? I could compile and test it a bit.
> It works.
> Anyone who could do it? What does Bryan Cain say about it?
Hi Egon,
Last month,
On Wed, 13 Jul 2011 01:18:16 +0800
Corbin Simpson wrote:
> I'd like to see it merged eventually for my GSoC student's work, which
> will probably depend on it, but waiting until August will probably be
> alright.
No, the post-processing doesn't depend on the glsl-to-tgsi work, at
least as it is
I'd like to see it merged eventually for my GSoC student's work, which
will probably depend on it, but waiting until August will probably be
alright.
~ C.
On Wed, Jul 13, 2011 at 1:00 AM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/11/2011 09:53 AM, Egon Ashra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/2011 10:04 AM, Jose Fonseca wrote:
>
>
> - Original Message -
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 07/12/2011 06:27 AM, Marek Olšák wrote:
>>> I prefer it this way and it has been suggested earlier by others
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For the series:
Reviewed-by: Ian Romanick
I especially like the tnl_pipeline_running guards in 2/6.
On 07/11/2011 06:53 PM, Eric Anholt wrote:
> ---
> src/mesa/drivers/dri/intel/intel_tex_image.c | 25 +++--
> 1 files changed
- Original Message -
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/12/2011 06:27 AM, Marek Olšák wrote:
> > I prefer it this way and it has been suggested earlier by others
> > too.
> > Opinions?
>
> So what happens to people that don't build any of gallium but do
> occasi
On Die, 2011-07-12 at 09:56 -0700, Ian Romanick wrote:
> On 07/12/2011 06:27 AM, Marek Olšák wrote:
> > I prefer it this way and it has been suggested earlier by others too.
> > Opinions?
>
> So what happens to people that don't build any of gallium but do
> occasionally compare with a software d
2011/7/12 Christian König :
> Am Dienstag, den 12.07.2011, 15:44 +0200 schrieb Henri Verbeet:
>> 2011/7/12 Christian König :
>> > + // TODO get BLEND_CLAMP state from rasterizer state
>> Is this comment still accurate?
> Yes it is, the very first generation of R600 chipsets need to know i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/11/2011 09:53 AM, Egon Ashrafinia wrote:
> Hello guys.
>
> 1 month ago, we talked about merging glsl-to-tgsi to master but it still
> not happend. What about now? I could compile and test it a bit. It works.
> Anyone who could do it? What does B
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/2011 06:27 AM, Marek Olšák wrote:
> I prefer it this way and it has been suggested earlier by others too.
> Opinions?
So what happens to people that don't build any of gallium but do
occasionally compare with a software driver? Does this mak
https://bugs.freedesktop.org/show_bug.cgi?id=39158
Ian Romanick changed:
What|Removed |Added
AssignedTo|mesa-dev@lists.freedesktop. |jbar...@virtuousgeek.org
https://bugs.freedesktop.org/show_bug.cgi?id=39147
--- Comment #3 from Laurent carlier 2011-07-12 09:11:40
PDT ---
... and applying only the first hunk seems enough.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://bugs.freedesktop.org/show_bug.cgi?id=39147
--- Comment #2 from Laurent carlier 2011-07-12 08:59:17
PDT ---
The patch fixes the problem.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee f
Am Dienstag, den 12.07.2011, 15:44 +0200 schrieb Henri Verbeet:
> 2011/7/12 Christian König :
> > it works with my available hardware (no piglit regressions). The changes
> > to the winsys code is about making a bo optional, even when the reg
> > informations says it isn't. This is useful for regis
On Tue, Jul 12, 2011 at 4:28 PM, Brian Paul wrote:
> On 07/12/2011 07:27 AM, Marek Olšák wrote:
>>
>> I think the past are those times when the gallium interface was changed
>> all
>> the time. Now it is not, so there is no reason to always compile the libs
>> if they are not needed.
>>
>> No ide
- Original Message -
> Hi guys,
>
> as the subject already indicates: I'm about to merge pipe-video to
> master and just wanted to ask if anybody has still any objections?
>
> After following Jose and Younes discussion on mesa-dev about how to
> design such an abstraction layer I took a
On Tue, 2011-07-12 at 11:13 -0400, Younes Manton wrote:
> 2011/7/12 Keith Whitwell :
> > I'm a bit unsure about what's the best approach here, though at this
> > stage I'm happy with your approach and don't think it needs to be
> > changed before any merge.
> >
> > But speaking in general terms, in
https://bugs.freedesktop.org/show_bug.cgi?id=39158
Ian Romanick changed:
What|Removed |Added
Component|Drivers/DRI/i965|GLX
AssignedTo|i...@freedesktop.o
2011/7/12 Keith Whitwell :
> I'm a bit unsure about what's the best approach here, though at this
> stage I'm happy with your approach and don't think it needs to be
> changed before any merge.
>
> But speaking in general terms, individual planes map well onto 8-bit
> single-component texture image
https://bugs.freedesktop.org/show_bug.cgi?id=39147
--- Comment #1 from Chia-I Wu 2011-07-12 08:00:34 PDT ---
Created an attachment (id=49010)
View: https://bugs.freedesktop.org/attachment.cgi?id=49010
Review: https://bugs.freedesktop.org/review?bug=39147&attachment=49010
fix linking errors
Do
Thank you for your replies!
在 2011年7月12日 下午10:47，Brian Paul 写道：
> On 07/12/2011 08:40 AM, Zhenbo Xu wrote:
> > I found the following bugs in mesa(v100) for SPEC CPU2000 v1.3
> >
> > leak bug 1:
> > //in file textimage.c at line 345
> > gl_text_image* image_to_texture(...) {
> > ...
> > textImage
On 07/12/2011 08:40 AM, Zhenbo Xu wrote:
> I found the following bugs in mesa(v100) for SPEC CPU2000 v1.3
>
> leak bug 1:
> //in file textimage.c at line 345
> gl_text_image* image_to_texture(...) {
> ...
> textImage = gl_alloc_texttrue_image(...);
> if (!textImage)
> return NULL;
> ...
> switch (
I found the following bugs in mesa(v100) for SPEC CPU2000 v1.3
leak bug 1:
//in file textimage.c at line 345
gl_text_image* image_to_texture(...) {
...
textImage = gl_alloc_texttrue_image(...);
if (!textImage)
return NULL;
...
switch (image->Type) {
case ...
...
default:
On 07/11/2011 08:42 AM, Emil Velikov wrote:
In some cases _mesa_create_context() can return NULL
an in the mesa state tracker, we do not concider the
case, which may cause issues within st_create_context_priv()
This patch adds a simple check (similar to the one in the
dri drivers)
v2 Do not zer
On 07/12/2011 07:27 AM, Marek Olšák wrote:
I think the past are those times when the gallium interface was changed all
the time. Now it is not, so there is no reason to always compile the libs
if they are not needed.
No idea why some hardware drivers need to contain whole softpipe and llvmpipe.
On 07/12/2011 07:27 AM, Marek Olšák wrote:
I prefer it this way and it has been suggested earlier by others too.
Opinions?
OK by me.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-d
On 07/12/2011 06:38 AM, Zhenbo Xu wrote:
Hi all,
I have been detecting memory leaks in mesa for SPEC2000,
and I found a kind of memory leaks shown in the following code
gl_text_image* image_to_texture(...) {
...
textImage = gl_alloc_texttrue_image(...);
if (!textImage)
return NULL;
I'm in favor for this FWIW.
Jose
- Original Message -
> I prefer it this way and it has been suggested earlier by others too.
> Opinions?
> ---
> src/egl/drivers/dri2/egl_dri2.c |5 -
> src/gallium/targets/dri-swrast/Makefile |2 +-
> src/gallium/targets/dri-swras
2011/7/12 Christian König :
> it works with my available hardware (no piglit regressions). The changes
> to the winsys code is about making a bo optional, even when the reg
> informations says it isn't. This is useful for registers where only a
> subset of the bits needs to be informed about a bo r
Only some targets need that, the others don't.
---
configure.ac|2 +-
src/gallium/targets/Makefile.dri|1 -
src/gallium/targets/Makefile.xorg |1 -
src/gallium/targets/dri-i915/Makefile |1 +
src/gallium/targets/dri-i965/Makefile |1
I think the past are those times when the gallium interface was changed all
the time. Now it is not, so there is no reason to always compile the libs
if they are not needed.
No idea why some hardware drivers need to contain whole softpipe and llvmpipe.
---
configure.ac | 23 +---
I prefer it this way and it has been suggested earlier by others too.
Opinions?
---
src/egl/drivers/dri2/egl_dri2.c |5 -
src/gallium/targets/dri-swrast/Makefile |2 +-
src/gallium/targets/dri-swrast/SConscript |6 +++---
src/glx/drisw_glx.c |3
Hi Jose,
On Sat, Jul 9, 2011 at 6:03 AM, Jose Fonseca wrote:
> I heard no concerns so I went ahead and made a branch where:
> - I removed GLUT
> - derived Mesa tarballs' file list from git ls-files.
>
> http://cgit.freedesktop.org/mesa/mesa/log/?h=robust-tarballs
>
> I've confirmed that both auto
Hi all,
I have been detecting memory leaks in mesa for SPEC2000,
and I found a kind of memory leaks shown in the following code
gl_text_image* image_to_texture(...) {
...
textImage = gl_alloc_texttrue_image(...);
if (!textImage)
return NULL;
...
switch (image->Type) {
case ...
Am Dienstag, den 12.07.2011, 13:06 +0200 schrieb Henri Verbeet:
> 2011/7/11 Christian König :
> > So what do you guys think about it?
> >
> I didn't look much at the rest of the changes, but some of the changes
> for r600g (diff attached) look a bit questionable. Could you take a
> look at those to
Hi,
> >as the subject already indicates: I'm about to merge pipe-video to
> >master and just wanted to ask if anybody has still any objections?
> >
>
> Yes [I am a watchman of compile/build errors (I know I am an old bitcher but
> code quality rules)]:
>
> https://build.opensuse.org/package/raw
2011/7/11 Christian König :
> So what do you guys think about it?
>
I didn't look much at the rest of the changes, but some of the changes
for r600g (diff attached) look a bit questionable. Could you take a
look at those to see if they're really all intentional and correct
before merging?
r600g.d
On Mon, 2011-07-11 at 18:24 +0200, Christian König wrote:
> Hi guys,
>
> as the subject already indicates: I'm about to merge pipe-video to
> master and just wanted to ask if anybody has still any objections?
>
> After following Jose and Younes discussion on mesa-dev about how to
> design such an
55 matches
Mail list logo
