In commit 16060c5adcd4d809f97e874fcde763260c17ac18, Eric changed the
code to not relayout just for baselevel changes - only if the range of
miplevels actually increases. So this comment is now wrong.
Notably, the i915 version of the code actually does what the comment
says.
Signed-off-by: Kennet
On Fri, 31 Jan 2014 10:58:48 -0800
Kenneth Graunke wrote:
> On 01/31/2014 03:14 AM, Lauri Kasanen wrote:
> > It's important not to break existing uses. There is no need to require
> > udev for 3d. This is an alternative to Stéphane Marchesin's patch
> > "loader: Make drmGetVersion logic condition
On Fri, 31 Jan 2014 13:28:48 -0800
Carl Worth wrote:
> Lauri Kasanen writes:
> >> 32-bit use is on the increase due to Steam; avoid any surprises
> >> and make Mesa LFS-aware.
> ...
> >> AC_PROG_MKDIR_P
> >> +AC_SYS_LARGEFILE
>
> Hi Lauri,
>
> Can you describe a bit more what failure modes yo
On Fri, 31 Jan 2014 23:54:43 -0800
Keith Packard wrote:
> Lauri Kasanen writes:
>
> > Forgot to mention, this would appear to make 3d impossible without udev
> > (ie, static devices, mdev, or other solutions).
>
> No, DRI2 continues to fall back to using the driver provided by the X
> server i
I wonder if we could lose mt->first_level entirely? It looks like it's
always going to be zero in i965 now.
On Sat, Feb 1, 2014 at 10:10 PM, Kenneth Graunke wrote:
> In commit 16060c5adcd4d809f97e874fcde763260c17ac18, Eric changed the
> code to not relayout just for baselevel changes - only if th
On Sat, 1 Feb 2014 11:36:07 +0200
Lauri Kasanen wrote:
> On Fri, 31 Jan 2014 13:28:48 -0800
> Carl Worth wrote:
>
> > Lauri Kasanen writes:
> > >> 32-bit use is on the increase due to Steam; avoid any surprises
> > >> and make Mesa LFS-aware.
> > ...
> > >> AC_PROG_MKDIR_P
> > >> +AC_SYS_LARG
https://bugs.freedesktop.org/show_bug.cgi?id=74312
Priority: medium
Bug ID: 74312
CC: olva...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: ilo_dri.so is not installed like other drivers
Severity: normal
Classif
Am 31.01.2014 21:36, schrieb Alex Deucher:
On Fri, Jan 31, 2014 at 7:05 AM, Marek Olšák wrote:
I think we always flush the HDP cache after (before?) command submission.
The kernel flushes the HDP cache in the fence command sequence.
But we do this at the top of the pipe instead of the botto
Reviewed-by: Marek Olšák
Marek
On Sat, Feb 1, 2014 at 1:38 AM, Brian Paul wrote:
> glTexSubImage(), glCopyTexSubImage() and glCompressedTexSubImage()
> only change the texel data, not other state like texture size or format.
> If a driver really needs do something special it can hook into the
>
https://bugs.freedesktop.org/show_bug.cgi?id=74312
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index f80a6a2..434a651 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 73526d8..b8a96fe 100644
--- a/src/gallium/
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index b8a96fe..b7921fa 100644
--- a/src/gallium/drivers/radeon/r600_buf
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index b7921fa..c973e39 100644
--- a/src/gallium/driver
Just for better organization.
---
src/mesa/Makefile.sources |1 +
src/mesa/SConscript |1 +
src/mesa/main/blit.c | 513 +
src/mesa/main/blit.h | 39
src/mesa/main/fbobject.c | 473
Mipmap generation has nothing to do with FBOs.
---
src/mesa/Makefile.sources |1 +
src/mesa/SConscript |1 +
src/mesa/main/fbobject.c | 92 ---
src/mesa/main/fbobject.h |4 --
src/mesa/main/genmipmap.c | 131 +++
The four functions in question weren't called from any other file.
---
src/mesa/main/fbobject.c | 70 +++---
src/mesa/main/fbobject.h | 20 -
2 files changed, 35 insertions(+), 55 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa
On 02/01/2014 01:42 AM, Chris Forbes wrote:
> I wonder if we could lose mt->first_level entirely? It looks like it's
> always going to be zero in i965 now.
Oh wow, I hadn't noticed that. It looks like you're right, except maybe
in one case...intel_renderbuffer_move_to_temp sets it to
intel_image-
https://bugs.freedesktop.org/show_bug.cgi?id=74127
--- Comment #10 from Kertesz Laszlo ---
I saw this bug when i installed mesa from git on Debian Wheezy (now the stable
version).
Debian Whezy doesnt have libudev1, only libudev0 (at version 175). After a few
hours of recompiling and hair pulling
On 02/01/2014 07:59 AM, Brian Paul wrote:
> Just for better organization.
> ---
> src/mesa/Makefile.sources |1 +
> src/mesa/SConscript |1 +
> src/mesa/main/blit.c | 513
> +
> src/mesa/main/blit.h | 39
> src/mesa/main/
On 01/31/2014 04:28 PM, Brian Paul wrote:
> Not really used anywhere.
> ---
> src/mesa/drivers/dri/nouveau/nouveau_state.c |2 +-
> src/mesa/drivers/dri/r200/r200_tex.c |5 ++---
> src/mesa/drivers/dri/radeon/radeon_tex.c |2 +-
> src/mesa/main/dd.h
On 01/31/2014 04:12 PM, Brian Paul wrote:
> Wasn't used in any other file.
> ---
> src/mesa/main/teximage.c | 10 +-
> src/mesa/main/teximage.h |3 ---
> 2 files changed, 5 insertions(+), 8 deletions(-)
Reviewed-by: Kenneth Graunke
signature.asc
Description: OpenPGP digital sig
On 01/31/2014 04:11 PM, Brian Paul wrote:
> ---
> src/mesa/drivers/dri/r200/r200_texstate.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/r200/r200_texstate.c
> b/src/mesa/drivers/dri/r200/r200_texstate.c
> index 5160c2c..c3c92cb 100644
>
On 01/31/2014 01:12 PM, Paul Berry wrote:
> From the GLSL 4.40 spec, section 6.4 (Jumps):
>
> The continue jump is used only in loops. It skips the remainder of
> the body of the inner most loop of which it is inside. For while
> and do-while loops, this jump is to the next evaluation
Kenneth Graunke writes:
> On 02/01/2014 01:42 AM, Chris Forbes wrote:
>> I wonder if we could lose mt->first_level entirely? It looks like it's
>> always going to be zero in i965 now.
>
> Oh wow, I hadn't noticed that. It looks like you're right, except maybe
> in one case...intel_renderbuffer_m
https://bugs.freedesktop.org/show_bug.cgi?id=74127
Eric Anholt changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=73902
Matt Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=73900
--- Comment #2 from Matt Turner ---
I've added a request for this to be picked for 10.0.3.
--
You are receiving this mail because:
You are the QA Contact for the bug.
___
mesa-dev mailing list
mesa-de
Another couple 10.0.3 requests
- fcefdc9a595c5 (see https://bugs.freedesktop.org/show_bug.cgi?id=73900)
- 1cdeeef6c400 (see https://bugs.freedesktop.org/show_bug.cgi?id=73902)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesk
Thanks Paul. Both are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Jan 31, 2014 at 1:22 PM, Carl Worth wrote:
> Matt Turner writes:
>> ---
>> src/glsl/opt_vectorize.cpp | 14 --
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> Hi Matt,
>
> I'm missing the rest of your commit message besides the one-line
> summary.
>
> I think the disci
On Thu, Jan 9, 2014 at 6:19 PM, Paul Berry wrote:
> ---
> src/glsl/main.cpp | 1 +
> src/glsl/standalone_scaffolding.cpp | 1 +
> src/mesa/main/context.c | 1 +
> src/mesa/main/get.c | 1 +
> src/mesa/main/get_hash_params.py| 3 +++
> src/mesa/mai
Now that the field is named "VAO" instead of "ArrayObj", it makes sense
to call the local variables "vao" instead of "arrayObj".
Completely generated by:
$ find . -type f -print0 | xargs 0 sed -i 's/arrayObj/vao/g'
Signed-off-by: Kenneth Graunke
---
src/mesa/main/api_arrayelt.c | 48 ++
For consistency with the previous renames.
Completely generated by:
$ find . -type f -print0 | xargs -0 sed -i \
's/_mesa_lookup_arrayobj/_mesa_lookup_vao/g'
Signed-off-by: Kenneth Graunke
---
src/mesa/main/arrayobj.c| 8
src/mesa/main/arrayobj.h| 2 +-
src/mesa/main/objectla
ctx is always used, even on release builds.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/arrayobj.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index acb1bf7..b33ba80 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj
Signed-off-by: Kenneth Graunke
---
src/mesa/main/arrayobj.c | 5 -
src/mesa/main/mtypes.h | 15 +++
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 46ccbdc..0b9592f 100644
--- a/src/mesa/main/arrayobj.c
+
DirectX and most hardware documentation use the term "Index Buffer" to
refer to a buffer containing indexes into arrays of vertex data, which
allows random access to vertex data, rather than sequential access.
OpenGL uses a different term for this concept: "Element Array Buffer".
However, "Index B
Chances are, people will be using the core names these days.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/arrayobj.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 0b9592f..acb1bf7 100644
--- a/src/mesa/main
_mesa_update_vao_client_arrays() is less of a mouthful than
_mesa_update_array_object_client_arrays(), and generally clearer.
Generated by:
$ find . -type f -print0 | xargs -0 sed -i \
's/_mesa_\([^_]*\)_array_object/_mesa_\1_vao/g'
with manual whitespace and indentation fixes applied.
Signed-o
I considered replacing it with "gl_vao", but spelling it out seemed to
fit better with Mesa's traditional style. Mesa doesn't shy away from
long type names - consider gl_transform_feedback_object,
gl_fragment_program_state, gl_uniform_buffer_binding, and so on.
Completely generated by:
$ find . -
On Thu, Jan 9, 2014 at 6:19 PM, Paul Berry wrote:
> ---
> src/mesa/main/shaderapi.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index 053f27b..680d449 100644
> --- a/src/mesa/main/shaderapi.c
> +++ b/src/mesa
27-28 Reviewed-by: Jordan Justen
On Thu, Jan 9, 2014 at 6:19 PM, Paul Berry wrote:
> Fixes piglit test:
> spec/ARB_compute_shader/linker/mix_compute_and_non_compute
> ---
> src/glsl/linker.cpp | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.
On Thu, Jan 9, 2014 at 6:19 PM, Paul Berry wrote:
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 8
> src/mesa/drivers/dri/i965/brw_program.c | 11 +++
> 2 files changed, 19 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/
On Thu, Jan 9, 2014 at 6:19 PM, Paul Berry wrote:
> This will allow testing of compute shader functionality before it is
> completed.
>
> To enable ARB_compute_shader functionality in the i965 driver, set
> INTEL_COMPUTE_SHADER=1.
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 11
44 matches
Mail list logo