On 11/02/2010 12:25 PM, Francisco Jerez wrote:
Brian Paul writes:
On 11/01/2010 08:02 PM, Francisco Jerez wrote:
Brian Paul writes:
[...]
- bitmap8 = (GLubyte *) calloc(1, width * height);
+ bitmap8 = (GLubyte *) malloc(width * height);
if (bitmap8) {
+ memset(bitmap8, ~a
Signed-off-by: Tilman Sauerbeck
---
v2: Also call into the pipe driver to make it release its reference.
src/mesa/state_tracker/st_context.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
in
On Tue, Nov 2, 2010 at 7:54 PM, Alex Deucher wrote:
> On Tue, Nov 2, 2010 at 3:40 PM, Keith Whitwell wrote:
>> These were previously being left in the default (D3D) mode. This mean
>> that triangles were drawn slightly incorrectly, but also because this
>> state is relied on by the u_blitter cod
On Tue, Nov 2, 2010 at 3:40 PM, Keith Whitwell wrote:
> Restore lost hunk in patch 2.
Set looks good to me. See my comment about updating evergreen to
follow the state rasterization rules as well.
Alex
>
> ___
> mesa-dev mailing list
> mesa-dev@lists
On Tue, Nov 2, 2010 at 3:40 PM, Keith Whitwell wrote:
> These were previously being left in the default (D3D) mode. This mean
> that triangles were drawn slightly incorrectly, but also because this
> state is relied on by the u_blitter code, all blits were half a pixel
> off.
Looks good. Evergr
These were previously being left in the default (D3D) mode. This mean
that triangles were drawn slightly incorrectly, but also because this
state is relied on by the u_blitter code, all blits were half a pixel
off.
---
src/gallium/drivers/r600/r600_state.c |5 +
src/gallium/driver
These were being set but not used anywhere.
---
src/gallium/drivers/r600/r600_buffer.c | 27 ---
src/gallium/drivers/r600/r600_resource.h |5 -
src/gallium/drivers/r600/r600_texture.c |1 -
3 files changed, 0 insertions(+), 33 deletions(-)
diff --git a/src
Generalize the existing tiled_buffer path in texture transfers for use
in some non-tiled up and downloads.
Use a staging buffer, which the winsys will restrict to GTT memory.
GTT buffers have the major advantage when they are mapped, they are
cachable, which is a very nice property for downloads,
This opens the question of what interface the winsys layer should
really have for talking about these concepts.
For now I'm using the existing gallium resource usage concept, but
there is no reason not use terms closer to what the hardware
understands - eg. the domains themselves.
---
src/gallium
---
src/gallium/drivers/r600/r600_texture.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index 4ebd5b7..7222b43 100644
--- a/src/gallium/drivers/r600/r600_textu
Restore lost hunk in patch 2.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hmm, after "cleaning" these patches up to mail out, I'm now seeing some
problems with this one... sigh. I'll resend shortly.
Keith
On Tue, 2010-11-02 at 11:40 -0700, Keith Whitwell wrote:
> This opens the question of what interface the winsys layer should
> really have for talking about these c
https://bugs.freedesktop.org/show_bug.cgi?id=31257
Sven Arvidsson changed:
What|Removed |Added
CC||s...@whiz.se
--- Comment #2 from Sven A
These were previously being left in the default (D3D) mode. This mean
that triangles were drawn slightly incorrectly, but also because this
state is relied on by the u_blitter code, all blits were half a pixel
off.
---
src/gallium/drivers/r600/r600_state.c |5 +
src/gallium/driver
These were being set but not used anywhere.
---
src/gallium/drivers/r600/r600_buffer.c | 27 ---
src/gallium/drivers/r600/r600_resource.h |5 -
src/gallium/drivers/r600/r600_texture.c |1 -
3 files changed, 0 insertions(+), 33 deletions(-)
diff --git a/src
Generalize the existing tiled_buffer path in texture transfers for use
in some non-tiled up and downloads.
Use a staging buffer, which the winsys will restrict to GTT memory.
GTT buffers have the major advantage when they are mapped, they are
cachable, which is a very nice property for downloads,
This opens the question of what interface the winsys layer should
really have for talking about these concepts.
For now I'm using the existing gallium resource usage concept, but
there is no reason not use terms closer to what the hardware
understands - eg. the domains themselves.
---
src/gallium
---
src/gallium/drivers/r600/r600_texture.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index 4ebd5b7..7222b43 100644
--- a/src/gallium/drivers/r600/r600_textu
On Tue, 2010-11-02 at 11:21 -0700, Francisco Jerez wrote:
> Keith Whitwell writes:
>
> > Francisco,
> >
> > This looks good - my only comment is that there seem to be two distinct
> > changes in this patch -- the modification to VBO behaviour when adding a
> > new attribute being one, but the cha
Brian Paul writes:
> On 11/01/2010 08:02 PM, Francisco Jerez wrote:
>> Brian Paul writes:
>>
>>> [...]
- bitmap8 = (GLubyte *) calloc(1, width * height);
+ bitmap8 = (GLubyte *) malloc(width * height);
if (bitmap8) {
+ memset(bitmap8, ~alpha, width * height
https://bugs.freedesktop.org/show_bug.cgi?id=31257
--- Comment #1 from jonathan 2010-11-02 11:22:09 PDT
---
ping
a little commenht please for know state
thanks
best regards
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail becaus
Keith Whitwell writes:
> Francisco,
>
> This looks good - my only comment is that there seem to be two distinct
> changes in this patch -- the modification to VBO behaviour when adding a
> new attribute being one, but the changes to vbo_exec_draw.c seem to be
> an unrelated cleanup. Is that corr
Tilman Sauerbeck [2010-10-31 17:38]:
> Signed-off-by: Tilman Sauerbeck
> ---
> src/mesa/state_tracker/st_context.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_context.c
> b/src/mesa/state_tracker/st_context.c
> index b5ea6d0..c0bfbe
On 11/01/2010 08:06 PM, Francisco Jerez wrote:
---
src/mesa/drivers/common/meta.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 9615b52..7ad1e72 100644
--- a/src/mesa/drivers/common/meta.c
+++
On 11/01/2010 08:02 PM, Francisco Jerez wrote:
Brian Paul writes:
[...]
- bitmap8 = (GLubyte *) calloc(1, width * height);
+ bitmap8 = (GLubyte *) malloc(width * height);
if (bitmap8) {
+ memset(bitmap8, ~alpha, width * height);
_mesa_expand_bitmap(width, height,&unpack
https://bugs.freedesktop.org/show_bug.cgi?id=31316
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Francisco,
This looks good - my only comment is that there seem to be two distinct
changes in this patch -- the modification to VBO behaviour when adding a
new attribute being one, but the changes to vbo_exec_draw.c seem to be
an unrelated cleanup. Is that correct?
Ordinarily I wouldn't bother p
https://bugs.freedesktop.org/show_bug.cgi?id=31316
Summary: The "clear" demo should be renamed
Product: Mesa
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
28 matches
Mail list logo
