Bump.
On 4 June 2013 23:03, Jonathan Liu wrote:
> Adds the dependencies of builtin_compiler as sources when cross
> compiling instead of using libtool to share compilation with src/glsl.
> The builtin_compiler executable is built for the host when cross
> compiling so it doesn't make sense to sha
Bump.
On 4 June 2013 23:04, Jonathan Liu wrote:
> The AC_CHECK_FILE macro can't be used for cross compiling as it will
> result in "error: cannot check for file existence when cross compiling".
> Replace it with the AS_IF macro.
>
> Signed-off-by: Jonathan Liu
> ---
> configure.ac | 12 ++--
On 07/02/2013 04:06 PM, Kenneth Graunke wrote:
The texture alignment unit functions are called from brw_tex_layout.c,
so it makes sense to put them there. Since the only caller of
intel_get_texture_alignment_unit() is in brw_tex_layout.c, it could be
made into a static function. However, this p
On 07/02/2013 01:54 AM, Kenneth Graunke wrote:
maxBatchSize was only ever initialized to BATCH_SZ, and a few places
used BATCH_SZ directly anyway.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 ++--
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 2 +-
On 07/02/2013 01:54 AM, Kenneth Graunke wrote:
brw_render_target_supported() is the only implementation of this
function, so it makes sense to just call it directly.
Rather than adding an #include of brw_wm.h, this patch moves the
prototype to brw_context.h. Prototypes seem to be in rather arbi
On 07/02/2013 01:54 AM, Kenneth Graunke wrote:
The __DRI_USE_INVALIDATE extension was added in May 11th, 2010 by commit
4258e3a2e1c327. At this point, it's unlikely that anyone's using the
right mix of new and old components to hit this path. Deleting it
removes an untested code path and cleans
On 07/02/2013 01:54 AM, Kenneth Graunke wrote:
The hook was a noop.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 6 --
src/mesa/drivers/dri/i965/intel_context.c | 3 ---
src/mesa/drivers/dri/i965/intel_context.h | 3 ---
3 files changed, 12 deletions(-
On 07/02/2013 01:54 AM, Kenneth Graunke wrote:
There are always better ways to do things.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_screen.c | 5 -
1 file changed, 5 deletions(-)
Patches 2-5 are
Reviewed-by: Chad Versace
__
On 07/02/2013 01:54 AM, Kenneth Graunke wrote:
A random smattering of things that just aren't used anymore.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_clip.h | 2 -
src/mesa/drivers/dri/i965/brw_draw.h | 5 --
src/mesa/drivers/dri/i965/brw_gs.h
For the series,
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
The texture alignment unit functions are called from brw_tex_layout.c,
so it makes sense to put them there. Since the only caller of
intel_get_texture_alignment_unit() is in brw_tex_layout.c, it could be
made into a static function. However, this patch instead simply folds
it into the caller, as
intel_miptree_create_layout() calls intel_get_texture_alignment_unit()
and then immediately calls brw_miptree_layout(). There are no other
callers.
intel_get_texture_alignment_unit() populates the miptree's alignment
unit fields, which are used by brw_miptree_layout() to determine where
to place
https://bugs.freedesktop.org/show_bug.cgi?id=66359
--- Comment #5 from Stefan Brüns ---
Might be the same problem as reported in this thread:
http://comments.gmane.org/gmane.comp.video.mesa3d.devel/55797
Long story, short answer: recompile xf86-video-intel without glamor support.
If you are o
The series is
Reviewed-by: Ian Romanick
On 07/02/2013 11:49 AM, Kenneth Graunke wrote:
A bit cleaner than having it in one giant function.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 159 +++--
1 file changed, 82 insertions(+), 7
Hi
I sent this to the wrong mailing list and it had the wrong patch format
Fixed thanks to glisse
Cheers
Mike
On 2 July 2013 21:34, Mike Lothian wrote:
> Hi
>
> This patch allows me to compile using GCC 4.7.3 system when using ld.bfd -
> it doesn't seem to be required on my GCC 4.8.1 system
On Wed, Jul 3, 2013 at 7:37 AM, Matt Turner wrote:
> On Tue, Jul 2, 2013 at 1:02 PM, Ian Romanick wrote:
>> 2. Instead of just posting md5sum for the release tarballs, I think we
>> should start GPG signing them. I'm not sure what sort of process we want to
>> establish for this. Should they ju
On Tue, Jul 2, 2013 at 11:37 PM, Matt Turner wrote:
> On Tue, Jul 2, 2013 at 1:02 PM, Ian Romanick wrote:
> > 2. Instead of just posting md5sum for the release tarballs, I think we
> > should start GPG signing them. I'm not sure what sort of process we
> want to
> > establish for this. Should
On Tue, Jul 2, 2013 at 1:02 PM, Ian Romanick wrote:
> 2. Instead of just posting md5sum for the release tarballs, I think we
> should start GPG signing them. I'm not sure what sort of process we want to
> establish for this. Should they just be signed by the release managers key?
> Is this easie
If the size argument isn't a multiple of four, we would have read/
copied uninitialized memory.
Fixes an issue reported by Myles C. Maxfield
---
src/mesa/program/prog_parameter.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/src/mesa/program/prog_paramete
OK, so I actually tested it (and fixed it) now and will post a patch for
review shortly.
-Brian
On 07/01/2013 04:09 PM, Myles C. Maxfield wrote:
Looks good to me. Thanks for fixing it up. Do the prospects look good
for getting this committed?
It would be cool if my name was attached to the p
Hi
This patch allows me to compile using GCC 4.7.3 system when using ld.bfd -
it doesn't seem to be required on my GCC 4.8.1 system using ld.gold - I'm
not sure why
Cheers
Mike
seq_file.patch
Description: Binary data
___
mesa-dev mailing list
mesa-de
To keep our six-month release cadence, it looks like we'll target August
22nd for 9.2. That means we'll probably need to make the release branch
on July 18th... that's just over two weeks from now.
Assuming that works for everyone, I'd like to propose a couple changes
to our post-9.2 release
On 07/02/2013 12:34 PM, Chad Versace wrote:
I second Marek's concern. Having intel_context defined differently
in two locations will cause nightmares in editors. It's possible,
but with much pain, to workaround that nightmare in Eclipse, but I'd
rather avoid it.
Seems reasonable to me.
I disl
I second Marek's concern. Having intel_context defined differently
in two locations will cause nightmares in editors. It's possible,
but with much pain, to workaround that nightmare in Eclipse, but I'd
rather avoid it.
I dislike brw_context, because it doesn't match all the other naming
conventi
https://bugs.freedesktop.org/show_bug.cgi?id=66359
--- Comment #4 from Fredrik Höglund ---
It looks like it's the indirect dispatch table that's broken.
The function pointer for glFramebufferTexture2D() is pointing at
glVertexAttrib2dv().
--
You are receiving this mail because:
You are the ass
https://bugs.freedesktop.org/show_bug.cgi?id=66359
--- Comment #3 from Hrvoje Senjan ---
Oops, that's
https://bugs.kde.org/show_bug.cgi?id=321760
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-
https://bugs.freedesktop.org/show_bug.cgi?id=66359
--- Comment #2 from Hrvoje Senjan ---
Downstream report
https://bugs.freedesktop.org/show_bug.cgi?id=66359
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailin
The driver is compiled in C99 mode, so this is not a problem. It's
slighlty tidier.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b
Using GL types is silly; this isn't even remotely API-facing.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/
This uses Doxygen style for the file comments, and generally makes it
more consistent with the rest of the driver.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 65 ++
1 file changed, 31 insertions(+), 34 deletions(-)
diff --git a/sr
This consolidates the miptree layout logic in a single file.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 74 +++-
src/mesa/drivers/dri/i965/intel_tex_layout.c | 67 -
src/mesa/drivers/dri/i965/intel_tex_layout.
Now that both 2DArray and Cube layouts are taken care of by helper
functions, it's easy to just call the right function for each
generation. This is a little cleaner than falling through.
This also reworks the comments. Referencing "Volume 1" of the BSpec
isn't very helpful, since that's only av
These do the exact same thing; combining them is tidier.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layout
A bit cleaner than having it in one giant function.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 159 +++--
1 file changed, 82 insertions(+), 77 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dr
On 07/02/2013 01:42 AM, Chris Forbes wrote:
Include src0 alpha in the RT write message when using MRT, so it is used
for the alpha test instead of the normal per-RT alpha value.
Fixes broken rendering in Dota2 under Wine [FDO #62647].
Could you use the normative bugzilla reference, and add a n
On 2 July 2013 01:42, Chris Forbes wrote:
> Include src0 alpha in the RT write message when using MRT, so it is used
> for the alpha test instead of the normal per-RT alpha value.
>
> Fixes broken rendering in Dota2 under Wine [FDO #62647].
>
> No Piglit regressions on Ivybridge.
>
> V2: reuse (a
On Sun, Jun 30, 2013 at 9:53 PM, Marek Olšák wrote:
> this also fixes the fast clear with multiple colorbuffers and each having
> a different format
Series is:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_blit.c | 21 -
> 1 file changed, 12 insertions(+)
Hi Kenneth,
please don't use the same name intel_context defined differently in
both drivers. The code indexing of my editor would be confused. It
would break features like jumping to the definition, finding all
usages, and refactoring.
Marek
On Tue, Jul 2, 2013 at 10:52 AM, Kenneth Graunke wro
https://bugs.freedesktop.org/show_bug.cgi?id=66357
Ross Burton changed:
What|Removed |Added
CC||r...@burtonini.com
--
You are receiving t
maxBatchSize was only ever initialized to BATCH_SZ, and a few places
used BATCH_SZ directly anyway.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 ++--
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 2 +-
src/mesa/drivers/dri/i965/intel_context.c | 1 -
brw_annotate_aub() is the only implementation of this function, so it
makes sense to just call it directly.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 1 -
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 ++--
src/mesa/drivers/dri/i965/intel_context.h
brw_debug_batch() is the only implementation of this function, so it
makes sense to just call it directly.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 1 -
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 ++--
src/mesa/drivers/dri/i965/intel_context.h
brw_render_target_supported() is the only implementation of this
function, so it makes sense to just call it directly.
Rather than adding an #include of brw_wm.h, this patch moves the
prototype to brw_context.h. Prototypes seem to be in rather arbitrary
places at the moment, and either place seem
brw_is_hiz_depth_format() is the only implementation of this function,
so it makes sense to just call it directly.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 3 +++
src/mesa/drivers/dri/i965/brw_surface_formats.c | 19 +++
src/mesa/drive
The hook was a noop.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 6 --
src/mesa/drivers/dri/i965/intel_context.c | 3 ---
src/mesa/drivers/dri/i965/intel_context.h | 3 ---
3 files changed, 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
These functions translate GLenum comparison operations into the hardware
enumerations. They should never be passed something other than a GL
comparison operator, or something is very broken.
Assertions seem more appropriate than fprintf.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/
Both intel_context.h and brw_defines.h have #defines for comparison
functions, stencil ops, blending logic ops, and blending factors.
They're exactly the same values, so it makes sense to pick one.
brw_defines.h is the logical place for this kind of stuff, so this patch
converts intel_state.c to u
The __DRI_USE_INVALIDATE extension was added in May 11th, 2010 by commit
4258e3a2e1c327. At this point, it's unlikely that anyone's using the
right mix of new and old components to hit this path. Deleting it
removes an untested code path and cleans up the driver a bit.
---
src/mesa/drivers/dri/
There are always better ways to do things.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_screen.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index ffcb6ec..252d356 100644
--- a/
This wasn't called from anywhere; presumably it was used to examine
brw_regs when debugging shader assembly. However, it prints registers
in a different notation than brw_disasm.c which everyone is used
to...which means I doubt anyone will want to use it.
Signed-off-by: Kenneth Graunke
---
src/
Having a header file for a single prototype seems rather excessive.
Plus, the actual function is in brw_clear.c, not intel_clear.c, so
there isn't even the .c/.h filename symmetry one might expect.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_clear.c | 1 -
src/mesa/driv
Having an entire header file for a single prototype seems a bit
excessive.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_context.c| 1 -
src/mesa/drivers/dri/i965/intel_context.h| 3 +++
src/mesa/drivers/dri/i965/intel_extensions.c | 1 -
src/mesa/drivers/dri/i965
A random smattering of things that just aren't used anymore.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_clip.h | 2 -
src/mesa/drivers/dri/i965/brw_draw.h | 5 --
src/mesa/drivers/dri/i965/brw_gs.h| 2 -
src/mesa/drivers/dri/i965/brw_reg.h
Hi,
the attached patches add initial support for double precision operations on
Southern Islands cards.
Some expressions containing multiple double precision kernel arguments cause
llvm to run until all memory is used - but I do not (yet) know why.
It works fine as long as I pass pointers to do
Pass "cl_khr_fp64" preprocessor definition to clang
Signed-off-by: Niels Ole Salscheider
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 +
1 Datei geändert, 1 Zeile hinzugefügt(+)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clo
Hello all,
Now that we've split the "intel" code into i915/i965 variants, it
doesn't make a whole lot of sense to have separate brw_context and
intel_context structs; merging them seems obvious.
The question then, is: what should we call the merged structure?
Eric noted that the "brw" name h
Include src0 alpha in the RT write message when using MRT, so it is used
for the alpha test instead of the normal per-RT alpha value.
Fixes broken rendering in Dota2 under Wine [FDO #62647].
No Piglit regressions on Ivybridge.
V2: reuse (and simplify) existing sample_alpha_to_coverage flag in
th
Nothing uses this, apparently.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_buffer_objects.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.h
b/src/mesa/drivers/dri/i965/intel_buffer_objects.h
index 0ea7300..d91990c 100644
This was only used for BOs backed by system memory on i915. With that
gone, there's nothing that even sets source to non-zero, so this is
purely dead code.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 4
src/mesa/drivers/dri/i965/intel_buffer_object
Commit cf31a19300cbcecddb6bd0f878abb9316ebad2a1 removed support for BOs
backed by system memory, as it was only useful for i915. However, it
removed a little too much code: intel_bufferobj_buffer() used to call
intel_bufferobj_alloc_buffer(), and after that commit, it didn't.
This led to NULL poi
60 matches
Mail list logo
