Brian Paul pisze:
Michał Król wrote:
Brian Paul pisze:
I think I'd prefer to rename the simple LOOP2/ENDLOOP2 instructions
as LOOP/ENDLOOP and call the above functions LOOP_COUNT/ENDLOOP_COUNT.
I am all for renaming, but just to make them shorter, what about
Brian Paul pisze:
Michał Król wrote:
The LOOP/ENDLOOP opcodes have been loosely defined in gallium and the
de-facto definition had redundant semantics to BGNLOOP2/ENDLOOP2.
This patch documents this pair to closely match GL_NV_fragment_program2
LOOP/ENDLOOP behaviour.
Fixes
diff --git a/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt
b/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt
index a3f4947..5f88cc2 100644
--- a/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt
+++ b/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt
@@ -667,7 +667,16 @@ TGSI
José Fonseca pisze:
On Tue, 2009-07-28 at 08:09 -0700, Michał Król wrote:
José Fonseca pisze:
I found one other problem in the way we use 4 x 8bit color formats:
sometimes we interpret them as arithmetically coded in an unsigned (e.g
src/gallium/auxiliary/util/u_tile.c when reading
Keith Whitwell pisze:
Various opcodes which can be implemented trivially with other TGSI opcodes,
such as matrix multiplication and negation. These were not used by any
state tracker or implemented by any of the drivers.
Looks good. Thanks.
Keith Whitwell pisze:
Remove commented-out opcodes. Remove information about API mappings
to opcodes, but add a reference to tgsi-instruction-set.txt where
that information is better presented.
Looks nice, thanks for that.
It looks like I will have to focus and finish up this
Keith Whitwell pisze:
Remove the need to have a pointer in this struct by just including
the immediate data inline. Having a pointer in the struct introduces
complications like needing to alloc/free the data pointed to, uncertainty
about who owns the data, etc. There doesn't seem to be a
Keith Whitwell pisze:
Remove the need to have a pointer in this struct by just including
the immediate data inline. Having a pointer in the struct introduces
complications like needing to alloc/free the data pointed to, uncertainty
about who owns the data, etc. There doesn't seem to be a
Keith Whitwell pisze:
On Wed, 2009-07-22 at 01:35 -0700, Michał Król wrote:
Keith Whitwell pisze:
Remove the need to have a pointer in this struct by just including
the immediate data inline. Having a pointer in the struct introduces
complications like needing to alloc/free
Keith Whitwell pisze:
/*
* GL_EXT_vertex_shader
*/
#define TGSI_OPCODE_INDEX 22 /* considered for removal */
#define TGSI_OPCODE_NEGATE 23 /* considered for removal */
-#define TGSI_OPCODE_MADDTGSI_OPCODE_MAD
-#define TGSI_OPCODE_FRAC
José Fonseca pisze:
On Thu, 2009-05-07 at 14:57 -0700, Michał Król wrote:
José Fonseca pisze:
Michal,
You scons version is very old. Too old I'm afraid, as recent scons
versions starting to complain about using the deprecated *Options*
symbols. Can you upgrade to scons 1.1 or 1.2
CCing mesa3d-dev.
Michał Król pisze:
Keith Whitwell pisze:
Module: Mesa
Branch: master
Commit: e9fb90ab8889136f788a3d9dc395b0f4d46cfdcc
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=e9fb90ab8889136f788a3d9dc395b0f4d46cfdcc
Author: José Fonseca jfons...@vmware.com
Date
José Fonseca pisze:
Michal,
You scons version is very old. Too old I'm afraid, as recent scons
versions starting to complain about using the deprecated *Options*
symbols. Can you upgrade to scons 1.1 or 1.2?
Thanks. It looks like a simple apt-get upgrade is not sufficent and
won't get
José Fonseca pisze:
On Tue, 2009-04-21 at 02:52 -0700, Michał Król wrote:
Jose Fonseca pisze:
Module: Mesa
Branch: master
Commit: 86ed894e47bae10d158f2b4a02065daa9dbe5194
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=86ed894e47bae10d158f2b4a02065daa9dbe5194
Author
José Fonseca pisze:
On Wed, 2009-04-22 at 01:09 -0700, Michał Król wrote:
José Fonseca pisze:
On Tue, 2009-04-21 at 02:52 -0700, Michał Król wrote:
Jose Fonseca pisze:
Module: Mesa
Branch: master
Commit: 86ed894e47bae10d158f2b4a02065daa9dbe5194
URL
Attached a screenshot from python state tracker's vertex-shader
regress test using X8R8G8B8 rendertarget. Color clear value has been
set to 0x80808080. Run on linux-x86-64-debug, ubuntu, softpipe, X11.
Changing rendertarget format to A8R8G8B8 cures the problem.
--
Pozdrawiam,
Michal Krol
2009/4/3 Brian Paul bri...@vmware.com:
Michał Król wrote:
Attached a screenshot from python state tracker's vertex-shader
regress test using X8R8G8B8 rendertarget. Color clear value has been
set to 0x80808080. Run on linux-x86-64-debug, ubuntu, softpipe, X11.
Changing rendertarget format
Ian Romanick pisze:
Synchronization, memory barriers, atomic operations, etc. are all dark
voodoo. It's one of those things like crypto that really should be left
to the experts. Re-inventing it is almost universally the wrong choice.
Ian,
How would we use libatomic_ops in Windows
Ian Romanick pisze:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michał Król wrote:
Ian Romanick pisze:
Synchronization, memory barriers, atomic operations, etc. are all dark
voodoo. It's one of those things like crypto that really should be left
to the experts. Re-inventing
On Mon, Mar 16, 2009 at 10:41 AM, Thomas Hellstrom
thellst...@vmware.com wrote:
tom fogal wrote:
thellst...@vmware.com writes:
[snip]
+#if (defined(PIPE_CC_GCC) defined(__i386__))
^
This is basically an #ifdef (__GNUC__), I'm guessing?
Yes, however it seems
On Mon, Mar 16, 2009 at 1:59 PM, José Fonseca jfons...@vmware.com wrote:
Shouldn't we use InterlockedIncrement
( http://msdn.microsoft.com/en-us/library/ms683614(VS.85).aspx ) and
friends in Windows instead of assembly? It is implemented as a compiler
intrinsic, so it probably results in more
José Fonseca pisze:
On Mon, 2009-03-16 at 06:09 -0700, Michał Król wrote:
On Mon, Mar 16, 2009 at 1:59 PM, José Fonseca jfons...@vmware.com wrote:
Shouldn't we use InterlockedIncrement
( http://msdn.microsoft.com/en-us/library/ms683614(VS.85).aspx ) and
friends in Windows instead
On 17/05/07, Brian Paul [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Is there an easy way in this parser generator to change the grammar for
the TXP instruction? Basically, I want it to be invalid to use TXP with
the SHADOWARRAY2D target.
Michael would have to answer that. Michael?
I
On 30/04/07, Mikael Eriksson [EMAIL PROTECTED] wrote:
Michał Król skrev:
Hello,
Using git on cygwin I get the following log.
$ git clone git+ssh://[EMAIL PROTECTED]/git/mesa/mesa
Initialized empty Git repository in /home/mjkrol/mesa/.git/
Enter passphrase for key '/home/mjkrol/.ssh
On 13/10/06, Ian Romanick [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Micha? Król wrote:
I cannot successfully link current cvs mesa on Visual C++ 6.0. The
error log follows.
All of those symbols should come from src/mesa/main/dispatch.c. After
having this
On 06/10/06, David Cole [EMAIL PROTECTED] wrote:
First post to mesa lists... hopefully this is the right place for this
question:
The ability to icorporate custom GLSL shaders was recently added to VTK.
However, our tests of this fail when VTK is linked using mesa apparently
because there is
On 21/09/06, Keith Whitwell [EMAIL PROTECTED] wrote:
If anyone knows why these emails are turning out all screwed up and
missing the newlines, please let me know. I'm just using thunderbird on
ubuntu and it's a suprise that such a politically correct distro can't
handle emails that involve
Jeffrey,
I am assuming that you are not going to submit your GLSL preprocessor code
any time soon so I'm going to do it myself. I need it to finish
leftover functionality
at the front-end part of the compiler and I would like it to be complete for
the Mesa 6.6 release.
Thanks.
--
Pozdrawiam,
On 16/09/06, tscmga [EMAIL PROTECTED] wrote:
Hi!
Can Mesa be compiled with hardware acceleration under windows ? Our game
crashes on an Intel on_board graphic card(blue screen ).I want to compiled an
ICD opengl driver ,and find out what causes the error.
I am not 100% sure, but I
On 15/09/06, Michał Król [EMAIL PROTECTED] wrote:
On 15/09/06, Brian Paul [EMAIL PROTECTED] wrote:
Otherwise, can you find a working #ifdef test for Windows?
Change this:
#elif defined(__UNIXOS2__) || defined(__SOL64__)
typedef long int int32_t;
typedef long long int int64_t;
typedef
On 01/08/06, Brian Paul [EMAIL PROTECTED] wrote:
Michal Krol wrote:
CVSROOT: /cvs/mesa
Module name: Mesa
Repository: Mesa/include/GL/
Changes by: [EMAIL PROTECTED] 06/08/01 17:56:27
Log message:
Fix GL_MESA_shader_debug for glut.h.
You should be using GLuint instead
On 02/06/06, Philipp Klaus Krause [EMAIL PROTECTED] wrote:
I'll have a look at it and maybe send patches.
For most drivers fixed-function TcL and vertex programs are done in
software, so I don't think that being a software path is an argument
against vertex shaders there.
Beware, some
On 06/04/06, Brian Paul [EMAIL PROTECTED] wrote:
I think the arbitrary-length bitset type is overkill. We really just
need a 64-bit bitfield for the foreseeable future, right?
These macros in bitset.h are pretty heavy if all the bitsets are
just 64 bits or less.
[...]
The code would be
On 03/04/06, Keith Whitwell [EMAIL PROTECTED] wrote:
The way this has been done before is that you should ensure that the
drivers (especially the DRI drivers) at least compile with your changes,
and you should do your very best to ensure that your changes do the
right thing...
Before you
On 27/02/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Michal Krol wrote:
CVSROOT: /cvs/mesa
Module name: Mesa
Repository: Mesa/windows/VC6/mesa/osmesa/
Changes by: [EMAIL PROTECTED] 06/02/27 14:41:42
Log message:
More GLSL code:
- add x86 code generator;
Michal,
06-02-15, Brian Paul [EMAIL PROTECTED] napisał(a):
I'm going to check in some fixes for warnings in the new code (nested
comments, missing switch/default clauses, etc.).
I'd also like to run the code through 'indent' to make the style match
the rest of Mesa (3-space indentation etc).
I've
2006/2/15, Keith Whitwell [EMAIL PROTECTED]:
Two questions:
Firstly, I'm just looking at the shaders/slang directory now. How much
of the C++ code in there is required for your compiler/assembler? It
seems like from what is said above that your code is independent of the
3dlabs code, but
, it seems.
--
Pozdrawiam,
Michał Król
06-02-12, Keith Whitwell [EMAIL PROTECTED] napisał(a):
Michał Król wrote:
Hello,
I am planning to enable ARB_vertex_shader in Mesa.FWIU, I must add a new
stage in the tnl module.Done, dont see the results.Added conditions in
other stages that are replacedby vertex shaders. Still I see
of to have vertex shader running?
Also, I am not sure with the tnl attrib indexes.
What is the diferrence between VERT_ATTRIB_*,
VERT_RESULT_ and _TNL_ATTRIB_* index flavours?
Are the attrib indices generic and shared
among all vertex-programming models?
--
Pozdrawiam,
Michał Król
and compilers?
Maybe I should just make simple _mesa_* wrappers in imports.h
and if some problems occur, they are fixed in one central place?
--
Pozdrawiam,
Michał Król
NŹHYŢľéXŹ˛'˛ŢuźŚ[§Ü¨ş
ŢŚŘk˘č! WŹ~éŽĺzkśCŁ [EMAIL PROTECTED],şˇâ a{
ĺ,ŕHňÔ4¨mś˙ąéZ˛ë jYwţÇĽrg
of redirecting
the inputs and outputs.
--
Pozdrawiam,
Michał Król
NŹHYŢľéXŹ˛'˛ŢuźŚ[§Ü¨ş
ŢŚŘk˘č! WŹ~éŽĺzkśCŁ [EMAIL PROTECTED],şˇâ a{
ĺ,ŕHňÔ4¨mś˙ąéZ˛ë jYwţÇĽrg
42 matches
Mail list logo
