Keith Whitwell wrote:
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch adds the missing NV_vertex_program2 and NV_vertex_program3
instructions to the various internal tables. It does not add support
for them to the parser nor does it add support for them
was a
little faster, but still not nearly fast enough. is there a faster way?
(dma?) Or is there some limitation due to how the driver is written? I
noticed the open-source radeon driver was just as slow. The closed source
ati drivers were several orders of magnitude faster.
Keith Whitwell did some work
Keith Whitwell wrote:
1) I think this is the first solution for memory management that I can
imagine implementing. Also it's one which gives reasonable
performance when data is being evicted from the GART.
This sounds a little trite reading it back.
This a function of two things
Benjamin Herrenschmidt wrote:
On Sun, 2006-01-08 at 18:17 +, Keith Whitwell wrote:
In the past there has been talk about mapping user memory into the GTT
aperture as a mechanism to avoid copy-based uploading. What I'm
proposing is that this type of mapping becomes the only or at least
Adam Jackson wrote:
On Thursday 19 January 2006 13:43, Ian Romanick wrote:
Adam Jackson wrote:
Log message:
Avoid a crash when the user has enabled glVertex{,Attrib}Pointer but
hasn't filled in a valid pointer for that attribute or vertex array.
NAK. Any app that is hitting a crash
You should only be able to get into that stacktrace if you have set
MESA_EXPERIMENTAL in the environment. Is that true? What happens if
you unset it?
Keith
Donnie Berkholz wrote:
I recently updated Mesa from 6.4.1 to CVS HEAD, and discovered that the
UT2003 demo [1] didn't work anymore.
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 black screen.
Is your code being run? Try running gdb,
Michał Król wrote:
Hello,
I have enabled GLSL in Mesa, although it is not complete.Some programming
candies are not supported, butthis will change soon as I have now a plenty of
free time.
I have commited a demo, arbfslight, which is a GLSL versionof Brian's
arbfplight.c. It contains some
Stephane Marchesin wrote:
Hi,
What's the correct way of declaring inline functions inside a dri driver
? I see 4 ways to do that in existing code : __inline, __inline__,
inline and INLINE. So, which one is the right one ? Or maybe there is a
slight difference between those ?
Good question.
David Reveman wrote:
On Mon, 2006-03-13 at 14:04 -0800, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Reveman wrote:
On Mon, 2006-03-13 at 10:45 -0800, Ian Romanick wrote:
David Reveman wrote:
This patch adds direct and indirect rendering support for
Micha? Król wrote:
Hello,
Tomorrow I am going to make changes
that will affect drivers too.
The _TNL_ATTRIB_* 32-bit space has been
exhausted after adding 16 new vertex shader
attributes that cannot alias conventional ones.
Doing so, the TNLcontext::render_inputs will
be renamed to
Micha? Król wrote:
Hello,
I wasn't able to test it if it compiles on my machine,
so drivers/dri tree may be broken.
Please, somebody test it and apply.
If there are compile errors, there might
be #include tnl/t_context.h missing.
If there are heavier errors, please post
compiler log, I will
A while ago, Mesa started using the full width of variables like
Stencil.WriteMask, etc. to store values, while previously it had
restricted itself to only the low 8 bits.
Unfortunately there are many cases in the dri drivers that assumed the
old behaviour, and did things like comparisons:
Ian Romanick wrote:
It better doing and making no assumption on glPointSize as you might
once and again find other implementation with min max value = 1.
Better for whom???
The egg on our face is that, AFAIK, Mesa based drivers are the *only*
drivers that don't support this
Martijn van Oosterhout wrote:
On 7/1/06, Michel Dänzer [EMAIL PROTECTED] wrote:
Actually, this points out the possible source of the remaining problems:
x2 and y2 also need clamping to fbWidth-1 and fbHeight-1, respectively,
and if (x1 = x2 || y1 = y2), the cliprect is empty and should be
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here is my first pass at run-time dispatch generation code for x86-64.
It's not particularly well tested yet (or I'd just commit it now). I
wrote a test program that called fill_in_entrypoint with a few different
parameter
Hanno Böck wrote:
Am Donnerstag, 31. August 2006 20:23 schrieb Hanno Böck:
I'll try to figure out which cvs-change caused this, I'll probably give you
further info within the next hours, however I'd suggest to probably not put
out the 6.5.1-release till this is resolved.
After a while of
Roland Scheidegger wrote:
RCS file: /cvs/mesa/Mesa/src/mesa/main/texstore.c,v
revision 1.121
date: 2006-09-20 14:28:42 +; author: keithw; state: Exp;
lines: +19 -12
Fix _mesa_swizzle_ubyte_image() to deal with RGBA-RGB-RGBA
conversions, ensuring that the final A value is 0xff
Roland Scheidegger wrote:
RCS file: /cvs/mesa/Mesa/src/mesa/main/texstore.c,v
revision 1.121
date: 2006-09-20 14:28:42 +; author: keithw; state: Exp;
lines: +19 -12
Fix _mesa_swizzle_ubyte_image() to deal with RGBA-RGB-RGBA
conversions, ensuring that the final A value is
Michel Dänzer wrote:
On Wed, 2006-09-20 at 18:56 +, Keith Whitwell wrote:
CVSROOT: /cvs/mesa
Module name: Mesa
Repository: Mesa/src/mesa/main/
Changes by: [EMAIL PROTECTED] 06/09/20 18:56:19
Log message:
Support both big and little endian, more source types and more
Michel Dänzer wrote:
On Wed, 2006-09-20 at 18:56 +, Keith Whitwell wrote:
CVSROOT: /cvs/mesa
Module name: Mesa
Repository: Mesa/src/mesa/main/
Changes by: [EMAIL PROTECTED] 06/09/20 18:56:19
Log message:
Support both big and little endian, more source types and more
Michel Dänzer wrote:
On Thu, 2006-09-21 at 12:58 +0100, Keith Whitwell wrote: Michel Dänzer wrote: On Wed, 2006-09-20 at 18:56 +, Keith Whitwell wrote:
Log message:Support both big and little endian, more source types and moredestination formats
through the swizzle path
Michel Dänzer wrote:
On Thu, 2006-09-21 at 12:58 +0100, Keith Whitwell wrote: Michel Dänzer
wrote: On Wed, 2006-09-20 at 18:56 +, Keith Whitwell wrote:
Log message:Support both big and little endian, more source types and
moredestination formats through the swizzle path
Keith Whitwell wrote:
Michel Dänzer wrote: On Thu, 2006-09-21 at 12:58 +0100, Keith Whitwell
wrote: Michel Dänzer wrote: On Wed, 2006-09-20 at 18:56 +, Keith
Whitwell wrote: Log message:Support both big and little
endian, more source types and moredestination formats through
Micha? Król wrote:
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
Michel � wrote:
On Thu, 2006-09-21 at 13:55 +0100, Keith Whitwell wrote:
Michel Dänzer wrote:
On Thu, 2006-09-21 at 12:58 +0100, Keith Whitwell wrote: Michel Dänzer wrote: On Wed, 2006-09-20 at 18:56 +, Keith Whitwell wrote:
Log message:Support both big and little endian, more
Michel Dänzer wrote:
On Thu, 2006-09-21 at 16:15 +0100, Keith Whitwell wrote:
OK, so as you suggested, it looks like type_endian_mapping should be
identity for this case, as in the attached diff -- what happens next?
from 1908/GL_RGBA to 1907/GL_RGB map 0 1 2 4 4 5
from 1907/GL_RGB to 1908
Brian Paul wrote:
Keith Whitwell wrote:
Michel Dänzer wrote:
On Thu, 2006-09-21 at 16:29 +0100, Keith Whitwell wrote: OK, that's
kooky. I guess I haven't got a handle on the problem yet for bigEndian,
it may be that there's another conversion needed on the back end.
It could also
Michel Dänzer wrote:
On Thu, 2006-09-21 at 19:28 +0100, Keith Whitwell wrote:
Michel Dänzer wrote:
On Thu, 2006-09-21 at 16:29 +0100, Keith Whitwell wrote: OK, that's
kooky. I guess I haven't got a handle on the problem yet for bigEndian,
it may be that there's another conversion needed
Michel Dänzer wrote:
- if (dstFormat == _mesa_texformat_argb) {
+ if (!littleEndian || dstFormat == _mesa_texformat_argb) {
In cases like this, wouldn't you want the exclusive or of the two
values, ie
((littleEndian dstFormat == _mesa_texformat_argb) ||
Michel Dänzer wrote:
On Fri, 2006-09-22 at 10:58 +0100, Keith Whitwell wrote:
Michel Dänzer wrote:
On Fri, 2006-09-22 at 10:41 +0100, Keith Whitwell wrote:
Michel Dänzer wrote:
- if (dstFormat == _mesa_texformat_argb) {
+ if (!littleEndian || dstFormat
Michel Dänzer wrote:
On Fri, 2006-09-22 at 11:14 +0100, Keith Whitwell wrote:
Maybe enable for the paths that are well understood and tested, but
where it is still behaving contrary to expectations, leave it disabled.
I'd say it is behaving as expected in the software mesa cases
Brian Paul wrote:
Michel Dänzer wrote:
Keith wrote:
I think from Brian's description of the meaning of the
texture format struct naming, a driver that wanted a
different component order in a packed field would have
to specify a different texformat struct - ie the
component ordering for a
Brian Paul wrote:
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It looks like adding support for GLX_SGI_make_current_read is almost as
easy as just enabling the extension thanks to Mesa's internal
framebuffer object changes. Thanks Brian!
However, there is one thing
Roland Scheidegger wrote:
CVSROOT: /cvs/mesa
Module name: Mesa
Repository: Mesa/src/mesa/drivers/dri/radeon/
Changes by: [EMAIL PROTECTED] 06/10/15 21:47:56
Log message:
fix handling of textures with a base internal format that does not have all
four rgba values set for
Andrew Barr wrote:
Using these OpenGL compositing managers on recent Mesa CVS causes the windows
to be outlined by thick black bars. It looks as though they are supposed to
be shadows but are not being alpha blended. This has been personally observed
by me on a G965 and an 855GM Intel GPU.
Brian Paul wrote:
CVSROOT: /cvs/mesa
Module name: Mesa
Repository: Mesa/src/mesa/tnl/
Changes by: [EMAIL PROTECTED] 06/10/18 17:36:57
Log message:
Fix a dangerous use of ASSERT in an else-clause not enclosed in braces.
We've been lucky if this hasn't been causing line
I've just created a branch to house some experiments to do with
integrating the i965 driver a little better with core Mesa.
In particular, the i965 driver houses a cloned version of the vertex
building code from the tnl module. My particular plan is to eliminate
both copies of this code and
Roland Scheidegger wrote:
Currently, fog in vertex programs doesn't work when using per-vertex
fog, since the fog factor computation is not done in the tnl pipeline. I
think the most elegant solution to this problem would be to just move
the (slightly changed) fog pipeline stage to after the
Are there any Mesa platforms (that we care about) that don't provide a
GLuint64EXT? It would be helpful to me to have a 64bit integer type
available, though of course I can manage without.
It seems that every platform has a gcc target at least, which would
imply 'long long' support.
Keith
Brian Paul wrote:
Keith Whitwell wrote:
Are there any Mesa platforms (that we care about) that don't provide a
GLuint64EXT? It would be helpful to me to have a 64bit integer type
available, though of course I can manage without.
It seems that every platform has a gcc target at least
We've just merged the texmem-0-3-branch code. This has been a major
project, probably much bigger than we realized when we started on it.
The fundamental technology underpinning the changes is Thomas
Hellstrom's new TTM memory manager which dynamically maps buffers into
and out of the GART
OK, the first round of work on the VBO branch seems to have gone quite
smoothly. It'd be great if a couple of the key r200/r300 people could
check the branch out and verify whether I've broken those drivers or not.
It'd be particularly interesting to see if someone (Aapo?) can take a
look at
Keith Whitwell wrote:
OK, the first round of work on the VBO branch seems to have gone quite
smoothly. It'd be great if a couple of the key r200/r300 people could
check the branch out and verify whether I've broken those drivers or not.
It'd be particularly interesting to see if someone
Jerome Glisse wrote:
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
OK, the first round of work on the VBO branch seems to have gone quite
smoothly. It'd be great if a couple of the key r200/r300 people could
check the branch out and verify whether I've broken
Dave Airlie wrote:
Now that the merge is done I propose:
1. Finish up the glClear() parameter changes I started a week or two ago.
2. Get people to test the i915tex driver.
I setup a machine at home running my gaming machine app which is a very
heavy texture user, it uses compressed,
Jerome Glisse wrote:
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
OK, the first round of work on the VBO branch seems to have gone
quite
smoothly. It'd be great if a couple of the key
Jerome Glisse wrote:
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
OK, the first round of work on the VBO branch seems to have gone quite
smoothly. It'd be great if a couple of the key r200
Jerome Glisse wrote:
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
OK, the first round of work on the VBO branch
Dave Airlie wrote:
Sorry for the delay. I have to admit I find compressed textures really
confusing for some reason, and basically do what I can to avoid them...
Have you got an application or Mesa demo which you can point at doing
the wrong thing? It'd be easier to work from something like
Roland Scheidegger wrote:
Roland Scheidegger wrote:
Below's the backtrace from Mesa's cva test, which uses DrawElements.
The same thing also happens with software mesa (once you get past
cva's gl version check...).
Ah. Looks like vbo_exec_DrawRangeElements needs to call bind_arrays()?
With
Roland Scheidegger wrote:
Roland Scheidegger wrote:
Below's the backtrace from Mesa's cva test, which uses DrawElements.
The same thing also happens with software mesa (once you get past
cva's gl version check...).
Ah. Looks like vbo_exec_DrawRangeElements needs to call bind_arrays()?
With
Jerome Glisse wrote:
On 11/18/06, Aapo Tahkola [EMAIL PROTECTED] wrote:
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
OK, the first round of work on the VBO branch seems to have gone
quite
Eric, Gary,
This code looks like a re-implementation of the existing
do_texture_copypixels() from the i915 driver. It seems to do a similiar but
not-quite-the-same operation but by a divergent set of code changes.
Is there any reason not to have just ported the changes over from i915tex?
be something going on, so maybe not.
Keith
- Original Message
From: Gary Wong [EMAIL PROTECTED]
To: Keith Whitwell [EMAIL PROTECTED]
Cc: mesa3d-dev@lists.sourceforge.net; [EMAIL PROTECTED]
Sent: Wednesday, November 29, 2006 1:57:11 PM
Subject: Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk
Gary -- I know how you feel... It's an obvious next step, the difficulty is
fitting it in with everything else.
Keith
- Original Message
From: Gary Wong [EMAIL PROTECTED]
To: Keith Whitwell [EMAIL PROTECTED]
Cc: mesa3d-dev@lists.sourceforge.net
Sent: Wednesday, November 29, 2006 6:04
(Reply to all)
- Forwarded Message
From: Keith Whitwell [EMAIL PROTECTED]
To: Xiang, Haihao [EMAIL PROTECTED]
Sent: Thursday, December 7, 2006 9:25:57 AM
Subject: Re: [Mesa3d-dev] Two patches for i965 driver
Haihao,
Your analysis is correct - the patch should go in unchanged.
I'm
I wonder if the commit scripts can't be hacked up to elide the patch
information when it exceeds a certain threshold in size.
Also - a pet hate is that in multiple commit git messages, you have to scroll
through the email searching for the description of each separate commit. It'd
be nice
Brian Paul wrote:
Oliver McFadden wrote:
Hi,
I believe I've found a few bugs caused by the unaliasing of generic vertex
attributes (commit 095c6699f449ed4803f23e844cc0227743a9c3e1), specifically in
the file src/mesa/shader/arbprogparse.c:
case VERTEX_ATTRIB_GENERIC:
{
Michel Dänzer wrote:
On Mon, 2007-01-15 at 12:42 -0800, Eric Anholt wrote:
If you know what branch was merged before the git conversion that's
causing you your pain, one way forward might be to do:
git-checkout master
git pull -s ours . that-merged-branch
git pull . my-branch
It's more
Hanno Böck wrote:
Am Dienstag, 16. Januar 2007 19:38 schrieb Keith Whitwell:
Could anyone who had issues with the old CVS vbo branch please try again
with the new vbo-0.2 branch?
Would like to, but could you write some short howto?
Questions I'd have:
* Which cards benefit from it atm
Roland Scheidegger wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
Roland Scheidegger wrote:
Didn't have time to look into this yet, but just retesting all the apps
I had trouble with vbo_0_1_branch some months ago showed that the quake3
intro screen is now fixed (with r200
I'd like to consider merging the vbo branch in the next few days. If
you want to do some testing of it before the merge, I'd suggest doing so
soon getting me feedback/bug reports.
Keith
-
Using Tomcat but need to do
Roland Scheidegger wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
Roland Scheidegger wrote:
Didn't have time to look into this yet, but just retesting all the apps
I had trouble with vbo_0_1_branch some months ago showed that the quake3
intro screen is now fixed (with r200
Nan hai Zou wrote:
src/mesa/drivers/dri/i915/i915_state.c | 10 ++
Please note that the old i915 driver is deprecated in favour of i915tex,
and will be removed at some point. Fixes should probably go into both,
but if they only go into one, it should be i915tex.
Keith
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
I'm getting close to merging the glsl-compiler-1 branch into the Mesa
trunk. I did a trunk-to-branch merge today. I need to at least make
sure the DRI drivers build (they don't right now).
Excellent!
Xiang, Haihao wrote:
Hi, all
With some gdb analysis, I noticed some software render
functions are no longer installed after merging with vbo-0.2 in i965 and
this will break some 3D apps. I worked out a fix for it. Could anyone
take a look? (See
Xiang, Haihao wrote:
-Original Message-
From: Keith Whitwell [mailto:[EMAIL PROTECTED]
Sent: 2007?3?2? 17:32
To: Xiang, Haihao
Cc: Mesa3d-dev@lists.sourceforge.net
Subject: Re: [Mesa3d-dev] Fallback to software in i965 triggers segment fault
after merging with vbo-0.2
Xiang
Brian Paul wrote:
src/mesa/drivers/x11/xm_api.c|6 ++
src/mesa/drivers/x11/xm_buffer.c | 12
src/mesa/main/fbobject.c |2 --
src/mesa/main/framebuffer.c |7 +++
4 files changed, 21 insertions(+), 6 deletions(-)
New commits:
diff-tree
Keith Whitwell wrote:
Brian Paul wrote:
src/mesa/drivers/x11/xm_api.c|6 ++
src/mesa/drivers/x11/xm_buffer.c | 12
src/mesa/main/fbobject.c |2 --
src/mesa/main/framebuffer.c |7 +++
4 files changed, 21 insertions(+), 6 deletions(-)
New
Is there a git checkin script guru in the house?
There's two real issues with the current git commit messages that I'd
really love to see resolved.
Firstly - when ever anyone makes a non-trivial change (or series of
changes), the git commit message generated is so big that it is
unsuitable to
malc wrote:
Hello,
Perhaps someone could explain why there's a call to sched_yield in
r200CopyBuffer?
When viewing TV or playing some resource hungry movie and simulataneously
doing something else in the background i noticed that my method of putting
YUV data to the screen via GL starts
[EMAIL PROTECTED]
Cc: Keith Whitwell [EMAIL PROTECTED]; mesa3d-dev@lists.sourceforge.net
Sent: Wednesday, March 21, 2007 11:53:29 AM
Subject: Re: [Mesa3d-dev] SwapBuffers and schedulling
malc wrote:
On Wed, 21 Mar 2007, Keith Whitwell wrote:
malc wrote:
Hello,
[..snip..]
The yield
Sounds good to me.
Keith
- Original Message
From: Brian Paul [EMAIL PROTECTED]
To: MESA-Devel mesa3d-dev@lists.sourceforge.net
Sent: Wednesday, March 21, 2007 6:08:26 PM
Subject: Re: [Mesa3d-dev] git commit messages
Donnie Berkholz wrote:
Keith Whitwell wrote:
It's a lot to ask
This is not the first time someone has tried to remove that field. Dont! Just
because it isn't used in core mesa doesn't mean the drivers don't rely on it...
Yes, it's ugly, but it is currently neccessary.
Keith
- Original Message
From: Brian Paul [EMAIL PROTECTED]
To: Nicolai
Eric Anholt wrote:
On Fri, 2007-03-30 at 23:05 +0100, Keith Whitwell wrote:
Eric Anholt wrote:
src/mesa/drivers/dri/i965/intel_context.c |3 +++
src/mesa/drivers/dri/i965/intel_context.h |1 +
2 files changed, 4 insertions(+)
Boy, that's a long commit message, but most of the stuff
Brian Paul wrote:
src/mesa/main/context.c|8
src/mesa/shader/slang/slang_emit.c | 23 +++
src/mesa/tnl/t_vb_arbprogram.c |5 -
3 files changed, 27 insertions(+), 9 deletions(-)
New commits:
diff-tree
Brian Paul wrote:
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
I'd like to release Mesa 6.5.3 pretty soon (to be considered a
development release) then follow up
Brian,
Do you have any idea why it is necessary to short-circuit these tests?
If there is a problem with relying on the new_state flag for
notification on those statechanges, we've got much more serious
problems. It would be good to get to a root cause for this rather than
disabling these
Oliver McFadden wrote:
src/mesa/drivers/dri/r300/Makefile |2 -
src/mesa/drivers/dri/r300/r300_context.c |2 -
src/mesa/drivers/dri/r300/r300_emit.c| 49
---
src/mesa/drivers/dri/r300/r300_emit.h|8 +
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
About a year and a half ago, I posted a spec to the OpenGL extension
registry for what is now known as array textures. At the time, this was
the basis of a paper that I was writing for SIGGRAPH 2006. Unbeknown to
me, this
Michel Dänzer wrote:
On Thu, 2007-05-17 at 15:12 +0800, Wang Zhenyu wrote:
I've encountered problem when debugging rotation with DRI enabled.
I965 dri driver only checks sarea-ctxOwner when holding heavy lock,
but I think we also need to check it in light lock case, as ctxOwner
is used by
Micha? Król wrote:
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
Brian Paul wrote:
Keith Whitwell wrote:
Micha? Król wrote:
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
Zack Rusin wrote:
On Thursday 17 May 2007 05:36:45 pm Keith Whitwell wrote:
I think the Zack/Roberto LLVM tree has done just this. Unfortunately
for this immediate problem, they target a whole new intermediate
representation.
Zack, what tools did you use for the front-end/parser? I've been
I'm interested in understanding the extent of the assumptions which llvm
makes about the types of hardware it is capable of targeting.
In particular, I'm investigating a proposal by Zack Rusin to use llvm as
the shader compilation engine within Mesa, targeting GPU backends.
I'm aware of the
Brian Paul wrote:
Zack Rusin wrote:
On Thursday 17 May 2007 05:36:45 pm Keith Whitwell wrote:
I think the Zack/Roberto LLVM tree has done just this. Unfortunately
for this immediate problem, they target a whole new intermediate
representation.
Zack, what tools did you use for the front-end
Chris Lattner wrote:
On Fri, 18 May 2007, Keith Whitwell wrote:
I'm interested in understanding the extent of the assumptions which llvm
makes about the types of hardware it is capable of targeting.
Different pieces of the compiler make different assumptions. In
particular, the code
Origin again? It seems very easy to do.
Keith
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Zack Rusin wrote:
On Friday 18 May 2007 05:07:08 am Keith Whitwell wrote:
Sounds good.
I've been thinking about LLVM and Mesa a little bit the last few days.
If it can be made to work, it seems like a good way to go. There are a
couple of practical issues that should be taken into account
Brian Paul wrote:
Zack Rusin wrote:
On Friday 18 May 2007 05:07:08 am Keith Whitwell wrote:
Sounds good.
I've been thinking about LLVM and Mesa a little bit the last few days.
If it can be made to work, it seems like a good way to go. There are a
couple of practical issues that should
Chris Lattner wrote:
On Sat, 19 May 2007, Keith Whitwell wrote:
It seems that LLVA and by extension Vector-LLVA assumes that looping and
branching control flow can be expressed in terms of a simple br branch
operation.
LLVA is not a part of LLVM, so I won't answer for it.
OK, I guess I
OK,
I've pushed the beginnnings of the driver model / software rasterizer /
shader infrastructure rework.
The code is split into:
softpipe/state_tracker:
- device independent mesa state sanitizer.
- intended to maintain a set of constant state objects,
Brian,
Took a quick look at the sketched out sampler state, with a couple of
comments.
It's always worth taking a look at the i965/brw_structs.h file as this
gives a clear idea of what hardware state structs look like this is
more or less the style of interface I'm keen to target with
Keith Whitwell wrote:
Brian,
Took a quick look at the sketched out sampler state, with a couple of
comments.
Meant to say looks good, with a couple of comments...
The other comment is that you've got several bit field and float fields
intermingled - it's probably necessary to group
Wang Zhenyu wrote:
Attach patches for adding support of these chips.
Can I apply checkin permission to mesa?
Yes - I think you need to submit a bug report to fd.o asking for git
access, or something along those lines.
The patches look good though.
Keith
Brian Paul wrote:
Keith Whitwell wrote:
Keith Whitwell wrote:
Brian,
Took a quick look at the sketched out sampler state, with a couple of
comments.
Meant to say looks good, with a couple of comments...
The other comment is that you've got several bit field and float fields
Brian,
I'm wondering if there isn't some way to rationalize the multiple
sp_quad stages that each individually readback the current framebuffer
values for use within the stage.
At the moment that looks like:
- blend
- colormask
- final write (masked case)
It seems like
Brian,
I'm wondering if there isn't some way to rationalize the multiple
sp_quad stages that each individually readback the current framebuffer
values for use within the stage.
At the moment that looks like:
- blend
- colormask
- final write (masked case)
It seems like
I wonder if we shouldn't just implement GL_FRONT_AND_BACK through the
same mechanism as multiple render targets??
I'd be a lot happier having just one way to achieve these two fairly
similar effects.
And, typically, hardware may have MRT support but almost certainly
doesn't have
1 - 100 of 479 matches
Mail list logo
