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,
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
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
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
_
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
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
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
> ++-
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
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
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
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
>>> + 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
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
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
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
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
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
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
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
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
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
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
+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
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...
>
>
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
ng GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk5X1FIACgkQX1gOwKyEAw9CkwCbB5kmJPe56nolsuQFDwVV2YNX
> uiAAnR2HrythvfujHT1cSiVstanQICRD
> =TKdd
> -END PGP SIGNATURE-
> ___
> mesa-dev mailing list
> mesa-dev@lists.freede
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
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
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
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
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
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
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
; 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
Corbin Simpson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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.
--
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
&
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.
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
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
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"
> -
> -
> /*
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
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
| 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-
;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
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
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
If you believe that it is easier to implement features on your hardware by
straying from Gallium or Mesa interfaces, you are welcome to do so.
Posting from a mobile, pardon my terseness. ~ C.
On Apr 11, 2010 6:53 PM, "Luca Barbieri" wrote:
> include this deprecated GL feature
While it is depre
gonistic, but Gallium is supposed to be a
"common interface" and "abstraction," so features specific to one
chipset are invariably going to fall by the wayside. For example, r500
Radeons (and maybe r400?) have a filter4 kernel that they could use to
implement e.g. fast La
lacked
programmable swizzles and routing tables for linking shaders,
requiring shader compilers to be augmented with linking and selection
code to properly match outputs and inputs across shaders. Was a
Gallium-level module implemented to perform the desired shader
modifications, or was it done privately in the driver? Was the Gallium
API changed as a result of the discussion?
There's a balance here between common features and common needs.
--
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
up drivers in less time,
with less code," appears to be achieved. We are almost reaching r300c
performance levels, and beating it handily in certain benchmarks, so
it is possible to write good new drivers on this codebase.
~ C.
--
When the facts change, I change my mind.
because it makes me feel a bit
better about my failed attempt to test WebGL a few weeks ago. :3
~ 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
NAK as above and from IRC convo.
Posting from a mobile, pardon my terseness. ~ C.
On Apr 22, 2010 2:20 PM, "Alex Deucher" wrote:
On Thu, Apr 22, 2010 at 4:40 PM, Tormod Volden
wrote:
> From: Tormod Volden...
gallium and classic with kms get this number form the drm and can't
program the releva
I'll apply this when I get home. Looks good.
~ C.
Reviewed-by: Corbin Simpson
On Mon, Apr 26, 2010 at 10:18 AM, Matt Turner wrote:
> Signed-off-by: Matt Turner
> ---
> src/gallium/drivers/r300/r300_emit.c | 14 +++---
> 1 files changed, 3 insertions(+), 11 dele
tions as they come up. Thanks again
> to everyone. I can't wait to get started.
Welcome (again) to the project!
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
mesa-dev mailing list
mesa-dev
Why do we need any caps for this? Unless I read the spec wrong, this is a
mere SWZ following the affected texture lookup, in the worst case.
Posting from a mobile, pardon my terseness. ~ C.
On Apr 27, 2010 9:29 AM, "José Fonseca" wrote:
On Tue, 2010-04-27 at 08:59 -0700, Roland Scheidegger wrot
ertain that Gallium's gonna need to absorb
plenty more changes before it's ever included in a (non-Gentoo)
distro, right? So why can't we talk about them all at once?
Of course, feel free to disregard me. I maintain drivers that nobody
appears to care about besides Phoronix, and my n
are not supported. GL_*SHORT is
> supported only for 2- and 4-component vertex attributes, and GL_*BYTE
> only for 4-component attributes. All individual vertex attribute fetches
> must be DWORD-aligned.
Yeah, one of the things I wanted to do was provide a shadow-VBO setup,
an
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_supported(number, 2, b, g):
print "%s is an acceptable FBO colorbuf" % name
Comments, criticisms, flames, etc. welcome.
~ C.
(Just watch, Phoronix; next time, it'll be a tracker for Flash
rendering. I'll call it, "Galoshes!")
--
When the facts change
er than Eric's, but it's more or less
invalid now. It could build Gallium DRI drivers though.
~ 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
___
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
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
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
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
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
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
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,
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
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.
-
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
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
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-
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
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.
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
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
> +#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
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
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
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
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:
'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
1 - 100 of 114 matches
Mail list logo
