usy with work to keep hacking Mesa.
But yeah, in an ideal world, those scripts really should only take a
few seconds, not a few minutes.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev maili
gt; Besides that, the result of the blending equation is no longer clamped
> when dealing
> with FP buffers.
>
> On 11/6/2011 3:08 PM, Corbin Simpson wrote:
> > It's entirely possible that I'm still asleep, but what problem does this
> solve? Are ROPs not defin
It's entirely possible that I'm still asleep, but what problem does this
solve? Are ROPs not defined for FP operands?
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 4:31 AM, "Morgan Armand" wrote:
> ---
> src/gallium/drivers/softpipe/sp_quad_blend.c | 78
> ++-
I can't test this, as I have no big-endian hardware, but it looks very correct.
Reviewed-by: Corbin Simpson
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
the
fog block, and that is not something I'm gonna cry about.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
rsonally don't care.
We're not caring so much about r300c and r600c these days.
This all looks good. I can't really ack the Mesa parts, but the logic
seems sound enough.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
_
ight have trouble running them
manually...
* /src/mapi/mapi/mapi_abi.py has a couple more undefined names in error paths.
What are people's opinions on this? Is it worth spending some time to
clean up some of this code?
~ C.
--
When the facts change, I c
ailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
ctx->Extensions.EXT_texture_compression_s3tc = false;
> } else if (ctx->Mesa_DXTn || r300->options.s3tc_force_enabled) {
> - _mesa_enable_extension(ctx,
> "GL_EXT_texture_compression_s3tc");
> - _mesa_enable_extension(ctx,
ng GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk5X1FIACgkQX1gOwKyEAw9CkwCbB5kmJPe56nolsuQFDwVV2YNX
> uiAAnR2HrythvfujHT1cSiVstanQICRD
> =TKdd
> -END PGP SIGNATURE-
> ___
> mesa-dev mailing list
> mesa-dev@lists.freede
On Wed, Aug 24, 2011 at 3:37 PM, Luc Verhaegen wrote:
> On Wed, Aug 24, 2011 at 03:28:14PM -0700, Corbin Simpson wrote:
>> Ian's list of DRI1 drivers: i810, mach64, mga, r128, savage, sis,
>> tdfx, and unichrome. I have mga, r128, savage, sis, tdfx hardware, but
>> n
On Wed, Aug 24, 2011 at 3:14 PM, Luc Verhaegen wrote:
> On Wed, Aug 24, 2011 at 01:50:25PM -0700, Corbin Simpson wrote:
>> +1. If anybody needs them, they're in git.
>>
>> Sending from a mobile, pardon my terseness. ~ C.
>
> *sigh* Software populism...
>
>
+1. If anybody needs them, they're in git.
Sending from a mobile, pardon my terseness. ~ C.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Have not tested this, but it looks good. I'll apply after testing if Marek
doesn't get there first. Thanks!
Sending from a mobile, pardon my terseness. ~ C.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/lis
Sending from a mobile, pardon my terseness. ~ C.
On Aug 23, 2011 2:42 PM, "Tom Stellard" wrote:
> According to the GLSL spec, the implementor can decide which way to round
> when the fraction is .5. The r300 compiler will round down, so we can use
> CND and save an instruction.
> ---
>
> MLAA shou
ium.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
alan.coopersm...@oracle.com
> Oracle Solaris Platform Engineering: X Window System
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
When the facts change, I change my mi
Unless I missed something, we (the Mesa developers) do not endorse using
S3TC at all, anywhere in the stack, as long as it is patented.
Have you actually talked to any distros?
This is my last post; we aren't getting anywhere.
Sending from a mobile, pardon my terseness. ~ C.
On Aug 8, 2011 1:02
It is not transparent if applications must opt into using it.
Please go ask distributions to pick this up; we aren't going to do it
without the legal issues being cleared up.
Sending from a mobile, pardon my terseness. ~ C.
On Aug 8, 2011 6:12 AM, "Rudolf Polzer" wrote:
> On Mon, Aug 08, 2011 at
Sending from a mobile, pardon my terseness. ~ C.
On Aug 8, 2011 6:12 AM, "Rudolf Polzer" wrote:
> On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote:
>> - Original Message -
>> > The suggestion however is to include a S2TC-like method with Mesa, to
>> > basically
>> > make sure t
an _never_ a gaming Plattform. Not now and not in the future!
>
> Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D
*You* do it then. We already support an external S3TC lib which can be
built separately; go convince distros to pick it up.
~ C.
--
When the facts
drivers. Opinions?
>>
>> Um, don't kill nouveau_vieux, please.
>
> Does the old nouveau driver support some GPUs that the gallium nv50/nvc0
> drivers don't support?
>
> If we want to keep the older driver someone will need to volunteer to update
> the code to support the new driver hooks.
>
> -Brian
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
MyD45ChgwvAm5B2NJPE+G3
> 9aEAnA4eC8eipdDJ2vGJMVFRHfSg6X5v
> =zdUh
> -END PGP SIGNATURE-
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
When the facts change, I c
>>> + memcpy(stored,
>>> + &setup->fs.current,
>>> + sizeof setup->fs.current);
>>> + setup->fs.stored = stored;
>>> +
>>> + /* The scene now references the textures in the rasterization
>>> + * state record. Note that now.
>>> + */
>>> + for (i = 0; i < Elements(setup->fs.current_tex); i++) {
>>> + if (setup->fs.current_tex[i]) {
>>> + if (!lp_scene_add_resource_reference(scene,
>>> + setup->fs.current_tex[i],
>>> + new_scene)) {
>>> + assert(!new_scene);
>>> + return FALSE;
>>> }
>>> }
>>> }
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I have the HW as well, but I see no reason this wouldn't work.
Sending from a mobile, pardon the brevity. ~ C.
On Jun 7, 2011 3:36 PM, "Brian Paul" wrote:
> On Tue, Jun 7, 2011 at 3:56 PM, Nicolas Kaiser wrote:
>> Tested on a Matrox G550 AGP. I noticed that the two piglit
>> VAO tests as well as
dea for a replacement.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
w do you guys feel?
>
>
> - Lauri
> [ shameless ad: candgsoc.host56.com ]
I think that perhaps a good question to consider would be: What other
filters might go into the PP queue? Is there anything besides
anti-aliasing and color correction? (I'm trying to get a discussi
Acked-by: Corbin Simpson
Sending from a mobile, pardon the brevity. ~ C.
On Apr 19, 2011 4:13 PM, "Ian Romanick" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/16/2011 09:45 AM, Corbin Simpson wrote:
>> On Fri, Apr 15, 2011 at 11:10 PM, Ian Rom
ere's
a libxml2 library for Python, lxml, which has the etree API and is
quite nice.
This has been on my TODO list for a year or so, but no real useful
work has been made. Knowing that people actually care about it gives
me some incentive, but I can't promise anything.
~ C
;Awin" wrote:
> 於 2011/4/11 下午 11:23, Corbin Simpson 提到:
>> On Fri, Apr 8, 2011 at 4:17 AM, Awin wrote:
>>> Hi all,
>>> I need to write a OpenGL driver for my company's IC, and base on
gallium,
>>> how do I get start? Is there any document or sample code to
| 12 +-
> 15 files changed, 70 insertions(+), 272 deletions(-)
r300 *did* support FF fog at one point, but it got tossed out because
we couldn't get it to work with fog coordinates. (Well, *I* couldn't
get it to work; I think osiris got it mostly-working-sort-
facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Ah, yeah, I can see how that might be a problem.
Sending from a mobile, pardon the brevity. ~ C.
On Mar 31, 2011 3:41 PM, "Eric Anholt" wrote:
> On Thu, 31 Mar 2011 13:56:56 -0700, Corbin Simpson <
mostawesomed...@gmail.com> wrote:
>> On Thu, Mar 31, 2011 at 1:3
dfx/tdfx_dd.c
> b/src/mesa/drivers/dri/tdfx/tdfx_dd.c
> index d60931a..e981f9a 100644
> --- a/src/mesa/drivers/dri/tdfx/tdfx_dd.c
> +++ b/src/mesa/drivers/dri/tdfx/tdfx_dd.c
> @@ -41,9 +41,6 @@
> #include "main/context.h"
>
>
> -#define DRIVER_DATE "20061113"
> -
> -
> /*
HA1
> + " (" MESA_GIT_SHA1 ")"
> +#endif
> + ,
> ctx->VersionMajor, ctx->VersionMinor);
> }
> }
> --
> 1.7.4
Hmm, wouldn't the output of "git describe" be more useful?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
we need
to worry about immediately, especially if you're targeting VP8, which
is roughly as safe as Theora.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev
et that added to the libvdpau headers.
Also, from a conversation last year with ajax, I do remember that
Theora could definitely be an alternative first target, since it
shares much of its decoding pipeline with h.264 and VP8, and there are
lots of players out there that grok Theora.
~ C.
ompletely understand mapi and all the code handling
> the creation of a context given an API and extensions. Maybe this code is only
> needed for indirect GLX.
>
> Thanks for reading. I understand that this task is very big, but I hope that I
> will be able to make interesting things during this summer and that it will
&
ke such a design decision on my own so I cc'ed
> everybody who committed patches into r600g in the last couple of weeks.
>
> So hey guys what do you think about it?
>
> And to make my own opinion clear:
> I also really prefer tables, but didn't used them in the past
t; Regards
> Jon Severinsson
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Does anybody have any serious objections to merging pipe-video to
master? (Aside from the merge conflicts which I'll try my best to
handle...)
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mes
handling this in glXQuery(Server|Client)String
>>> > because these functions are known to be non-crashy.
>>>
>>> What you're asking for is not possible, because the information you
>>> need
>>> depends on the context which is current. No shortcuts here I'm
>>> afraid. :)
>>
>> We're doing driver blacklists on all platforms, and it tends to be quite
>> easy on other platforms. For example, on Windows, we just read all the
>> driver information from the registry. Couldn't X drivers likewise have some
>> metadata stored on disk, that could be queried via some new API? I proposed
>> GLX because glXQueryServerString already knows about at least the driver
>> vendor. But I don't mind having it exposed elsewhere than in GLX if that
>> makes more sense :)
>>
>> Please take this request seriously: driver blacklists are useful, not
>> limited to Firefox, and certainly not limited to X11. As I say, we blacklist
>> drivers on all platforms, and we'd never have been able to make Firefox 4
>> releasable without blacklisting many Windows drivers. Zhenyao Mo, in CC, is
>> working on similar features in Chromium.
>>
>> Cheers,
>> Benoit
>>
>>>
>>>
>>> --
>>> Earthling Michel Dänzer | http://www.vmware.com
>>> Libre software enthusiast | Debian, X and DRI developer
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
God, I hate flying while sick.
A bigger problem is that there is no good way to divine this info without
actually loading the DRI driver, unless we want to reduce Linux
compatibility to the same level as Win32 by only supporting the system
graphics. OTOH, there are a lot of coincidental circumstan
facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
t.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Argfl. Sending to list as well.
On Wed, Jan 12, 2011 at 11:36 AM, Corbin Simpson
wrote:
> You're using Python 2.5 and this script needs Python 2.6.
>
> Do we want to keep Python 2.5 compat?
>
> ~ C.
>
> On Wed, Jan 12, 2011 at 4:09 AM, Andy Furniss wrote:
>> Ke
Isn't there a --cflags-only-I or something along those lines?
Sending from a mobile, pardon the brevity. ~ C.
On Dec 6, 2010 9:42 AM, "Dan Nicholson" wrote:
> On Mon, Dec 6, 2010 at 9:15 AM, Brian Paul wrote:
>> On 12/05/2010 02:06 AM, Bob Gleitsmann wrote:
>>>
>>> Hello,
>>>
>>> Can someone ex
me something small, i think
>> bugle trace of the engine is maybe easier to use than looking at
>> quake3 source code. For the vs sampler i was surprised too but it's
>> just the fact that q3 changes the vertex buffer a lot and this trigger
>> the vs sampler.
Could
This. I thought that, to trigger uploads, we just had to change the domain
on the buffer.
Sending from a mobile, pardon the brevity. ~ C.
On Nov 11, 2010 3:00 PM, "Jerome Glisse" wrote:
> 2010/11/11 Keith Whitwell :
>> There is still more to do there. Currently r600g treats buffer and
texture u
there are some other approches but non of them can power the intel
>> > hardwares
>> > .
>> >
>> > so i want to disscuss with u about the topic .
>> >
>> > Q: can we use egl and egl_dri2 ?!
Which device is this? Which drivers are you using?
--
Whe
Have you seen Xephyr?
Sending from a mobile, pardon the brevity. ~ C.
On Oct 30, 2010 2:38 AM, "Eugen Friedrich" wrote:
>
> Hello dear mesa developers,
>
> I will use one of the mesa drivers to render some gles1 gles2 and openvg
> applications.
> This applications will run in the virtual machine
cialized nature of
pre-Dx10 GPUs, which are closer to DSPs than anything LLVM normally
targets. In particular, v4f32 is the only kind of register available,
there's not really any way to spill registers, etc. I suspect nvfx and
i915 have similar issues although I'll readily admit to not k
Yes, that particular part of the spec is fairly Poulsboriffic. Does any open
hardware have a scissor enable/disable bit?
Sending from a mobile, pardon the brevity. ~ C.
On Oct 12, 2010 8:47 PM, "Dave Airlie" wrote:
> On Wed, Oct 13, 2010 at 1:07 PM, Dave Airlie wrote:
>> On Wed, Oct 13, 2010 at
ttp://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mail
dn't mind stop pretending supporting them and
> removing them from the tree.
I'll support tdfx, mga, and (when I can get the damn thing POSTing)
r128. I have an sis VGA-USB thingy as well, but that'll take some
hacking and probably can't do 3D, so whatever.
--
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
; Note that we don't get to completely drop histogram.c and convolve.c, as
> we're supposed to have the entrypoints and just emit INVALID_OPERATION
> for the missing extensions even if the ARB_imaging subset isn't present.
>
> If we don't have any strong justificatio
roceed.
I'm going to bring this up again in 2 weeks at XDS. We talked last
year about *doing* something about a few of these patents, including
this particular one, and I want to follow up on that.
~ C.
--
When the facts change, I change my mi
en;
> -
> - sws = r300_drm_winsys_screen_create(fd);
> - if (!sws)
> - return NULL;
> -
> - screen = r300_screen_create(sws);
> - if (!screen)
> - return NULL;
> -
> - screen = debug_screen_wrap(screen);
> -
&g
Gallium, I'd say that we should keep our PIPE_ARCH_ stuff and
try very hard to build on just about everything.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mes
fying things and don't have
any of the SHOULD/MUST/ALLOWED feel of the GL specs, but this might
not be a problem given Gallium's flexibility.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
m
Xorg, at least, should be able to get by with only rects; just gotta write
the code.
Sending from a mobile, pardon the brevity. ~ C.
On Aug 18, 2010 4:55 PM, "Luca Barbieri" wrote:
> Pushed a new version that had no piglit regressions on nv30, softpipe
> and "softpipe without NPOT".
>
> Vega, Xo
We don't blit that often, and we're
still coming out far ahead of where we'd be if we were turning on the
2D engine for every blit.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
d have never owned the relevant hardware.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
NPOT:
~ Are rects *always* non-normalized?
~ Can rects have mipmaps?
~ Can rects have full border repeat and mirror?
If the answer is "yes, no, no", just like actual GL rects, then I support this.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
with nvfx. In r300g
there is a fragment program rewrite to normalize texcoords
unconditionally for r300 and conditionally for r500. This is also how
we fake our NPOT support. Is this kind of rewriting truly impossible
for nvfx, or just time-consumin
d llvmpipe with this error:
>> > tgsi/tgsi_ureg.c:746:ureg_emit_src: Assertion `src.File !=
>> > TGSI_FILE_OUTPUT' failed.
>> >
>> > glsl-orangebook-ch06-bump
>> > glsl-deadcode-varying
>>
>> I guess that hardware can't read back outputs that have been written?
>> Ugh. I'm not sure what to do about that one. Maybe a lowering pass to
>> generate writes to a shadow copy that can be read?
>>
>
> I'm not sure if this is a hardware limitation, or a limitation imposed
> by gallium, maybe someone who knows gallium a little better will be able
> to suggest a solution.
It's not doc'd AFAIR, but TGSI forbids reading from outputs. (I think
i915, r300, and nvfx have this limitation in HW as well, but I can't
say for sure.) I haven't looked at ureg in a while, so I don't know if
there's a utility that can rewrite to temp for these, or if somebody
needs to write one.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Agreed to all of the above. Libraries, even debug builds, should stay silent
by default. We can (and should!) just doc the various env vars instead,
IMHO.
Sending from a mobile, pardon the brevity. ~ C.
On Aug 5, 2010 6:20 PM, "Dave Airlie" wrote:
> On Fri, Aug 6, 2010 at 11:17 AM, Jakob Bornecr
then X2D and from the
> looks of it is supported natively on the nv30. Not plumbed into
> Gallium, no driver implement it.
>
> SFL, STR: Set on True/False, sets dst to either 0 or 1. Not plumbed to
> Gallium, no driver implement them.
T
then X2D and from the
> looks of it is supported natively on the nv30. Not plumbed into
> Gallium, no driver implement it.
>
> SFL, STR: Set on True/False, sets dst to either 0 or 1. Not plumbed to
> Gallium, no driver implement them.
T
Sounds very much like what nv50 needs/does. I sense opportunity. :3
Posting from a mobile, pardon my terseness. ~ C.
On Jul 23, 2010 5:09 PM, "Jerome Glisse" wrote:
On 07/23/2010 07:11 PM, Corbin Simpson wrote:
>
> On Fri, Jul 23, 2010 at
and maybe others) that can be done
in TGSI? Code sharing is fun, and I *really* don't want to see
features fall by the wayside just because the shader compiler needs
work.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
I personally do not care about Gallium breakage as long as the classic
drivers do not break. This is because any Gallium breakage in that case
would necessarily be from Gallium bugs, which I'd rather find sooner than
later.
Posting from a mobile, pardon my terseness. ~ C.
On Jul 21, 2010 6:58 PM,
Normally I wouldn't mind opening a new branch for your patches, but I don't
have commit access to that repo and don't know the code. Zack?
Posting from a mobile, pardon my terseness. ~ C.
On Jul 21, 2010 6:10 PM, "Anthony Waters" wrote:
mesa-dev,
I've done some work with mesa's implementation
er, and
> radeon direct rendering driver
> There's no need to install X-window system.
> if you're interested in this implementation, please contact
> joshua5...@gmail.com
Are you interested in your code being pulled into Mesa?
--
When the facts change, I change
I didn't ack the earlier version of the patch because it had no testers. Has
this been tested?
Posting from a mobile, pardon my terseness. ~ C.
On Jul 18, 2010 8:48 AM, "nobled" wrote:
All the other OS tests for FreeBSD use the form '*freebsd*',
except for this line. This fixes the build on kFr
We cater to MSVC, so sections of code not protected by PIPE_ARCH need to be
C89. Additionally, clarity is valued over tenseness. Elegance is even
better, but there aren't many opportunities for that in this sort of code.
:3
Posting from a mobile, pardon my terseness. ~ C.
On Jul 16, 2010 3:52 PM,
'll wait for a bit in case there are objections to it.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I will fix it when I get off the clock. Should be trivial.
Posting from a mobile, pardon my terseness. ~ C.
On Jul 12, 2010 7:23 AM, "Chris Ball" wrote:
http://tinderbox.x.org/builds/2010-07-12-0013/logs/libGL/#build
r300_render.c: In function 'r300_blitter_draw_rectangle':
r300_render.c:1064:
d value
>> "PIPE_MAX_ATTRIBS" which is already 32.
>
> I think the first actually responds to GL_MAX_VARYING_FLOATS * 4, the other to
> GL_MAX_VERTEX_ATTRIBS. They're both actually safe minimums, GL says that the
> first one needs to be at least 8, the other needs to be at least 16. So our
> values just double the minimum. We probably should have hardware queries for
> both. Also increasing PIPE_MAX_SHADER_INPUTS to 32 sounds good.
Sounds fine. We probably do need caps.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
rk remains, but I have things on my plate for the day.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Jun 24, 2010 at 2:51 AM, Julien Cristau wrote:
> On Thu, Jun 24, 2010 at 01:08:03 -0700, Corbin Simpson wrote:
>> This is only defined on HURD, right? It's not part of the GCC-specific
>> defines?
>>
> Correct.
Committed as fd7de146f6c5989ab3a8459d600c
> +#define PIPE_OS_HURD
> +#define PIPE_OS_UNIX
> +#endif
> +
> #if defined(__sun)
> #define PIPE_OS_SOLARIS
> #define PIPE_OS_UNIX
> --
> 1.5.4.3
This is only defined on HURD, right? It's not part of the GCC-specific defines?
~ C.
--
When t
I'd like somebody
to test first.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I would be happy to start another page for that. We are starting to get too
stuffed on that TGSI page.
Posting from a mobile, pardon my terseness. ~ C.
On Jun 23, 2010 7:25 PM, "Brian Paul" wrote:
On Wed, Jun 23, 2010 at 7:27 PM, Corbin Simpson
wrote:
> Very cool. I l...
I rem
On Wed, Jun 23, 2010 at 4:36 PM, Brian Paul wrote:
> I'll try to answer a few...
>
>
> Corbin Simpson wrote:
>>
>> Yep, it's that time again. These are just things marked in the docs as
>> unknown, so I'm not grinding any axes, just cleaning stuff up.
ble?
Thanks!
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
much else.
Texturing, in particular, appears completely busted.
Please flame me. It's apparently been a great day for flames.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-
I know that it won't work. I'm interested in how we will make it not work. I
will back out some of my doc changes for now, but there are still too many
potholes in the spec, and I do not want to unduly delay in fixing them.
Posting from a mobile, pardon my terseness. ~ C.
On Jun 17, 2010 12:05 PM
it requires drivers to magically Just Work for any shader. GL
(and IIRC D3D) permit shaders to fail for arbitrary reasons; why can't
we do the same?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
control, and primitive groups. My main
concern is splitting things into groups that make it easy to say, "Oh
yes, this hardware supports all of these opcodes." Also, we have a
*lot* of opcodes. Any kind of grouping based on the semantics of the
opcodes is going to be useful.
-
On Wed, Jun 16, 2010 at 7:04 PM, Corbin Simpson
wrote:
> So I've gone ahead and pushed some more doc patches, and I'll probably
> push more later too. One of them is 8b548846, which changes the TGSI
> ISA listing to be grouped by caps. The bits I've guessed at are
the docs, I have an up-to-date one
at http://people.freedesktop.org/~csimpson/gallium-docs .
Oh, and could we get the swizzle info for UV and Z textures settled? I
finally doc'd the R and RG textures...
~ C.
--
When the facts change, I change my mind. What do you do,
s will follow that pattern since for resource handling they are pretty
> much the same as a 2d array texture with array size of 6.
This all seems fine. Drivers for pre-texture-array chipsets can handle
all this by forcing off trilinear filtering, right?
~ C.
--
When the facts change, I change my
rest of the branches could get
merged so they don't bitrot.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailma
o introduce a new object for this?
pipe_stream_feedback or something along those lines?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://list
correct? Do we have a
list of HW that can do it? Is there a trivial way to emulate this on
older HW, or should those chipsets just use Draw?
Thank you very much for the docs. Looks good.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
enting that code block would help
somebody!)
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
a gallium/docs update in
> the same patch?
I'm going to be proactive here, and pull in both this patch and a docs update.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
ms instead of CW/CCW, so this is
fine and will reduce my LOC count. If/when a feature branch emerges,
I'll add a patch to clean up r300g.
I have zero idea how this affects nv50/nvfx.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
1 - 100 of 114 matches
Mail list logo
