https://bugs.freedesktop.org/show_bug.cgi?id=69874
Priority: medium
Bug ID: 69874
Assignee: mesa-dev@lists.freedesktop.org
Summary: Automake throws a lot of [...] option
'subdir-objects' is disabled
Severity: normal
On Thu, Sep 26, 2013 at 08:36:00PM -0700, Eric Anholt wrote:
If bufmgr didn't get created, then screen creation failed, and we never
should have got here in the first place. This was added by Chris Wilson
in 2010 with no explanation for why it would be needed.
Because it prevented a segfault,
On 27/09/13 04:35, Eric Anholt wrote:
i965, i915, radeon, r200, swrast, and nouveau were mostly trying to do the
same logic, except where they failed to. Notably, swrast had code that
appeared to try to enable GLES1/2 but forgot to set api_mask (thus
preventing any gles context from being
https://bugs.freedesktop.org/show_bug.cgi?id=69874
--- Comment #1 from Kenneth Graunke kenn...@whitecape.org ---
Note that this is new with Automake 1.14.
I think everything /works/ with 1.14, it's just grumbly.
--
You are receiving this mail because:
You are the assignee for the bug.
On 09/12/2013 06:46 PM, Brian Paul wrote:
I just pushed a gallium-bind-sampler-states branch to my git repo at
git://people.freedesktop.org/~brianp/mesa
It replaces the four
pipe_context::bind_fragment/vertex/geometry/compute_sampler_states()
functions with a single bind_sampler_states()
https://bugs.freedesktop.org/show_bug.cgi?id=69874
--- Comment #2 from Emil Velikov emil.l.veli...@gmail.com ---
New in 1.14:
...
- The next major Automake version (2.0) will unconditionally activate
the 'subdir-objects' option. In order to smooth out the transition,
we now give a
It wasn't clear that this was necessary for EGL, or why.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_context.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_context.c
Kenneth Graunke kenn...@whitecape.org writes:
On 09/26/2013 08:36 PM, Eric Anholt wrote:
The intel_screen.c used to be a dispatch to one of 3 driver functions, but
was down to 1, so it was kind of a waste. In addition, it was trying to
free all of the data that might have been partially
https://bugs.freedesktop.org/show_bug.cgi?id=69874
--- Comment #3 from Eric Anholt e...@anholt.net ---
Yeah. And subdir-objects is broken for the way we have our build set up at the
moment (libdricore built from a separate directory, on the same .c files as
core). Once we megadrivers, we can
From: Ian Romanick ian.d.roman...@intel.com
Starting with OpenGL 3.2 input limits and output limits for stages may
not match. This means they need to be accounted separately.
No piglit regressions.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Brian Paul bri...@vmware.com
From: Ian Romanick ian.d.roman...@intel.com
Pull the data directly from the context like the other varying related
limits. The parser state shadow copies were added back when the parser
state didn't have a pointer to the context. There's no reason to do it
now days.
Signed-off-by: Ian Romanick
From: Ian Romanick ian.d.roman...@intel.com
gl_MaxVertexOutputVectors = ctx-Const.VertexProgram.MaxOutputComponents
gl_MaxFragmentInputVectors = ctx-Const.FragmentProgram.MaxInputComponents
v2: Add types so that the code compiles. Pointed out by Brian.
v3: Leave gl_MaxVaryingFloats et al.
From: Ian Romanick ian.d.roman...@intel.com
The choices aren't just 0 and 1, so using the enum names is much more
clear.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
This goes on top of the series that I just sent. I sent them as
separate series because they're logically separate.
From: Ian Romanick ian.d.roman...@intel.com
Not just when there's an error.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/main.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp
index 8f59ada..4632356 100644
---
From: Ian Romanick ian.d.roman...@intel.com
The only GLSL extension that is not enabled is AMD_vertex_shader_layer.
I think the standalone-compiler could enable this (as shading language
support is complete), but no driver enables it.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
From: Ian Romanick ian.d.roman...@intel.com
Makes it a little easier to see which ones are missing.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/standalone_scaffolding.cpp | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git
From: Ian Romanick ian.d.roman...@intel.com
Infer whether or not to use ES based on the GLSL version (100 or 300 are
for ES). This replaces the --glsl-es command line option. Set various
compiler limits based on the minimums required for the specified GLSL
version.
Signed-off-by: Ian Romanick
On 09/26/2013 09:19 PM, Kenneth Graunke wrote:
On 09/26/2013 08:36 PM, Eric Anholt wrote:
If bufmgr didn't get created, then screen creation failed, and we never
should have got here in the first place. This was added by Chris Wilson
in 2010 with no explanation for why it would be needed.
In a future patch, this will allow us to enforce invariants when the
interface type is updated.
---
src/glsl/ast_to_hir.cpp| 4 ++--
src/glsl/ir.h | 15 +++
src/glsl/link_interface_blocks.cpp | 17 +
Although it's not explicitly stated in the GLSL 1.50 spec, it is
clearly implied that unsized arrays are allowed in interface blocks
(the built-in interface gl_PerVertex contains an unsized array,
gl_ClipDistance, and examples added in GLSL 4.30 make use of unsized
arrays in interface blocks).
Although it's not explicitly stated in the GLSL 1.50 spec, unsized
arrays are allowed in interface blocks.
section 1.2.3 (Changes from revision 5 of version 1.5) of the GLSL
1.50 spec says:
* Completed full update to grammar section. Tested spec examples
against it:
...
Future patches in this series will add calls to _mesa_glsl_error() to
ir.cpp. _mesa_glsl_error() calls _mesa_glsl_msg(), which calls
_mesa_shader_debug(), which is defined in mesa/main/errors.c (and
hence not available when compiling GLSL unit tests). To avoid link
errors, link
Currently, when converting an access to an array element from ast to
IR, we need to see if the array is an ir_dereference_variable, and if
so update the variable's max_array_access.
When we add support for unsized arrays in interface blocks, we'll also
need to account for cases where the array is
For interface blocks that contain arrays, this field will contain the
maximum element of each contained array that is accessed by the
shader. This is a first step toward supporting unsized arrays in
interface blocks.
---
src/glsl/ir.cpp | 3 ++-
src/glsl/ir.h | 17
This patch adds an implementation of
ir_dereference_record::update_max_array_access(), which ensures that
ir_variable::max_ifc_array_access is properly updated to reflect the
shader's use of arrays appearing within interface blocks.
---
src/glsl/ir.cpp | 36
---
src/glsl/ir_validate.cpp | 20
1 file changed, 20 insertions(+)
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index 2c64f4e..93bc4d9 100644
--- a/src/glsl/ir_validate.cpp
+++ b/src/glsl/ir_validate.cpp
@@ -674,6 +674,26 @@
Unsized arrays appearing inside named interface blocks now get a
proper size assigned by the array_sizing_visitor.
Fixes piglit tests:
- spec/glsl-1.50/execution/unsized-in-named-interface-block
- spec/glsl-1.50/execution/unsized-in-named-interface-block-gs
-
When multiple shaders of the same type access an interface block
containing an unsized array, we need to set the array size based on
the maximum array element accessed across all the shaders. This is
similar to what we already do with unsized arrays occurring outside of
interface blocks.
Note:
We were already setting the array size of unsized arrays that appeared
inside unnamed interface blocks, but we weren't updating
ir_variable::interface_type to reflect the new array size, causing
bogus link errors.
This patch causes array_sizing_visitor to keep track of all the
unnamed interface
I also forgot to mention... my next intended step is to have the
stand-alone compiler be installed as part of the regular Mesa install
process. The build system terrifies / annoys me enough that I'll have
to solicit some help doing that...
On 09/27/2013 11:58 AM, Ian Romanick wrote:
From: Ian
From the bspec documentation of the SEND instruction:
destination region cannot cross the 256-bit register boundary.
To avoid violating this restriction when executing SIMD16 texturing
operations (such as those used by blorp), we need to ensure that the
destination of the SEND instruction
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
* clone the drienv to driswenv and adjust approapriately
* export driswenv and use it in dri-swrast
* ensure __NOT_HAVE_DRM_H is defined for drisw, similar
to all other common_drisw users
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
With this patch building dri-swrast, dri-i915 and
For some reason that I don't yet fully understand, Glaze does not work with
libEGL unless libEGL is linked with -Bsymbolic.[*]
Beyond that specific reason, all of the reasons for which libGL.so is linked
with -Bsymbolic, (see the commit history), should also apply here.
[*] The specific behavior
The series is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Should patch 2 go to stable?
On 09/14/2013 09:16 AM, Brian Paul wrote:
Return bool instead of int. Const-qualify the syncObj. Add some comments.
---
src/mesa/main/syncobj.c | 12 ++--
src/mesa/main/syncobj.h |
There are some bits of this patch I'm trying to understand. I think
they can be cleared up by one question below...
On 09/14/2013 01:00 PM, Paul Berry wrote:
From: Bryan Cain bryanca...@gmail.com
This corresponds to the lowering of gl_ClipDistance to
gl_ClipDistanceMESA for vertex and
Patches 1, 2, and 4 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
I sent out a question about patch 3.
On 09/14/2013 01:00 PM, Paul Berry wrote:
This patch adds a location element to struct glsl_struct_field, so
that we can keep track of the gl_varying_slot associated with each
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
Gaetan Nadon (3):
gallium/targets/libgl-xlib: X11/Xlib.h: No such file or directory
gallium/state_trackers/egl: use X11_INCLUDES rather than X11_CFLAGS
The compiler cannot find the Xlib.h in the installed system headers.
All supplied include directives point to inside the mesa module.
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
The Xlib.h file is not
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
It is used for building the code in the x11 subdir.
The build does not fail on this one as LIBDRM_CFLAGS happens to have
the inludedir value as the one for
The compiler cannot find the Xlib.h in the installed system headers.
All supplied include directives point to inside the mesa module.
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
The Xlib.h file is not
On 09/18/2013 12:59 PM, Eric Anholt wrote:
This has no effect currently, because intel_finalize_mipmap_tree() always
makes mt-first_level == tObj-BaseLevel.
The change I made before to handle it
(b1080cfbdb0a084122fcd662cd27b4748c5598fd) got very close to working, but
after fixing some
On 09/18/2013 12:59 PM, Eric Anholt wrote:
We know that the object's mt is equal to the firstimage's mt because it's
gone through intel_finalize_mipmap_tree(). Saves a lookup of firstimage
on pre-gen7.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 4 +---
On 09/18/2013 12:59 PM, Eric Anholt wrote:
If the caller shows up with GL_BASE_LEVEL != 0, it doesn't mean that the
texture will over the course of its lifetime have that nonzero baselevel,
it means that the caller is filling the texture from the bottom up for
some reason (one could imagine
On 09/18/2013 12:59 PM, Eric Anholt wrote:
Given that a teximage that calls us with this flag set will immediately
proceed to allocate the other levels, we can probably just go ahead and
allocate those levels now.
Reduces miptree copies in piglit by about .05%.
---
On 09/18/2013 12:59 PM, Eric Anholt wrote:
As long as the baselevel, maxlevel still sit inside the range we had
previously validated, there's no need to reallocate the texture.
I also hope this makes our texture validation logic much more obvious.
It's taken me enough tries to write this
On 09/18/2013 12:59 PM, Eric Anholt wrote:
No change in copies during a piglit run, but it's one less first_level !=
0 in our codebase.
---
src/mesa/drivers/dri/i965/intel_tex_validate.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git
On 09/18/2013 12:59 PM, Eric Anholt wrote:
I've rewritten a lot of this file.
---
src/mesa/drivers/dri/i965/intel_tex_validate.c | 23 +++
1 file changed, 23 insertions(+)
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
On 09/18/2013 12:59 PM, Eric Anholt wrote:
We originally had a path just did the loop and called
ctx-Driver.AllocTextureImageBuffer(), which I moved into Mesa core. But
we can do better, avoiding incorrect miptree size guesses and later
texture validations by just directly allocating the
Error checking bufSize isn't mentioned in the spec, but it is in the
man pages. However, I believe the man page is incorrect. Typically,
GL functions that take GLsizei parameters check that they're positive
or non-negative. Negative values don't make sense here.
A spec bug has been filed with
On Fri, Sep 27, 2013 at 3:22 PM, Ian Romanick i...@freedesktop.org wrote:
The series is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Should patch 2 go to stable?
Yes. Thanks.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
This series combines brw_context.[ch] and intel_context.[ch],
and cleans up our context creation code quite a bit. A bunch of
functionality was awkwardly split between the two sets of files;
now it's all in one place.
While this series is large, it should be fairly easy reading.
Patch 28 does
error is a very generic name. dri_ctx_error is the name used in
intelInitContext(), which is more specific.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Now that there isn't an intel_context structure, the split between
brw_context.[ch] and intel_context.[ch] is rather awkward and arbitrary.
Removing intel_context.[ch] seems desirable, but not everything really
belongs in brw_context.[ch], either.
Moving INTEL_DEBUG handling into separate
It wasn't clear that this was necessary for EGL, or why.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_context.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_context.c
Now that intelInitContext isn't shared between i915 and i965, the split
is fairly arbitrary. This patch moves a bunch of the basic context
creation and generation checking code up to the top-level function
(and slightly earlier).
More will follow.
Signed-off-by: Kenneth Graunke
Using a helper function clarifies the context initialization code.
I would've liked to completely centralize it, but moving the optionCache
code from intelInitExtensions into here would've required setting flags
in the context, which seems like a waste.
Signed-off-by: Kenneth Graunke
Nothing uses the #define name, and it's not terribly useful - the
numerical ID serves the same purpose. The only thing we could really do
with it is generate slightly prettier preprocessed code. But who looks
at that?
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
I removed this a while ago, since we never used it, but I'm finally
resurrecting the idea in the next commits.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
include/pci_ids/i965_pci_ids.h| 186 +++---
include/pci_ids/pci_id_driver_map.h | 2
The idea is that struct brw_device_info should store statically-known
information about hardware features. Using the new family name in the
PCI ID table, we can easily grab the right structure.
This is basically the equivalent of intel_device_info in the kernel.
This patch also makes the new
This option was useful during initial development, but it's been ages
since I've heard of anyone using it. Plus, Gen7+ mandates separate
stencil, so it was really only useful on Sandybridge anyway.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_screen.c
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 39 +++-
src/mesa/drivers/dri/i965/intel_fbo.c| 2 +-
src/mesa/drivers/dri/i965/intel_screen.c | 34 +++-
Since each kind of device has its own brw_device_info structure, we can
simply store the URB and thread limits there. This eliminates all the
large if-ladders, and simplifies the context initialization code quite a
bit.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 10 +++---
src/mesa/drivers/dri/i965/brw_device_info.c | 9 -
src/mesa/drivers/dri/i965/brw_device_info.h | 16
3 files changed, 27 insertions(+), 8 deletions(-)
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 7 +++
src/mesa/drivers/dri/i965/brw_device_info.c | 11 +++
src/mesa/drivers/dri/i965/brw_device_info.h | 4
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git
This was always set to false, and is only used for debugging.
To enable it, simply change the if (0) block and recompile.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 2 --
src/mesa/drivers/dri/i965/brw_context.h | 2 --
This seems like a better place for it, and helps clean up
brwCreateContext (which is full of a lot of random stuff).
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 8
src/mesa/drivers/dri/i965/brw_state_upload.c | 8
2
This flag is only used in one place, and is only set on one platform.
Just check for original Gen4 in the relevant function.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c| 1 -
src/mesa/drivers/dri/i965/brw_context.h| 1 -
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 41117cb..0ad9ead
The split here was completely arbitrary.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 116 +++---
src/mesa/drivers/dri/i965/intel_context.h | 10 ---
2 files changed, 43 insertions(+), 83 deletions(-)
diff --git
Configuring which dirty flags we want sounds like a job for
brw_init_state().
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 4
src/mesa/drivers/dri/i965/brw_state_upload.c | 5 +
2 files changed, 5 insertions(+), 4 deletions(-)
intel_batchbuffer_init() sets up initial batchbuffer state; it seems
like a reasonable place to initialize this flag.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 2 --
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 ++
2 files
This seems generally useful, so it may as well live in core Mesa.
In fact, the comment for ALIGN() in macros.h actually says to see also
ROUND_DOWN_TO, which...was in a driver somewhere.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i915/intel_context.h | 13
These make it easy to convert a floating point value to a fixed point
numbers. The second parameter is the number of bits used for the
fractional part of the number.
It looks like core Mesa has similar functions already, but none that
allows an arbitrary number of fractional bits. The more
brw_context.h includes imports.h which includes compiler.h which already
defines these.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_context.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_context.h
This was only used for uploading batchbuffer data, and only on 32-bit
systems. If this is actually useful, we might want to use it more
widely. But more than likely, it isn't.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.h | 95 +++-
src/mesa/drivers/dri/i965/intel_context.h | 142 --
2 files changed, 93 insertions(+), 144 deletions(-)
delete mode 100644
brw_init_surface_formats already sets entries in TextureFormatsSupported
to true; it may as well take care of initializing it to false too.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 ++
src/mesa/drivers/dri/i965/intel_context.c
There's no point in having two files for context functions. This patch
moves the code from intel_context.c into brw_context.c unmodified
(other than whitespace fixes).
Right now, this looks silly; future patches will merge functions and
tidy things up.
Signed-off-by: Kenneth Graunke
They do exactly the same thing.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
It actually just wants generation checking, and brw-gen is the usual
way of doing that. In the future, we'll also want to check brw-hw_ctx,
which isn't available from the screen.
While we're changing the function signature, convert from studly caps to
our usual naming conventions.
On 09/27/2013 03:42 PM, Gaetan Nadon wrote:
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
Gaetan Nadon (3):
gallium/targets/libgl-xlib: X11/Xlib.h: No such file or directory
Ian Romanick i...@freedesktop.org writes:
On 09/26/2013 09:19 PM, Kenneth Graunke wrote:
On 09/26/2013 08:36 PM, Eric Anholt wrote:
If bufmgr didn't get created, then screen creation failed, and we never
should have got here in the first place. This was added by Chris Wilson
in 2010 with no
Emil Velikov emil.l.veli...@gmail.com writes:
* clone the drienv to driswenv and adjust approapriately
* export driswenv and use it in dri-swrast
* ensure __NOT_HAVE_DRM_H is defined for drisw, similar
to all other common_drisw users
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
On 13-09-27 07:59 PM, Brian Paul wrote:
On 09/27/2013 03:42 PM, Gaetan Nadon wrote:
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
Gaetan Nadon (3):
gallium/targets/libgl-xlib: X11/Xlib.h: No such
Emil Velikov emil.l.veli...@gmail.com writes:
* clone the drienv to driswenv and adjust approapriately
* export driswenv and use it in dri-swrast
* ensure __NOT_HAVE_DRM_H is defined for drisw, similar
to all other common_drisw users
I'm confused where __NOT_HAVE_DRM_H comes from. I don't
On 28/09/13 01:41, Eric Anholt wrote:
Emil Velikov emil.l.veli...@gmail.com writes:
* clone the drienv to driswenv and adjust approapriately
* export driswenv and use it in dri-swrast
* ensure __NOT_HAVE_DRM_H is defined for drisw, similar
to all other common_drisw users
I'm confused
On 28/09/13 01:39, Gaetan Nadon wrote:
On 13-09-27 07:59 PM, Brian Paul wrote:
On 09/27/2013 03:42 PM, Gaetan Nadon wrote:
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
Gaetan Nadon (3):
v2: Check fixed_hw_reg.{file,nr} instead of dst.reg.
---
src/mesa/drivers/dri/i965/brw_vec4.h | 1 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 103 +
2 files changed, 104 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
v2: Check fixed_hw_reg.{file,nr} instead of dst.reg.
---
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 103 +++
2 files changed, 104 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
v2: Set destination register using brw_null_reg().
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 15 ++-
src/mesa/drivers/dri/i965/brw_vec4.cpp | 15 ++-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
The registers in the architecture register file don't share much in
common, so there's no point in grouping them together. Use the HW_REG
class instead. The vec4 backend already does this.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 6 --
src/mesa/drivers/dri/i965/brw_fs.h
On 28/09/13 00:45, Kenneth Graunke wrote:
This series combines brw_context.[ch] and intel_context.[ch],
and cleans up our context creation code quite a bit. A bunch of
functionality was awkwardly split between the two sets of files;
now it's all in one place.
While this series is large, it
On Wed, Sep 25, 2013 at 08:14:43PM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This doesn't fix any known issue (I haven't run piglit with this yet),
but the code was obviously completely wrong. It looks like copy-pasted from
CMP.
Reviewed-by: Tom Stellard
On Mon, Sep 23, 2013 at 09:09:14PM +0200, mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
This fixes piglit:
- shaders/glsl-fs-texture2d-masked
- shaders/glsl-fs-texture2d-masked-4
Signed-off-by: Marek Olšák marek.ol...@amd.com
---
lib/Target/R600/SIISelLowering.cpp | 27
On Sun, Sep 22, 2013 at 09:29:27PM +0100, Emil Velikov wrote:
libllvmradeon.la is available whenever NEED_RADEON_LLVM is set, using
R600_NEED_RADEON_GALLIUM is rather ambiguous and unnecessary. Drop it
in favour of NEED_RADEON_LLVM.
Reviewed-by: Tom Stellard thomas.stell...@amd.com
On Sun, Sep 22, 2013 at 09:29:24PM +0100, Emil Velikov wrote:
From: Johannes Obermayr johannesoberm...@gmx.de
libdricommon.la is available whenever a non swrast driver is built.
All the classic dri drivers make use of the prebuild library but all
of the gallium ones rebuild it explicitly.
On Sun, Sep 22, 2013 at 09:29:26PM +0100, Emil Velikov wrote:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/drivers/radeon/Makefile.am | 3 ---
1 file changed, 3 deletions(-)
diff --git
On 28/09/13 04:36, Tom Stellard wrote:
On Sun, Sep 22, 2013 at 09:29:24PM +0100, Emil Velikov wrote:
From: Johannes Obermayr johannesoberm...@gmx.de
libdricommon.la is available whenever a non swrast driver is built.
All the classic dri drivers make use of the prebuild library but all
of the
On Sun, Sep 22, 2013 at 09:29:28PM +0100, Emil Velikov wrote:
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
As long as you have build tested these with both automake and scons and
are prepared to deal with any fallout once they are committed.
Patches 5 through 29 are:
Reviewed-by: Tom
1 - 100 of 112 matches
Mail list logo
