Hello,
Mareko and me had a small discussion about this on IRC.
Basically with GLES (1.0, 2.0 at least) the application has no way to
control the exact internal format [1]. This is intentional give the
hardware more leeway.
See http://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexImage2D.xml :
On 09/28/2013 10:08 AM, Vinson Lee wrote:
Fixes "Deference before null check" defect reported by Coverity.
Signed-off-by: Vinson Lee
Reviewed-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_ra_init.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium
Fixes "Overflowed return value" defects reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/r600/r600_isa.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_isa.h
b/src/gallium/drivers/r600/r600_isa.h
index c6bb869..5b9c3d0 100644
--
Fixes "Deference before null check" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/r600/sb/sb_ra_init.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_ra_init.cpp
b/src/gallium/drivers/r600/sb/sb_ra_init.cpp
The block size for all formats is currently at least 1 byte. Add an
assertion for this.
This should silence several Coverity "Division or modulo by zero"
defects.
Signed-off-by: Vinson Lee
---
src/gallium/auxiliary/util/u_format.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
dif
Fixes "Uninitialized scalar field" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index f
Fixes "Resource leak" defects reported by Coverity.
Signed-off-by: Vinson Lee
---
src/mesa/drivers/dri/i915/intel_mipmap_tree.c | 4 +++-
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_mipmap_
Fixes "Resource leak" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/mesa/drivers/dri/i915/intel_pixel_read.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i915/intel_pixel_read.c
b/src/mesa/drivers/dri/i915/intel_pixel_read.c
index 26eb496..8fd1c8d 10
There is an earlier null check for draw so draw could be null here as
well.
Fixes "Dereference after null check" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/auxiliary/draw/draw_pipe_unfilled.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gal
In commit 247f90c77e8f3894e963d796628246ba0bde27b5 (i965/gs: Set
control data header size/format appropriately for EndPrimitive()), I
incorrectly numbered the DWORDs in the 3DSTATE_GS command starting
from 1 instead of starting from 0. This caused the control data
format to be programmed into the
cfg is only used inside for loop so also move declaration there.
Fixes "Unused pointer value" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/drivers/nouve
shader has already been dereferenced earlier so cannot be null here.
Fixes "Dereference before null check" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/llvmpipe/lp_state_fs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/driver
Otherwise, the while(dirty) loop will never exit.
Fixes "Infinite loop" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/nouveau/nv30/nv40_verttex.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv30/nv40_verttex.c
b/src/gallium
Fixes "Unintentional integer overflow" defects reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/nouveau/nouveau_vp3_video.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
b/src/gallium/drivers/nouvea
On Sat, Sep 28, 2013 at 04:42:34AM +0100, Emil Velikov wrote:
> 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
> >>
> >> libdricommon.la is available whenever a non swrast driver is built.
> >> All the classic d
dst0 is not initialized if tgsi.dstCount() is false.
Fixes "Uninitialized pointer read" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/
On Sun, Sep 22, 2013 at 09:29:28PM +0100, Emil Velikov wrote:
> Signed-off-by: Emil Velikov
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 Stellard
> ---
> src/g
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
>>
>> 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
On Sun, Sep 22, 2013 at 09:29:26PM +0100, Emil Velikov wrote:
Reviewed-by: Tom Stellard
> Signed-off-by: Emil Velikov
> ---
> src/gallium/drivers/radeon/Makefile.am | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/Makefile.am
> b/src/gallium/drivers/radeon/
On Sun, Sep 22, 2013 at 09:29:24PM +0100, Emil Velikov wrote:
> From: Johannes Obermayr
>
> 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.
>
> While we're here
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
> Signed-off-by: Emil Velikov
On Mon, Sep 23, 2013 at 09:09:14PM +0200, mar...@gmail.com wrote:
> From: Marek Olšák
>
> This fixes piglit:
> - shaders/glsl-fs-texture2d-masked
> - shaders/glsl-fs-texture2d-masked-4
>
> Signed-off-by: Marek Olšák
> ---
> lib/Target/R600/SIISelLowering.cpp | 27 +--
>
On Wed, Sep 25, 2013 at 08:14:43PM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
> 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
> ---
> src/gallium/drive
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 larg
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
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
b/src/mesa/drivers/
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
b/src/mesa/drivers/dri
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
b/src/mesa/drivers
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
On 28/09/13 01:41, Eric Anholt wrote:
> Emil Velikov 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
Emil Velikov 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 see any
references to
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.
Emil Velikov 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
> ---
>
> With this patch building dri-swrast,
Ian Romanick 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 explanat
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
gallium/state_trackers
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.
Signed-off-b
They do exactly the same thing.
Signed-off-by: Kenneth Graunke
---
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
index 569e881..6b6bea8
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
---
src/me
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
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 ++
src/mesa/drivers/dri/i965/intel_context.c | 3 ---
2 files
Signed-off-by: Kenneth Graunke
---
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 src/mesa/drivers/dri/i965/intel_context.
brw_context.h includes imports.h which includes compiler.h which already
defines these.
Signed-off-by: Kenneth Graunke
---
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
b/src/mesa/drivers/dri/i9
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
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
src/mesa/drivers/dri/i965/in
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 gener
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
---
src/mesa/drivers/dri/i915/intel_context.h | 13 -
src/mesa/
intel_batchbuffer_init() sets up initial batchbuffer state; it seems
like a reasonable place to initialize this flag.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.c | 2 --
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 ++
2 files changed, 2 insertions(+), 2
Configuring which dirty flags we want sounds like a job for
brw_init_state().
Signed-off-by: Kenneth Graunke
---
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(-)
diff --git a/src/mesa/
The split here was completely arbitrary.
Signed-off-by: Kenneth Graunke
---
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 a/src/mesa/drivers/dri/i
Signed-off-by: Kenneth Graunke
---
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 100644
--- a/src/mesa
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
---
src/mesa/drivers/dri/i965/brw_context.c| 1 -
src/mesa/drivers/dri/i965/brw_context.h| 1 -
src/mesa/drivers/dri/i965/brw_misc_s
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
---
src/mesa/drivers/dri/i965/brw_context.c | 8
src/mesa/drivers/dri/i965/brw_state_upload.c | 8
2 files changed, 8 inserti
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
---
src/mesa/drivers/dri/i965/brw_context.c | 2 --
src/mesa/drivers/dri/i965/brw_context.h | 2 --
src/mesa/drivers/dri/i965/brw_sta
Signed-off-by: Kenneth Graunke
---
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 a/src/mesa/drivers/dri/i9
Signed-off-by: Kenneth Graunke
---
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(-)
diff --git a/src/mesa/d
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
---
src/mesa/drivers/dri/i965/brw_context.c
Signed-off-by: Kenneth Graunke
---
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 +++-
src/mesa/drivers/dri/i965/intel_screen.h | 9
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
---
src/mesa/drivers/dri/i965/intel_screen.c | 27
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 str
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
---
include/pci_ids/i965_pci_ids.h| 186 +++---
include/pci_ids/pci_id_driver_map.h | 2 +-
src/mesa/drivers/d
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
---
include/pci_ids/i965_pci_ids.h
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
---
src/me
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
---
src/mesa/dr
It wasn't clear that this was necessary for EGL, or why.
Signed-off-by: Kenneth Graunke
---
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
b/src/mesa/drivers/dri/i965/intel_context.c
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 intel_de
"error" is a very generic name. dri_ctx_error is the name used in
intelInitContext(), which is more specific.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_contex
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 hav
On Fri, Sep 27, 2013 at 3:22 PM, Ian Romanick wrote:
> The series is
>
> Reviewed-by: Ian Romanick
>
> Should patch 2 go to stable?
Yes. Thanks.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/list
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 K
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 miptre
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
___
mesa-dev mailing list
m
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 a/src/mesa/drivers/dri/i965/inte
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 change,
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%.
---
src/mesa/drivers/dri/i965/in
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 deman
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 +---
src/mesa/drivers/dri/i965/g
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 unrelat
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 X1
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.
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
Patches 1, 2, and 4 are
Reviewed-by: Ian Romanick
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
> built-in geometry shader
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
>
> This corresponds to the lowering of gl_ClipDistance to
> gl_ClipDistanceMESA for vertex and geometry shader output
The series is
Reviewed-by: Ian Romanick
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 |5 +++--
> 2 files ch
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
* 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
---
With this patch building dri-swrast, dri-i915 and dri-vmware
build correctly
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>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
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 R
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 ty
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: on
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
- spec/glsl-1.50/linker/unsized-in-named
---
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 @@ ir_validate::visit(ir_variable
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
sr
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 +
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
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 uniform-initialize
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:
...
*
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).
>Fr
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 +
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 neede
From: Ian Romanick
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
---
src/glsl/main.cpp |
1 - 100 of 116 matches
Mail list logo
