On Tue, Feb 22, 2011 at 12:02 AM, kumar vemuri kumar21...@gmail.com wrote:
One more question Dave. Can a 3D APP/Game refuse to run if hw
acceleration is not available? I understand that without hw acceleration
they will be extremely slow and unplayable but i want to know if its
possible to run
Hi guys,
I've pushed a branch to my personal repo with support for mesa core +
swrast + gallium (enough for r600g to work) for this extension.
I've just ported the alpha compression from Roland's DXTn work and as
far as I can ascertain from reading the EXT_texture_compression_rgtc
specification
On Mon, Feb 28, 2011 at 1:28 AM, Fabian Bieler der.f...@gmx.net wrote:
This fixes piglit tests glsl-fs-abs-neg and glsl-vs-abs-neg.
Hi Fabian, this causes a gears regression.
I get some wierd rendering here with it.
Dave.
___
mesa-dev mailing list
Hi guys,
Two open questions with the RGTC support in gallium:
a) I'd like to share texcompress_rgtc_tmp.h between gallium and mesa,
at the moment gallium has an extended
../../../mesa/main/texcompress_rgtc_tmp.h in it,
do we have a better place to put this file? any suggestions on where
things
On Fri, Mar 4, 2011 at 8:17 AM, Jose Fonseca jfons...@vmware.com wrote:
About a), one day we should have this in a library shared by mesa/gallium,
but until then anywhere is fine by me.
About b) please provide unorm8 support for all formats. It's useful for
debugging/displaying, e.g.,
Hi guys,
I know this used to work, but it seems to be well busted now.
If you made glx changes in mesa you could just set XORG_BASE and run
make and it would regenerate all the files in the X server which
really are cryptic as all hell. Now when I do that stuff breaks all
over the place, missing
Hi,
yet another GLX question to go into the void (anyone want to reply on
why the X glx gen scripts are foobar yet?)
So fglrx seems broken wrt GLX_EXT_framebuffer_sRGB and GLX_ARB_fbconfig_float
server glx vendor string: ATI
server glx version string: 1.4
server glx extensions:
On Mon, Mar 7, 2011 at 3:42 AM, Marek Olšák mar...@gmail.com wrote:
Hi,
I have several questions about Gallium. Some of them are about undocumented
stuff, others are just little things from the top of my head. Please
consider these as things I may do when time allows.
1) Flush flags
On Sun, Mar 13, 2011 at 5:02 PM, Denis Oliver Kropp d...@directfb.org wrote:
Hi,
thanks to all of you who contributed to Mesa/DRM/KMS.
Following are some benchmark results of the new DirectFB on Mesa port.
The code is checked into git.directfb.org now.
I also think I know how to map the
On Sun, Mar 13, 2011 at 5:15 PM, Denis Oliver Kropp d...@directfb.org wrote:
On 13/03/11 08:09, Dave Airlie wrote:
On Sun, Mar 13, 2011 at 5:02 PM, Denis Oliver Kropp d...@directfb.org
wrote:
Hi,
thanks to all of you who contributed to Mesa/DRM/KMS.
Following are some benchmark results
On Fri, Mar 4, 2011 at 11:24 AM, Dave Airlie airl...@gmail.com wrote:
Hi guys,
I know this used to work, but it seems to be well busted now.
If you made glx changes in mesa you could just set XORG_BASE and run
make and it would regenerate all the files in the X server which
really
On Fri, Apr 1, 2011 at 5:51 AM, Ian Pilcher arequip...@gmail.com wrote:
With latest batch of Fedora 15 test updates, I get GPU hangs very
shortly after logging in (with KDE desktop effects enabled).
Unfortunately, the hangs do not occur if I boot with drm.debug=14.
Any ideas on how I can
On Sun, Apr 17, 2011 at 12:18 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Sat, Apr 16, 2011 at 5:06 AM, Marek Olšák mar...@gmail.com wrote:
From GL_ARB_draw_instanced:
EXT_gpu_shader4 or NV_vertex_program4 or OpenGL 3.0 is required.
which means we can't advertise it. :( Well at least
On Sun, Apr 17, 2011 at 11:45 AM, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/16/2011 04:06 AM, Marek Olšák wrote:
From GL_ARB_draw_instanced:
EXT_gpu_shader4 or NV_vertex_program4 or OpenGL 3.0 is required.
which means we can't
From: Dave Airlie airl...@redhat.com
This is a first step to decreasing the CPU usage, by decreasing how much
stuff we pass to the GPU and hence to the kernel CS checker.
This adds a check to see if the values we need to write are actually dirty,
and avoids writing if they are. However certain
On Mon, Apr 18, 2011 at 11:00 AM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
This is a first step to decreasing the CPU usage, by decreasing how much
stuff we pass to the GPU and hence to the kernel CS checker.
This adds a check to see if the values we need
On Thu, Apr 14, 2011 at 4:36 AM, Bas Nieuwenhuizen
b...@basnieuwenhuizen.nl wrote:
previously, we always emitted blocks that were set before a draw, after this
patch the block only gets emitted when it is really changed.
Also added a force parameter to r600_context_pipe_state_set, because the
,
Reviewed-by: Dave Airlie airl...@redhat.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Dave Airlie airl...@redhat.com
This seems more in line with what the documentation suggests we should be
doing. It doesn't fix the rv635 regression, though I thought it might,
so it means I've no idea whats actually going wrong there.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src
On Wed, 2011-05-04 at 16:16 -0700, Jesse Barnes wrote:
On Wed, 04 May 2011 15:17:31 -0700
Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2011 12:21 PM, Jesse Barnes wrote:
We only spec a 32 bit swap count, so drop the high sbc field.
So I wasn't watching and glproto broke its interface, and I think its bad.
Why?
You can no longer bisect things across this point without now moving glproto.
glxproto.h:xGLXBufferSwapComplete was a released header file
definition, you cannot go back and change history.
This should have been
2011/5/3 Mathias Fröhlich mathias.froehl...@gmx.net:
Marek,
On Tuesday, May 03, 2011 01:33:17 you wrote:
2011/5/2 Mathias Fröhlich mathias.froehl...@gmx.net:
I have again spent some more tries with different kinds of flushes on the
rv635. What helps for the mipmap problem here is emitting
So to be honset I do not understand where the data sticks and what I need to
do to get it out.
May be that observations make sense for somebody else?
I've been staring at this I'm running out of good ideas, and even bad ideas.
It really does seem like the TC has some invalid lines in it
2011/5/5 Dave Airlie airl...@gmail.com:
So to be honset I do not understand where the data sticks and what I need to
do to get it out.
May be that observations make sense for somebody else?
I've been staring at this I'm running out of good ideas, and even bad ideas.
It really does seem
From: Dave Airlie airl...@redhat.com
Currently r600g always maps every bo, this is quite pointless as it wastes
VM and on 32-bit with wine running VM space is quite useful.
So with this patch we don't create the mappings until first use, without
tiling enabled this probably won't make a major
Hey,
So we got a bug reported against F15 where we were getting an illegal
input event type 0, after passing it around the RH X team I eventually
came to look at it.
The problem appears to be that we are using llvmpipe as our swrast
renderer and on systems that fallback to that we end up with
From: Dave Airlie airl...@redhat.com
This table covered a large range unnecessarily, reduce the address
range covered, use the fact that the bottom two bits aren't significant,
and remove unused fields from the range struct. It also drops the
hash_size/shift in context in favour of a define
From: Dave Airlie airl...@redhat.com
We only need to do this when the texture and CB are using the
same memory area.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/winsys/r600/drm/r600_hw_context.c | 23 +++
src/gallium/winsys/r600/drm/r600_priv.h
From: Dave Airlie airl...@redhat.com
I'm hard pressed to think of any reason a gallium thread would want to
receive a signal, especially considering its probably loaded as a library
and you don't want the threads interfering with the main threads signal
handling.
This solves a problem loading
From: Dave Airlie airl...@redhat.com
This fixes piglits fragment-and-vertex-texturing test on llvmpipe for me.
I've no idea if someone had another plan for this that is smarter than what
I've done here, but what I've basically done is
split fragment and vertex sampler and sampler_view setup
From: Dave Airlie airl...@redhat.com
This function was taking a lot more CPU than required due to it memsetting
a bunch of memory that didn't require it from what I can see.
We should only memset here when we are about to fill out the sampler,
otherwise we end up doing a bunch of memsets
From: Dave Airlie airl...@redhat.com
(I've already pushed this by accident, if its bad I can revert it).
this seems like a logical thing to do and sets the correct st flags
for vertex textures.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_atom.c |1
From: Dave Airlie airl...@redhat.com
We are getting inconsistent methods for endian detection (same answer when
it works, just doesn't work on some platforms) depending on whether __GLIBC__
is defined, which of course depends on include ordering before p_config.h
Just make p_config.h include
I don't think that's the correct solution either. If the state-trackers
notion of the drawable is just marked invalid, the first state tracker
context using the drawable will go ahead and update it. Subsequent contexts
will see the updated drawable, but might want to adjust their viewports.
Hi Brian,
did you forget to git add for the nouveau dri-core fix?
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Jun 9, 2011 at 12:54 AM, Jose Fonseca jfons...@vmware.com wrote:
Personally, I prefer the standard C bool type, given it's a) standard, b)
shorter. Furthermore Microsoft's windows.h already defines boolean:
$ grep -r '\boolean\' /usr/i586-mingw32msvc/include/
On Thu, Jun 16, 2011 at 7:38 AM, Bryan Cain bryanca...@gmail.com wrote:
My work on the GLSL IR to TGSI translator I announced on the list this
April is now at the point where I think it is ready to be merged into
Mesa. It is stable and doesn't regress any piglit tests on softpipe or
nv50.
From: Dave Airlie airl...@redhat.com
Just does a basic test to check the compiler can handle textureSize from
GLSL 1.30.
Signed-off-by: Dave Airlie airl...@redhat.com
---
.../glsl-1.30/compiler/texture/textureSize.frag| 14 ++
1 files changed, 14 insertions(+), 0 deletions
From: Dave Airlie airl...@redhat.com
I just used an opcode I called txs, TGSI has a RESINFO opcode this corresponds
to.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/glsl/builtins/profiles/130.frag |2 -
src/glsl/builtins/tools/texture_builtins.py | 59
On Sun, Jun 19, 2011 at 6:23 PM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
Oops sent this by mistake to this list, its on piglit list.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
By the looks of it the 0/POS attrib + the overlapping/16-31 ones check
_Current
and the others all check _Enabled, to me it would make some sense at
least if 0
was consistent with the others, but maybe someone knows what is correct.
The confusion probably goes all the way back to the ARB's
From: Dave Airlie airl...@redhat.com
inline the hotpath of the reference remaining the same, this shouldn't
penalise the slow path at all but improve the hot path so we don't have
to jump to the function.
It also moves some assert checks under an #ifndef NDEBUG.
Signed-off-by: Dave Airlie airl
On Mon, Jul 11, 2011 at 3:20 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On 07/09/2011 07:03 AM, Jose Fonseca wrote:
I heard no concerns so I went ahead and made a branch where:
- I removed GLUT
- derived Mesa tarballs' file list from git ls-files.
On Wed, Jul 13, 2011 at 4:53 PM, Brian Paul brian.e.p...@gmail.com wrote:
On Fri, Jun 24, 2011 at 7:20 AM, Brian Paul bri...@vmware.com wrote:
On 06/23/2011 11:22 PM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
inline the hotpath of the reference remaining the same, this shouldn't
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paul bri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
*
Hey,
so virgl stopped working on nouveau the other day and I bisected it to
the enable of the floating point compare instructions in the state
tracker,
I've attached a shader runner file that makes it hang,
Dave.
nouveau-float-compare-regression.shader_test
Description: Binary data
On Tue, Sep 10, 2013 at 11:59 AM, Dave Airlie airl...@gmail.com wrote:
Hey,
so virgl stopped working on nouveau the other day and I bisected it to
the enable of the floating point compare instructions in the state
tracker,
I've attached a shader runner file that makes it hang,
As usual 5
On Tue, Sep 10, 2013 at 12:04 PM, Dave Airlie airl...@gmail.com wrote:
On Tue, Sep 10, 2013 at 11:59 AM, Dave Airlie airl...@gmail.com wrote:
Hey,
so virgl stopped working on nouveau the other day and I bisected it to
the enable of the floating point compare instructions in the state
tracker
Maybe the type isn't set correctly? Looks to me like these instructions
end up in mkCmp, which will set both src and dst type but ignore src
type and set both according to the same type (which was the dst type).
Roland
Okay I've attached my next attempt at fixing it, fixes the two testcases
On Fri, Sep 13, 2013 at 12:24 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 12.09.2013 16:14, Roland Scheidegger wrote:
Am 12.09.2013 03:40, schrieb Dave Airlie:
Maybe the type isn't set correctly? Looks to me like these instructions
end up in mkCmp, which will set both src
It seems a user app can get us into this state, I trigger the fail
running fbo-maxsize inside virgl, it fails to create the backing
storage for the texture object, but then segfaults here when it
should fail the completeness test.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa
Last question set and I do not know a good way to go about this. Right now
the documentation of Mesa looks like to me to be in the code in comments;
this is great when working on one area/zone, but really hard to get a global
picture of Mesa. Given that I am trying to do just that, I think
On Sun, Sep 22, 2013 at 12:57 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Fri, Sep 20, 2013 at 7:52 PM, Eric Anholt e...@anholt.net wrote:
Noticed while grepping through the code for something else.
---
src/mesa/program/program.c | 36 ++--
1 file changed,
Hey,
So for virgl I was praying I could avoid having to keep a GL context
on the host per guest context but it appears to do
NV_conditional_render properly I either need the ability to
suspend/resume queries (maybe I could write an extension) or I need
contexts :-(
So this led me to look at the
Just want to check an inconsistency,
so GL clears respect glDepthMask, gallium docs don't explicitly
mention depth masking, they say clear isn't affected by color or
stencil write masks, should that sentence contain depth?
Dave.
___
mesa-dev mailing
On Fri, Oct 11, 2013 at 2:27 PM, Paul Berry stereotype...@gmail.com wrote:
It's been a long and rocky road, but geometry shader support in Mesa's
i965/gen7 driver has finally reached a point I'm willing to call
feature complete. Since geometry shaders were the last remaining
feature needed
Hi,
I pulled Brian's patches and then hacked llvmpipe locally to claim GL 3.2,
and ran piglit, fixed some of the obviously missing pieces and crashes.
These aren't immediately going to expose any new functionality, but it
might help if someone doing r600g or nouveau support can concentrate on
From: Bryan Cain bryanca...@gmail.com
v2 (Paul Berry stereotype...@gmail.com: Split out to separate patch
(previously this was part of glsl: add builtins for geometry
shaders.)
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_program.c | 7 +++
1 file changed, 7
From: Bryan Cain bryanca...@gmail.com
v2 (Bryan Cain bryanca...@gmail.com): fix 2D array indexing order.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 101 ++-
src/mesa/state_tracker/st_program.c| 107
From: Fabian Bieler fabianbie...@fastmail.fm
From the ARB_geometry_shader4 spec (section Geometry Shader outputs):
The built-in special variable gl_Position is intended to hold the
homogeneous vertex position. Writing gl_Position is optional.
Signed-off-by: Dave Airlie airl...@redhat.com
This just adds the missing bits so the ubo tests don't crash.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_atom.c | 1 +
src/mesa/state_tracker/st_atom.h | 1 +
src/mesa/state_tracker/st_atom_constbuf.c | 17 +
3 files changed
This fixes a number of piglit crashes when running on a hacked up llvmpipe.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_program.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker
On Tue, Oct 15, 2013 at 7:58 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Hi,
I pulled Brian's patches and then hacked llvmpipe locally to claim GL 3.2,
and ran piglit, fixed some of the obviously missing pieces and crashes.
These aren't immediately going to
From: Dave Airlie airl...@redhat.com
If a driver wants to expose higher glsl levels have the state tracker
respect them.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_extensions.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/mesa
On Sun, Oct 20, 2013 at 11:00 PM, Brian Paul bri...@vmware.com wrote:
On 10/20/2013 01:07 PM, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
If a driver wants to expose higher glsl levels have the state tracker
respect them.
Signed-off-by: Dave Airlie airl...@redhat.com
From: Dave Airlie airl...@redhat.com
Limit the max glsl version level to what the state tracker supports.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_extensions.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/mesa
Do either of you guys plan to implement support for this extension? The
value to developers is obviously increased if more drivers support the
extension. This extension was born from feedback that I received from
people at FOSDEM and from various game developers at Game Developer
From: Dave Airlie airl...@redhat.com
+ nvc0 support for demo purposes, will split up later.
So I've done this by just adding pipe cap queries for this stuff,
we might want to add another high level query to say if we are
bothered exposing this stuff.
nouveau can't get the pci device id
On Sat, Oct 12, 2013 at 8:10 AM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
The enumerated values are currently allocated from Intel's range.
Some highlevel comments below,
+GLX renderer attribute number description
+
How does this interact with the rule that kernel interfaces require an
open source userspace? Is here are the mesa/libdrm patches that use
it sufficient to get the kernel interface merged?
That's my understanding: open source userspace needs to exist, but it
doesn't need to be merged
From: Dave Airlie airl...@redhat.com
I've no idea when this broke, but we have some people who wanted it fixed,
so here's my attempt.
reproducer, run readpix with swrast hit f, or run trival tri -sb things are
upside down, after this patch they aren't.
Bugzilla: https://bugs.freedesktop.org
Hey,
so I'm not really uptodate on latest Khronos stuff, but the glext.h
from the webpage is out of date and I can't seem to svn checkout the
xml files as i'm not a member.
So does glext.h contain the 4.4 ARB extensions like ARB_multi_bind or
do we need to start distributing glcorearb.h?
Dave.
On Mon, Nov 18, 2013 at 7:58 PM, Dave Airlie airl...@gmail.com wrote:
Hey,
so I'm not really uptodate on latest Khronos stuff, but the glext.h
from the webpage is out of date and I can't seem to svn checkout the
xml files as i'm not a member.
So does glext.h contain the 4.4 ARB extensions
From: Dave Airlie airl...@redhat.com
GLX 1.2 servers with no SGIX_fbconfigs exist (some citrix thing),
and we fail glxinfo completely in those cases.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/glx/glxcmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glx
From: Dave Airlie airl...@redhat.com
If we get a server that has only GLX1.2 and no SGIX_fbconfig, we can
print stuff we shouldn't. If we have no fbconfigs then we don't have core
profile, so don't bother trying visual path when doing core profile.
Signed-off-by: Dave Airlie airl...@redhat.com
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
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 airl...@redhat.com
---
src/gallium/state_trackers/dri/sw/drisw.c | 24 +++-
1 file changed, 23
From: Dave Airlie airl...@redhat.com
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
This just always returns 0.5,0.5 as the position.
Signed-off-by: Dave Airlie airl...@redhat.com
---
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
support was added in commit
e0e7e295.
Looks good to me,
Reviewed-by: Dave Airlie airl...@redhat.com
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
.
Signed-off-by: Dave Airlie airl...@redhat.com
---
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
On Thu, Nov 28, 2013 at 4:13 AM, Roland Scheidegger srol...@vmware.com 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 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 airl...@redhat.com
---
include/GL/internal/dri_interface.h | 9 +++-
src/gallium/drivers/llvmpipe/lp_screen.c | 17
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 airl...@gmail.com 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.
Yeah I thought
this 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 airl...@redhat.com
---
include/GL
From: Dave Airlie airl...@redhat.com
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
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
From: Dave Airlie airl...@redhat.com
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 airl...@redhat.com
From: Dave Airlie airl...@redhat.com
Before I cut-n-paste this a 3rd time lets consolidate it.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/state_trackers/dri/drm/dri2.c | 81 +--
1 file changed, 35 insertions(+), 46 deletions(-)
diff --git a/src
From: Dave Airlie airl...@redhat.com
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 airl...@redhat.com
---
src/mesa/state_tracker/st_program.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/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 airl
On Sun, Jan 19, 2014 at 5:45 AM, Emil Velikov emil.l.veli...@gmail.com 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
From: Dave Airlie airl...@redhat.com
for consistency with vs and fs dumpers.
Signed-off-by: Dave Airlie airl...@redhat.com
---
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
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 airl...@redhat.com
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 airl...@redhat.com
---
src/mesa/state_tracker/st_program.c | 9 +
1 file changed, 9 insertions
From: Dave Airlie airl...@redhat.com
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 airl...@redhat.com
---
src/mesa/state_tracker/st_atom_scissor.c | 75
From: Dave Airlie airl...@redhat.com
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 airl...@redhat.com
---
configure.ac | 7 ---
1 file changed, 4 insertions(+), 3
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.
601 - 700 of 3958 matches
Mail list logo
