https://bugs.freedesktop.org/show_bug.cgi?id=66346
--- Comment #2 from Vinson Lee v...@freedesktop.org ---
(In reply to comment #1)
Created attachment 81814 [details] [review]
use a function to convert from GLhandleARB to GLuint
Vinson, can you try this patch? There may be other files to
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
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 4
Nothing uses this, apparently.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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
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 has
Pass cl_khr_fp64 preprocessor definition to clang
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
---
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
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
A random smattering of things that just aren't used anymore.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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 -
Having an entire header file for a single prototype seems a bit
excessive.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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 -
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_clear.c
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
There are always better ways to do things.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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
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 kenn...@whitecape.org
---
The hook was a noop.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.h | 3 +++
src/mesa/drivers/dri/i965/brw_surface_formats.c | 19
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
brw_debug_batch() is the only implementation of this function, so it
makes sense to just call it directly.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 1 -
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 ++--
brw_annotate_aub() is the only implementation of this function, so it
makes sense to just call it directly.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 1 -
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 ++--
maxBatchSize was only ever initialized to BATCH_SZ, and a few places
used BATCH_SZ directly anyway.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 ++--
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 2 +-
https://bugs.freedesktop.org/show_bug.cgi?id=66357
Ross Burton r...@burtonini.com changed:
What|Removed |Added
CC||r...@burtonini.com
--
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
On Sun, Jun 30, 2013 at 9:53 PM, Marek Olšák mar...@gmail.com wrote:
this also fixes the fast clear with multiple colorbuffers and each having
a different format
Series is:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/r600/r600_blit.c | 21
On 2 July 2013 01:42, Chris Forbes chr...@ijw.co.nz 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:
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
A bit cleaner than having it in one giant function.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
These do the exact same thing; combining them is tidier.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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
This consolidates the miptree layout logic in a single file.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 74 +++-
src/mesa/drivers/dri/i965/intel_tex_layout.c | 67 -
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 65 ++
1 file changed, 31 insertions(+), 34
The driver is compiled in C99 mode, so this is not a problem. It's
slighlty tidier.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=66359
--- Comment #2 from Hrvoje Senjan hrvoje.sen...@gmail.com ---
Downstream report
https://bugs.freedesktop.org/show_bug.cgi?id=66359
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66359
--- Comment #3 from Hrvoje Senjan hrvoje.sen...@gmail.com ---
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.
___
https://bugs.freedesktop.org/show_bug.cgi?id=66359
--- Comment #4 from Fredrik Höglund fred...@kde.org ---
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:
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
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
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
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
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
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 myles.maxfi...@gmail.com
---
src/mesa/program/prog_parameter.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git
On Tue, Jul 2, 2013 at 1:02 PM, Ian Romanick i...@freedesktop.org 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
On Tue, Jul 2, 2013 at 11:37 PM, Matt Turner matts...@gmail.com wrote:
On Tue, Jul 2, 2013 at 1:02 PM, Ian Romanick i...@freedesktop.org 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
On Wed, Jul 3, 2013 at 7:37 AM, Matt Turner matts...@gmail.com wrote:
On Tue, Jul 2, 2013 at 1:02 PM, Ian Romanick i...@freedesktop.org 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
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 m...@fireburn.co.uk 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
The series is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 159
https://bugs.freedesktop.org/show_bug.cgi?id=66359
--- Comment #5 from Stefan Brüns stefan.bru...@rwth-aachen.de ---
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
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
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
For the series,
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_clip.h | 2 -
src/mesa/drivers/dri/i965/brw_draw.h | 5 --
On 07/02/2013 01:54 AM, Kenneth Graunke wrote:
There are always better ways to do things.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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:
The hook was a noop.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 ++--
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
Bump.
On 4 June 2013 23:04, Jonathan Liu net...@gmail.com 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 net...@gmail.com
---
Bump.
On 4 June 2013 23:03, Jonathan Liu net...@gmail.com 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
58 matches
Mail list logo
