On Thu, Sep 15, 2011 at 11:26 PM, Brian Paul wrote:
> From: Brian Paul
>
> Pass an explicit surface format as we do with pipe_put_tile_rgba_format().
> This fixes the piglit fbo-srgb-blit test. With GL_EXT_framebuffer_sRGB we
> override the resource's format with an explicit format (linear vs. s
On Thu, Sep 15, 2011 at 11:26 PM, Brian Paul wrote:
> From: Brian Paul
Reviewed-by: Dave Airlie
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=40754
ojab changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 09/15/2011 09:19 AM, Paul Berry wrote:
> When copy propagating a value into an instruction that negates its
> argument, we need to invert the sense of the value's "negate" flag, so
> that -(+x) becomes -x and -(-x) becomes +x.
>
> Previously, we were always setting the value's "negate" flag to
In i965 GEN6+ (and I suspect most other hardware), gl_ClipDistance
needs to be laid out as a pair of vec4's (the first containing clip
distances 0-3, and the second containing clip distances 4-7).
However, it is declared in GLSL as an array of 8 floats.
This lowering pass acts at the GLSL level, m
This patch fixes a bug in ir_hirearchical_visitor: when traversing an
exec_list representing the formal or actual parameters of a function,
it modified base_ir to point to each parameter in turn, rather than
leaving it as a pointer to the enclosing statement. This was a
problem, since base_ir is u
From: Brian Paul
Pass an explicit surface format as we do with pipe_put_tile_rgba_format().
This fixes the piglit fbo-srgb-blit test. With GL_EXT_framebuffer_sRGB we
override the resource's format with an explicit format (linear vs. sRGB).
We need to do so both when getting and putting tiles.
F
From: Brian Paul
---
src/gallium/drivers/softpipe/sp_tile_cache.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_tile_cache.c
b/src/gallium/drivers/softpipe/sp_tile_cache.c
index 60870b8..7372470 100644
--- a/src/gallium/drivers/s
On 09/15/2011 03:55 PM, Paul Berry wrote:
draw_pipe_clip.c contained an ifdef to ensure that its local
definition of MAX_CLIPPED_VERTICES would not take effect if the global
MAX_CLIPPED_VERTICES (defined in src/mesa/main/config.h) was already
defined. This was unnecessary because draw_pipe_clip.
Since Mesa is now capable of supporting up to 8 clipping planes
instead of 6, this patch updates Gallium internals to support 8
clipping planes as well.
---
src/gallium/include/pipe/p_state.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/include/pipe/p_state
draw_pipe_clip.c contained an ifdef to ensure that its local
definition of MAX_CLIPPED_VERTICES would not take effect if the global
MAX_CLIPPED_VERTICES (defined in src/mesa/main/config.h) was already
defined. This was unnecessary because draw_pipe_clip.c doesn't
directly or indirectly include src
On 09/15/2011 02:24 PM, Marek Olšák wrote:
On Thu, Sep 15, 2011 at 5:38 PM, Brian Paul wrote:
From: Brian Paul
If we're drawing to a luminance, luminance/alpha or intensity surface
we have to adjust (rebase) the fragment/quad colors before writing them
to the tile cache. The tile cache always
On 09/14/2011 06:39 PM, Tobias Droste wrote:
LLVM 3.0svn added SubtargetInfo as additional parameter to
createMCDisassembler() and createMCInstPrinter().
See revision 139237 of LLVM.
Signed-off-by: Tobias Droste
Pushed. Thanks.
-Brian
___
mesa-dev
On 14 September 2011 13:04, Brian Paul wrote:
> On 09/14/2011 01:49 PM, Paul Berry wrote:
>
>> To support GLSL 1.30, we will need to increase MAX_CLIP_PLANES to 8,
>> and as a side effect this will increase the value of
>> MAX_CLIPPED_VERTICES defined in src/mesa/main/config.h. Gallium has
>> it
On Thu, Sep 15, 2011 at 5:38 PM, Brian Paul wrote:
> From: Brian Paul
>
> If we're drawing to a luminance, luminance/alpha or intensity surface
> we have to adjust (rebase) the fragment/quad colors before writing them
> to the tile cache. The tile cache always stores RGBA colors but if
> we're c
https://bugs.freedesktop.org/show_bug.cgi?id=40920
Summary: [openvg] defective pixels using mesa with openvg
Product: Mesa
Version: git
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=40919
Summary: vgChildImage seems not to be implemented
Product: Mesa
Version: git
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Co
Am 15.09.2011 19:11, schrieb Dave Airlie:
>>>
>>> This moves the gallium interface for clears from using a pointer to 4 floats
>>> to a pointer to a union of float/unsigned/int values. This is step one
>>> in allowing integer clears. I've tried to build as many drivers/pieces
>>> as I could, but I
On 09/15/2011 10:08 AM, Michel Dänzer wrote:
On Don, 2011-09-15 at 09:01 -0600, Brian Paul wrote:
On 09/15/2011 04:55 AM, Michel Dänzer wrote:
On Mit, 2011-09-14 at 11:44 -0600, Brian Paul wrote:
On 09/14/2011 11:16 AM, Michel Dänzer wrote:
From: Michel Dänzer
This makes sure that stObj->pt
On Don, 2011-09-15 at 13:01 -0400, Jeffrey Collins wrote:
> I am using Mesa 7.10, DRI driver for R600. I believe I see a memory
> leak of 1 page per frame with the code
>
>
> drawme()
> {
> glClearColor(0.0, 1.0, 0.0, 0.0);
> glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
> glClea
>>
>> This moves the gallium interface for clears from using a pointer to 4 floats
>> to a pointer to a union of float/unsigned/int values. This is step one
>> in allowing integer clears. I've tried to build as many drivers/pieces
>> as I could, but I think I missed a couple, (vega for instance see
I am using Mesa 7.10, DRI driver for R600. I believe I see a memory leak of 1
page per frame with the code
drawme(){glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);glClearColor(0.0, 1.0,
1.0, 1.0);glClear(GL_COLOR_BUFFER_BIT);eglSwapBuffers(
Am 15.09.2011 15:35, schrieb Dave Airlie:
> From: Dave Airlie
>
> This moves the gallium interface for clears from using a pointer to 4 floats
> to a pointer to a union of float/unsigned/int values. This is step one
> in allowing integer clears. I've tried to build as many drivers/pieces
> as I c
When copy propagating a value into an instruction that negates its
argument, we need to invert the sense of the value's "negate" flag, so
that -(+x) becomes -x and -(-x) becomes +x.
Previously, we were always setting the value's "negate" flag to true
in this circumstance, so that both -(+x) and -(
On Don, 2011-09-15 at 09:01 -0600, Brian Paul wrote:
> On 09/15/2011 04:55 AM, Michel Dänzer wrote:
> > On Mit, 2011-09-14 at 11:44 -0600, Brian Paul wrote:
> >> On 09/14/2011 11:16 AM, Michel Dänzer wrote:
> >>> From: Michel Dänzer
> >>>
> >>> This makes sure that stObj->pt exists and is up to da
Looks great to me.
Feel free to add a new UTIL_FORMAT_SWIZZLE_MAX if it helps.
Jose
- Original Message -
> From: Brian Paul
>
> ---
> src/gallium/auxiliary/util/u_format.c | 94
> +
> src/gallium/auxiliary/util/u_format.h | 16 ++
> 2 files cha
From: Brian Paul
If we're drawing to a luminance, luminance/alpha or intensity surface
we have to adjust (rebase) the fragment/quad colors before writing them
to the tile cache. The tile cache always stores RGBA colors but if
we're caching a L/A surface (for example) we need to be sure that R=G=
From: Brian Paul
---
src/gallium/auxiliary/util/u_format.c | 94 +
src/gallium/auxiliary/util/u_format.h | 16 ++
2 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format.c
b/src/gallium/auxiliary/util/u_format.
On Thu, Sep 15, 2011 at 11:17 PM, Brian Paul wrote:
> From: Brian Paul
>
> When compiling glDrawPixels, glTexImage(), etc. and we're copying
> the user's image we need to be careful about GL error checking.
> Previously, we were incorrectly generating GL_OUT_OF_MEMORY in
> unpack_image() if width
From: Brian Paul
When compiling glDrawPixels, glTexImage(), etc. and we're copying
the user's image we need to be careful about GL error checking.
Previously, we were incorrectly generating GL_OUT_OF_MEMORY in
unpack_image() if width < 0 or height < 0 or for invalid format/type
values. We now ch
On 09/15/2011 09:00 AM, Liu Aleaxander wrote:
On Thu, Sep 15, 2011 at 10:44 PM, Liu Aleaxander wrote:
On Thu, Sep 15, 2011 at 10:17 PM, Brian Paul wrote:
[snip]
...
The attached patch fixes the issues you've raised but defers error
generation from compile-time to execute-time. OK?
It's
From: Brian Paul
When compiling glDrawPixels, glTexImage(), etc. and we're copying
the user's image we need to be careful about GL error checking.
Previously, we were incorrectly generating GL_OUT_OF_MEMORY in
unpack_image() if width < 0 or height < 0 or for invalid format/type
values. We now ch
On Thu, Sep 15, 2011 at 11:04 PM, Brian Paul wrote:
> On 09/15/2011 08:44 AM, Liu Aleaxander wrote:
>>
>> On Thu, Sep 15, 2011 at 10:17 PM, Brian Paul wrote:
>>>
>>> On 09/14/2011 11:34 PM, Yuanhan Liu wrote:
Handle errors in _mesa_unpack_image instead in unpack_image. This
would m
On 09/15/2011 08:44 AM, Liu Aleaxander wrote:
On Thu, Sep 15, 2011 at 10:17 PM, Brian Paul wrote:
On 09/14/2011 11:34 PM, Yuanhan Liu wrote:
Handle errors in _mesa_unpack_image instead in unpack_image. This
would make the error message more detailed and specified.
This patch does:
1. trigg
On 09/15/2011 04:55 AM, Michel Dänzer wrote:
On Mit, 2011-09-14 at 11:44 -0600, Brian Paul wrote:
On 09/14/2011 11:16 AM, Michel Dänzer wrote:
From: Michel Dänzer
This makes sure that stObj->pt exists and is up to date.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39193 .
Signed-off-by
On Thu, Sep 15, 2011 at 10:44 PM, Liu Aleaxander wrote:
> On Thu, Sep 15, 2011 at 10:17 PM, Brian Paul wrote:
[snip]
...
>>
>> The attached patch fixes the issues you've raised but defers error
>> generation from compile-time to execute-time. OK?
>
> It's OK to me.
oops, I didn't look it caref
On Thu, Sep 15, 2011 at 3:14 PM, Marcin Slusarz
wrote:
> On Thu, Sep 15, 2011 at 02:35:49PM +0100, Dave Airlie wrote:
>> diff --git a/src/mesa/state_tracker/st_extensions.c
>> b/src/mesa/state_tracker/st_extensions.c
>> index 722db8d..f36994a 100644
>> --- a/src/mesa/state_tracker/st_extensions.c
On Thu, Sep 15, 2011 at 10:17 PM, Brian Paul wrote:
> On 09/14/2011 11:34 PM, Yuanhan Liu wrote:
>>
>> Handle errors in _mesa_unpack_image instead in unpack_image. This
>> would make the error message more detailed and specified.
>>
>> This patch does:
>> 1. trigger a GL_INVALID_VALUE if (width<
On Thu, Sep 15, 2011 at 3:17 PM, Jose Fonseca wrote:
> The interpretation of pipe_color_union depends on state which is not readily
> available (IIUC, it depends on the pipe format of the respective color
> rendertarget). I think this is recipe for a lot of bugs.
Apart from u_blitter you shoul
On 09/14/2011 11:34 PM, Yuanhan Liu wrote:
Handle errors in _mesa_unpack_image instead in unpack_image. This
would make the error message more detailed and specified.
This patch does:
1. trigger a GL_INVALID_VALUE if (width< 0 || height< 0 || depth< 0)
It's incorrect to generate an error
On Thu, Sep 15, 2011 at 02:35:49PM +0100, Dave Airlie wrote:
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index 722db8d..f36994a 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -215,7 +2
On Mit, 2011-09-14 at 11:44 -0600, Brian Paul wrote:
> On 09/14/2011 11:16 AM, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > This makes sure that stObj->pt exists and is up to date.
> >
> > Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39193 .
> >
> > Signed-off-by: Michel Dänzer
[...]
intel_image->mt might be NULL, say with border width set. It then would
trigger a segfault at intel_map/unmap_texture_image function.
This would fix the oglc misctest(basic.textureBorderIgnore) fail.
Signed-off-by: Yuanhan Liu
---
src/mesa/drivers/dri/intel/intel_tex.c |5 +++--
1 files cha
43 matches
Mail list logo
