On Sun, Jan 31, 2010 at 1:37 AM, Roland Scheidegger wrote:
>
>
>>7) Is there more information on the dual-source blend modes? I'm not
>>sure if I can do them; might have to bug AMD for the register values.
>>
>> I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not
>> pres
Roland Scheidegger wrote:
> On 01.02.2010 20:23, Brian Paul wrote:
>> Speaking of texture formats and texture sampling, one area of Gallium
>> that's under-specified is what (x,y,z,w) values are returned by TEX
>> instructions when sampling from each of the various texture formats.
>>
>> A while
On 01.02.2010 20:23, Brian Paul wrote:
> Speaking of texture formats and texture sampling, one area of Gallium
> that's under-specified is what (x,y,z,w) values are returned by TEX
> instructions when sampling from each of the various texture formats.
>
> A while back I started a table comparing
This++. I've been scratching my head at some of these; having them specified
would be great.
Posting from a mobile, pardon my terseness. ~ C.
On Feb 1, 2010 11:25 AM, "Brian Paul" wrote:
Speaking of texture formats and texture sampling, one area of Gallium
that's under-specified is what (x,y,z,
Speaking of texture formats and texture sampling, one area of Gallium
that's under-specified is what (x,y,z,w) values are returned by TEX
instructions when sampling from each of the various texture formats.
A while back I started a table comparing OpenGL to D3D:
texture componentsOpenGL
On 01.02.2010 18:37, Roland Scheidegger wrote:
> On 31.01.2010 18:41, Christoph Bumiller wrote:
>
>> On 31.01.2010 01:37, Roland Scheidegger wrote:
>>
>>> Marek Olšák wrote:
>>>
>>>
6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
the fragme
On 31.01.2010 18:41, Christoph Bumiller wrote:
> On 31.01.2010 01:37, Roland Scheidegger wrote:
>> Marek Olšák wrote:
>>
>>> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
>>> the fragment constants reads, "Since Gallium doesn't support
>>> GL_ARB_shadow_ambie
-dev] Grab bag of random questions (whoo)
On Sun, Jan 31, 2010 at 6:21 AM, José Fonseca wrote:
> On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote:
>> 5) How const is const for CSO? e.g. r300_state.c:498, we're not
>> copying pipe_framebuffer_state but just the pointer. I
On Sun, Jan 31, 2010 at 3:21 PM, José Fonseca wrote:
> On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote:
>> Handful of random things bugging me.
>
> Bellow some answers for the things I know enough to comment.
>
>> 1) Team Fortress 2 (and probably other Source games, haven't really
>> check
In r300 we already have had to cross several states to get conformant
rendering in some situations. It's not terribly fun, but it's
necessary. IIRC textures and samplers were the first to be emitted
together.
On Sun, Jan 31, 2010 at 9:41 AM, Christoph Bumiller
wrote:
> On 31.01.2010 01:37, Roland
On Sun, Jan 31, 2010 at 6:21 AM, José Fonseca wrote:
> On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote:
>> 5) How const is const for CSO? e.g. r300_state.c:498, we're not
>> copying pipe_framebuffer_state but just the pointer. It appears to
>> work, but is it actually safe?
>
> The const m
On 31.01.2010 01:37, Roland Scheidegger wrote:
> Marek Olšák wrote:
>
>> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
>> the fragment constants reads, "Since Gallium doesn't support
>> GL_ARB_shadow_ambient, this is always (0,0,0,0), right?"
>>
>> I think th
On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote:
> Handful of random things bugging me.
Bellow some answers for the things I know enough to comment.
> 1) Team Fortress 2 (and probably other Source games, haven't really
> checked) request some fairly large VBOs and indexbufs, beyond what I
Corbin Simpson wrote:
>
>>> Another
>>> comment reads, "Gallium doesn't provide us with any information
>>> regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE,"
>>> above the texture compare modes. I don't really like that section of
>>> code, but it probably can't get cleaner, righ
Marek Olšák wrote:
> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
> the fragment constants reads, "Since Gallium doesn't support
> GL_ARB_shadow_ambient, this is always (0,0,0,0), right?"
>
> I think the extension could be added to Gallium since the r300 compi
On Sat, Jan 30, 2010 at 5:13 AM, Roland Scheidegger wrote:
> On 30.01.2010 13:06, Corbin Simpson wrote:
>> Handful of random things bugging me.
>
>> 2) progs/tests/drawbuffers and progs/tests/drawbuffers2, and possibly
>> others, segfault with both softpipe and the HW driver at
>> sl_pp_version.c:
On Sat, Jan 30, 2010 at 8:24 AM, Marek Olšák wrote:
> Hi Corbin,
>
> On Sat, Jan 30, 2010 at 1:06 PM, Corbin Simpson
> wrote:
>>
>> 5) ... Also, on the topic of framebuffers, is
>> it okay to refuse to render if no MRTs or Z buffer are present?
>
> Do you mean color-only and depth-only rendering?
Hi Corbin,
On Sat, Jan 30, 2010 at 1:06 PM, Corbin Simpson
wrote:
> 5) ... Also, on the topic of framebuffers, is
> it okay to refuse to render if no MRTs or Z buffer are present?
>
Do you mean color-only and depth-only rendering? This is a must. Shadow
mapping heavily relies on depth-only render
On 30.01.2010 13:06, Corbin Simpson wrote:
> Handful of random things bugging me.
> 2) progs/tests/drawbuffers and progs/tests/drawbuffers2, and possibly
> others, segfault with both softpipe and the HW driver at
> sl_pp_version.c:45. I think there's some codegen going on there? At
> any rate, if
Handful of random things bugging me.
1) Team Fortress 2 (and probably other Source games, haven't really
checked) request some fairly large VBOs and indexbufs, beyond what I
can provide. Is there any good example code on how to use
translate/indices to slice up buffers for multiple render runs?
2
20 matches
Mail list logo
