From: Dave Airlie
We have cases on virtual GPU hw that renders using a wrapped llvmpipe,
that we can't produce the normal DRI2 semantics having the kernel/hw
enforce synchronisation semantics. It is also suboptimal to flush
all surfaces on the server side in the block handler. So the
From: Dave Airlie
This is for a specific use-case for the QXL driver (which wraps
llvmpipe/softpipe). Texture it get via TFP are inverted, so
we need to use a negative stride to sample from them. So
this converts a bunch of cases where we use unsigned stride
to a signed value. I can't se
> Errr, what about using flush_frontbuffer, it seems todo
> the exact same thing.
Hmm I wonder if I could overload it actually I hadn't considered that,
its not exactly the same thing,
but its pretty close to what I'd want to do alright.
>> diff --git a/src/gallium/drivers/softpipe/sp_texture.h
> I have no particular objection with the above in principle, as this seems a
> perfectly valid use of llvmpipe.
>
> I just have some remarks on implementation details done separately.
>
>
> For my curiosity sake, how much these changes matter in practice? (For
> example, what is the % effect of
On Tue, Mar 19, 2013 at 8:54 PM, Jose Fonseca wrote:
> I think this is fine in principle, but I believe it's better to be exhaustive
> now than to waste time debugging unsigned/signed stride mismatches later.
>
> Especially all src/gallium/auxiliary/util modules should be updated:
>
> - src/galli
On Tue, Mar 19, 2013 at 9:21 PM, Dave Airlie wrote:
>> I have no particular objection with the above in principle, as this seems a
>> perfectly valid use of llvmpipe.
>>
>> I just have some remarks on implementation details done separately.
>>
>>
>> For
so I've been playing with MSAA in softpipe and saw this, I don't think
any of my code is causing it, but it does take an MSAA test to trigger
it
with texelFetch fs sampler2DMS 4 I get the below valgrind trace
so it looks like we are keeping a reference in ctx->Array._DrawArrays
that is stale, wit
>
>>> correctly). But Marek is quite right that this only counts for state
>>> objects
>>> and makes no sense for set_* and draw_* calls (and I'm currently thinking
>>> how to avoid that and can't come up with a proper solution). Anyway it's
>>> definitely not an urgent problem for radeonsi.
>>
>>
On 27 Mar 2013 08:45, "Dave Airlie" wrote:
>
> >
> >>> correctly). But Marek is quite right that this only counts for state
> >>> objects
> >>> and makes no sense for set_* and draw_* calls (and I'm currently thinking
> >>>
On Tue, Apr 2, 2013 at 3:11 AM, Mark London wrote:
> Sorry to post this here, but no one answered me on the mesa-users mailing
> list.
>
> A recent update of mesa-dri-drivers on Redhat 6 (upgraded 7 to 9), removed
> the nouveau_dri.so file, which libGl uses. Does anyone know why Redhat
> might h
I sent these before, and Marek reviewed them (the first 3 at least).
But I'd like to have the r600g one looked at before I pushed it,
I rewrote it to properly return the sample positions from the
correct place.
One other issue is all the 2D MS Array sampler tests fail on r600g,
not sure why, I've
From: Dave Airlie
This is to be used to implement glGet GL_SAMPLE_POSITION.
Reviewed-by: Marek Olšák
Signed-off-by: Dave Airlie
---
src/gallium/include/pipe/p_context.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe
From: Dave Airlie
This just calls into the gallium interface.
Reviewed-by: Marek Olšák
Signed-off-by: Dave Airlie
---
src/mesa/sources.mak| 1 +
src/mesa/state_tracker/st_cb_msaa.c | 52 +
src/mesa/state_tracker/st_cb_msaa.h | 39
From: Dave Airlie
This adds support to the mesa state tracker for ARB_texture_multisample.
hardware doesn't seem to use a different texture instructions, so
I don't think we need to create one for TGSI at this time.
Thanks to Marek for fixes to sample number picking.
Reviewed-by: M
From: Dave Airlie
I rewrote this to use the sample positions properly.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 269 +
src/gallium/drivers/r600/r600_state.c | 67 +--
2 files changed, 214 insertions(+), 122 deletions
On Sat, Apr 6, 2013 at 8:05 PM, Dave Airlie wrote:
> I sent these before, and Marek reviewed them (the first 3 at least).
Oh calim pointed out I'd missed some comments from before, I've pushed
these to a branch with get_sample_position documented in p_context.h,
and switching to u
From: Dave Airlie
calim pointed out we were getting mipmap levels for array multisamples,
this didn't make sense. So then I noticed this function takes last_level
so we are passing in a too high value here.
I think this should fix the case he was seeing.
Signed-off-by: Dave Airlie
---
Hi guys,
this hopefully addresses the issues pointed out in previous reviews,
the main difference is the st/mesa max samples chooser is correct,
which Ian pointed out.
Also r600g sample positions are now valid, my last attempt missed
some unsigned/signed issues.
Dave.
_
From: Dave Airlie
This allows us to reuse this for choosing formats for MSAA limits.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_format.c | 24 +++-
src/mesa/state_tracker/st_format.h | 5 +
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a
From: Dave Airlie
This is to be used to implement glGet GL_SAMPLE_POSITION.
Reviewed-by: Marek Olšák
Signed-off-by: Dave Airlie
---
src/gallium/include/pipe/p_context.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium
From: Dave Airlie
This just calls into the gallium interface.
Reviewed-by: Marek Olšák
Signed-off-by: Dave Airlie
---
src/mesa/sources.mak| 1 +
src/mesa/state_tracker/st_cb_msaa.c | 54 +
src/mesa/state_tracker/st_cb_msaa.h | 39
From: Dave Airlie
This adds support to the mesa state tracker for ARB_texture_multisample.
hardware doesn't seem to use a different texture instructions, so
I don't think we need to create one for TGSI at this time.
Thanks to Marek for fixes to sample number picking.
v2: idr pointed
From: Dave Airlie
v2: I rewrote this to use the sample positions properly.
v3: rewrite properly to use bitfield to cast back to signed ints
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 287 ++---
src/gallium/drivers/r600/r600_state.c
ive of a problem.
Dave.
>
> Signed-off-by: Dave Airlie
> ---
> src/mesa/state_tracker/st_format.c | 24 +++-
> src/mesa/state_tracker/st_format.h | 5 +
> 2 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/state_tracker
> i965 is fully programmable. It can do vertex, geometry, hull, domain, and
> fragment shading in hardware. The only thing the i965 classic driver uses
> software rendering for is some deprecated and rarely used GL 1.x features.
I think the original 965G and 965GM chip suffered from a balance
pr
>> Those are just ideas. I'm open to discussion.
>
> The driver is disabled by default and needs to be enabled via
> --with-gallium-drivers=i965.
I think a warning + maybe something like
--with-gallium-drivers=i965g-unofficial might work,
the thing is distros should probably be using i915g at th
From: Dave Airlie
the max version check was using the default cache, not reading
from drirc, which kinda made it hard to force enable it in drirc land.
So temporarily parse the dri config files and throw away the results.
Signed-off-by: Dave Airlie
---
src/mesa/drivers/dri/intel
From: Dave Airlie
For some reason I made this happen under indirect rendering,
I think we might have a leak, valgrind gave out, so I said I'd
fix the basic problem.
Signed-off-by: Dave Airlie
---
src/glsl/ralloc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
Hi,
I put a 3Ghz Core2 Q35 box i found in the office to good use (so much
nicer than a pineview atom).
http://people.freedesktop.org/~airlied/piglit/i915c/
is a full run with i915c forced to advertise GL2.0 using the stub
occlusion query hack in drirc, and i915g advertising GL2.1, and built
agai
I actually had a change for this reviewed already I'll push it.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Dave Airlie
So GL4.3 spec pretty much says glClear on integer buffers is undefined,
then we have a piglit multisample test
ext_framebuffer_multisample-int-draw-buffers-alpha-to-coverage
that actually does undefined things but doesn't rely on the results except
not crashing.
(The
These two patches fake MSAA support for drisw and llvmpipe,
Discuss... :-)
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
This adds support for multisample to drisw, even if we fake
multisample in the drivers we should at least do best effort,
and not fail to render.
Signed-off-by: Dave Airlie
---
src/gallium/state_trackers/dri/sw/drisw.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion
From: Dave Airlie
We've talked in the past about just faking multisample support
in the sw drivers as much as we possibly can, this just adds enough
to llvmpipe to do that.
It produces some valid fails in piglit, like the accuracy tests
and the texelFetch tests fail due to lack of second
This just always returns 0.5,0.5 as the position.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/llvmpipe/lp_context.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe/lp_context.c
b/src/gallium/drivers/llvmpipe/lp_context.c
index 9a6d13b
mmit
> e0e7e295.
>
Looks good to me,
Reviewed-by: Dave Airlie
> Since this just adds a missing error check, it's arguable that this
> should not be included in stable branches. Opinions?
and can't see the point of stable for it.
>
> src/mesa/main/texobj.c |
lears.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/llvmpipe/lp_screen.c | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
src/mesa/main/mtypes.h | 1 +
src/mesa/main/version.c | 2 +-
src/mesa/state_tracker/st_extensions.c | 7 +++
5 files change
On Thu, Nov 28, 2013 at 4:13 AM, Roland Scheidegger wrote:
> Looks good to me.
> Though frankly I don't know if that really is better than your idea of
> faking 4-sample resources - it at least is simpler. But noone else
> chimed in...
>
I'm pretty ambivalent about which way to go, this is probabl
with gnome-shell with a cogl hacked to reenable sub copies
for llvmpipe and the one piglit test.
I could probably split this patch up as well.
Signed-off-by: Dave Airlie
---
include/GL/internal/dri_interface.h | 9 +++-
src/gallium/drivers/llvmpipe/lp_screen.c | 17 +++
src/ga
> Instead of I'd prefer that we added an optional rectangle structure pointer
> to flush_frontbuffer. Less one entrypoint, and both paths can probably share
> a lot of code in most cases. Ditto for sw_winsys.h.
>
Yeah I thought someone might suggest that, it was just a lot larger
patch results,
On Fri, Nov 29, 2013 at 6:20 AM, Dave Airlie wrote:
>> Instead of I'd prefer that we added an optional rectangle structure pointer
>> to flush_frontbuffer. Less one entrypoint, and both paths can probably share
>> a lot of code in most cases. Ditto for sw_winsys.h
with gnome-shell with a cogl hacked to reenable sub copies
for llvmpipe and the one piglit test.
I could probably split this patch up as well.
v2: pass a pipe_box, to reduce the entrypoints, as per Jose's review,
add to p_screen doc comments.
Signed-off-by: Dave Airlie
---
include/G
From: Dave Airlie
This readback from the frontbuffer with swrast was broken, that bug
just made it more obviously broken, this fixes it by inverting the
sub image gets. Also fixes a few other piglits.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=72327
Fixes: https://bugs.freedesktop.org
So the llvmpipe endian work broke the nouveau nv40 support for the
nv43 in the ppc G5 a few people have,
Now I'm not really sure how this is supposed to be fixed,
the gallium driver exports the formats it supports, which doesn't
include the translated formats for PIPE_FORMAT_BGRA and
PIPE_FOR
From: Dave Airlie
This is just a simple implementation that stores the extra values into the
DRIimage
struct and just uses the fd importer. I haven't looked into what is required
to import YUV or deal with the extra parameters.
Signed-off-by: Dave Airlie
---
src/gallium/state_tracker
From: Dave Airlie
Before I cut-n-paste this a 3rd time lets consolidate it.
Signed-off-by: Dave Airlie
---
src/gallium/state_trackers/dri/drm/dri2.c | 81 +--
1 file changed, 35 insertions(+), 46 deletions(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
From: Dave Airlie
For GLSL 1.50 we can get frag shaders with primitive id as an
input, add support to the translator for this.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_program.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/state_tracker/st_program.c
b/src
Not sure this is 100% the correct way to do this, since it may be a change
at the glsl->tgsi level that is required, either way open discussions!
fixes piglit tests/spec/glsl-1.50/execution/geometry/primitive-id-in.shader_test
with llvmpipe with fake MSAA
Signed-off-by: Dave Airlie
---
On Sun, Jan 19, 2014 at 5:45 AM, Emil Velikov wrote:
> On 13/01/14 18:47, Tom Stellard wrote:
>> On Sat, Jan 11, 2014 at 03:53:58PM +, Emil Velikov wrote:
>>> Hello list,
>>>
>>> While going though mesa's build systems I was wondering what it would
>>> take to improve the overall experience of
From: Dave Airlie
for consistency with vs and fs dumpers.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/llvmpipe/lp_state_gs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_state_gs.c
b/src/gallium/drivers/llvmpipe/lp_state_gs.c
Hey,
This is just a couple of patches I threw together to interface the new
mesa viewport array code to gallium, I've ran a few tests on llvmpipe,
and they seem to pass with this code.
The only question I really have is do we want to expand the CSO interface
to cover this or not?
Dave.
From: Dave Airlie
This adds GS output and FS input support, even though FS input
support isn't supported until GLSL 4.30 from what I can see.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_program.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/state_tr
From: Dave Airlie
this just ties the mesa code to the pre-existing gallium interface,
I'm not sure what to do with the CSO stuff yet.
0.2: fix min/max bounds
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_atom_scissor.c | 75 ---
src/mesa/state_tr
From: Dave Airlie
I sometimes build without EGL just for speed purposes, however
it no longer finds my drivers when I do due to the HAVE_LIBUDEV
defines being wrong.
Signed-off-by: Dave Airlie
---
configure.ac | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a
I've just been playing with layered rendering on r600g and the depth
test Marek wrote, and I noticed I'm sometimes getting a gallium
framebuffer state with 1 cbuf but no defined cbuf,
this comes direct from the Mesa state in the gl_framebuffer object, is
this legal?
Dave.
___
>
> Yes, it's legal. Drivers should handle NULL color buffer bindings and
> there is a test for it:
> http://cgit.freedesktop.org/piglit/commit/?id=ff2398a4e3c4805e7d1bea38f4ae6f9811b42ede
>
> I fixed it just recently.
>
Ah okay on r600g this is broken due to how we work out the
CB_TARGET_MASK, th
>> 3) In si_init_gs_rings:
>> - could you please use readable decimal numbers for specifying the
>> sizes? Like 1024 * 1024 * ...
> [...]
>> - isn't 64 MB too many for a ring buffer?
>
> I can write the numbers any way you like. :) But I just copied them from
> the corresponding r600g patches; I do
This series adds support for geometry shaders to r600g for evergreen and
later GPUs. I don't think r600/r700 support is that hard, but I haven't
had time to look at it at all, and I expect possible erratum.
This passes most of the piglit tests on my BARTS board and doesn't
hang the GPU anymore tha
From: Dave Airlie
It looks like we need these for geom shaders in the future.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/eg_asm.c | 6 --
src/gallium/drivers/r600/r600_asm.c | 9 +++--
src/gallium/drivers/r600/r600_asm.h | 1 +
3 files changed, 12 insertions(+), 4
From: Dave Airlie
SB needs fixes for three GS instructions it seems to raise
them outside loops etc despite my best efforts.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b
From: Vadim Girlin
[airlied: fix dropped streamout line - fix for master]
Signed-off-by: Vadim Girlin
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 1 -
src/gallium/drivers/r600/r600_state.c| 2 -
src/gallium/drivers/r600/r600_state_common.c | 123
From: Vadim Girlin
Signed-off-by: Vadim Girlin
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/eg_asm.c | 10 ++
src/gallium/drivers/r600/r600_asm.c| 21 +++--
src/gallium/drivers/r600/r600_asm.h| 4 ++--
src/gallium/drivers/r600/r600_shader.c
From: Vadim Girlin
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreend.h | 80 ---
src/gallium/drivers/r600/r600d.h | 1 +
2 files changed, 75 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreend.h
b/src/gallium
From: Dave Airlie
This can happen in normal operation, so don't report an error on it,
just continue.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
From: Dave Airlie
For geometry shaders we need to call this code from a second place.
Just move it out for now to keep future patches cleaner.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 213 +
1 file changed, 110 insertions(+), 103
From: Dave Airlie
Although we don't use SB on geom shaders, the VS copy shader will use it
so we might as well implement MEM_RING support in sb.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/sb/sb_bc_dump.cpp | 3 +++
src/gallium/drivers/r600/sb/sb_bc_finalize.cpp | 2 +-
From: Dave Airlie
Trivial fix to Vadim's code.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index d62267f..a3ca43a 100644
---
From: Dave Airlie
only enable prim id if gs uses it
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 6 +-
src/gallium/drivers/r600/evergreend.h | 4
src/gallium/drivers/r600/r600_shader.c | 9 +
src/gallium/drivers/r600/r600_shader.h
From: Dave Airlie
this fixes a bunch of the geom shader built-in tests
---
src/gallium/drivers/r600/r600_shader.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index a3ca43a..93fe851
From: Dave Airlie
As we do for vertex and pixel shaders.
`
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index d99f423
From: Dave Airlie
If the shader has no CF clauses at all emit an nop
If the last instruction is an ENDLOOP add a NOP for the LOOP to go to
if the last instruction is CALL_FS add a NOP
These fix a bunch of hangs in the geometry shader tests.
Signed-off-by: Dave Airlie
---
src/gallium/drivers
From: Dave Airlie
This enables streamout with GS in the mix, from the
VS dma shader.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 6 --
src/gallium/drivers/r600/r600_state_common.c | 4
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a
On Thu, Jan 30, 2014 at 10:42 AM, Dave Airlie wrote:
> From: Vadim Girlin
>
> Signed-off-by: Vadim Girlin
> Signed-off-by: Dave Airlie
This commit has a missing line in the r600 case that causes a
regression, I'll fix it up.
Dave.
___
From: Vadim Girlin
v2: fix regression on r600 NOP instructions.
Signed-off-by: Vadim Girlin
Signed-off-by: Dave Airlie
Fix regression since eop moving
---
src/gallium/drivers/r600/eg_asm.c | 10 ++
src/gallium/drivers/r600/r600_asm.c| 24 +---
src
From: Dave Airlie
This is my first attempt at enabling r600/r700 geometry shaders,
the basic tests pass on both my rv770 and my rv635,
It requires this kernel patch:
http://www.spinics.net/lists/dri-devel/msg52745.html
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_asm.c
So I was looking at adding ARB_texture_query_levels support to
gallium, and hit a bit of a saga in the state tracker texture
finalising code.
commits involved in this are below,
So to fix the query levels test I essentially wanted to revert
529b7b355d392b1534ccd8ff7b428dc21cbfdc21 so that the hw
So I wanted to implement ARB_texture_query_levels, in order to get the
right answers I had to make sure the gallium texture has the same levels
as the mesa one, so the hw is programmed correctly.
This led to some fallout as we were suddenly hitting the finalize texture
reallocation path in cases w
On Sat, Apr 12, 2014 at 10:25 AM, Giovanni Campagna
wrote:
> Hi everyone,
>
> Some time ago I sent patches to enable the swrast driver on
> GBM/DRM, and I did them in the dumbest way possible (that is,
> having GBM implement the dri-swrast interface), to make sure
> it would work without kernel su
this hadn't
>> been tested before.
Reviewed-by: Dave Airlie
I had this patch in when I tested some of this stuff previously
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 6 May 2014 14:51, Patrick McMunn wrote:
> I'm using some older hardware - an ATI Radeon 9200 - which can only handle
> up to OpenGL 1.2. I was wondering if it's possible to use the hardware
> renderer generally and have the driver hand off the handling of functions
> which my video card can't h
4 texgathers, with only one of the
>> returned 4 components used from each one. (And it can't use texfetch
>> since the min/max offsets are different, and there's probably some
>> other clever reason as well.)
>>
>>> I think though some radeon hw could real
>>>
>> Getting back on topic... what should I do? :) Check this in with the
>> new cap? Or just make it the default behaviour and let drivers that
>> can't handle it do the lowering in the driver? FWIW, I believe Dave
>> Airlie was against that, b
On Sun, Apr 21, 2013 at 5:36 PM, Jose Fonseca wrote:
> - Original Message -
>> Do we really need the lower_left_origin state? I think I can't
>> implement it for radeon and it's the kind of stuff that should be
>> taken care of by the state tracker anyway.
>
> My understanding is that hard
On Mon, Apr 22, 2013 at 9:09 PM, Jose Fonseca wrote:
> - Original Message -
>> From: Christopher James Halse Rogers
>>
>> This is only exposed by drivers wich support the new PIPE_CAP_PRIME
>> parameter,
>> for PRIME import/export.
>
> What does exactly PIPE_CAP_PRIME entail? Please docum
Building on RHEL6 tinderbox, we get -std=c99, and the radeon uvd code
uses anonymous unions which this disables.
It doesn't look too difficult to fix, just wondering if there was a
reason for using anon unions in the first place?
Dave.
___
mesa-dev mail
On Fri, Apr 26, 2013 at 4:48 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> Building on RHEL6 tinderbox, we get -std=c99, and the radeon uvd code
>> uses anonymous unions which this disables.
>>
>> It doesn't look too difficult to fix, just wondering if there was a
>> reason for usi
I've been playing with a gallium driver, and started looking at some
wierd gears behaviour,
The vbo code maps the buffer with GL_MAP_FLUSH_EXPLICIT_BIT which to
me requires that at some point
we call ctx->Driver.FlushMappedBufferRange. Now the code attempts to
call it in vbo_exec_vtx_unmap
but fro
On Mon, Apr 29, 2013 at 2:52 PM, Dave Airlie wrote:
> I've been playing with a gallium driver, and started looking at some
> wierd gears behaviour,
>
> The vbo code maps the buffer with GL_MAP_FLUSH_EXPLICIT_BIT which to
> me requires that at some
From: Dave Airlie
Not sure if this makes a difference or not, but either its inconsistent
for some undocumented reason or its just a bug.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/util/u_upload_mgr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium
le branches.
>> ---
>> src/mesa/drivers/dri/i965/gen6_blorp.cpp | 36
>>
>> 1 file changed, 36 insertions(+)
>
>
> Wow.
>
> Reviewed-by: Kenneth Graunke
>
Tested-by: Dave Airlie
Tested on top of the tree that was broken when I las
On Fri, May 3, 2013 at 6:04 AM, Zack Rusin wrote:
>> Well in contrast to the IF/UIF they'd be really redundant unless I'm
>> missing something so just for supporting negation on inputs or not this
>> looks like not really worth it (and as said there are also other signed
>> instructions where supp
> Sorry to hear the hw doesn't support it, but this is supported by d3d10
> so it's quite likely some hw indeed supports it. There's always some
> things some hw can't do natively.
Well I was hoping before adding new things for sw driver to gallium we
should confirm if it
makes sense for hw.
> I'
>> What do you think?
>
> It would need some sort of plan for how to deal with making
> drm_intel_bufmgr_check_aperture work correctly and efficiently when a
> reloced-to BO gets new relocs, which is the reason everything is in one
> BO currently.
I was looking for code that did this for something
>>
>>> Haswell has been broken on master for a surprisingly long time, since
>>> commit
>>> 1dfea559c3 (Thu May 2 11:27:37 2013 -0700). Reverting that commit fixed
>>> it
>>> for me.
>>>
>>> If it doesn't get properly fixed by the 7th day, I'd like to see the
>>> guilty
>>> patch reverted. A full w
> considering whether two 32-bit formats are sufficiently compatible.
>
>
> It looks like you're undoing change a2817f6ae by Dave Airlie.
>
> Dave should review this. It's not 100% clear to me what's going on there.
I think I'd rather put back what Marek's cha
On Wed, May 8, 2013 at 11:14 AM, Marek Olšák wrote:
> Sorry, I'm not following. Which commit of mine are you referring to?
The one ajax pointed out in the first message,
62452883
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lis
From: Dave Airlie
Some drivers change the default for Const.MaxUniformBufferBindings,
the current code allocates them before the point drivers would ever get
a chance to do such modifications.
Instead allocate them, and if the driver requires it can later reallocate
them to there larger side
On Wed, May 15, 2013 at 2:03 AM, Marek Olšák wrote:
> Some Gallium drivers were crashing, because the array was not large enough.
>
> NOTE: This is a candidate for the stable branches.
> ---
> src/mesa/main/bufferobj.c | 10 ++
> src/mesa/main/config.h |
From: Dave Airlie
This is my attempt at fixing this as the CVE is making RH security team
care enough to make me look at this. (please upstream, security fixes are
more important than whatever else you are doing, if for no other reason than
it saves me having to fix stuff I've no real clue
On Thu, May 30, 2013 at 10:21 AM, Eric Anholt wrote:
> Dave Airlie writes:
>
>> From: Dave Airlie
>>
>> This is my attempt at fixing this as the CVE is making RH security team
>> care enough to make me look at this. (please upstream, security fixes are
>> m
801 - 900 of 4069 matches
Mail list logo
