On Fri, 2010-01-08 at 21:44 -0800, Vinson Lee wrote:
Module: Mesa
Branch: mesa_7_7_branch
Commit: 4775723d2f641dcd82e8c9cd39ba52f8d86158c7
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4775723d2f641dcd82e8c9cd39ba52f8d86158c7
Author: Vinson Lee v...@vmware.com
Date: Fri Jan
On Sun, 2010-01-10 at 12:04 -0800, Luca Barbieri wrote:
+ {
+ char* dst = texImage-Data;
+ char* src = pixels;
+ for(int i = 0; i height; ++i)
+ {
+memcpy(dst, src, srcImageStride);
+dst += dstRowStride;
+src +=
On Sun, 2010-01-10 at 05:26 -0800, José Fonseca wrote:
Attached is a patch that generalizes the ALIGN16/8_XXX macros in
p_compiler.h to work on MSVC and handle alignments beyond 8 and 16
bytes.
There is more than one way to have cross-platform alignment macros --
all quite ugly.
The
These patches add support to double opcodes as discussed in mail list.
The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
dmuladd, drcp and dslt.
They are used like suggested by Zack:
MOVD A.xy, C.xy, c.xy
where x is the lsb and y is the msb.
There are still missing some opcodes
On Mon, 2010-01-11 at 05:37 -0800, Igor Oliveira wrote:
These patches add support to double opcodes as discussed in mail list.
The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
dmuladd, drcp and dslt.
They are used like suggested by Zack:
MOVD A.xy, C.xy, c.xy
where x is
On 8 jan 2010, at 18.42, Mike Stroyan wrote:
On Thu, Jan 7, 2010 at 4:34 AM, Keith Whitwell kei...@vmware.com
wrote:
It looks like there are some unrelated changes in your diff -- can you
separate them out into disjoint changes? One way is to make several
commits to your local git repo and
On Mon, 2010-01-11 at 05:37 -0800, Igor Oliveira wrote:
+OP13(DMULADD)
For consistency with the existing opcodes, would it be better to have
DMAD here?
Keith
--
This SF.Net email is sponsored by the Verizon Developer
2010/1/10 Chia-I Wu olva...@gmail.com:
Hi Kristian,
I found there are some more breakages after -fvisibility=hidden in
Gallium state trackers. This patch series marks 3 APIs public
* OpenVG API (patch 1)
* st_public.h (patch 3)
* GLX API in GLX state tracker (patch 4)
I am working on a
Hi,
I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
change, so things should continue to run :-).
Roland
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of
Pardon the subject pun, it was totally necessary at this early hour. :3
If the scissor test is enabled, and the scissors obscure the entire
framebuffer, should drawing calls still be run? Talking on IRC, it
seems like there's a valid use-case for performance testing, and I'm
of the mind that
On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
Hi,
I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
change, so things should continue to run :-).
Roland,
Before you do this, can you make sure that the set_constant_buffer()
entrypoint is properly documented
On 11.01.2010 16:42, Keith Whitwell wrote:
On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
Hi,
I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
change, so things should continue to run :-).
Roland,
Before you do this, can you make sure that the
On Mon, 2010-01-11 at 07:39 -0800, Corbin Simpson wrote:
Pardon the subject pun, it was totally necessary at this early hour. :3
If the scissor test is enabled, and the scissors obscure the entire
framebuffer, should drawing calls still be run? Talking on IRC, it
seems like there's a valid
http://bugs.freedesktop.org/show_bug.cgi?id=21979
--- Comment #4 from Przemyslaw.szczepaniak przemyslaw.szczepan...@imgtec.com
2010-01-11 08:15:42 PST ---
Created an attachment (id=32569)
-- (http://bugs.freedesktop.org/attachment.cgi?id=32569)
Fix for glBlendEquationSeparate
On 11.01.2010 16:53, Keith Whitwell wrote:
On Mon, 2010-01-11 at 07:50 -0800, Roland Scheidegger wrote:
On 11.01.2010 16:42, Keith Whitwell wrote:
On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
Hi,
I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
change,
Right,
Doing it.
On Mon, Jan 11, 2010 at 10:15 AM, Keith Whitwell kei...@vmware.com wrote:
On Mon, 2010-01-11 at 05:37 -0800, Igor Oliveira wrote:
These patches add support to double opcodes as discussed in mail list.
The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
dmuladd,
Ok
Igor
On Mon, Jan 11, 2010 at 10:37 AM, Keith Whitwell kei...@vmware.com wrote:
On Mon, 2010-01-11 at 05:37 -0800, Igor Oliveira wrote:
+OP13(DMULADD)
For consistency with the existing opcodes, would it be better to have
DMAD here?
Keith
Hey,
knowing that we're starting to have serious issues with figuring out what
features the given device supports and what api's/extensions can be reasonably
implemented on top of it I've spent the weekend trying to define feature
levels. Feature levels were effectively defined by the Direct3D
Igor Oliveira wrote on 2010-01-11 14:37:
These patches add support to double opcodes as discussed in mail list.
The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
dmuladd, drcp and dslt.
They are used like suggested by Zack:
MOVD A.xy, C.xy, c.xy
where x is the lsb and y is
Hello,
On Mon, Jan 11, 2010 at 1:54 PM, michal mic...@vmware.com wrote:
Igor Oliveira wrote on 2010-01-11 14:37:
These patches add support to double opcodes as discussed in mail list.
The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
dmuladd, drcp and dslt.
They are used
On Mon, 2010-01-11 at 09:36 -0800, Igor Oliveira wrote:
Right,
Doing it.
Thanks Igor.
Keith
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app
Keith Whitwell wrote:
On Mon, 2010-01-11 at 07:39 -0800, Corbin Simpson wrote:
Pardon the subject pun, it was totally necessary at this early hour. :3
If the scissor test is enabled, and the scissors obscure the entire
framebuffer, should drawing calls still be run?
If the scissor box size
gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
-I../../src/gallium/auxiliary -Wall -Wmissing-prototypes
-Wdeclaration-after-statement -Wpointer-arith -g -fPIC -D_POSIX_SOURCE
-D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE
-DPTHREADS -DUSE_XSHM
It was NOT intended to be a performance optimization, it's a fix. I added it
because kernel would have rejected the command stream if everything had been
culled by scissoring.
Marek
On Mon, Jan 11, 2010 at 4:39 PM, Corbin Simpson
mostawesomed...@gmail.comwrote:
Pardon the subject pun, it was
If that's the case, then I will patch the kernel to not be such a crybaby.
Posting from a mobile, pardon my terseness. ~ C.
On Jan 11, 2010 11:20 AM, Marek Olšák mar...@gmail.com wrote:
It was NOT intended to be a performance optimization, it's a fix. I added it
because kernel would have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
Attached is a patch that generalizes the ALIGN16/8_XXX macros in
p_compiler.h to work on MSVC and handle alignments beyond 8 and 16
bytes.
There is more than one way to have cross-platform alignment macros --
all quite ugly.
On Mon, 2010-01-11 at 11:14 -0800, Brian Paul wrote:
Keith Whitwell wrote:
Module: Mesa
Branch: gallium-fb-dimensions
Commit: 609b043d442c99e48d5310244e648ea8a6cc2e8a
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=609b043d442c99e48d5310244e648ea8a6cc2e8a
Author: Keith
On Mon, 2010-01-11 at 11:18 -0800, Luca Barbieri wrote:
gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
-I../../src/gallium/auxiliary -Wall -Wmissing-prototypes
-Wdeclaration-after-statement -Wpointer-arith -g -fPIC -D_POSIX_SOURCE
-D_POSIX_C_SOURCE=199309L
On Mon, 2010-01-11 at 11:19 -0800, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
Attached is a patch that generalizes the ALIGN16/8_XXX macros in
p_compiler.h to work on MSVC and handle alignments beyond 8 and 16
bytes.
There is more than one
On 11.01.2010 18:49, Zack Rusin wrote:
Hey,
knowing that we're starting to have serious issues with figuring out what
features the given device supports and what api's/extensions can be
reasonably
implemented on top of it I've spent the weekend trying to define feature
levels. Feature
The feature levels in the attached table don't apply exactly to all hardware.
For instance:
1. Two sided stencil is supported from NV30/GeForce FX
2. Triangle fans and point sprites are supported in hardware on NV50
(according to Nouveau registers)
3. Alpha-to-coverage should be supported on R300
On Mon, 2010-01-11 at 12:42 -0800, Luca Barbieri wrote:
But for Mesa core and shared Gallium code, we target portability and
that means pretty strict C90...
Well, then maybe -std=c99 should be removed from the global config and
put in driver Makefiles.
Yes, that's a good idea.
Anyway,
On Fri, 2010-01-01 at 10:13 -0800, José Fonseca wrote:
On Tue, 2009-12-29 at 15:41 -0800, Luca Barbieri wrote:
The reason why I didn't implement the glX*Gallium*Mesa functions is
because the glx* extensions are implemented by libGL, and a driver
driver never has chance to export those
On Monday 11 January 2010 15:17:00 Roland Scheidegger wrote:
- extra mirror wrap modes - i don't think mirror repeat was ever
supported and mirror clamp was removed in d3d10 but it seems that some
hardware kept support for those
Mirror repeat is a core feature in GL since 1.4 hence we
On 11 jan 2010, at 17.49, Zack Rusin wrote:
Hey,
knowing that we're starting to have serious issues with figuring out
what
features the given device supports and what api's/extensions can be
reasonably
implemented on top of it I've spent the weekend trying to define
feature
levels.
On Monday 11 January 2010 15:22:43 Luca Barbieri wrote:
The feature levels in the attached table don't apply exactly to all
hardware.
For instance:
1. Two sided stencil is supported from NV30/GeForce FX
2. Triangle fans and point sprites are supported in hardware on NV50
(according to
On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote:
On 11 jan 2010, at 17.49, Zack Rusin wrote:
I think the other stuff is acceptable. Take a look at the docs and
let me know
what you think.
Hmm I don't think you should remove the CAPs but instead just say if
level X then CAPs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zack Rusin wrote:
On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote:
On 11 jan 2010, at 17.49, Zack Rusin wrote:
I think the other stuff is acceptable. Take a look at the docs and
let me know
what you think.
Hmm I don't think you should
I thought MSVC supported C99, but that seems not to be the case.
However, it seems to have partial C99 support, and according to MSDN
the particular case of for loop initializers C99 behaviour may be
selected with /Zc:forScope.
I can't find any reference on exactly which parts of C99 are
On 11 jan 2010, at 21.17, Zack Rusin wrote:
On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote:
On 11 jan 2010, at 17.49, Zack Rusin wrote:
I think the other stuff is acceptable. Take a look at the docs and
let me know
what you think.
Hmm I don't think you should remove the CAPs
On Mon, 2010-01-11 at 14:56 -0800, Zack Rusin wrote:
Module: Mesa
Branch: mesa_7_7_branch
Commit: 3447d545d99c450c6a13d8a37e9cb9f5463a40eb
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=3447d545d99c450c6a13d8a37e9cb9f5463a40eb
Author: Zack Rusin za...@vmware.com
Date: Mon
Jose,
Your commit
5b64d94390e4805e1634f0c8b5e3156e12b8b872, pipebuffer: Multi-threading
fixes for fencing
Makes the Xorg state-tracker deadlock at startup with the following
backtrace, on mesa_7_7_branch.
/Thomas
0x7fd15d3bd6a4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1
Luca Barbieri l...@luca-barbieri.com writes:
I thought MSVC supported C99, but that seems not to be the case.
However, it seems to have partial C99 support, and according to MSDN
the particular case of for loop initializers C99 behaviour may be
selected with /Zc:forScope.
Wow, I never knew
On Monday 11 January 2010 18:04:01 Michel Dänzer wrote:
A better fix should be to make sure the exaMoveInPixmap() call is before
the exaGetPixmapDriverPrivate() call. The latter should never return
NULL then (unless we run out of resources maybe - might be worth keeping
the checks for that).
It's better to revert that commit for now. I thought it the change is was an
improvement but apparently not.
I'm doing more changes to this code, but it's not ready to commit yet.
Jose
From: Thomas Hellström [tho...@shipmail.org]
Sent: Monday, January
On Mon, 2010-01-11 at 18:05 -0500, Zack Rusin wrote:
On Monday 11 January 2010 18:04:01 Michel Dänzer wrote:
A better fix should be to make sure the exaMoveInPixmap() call is before
the exaGetPixmapDriverPrivate() call. The latter should never return
NULL then (unless we run out of
On Monday 11 January 2010 18:18:30 Michel Dänzer wrote:
On Mon, 2010-01-11 at 18:05 -0500, Zack Rusin wrote:
On Monday 11 January 2010 18:04:01 Michel Dänzer wrote:
A better fix should be to make sure the exaMoveInPixmap() call is
before the exaGetPixmapDriverPrivate() call. The latter
Hi all,
Am 10.12.2009 17:36, schrieb José Fonseca:
On Thu, 2009-12-10 at 08:31 -0800, Jose Fonseca wrote:
Module: Mesa
Branch: glsl-pp-rework-2
Commit: 491f384c3958067e6c4c994041f5d8d413b806bc
URL:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
I thought MSVC supported C99, but that seems not to be the case.
However, it seems to have partial C99 support, and according to MSDN
the particular case of for loop initializers C99 behaviour may be
selected with
On Mon, Jan 11, 2010 at 11:33 AM, Keith Whitwell kei...@vmware.com wrote:
On Mon, 2010-01-11 at 11:18 -0800, Luca Barbieri wrote:
gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
-I../../src/gallium/auxiliary -Wall -Wmissing-prototypes
-Wdeclaration-after-statement
On Tue, Jan 12, 2010 at 5:06 AM, José Fonseca jfons...@vmware.com wrote:
I think that there was enough time for everybody interested to voice
their opinion.
I'm going to start committing Luca's patches.
Are both GLX_MESA_gallium and EGL_MESA_gallium required for direct Gallium
access? If
On Sun, Jan 3, 2010 at 3:33 PM, Chia-I Wu olva...@gmail.com wrote:
This patch series brings a new EGL (meta) driver, libegl.a. Like
libegldrm.a living under state_trackers/egl/, the build process uses it
to build various EGL drivers, like egl_i915.so, egl_radeon.so, and etc.
I've only tested
Regardless of my personal preference as expressed, there are some minor issues
in the EGL part of the patch. One is that, it lifts certain restrictions
required by EGL 1.4 by commenting out the code (e.g. in eglSwapBuffers). It
should check if EGL_MESA_gallium is supported and decide what to
Hi all,
I just pushed a new EGL driver (egl_g3d) to master. The new driver is located
at src/gallium/state_trackers/egl_g3d/. When built, it provides .a archives
that are later linked to by src/gallium/winsys/drm/hw/egl_g3d/ to provide the
final EGL drivers loadable by libEGL.
This new driver
On Tue, Jan 12, 2010 at 12:23 PM, Luca Barbieri l...@luca-barbieri.com wrote:
Regardless of my personal preference as expressed, there are some minor
issues
in the EGL part of the patch. One is that, it lifts certain restrictions
required by EGL 1.4 by commenting out the code (e.g. in
Indeed both EGL 1.0 and EGL1.4 contain that language in the specs, but
the Khronos manpage does not.
I think we can safely ignore this.
Applications are very unlikely to rely on eglSwapBuffers failing in
that case, and anyway the specification explicitly prohibits them from
doing so by saying
The hybrid approach is appealing to me, since Radeons are so damn
quirky, but anything not requiring me to set up the dedicated fog
block wins my vote.
~ C.
On Mon, Jan 11, 2010 at 1:50 PM, Jakob Bornecrantz ja...@vmware.com wrote:
On 11 jan 2010, at 21.17, Zack Rusin wrote:
On Monday 11
On Tue, Jan 12, 2010 at 12:39 PM, Luca Barbieri l...@luca-barbieri.com wrote:
Indeed both EGL 1.0 and EGL1.4 contain that language in the specs, but
the Khronos manpage does not.
I think we can safely ignore this.
Applications are very unlikely to rely on eglSwapBuffers failing in
that case,
On Mon, Jan 4, 2010 at 11:12 PM, Luca Barbieri l...@luca-barbieri.com wrote:
It is implemented by adding a new depth/stencil native attachment.
While depth seems to work even without this, due to the Mesa state tracker
creating it itself, this is the way other DRI2 drivers work and might work
On Mon, Jan 4, 2010 at 11:12 PM, Luca Barbieri l...@luca-barbieri.com wrote:
Currently DRI2 always calls texture_from_shared_handle on validate.
This may cause problems due if it is called multiple times on the same
handle, since multiple struct pipe_texture pointing to the same GEM buffer
I left out depth/stencil attachment because I could not think of a good reason
for it. Do you have an example that it is better to ask the display server
for
a depth/stencil buffer than asking the pipe driver?
I'm not sure about this. I mostly added it just because the old driver
stack asks
This looks good. Do you mind re-create this patch without the
dependency on the depth/stencil patch?
OK.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class
On Mon, Jan 4, 2010 at 11:12 PM, Luca Barbieri l...@luca-barbieri.com wrote:
The current code revalidates based on whether width or height have changed.
This is unreliable (it may change two times, with another context having got
the buffers for the intermediate size in the meantime) and
- num_surfaces = (gctx-base.ReadSurface == gctx-base.DrawSurface) ? 1 :
2;
- for (s = 0; s num_surfaces; s++) {
+ for (s = 0; s 2; s++) {
Why this change?
Ignore it.
struct pipe_texture *textures[NUM_NATIVE_ATTACHMENTS];
struct egl_g3d_surface *gsurf;
struct
64 matches
Mail list logo
