On Mon, Nov 28, 2011 at 12:08 AM, Ian Romanick wrote:
> In Mesa, we have four drivers that advertise 4096 uniform components on some
> combinations of hardware: i915, i915g, nouveau, and r300g. By putting
> resource counting in the driver we have the potential for shaders to compile
> and link on
On 11/25/2011 01:13 AM, Dave Airlie wrote:
I'm honestly shocked to read this, Marek. We "deliberately want [your]
driver to be less capable" and "couldn't care about less about anything
except [our] driver"? This is sounding remarkably like a conspiracy
theory, and I really didn't expect that f
- Original Message -
> People are being more honest on
> IRC than here.
I read some of the IRC logs from the past days, and there were several
saddening statements made in there by several people.
But I wonder if IRC does really bring the most honest side out of people, or
simply their
On Fri, Nov 25, 2011 at 1:46 AM, Kenneth Graunke wrote:
>> another, no driver should be crippled ever. I know you couldn't care
>> less about anything except your driver, but there are people who care.
>>
>> Marek
>
> I'm honestly shocked to read this, Marek. We "deliberately want [your]
> driver
Am 25.11.2011 09:15, schrieb Jose Fonseca:
> - Original Message -
>> While Ian and I may take a more idealist stance (favoring strict
>> compliance), and you perhaps a more pragmatic view (get more apps
>> running), we're all working toward the same goal: to build great
>> OpenGL drivers
> I'm honestly shocked to read this, Marek. We "deliberately want [your]
> driver to be less capable" and "couldn't care about less about anything
> except [our] driver"? This is sounding remarkably like a conspiracy
> theory, and I really didn't expect that from you.
I think it takes two to tan
- Original Message -
> While Ian and I may take a more idealist stance (favoring strict
> compliance), and you perhaps a more pragmatic view (get more apps
> running), we're all working toward the same goal: to build great
> OpenGL
> drivers and advance the state of the art for open source
On 11/24/2011 04:47 AM, Marek Olšák wrote:
> On Wed, Nov 23, 2011 at 7:25 PM, Ian Romanick wrote:
>> Let me paraphrase this a little bit in a way that I think concisely captures
>> the intention:
>>
>>"We need to work really hard to make things work on older hardware."
>>
>> I don't think anyo
On 11/24/11 05:25, Dave Airlie wrote:
On UNIX malloc generally hasn't returned NULL since overcommit was
invented, what happens now is some time in the future
you attempt to use a page and your app dies.
s/UNIX/Linux/ - other Unixes still prefer reliability over random
OOM crashes.
--
> By this same logic, malloc should never return NULL because most apps can't
> handle it. Instead it should mmap /dev/null and return a pointer to that.
> That analogy isn't as far off as it may seem: in both cases the underlying
> infrastructure has lied to the application that an operation su
On Wed, Nov 23, 2011 at 7:25 PM, Ian Romanick wrote:
> Let me paraphrase this a little bit in a way that I think concisely captures
> the intention:
>
> "We need to work really hard to make things work on older hardware."
>
> I don't think anyone disagrees with that. However, the solutions you
On Wed, Nov 23, 2011 at 7:27 PM, Ian Romanick wrote:
> On 11/23/2011 05:42 AM, Marek Olšák wrote:
>>
>> On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke
>> wrote:
>>>
>>> So, again, if the interest is in making more apps succeed, we should
>>> start with varying packing. That's useful all around
On 11/23/2011 05:42 AM, Marek Olšák wrote:
On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke wrote:
So, again, if the interest is in making more apps succeed, we should
start with varying packing. That's useful all around, and I doubt
anyone can dispute that it's necessary.
No, that's not the
On 11/22/2011 07:27 PM, Marek Olšák wrote:
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick wrote:
All of this discussion is largely moot. The failure that you're so angry
about was caused by a bug in the check, not by the check itself. That bug
has already been fixed (commit 151867b).
The exac
On 11/23/2011 05:42 AM, Marek Olšák wrote:
> On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke
> wrote:
>> On 11/22/2011 07:27 PM, Marek Olšák wrote:
>>> On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick wrote:
All of this discussion is largely moot. The failure that you're so angry
about
On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke wrote:
> On 11/22/2011 07:27 PM, Marek Olšák wrote:
>> On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick wrote:
>>> All of this discussion is largely moot. The failure that you're so angry
>>> about was caused by a bug in the check, not by the check
On 11/22/2011 07:27 PM, Marek Olšák wrote:
> On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick wrote:
>> All of this discussion is largely moot. The failure that you're so angry
>> about was caused by a bug in the check, not by the check itself. That bug
>> has already been fixed (commit 151867b).
>
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick wrote:
> All of this discussion is largely moot. The failure that you're so angry
> about was caused by a bug in the check, not by the check itself. That bug
> has already been fixed (commit 151867b).
>
> The exact same check was previously performed
On 11/22/2011 07:54 AM, Marek Olšák wrote:
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca wrote:
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface changes:
- e.g., provide to GLSL compiler infinite/huge limits, while adverti
On Tue, Nov 22, 2011 at 6:04 PM, Jose Fonseca wrote:
> - Original Message -
>> On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca
>> wrote:
>> > Marek,
>> >
>> > I think we should take one of two approaches here:
>> > - aim for a short-term workaround, without gallium interface
>> > changes:
>
- Original Message -
> On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca
> wrote:
> > Marek,
> >
> > I think we should take one of two approaches here:
> > - aim for a short-term workaround, without gallium interface
> > changes:
> > - e.g., provide to GLSL compiler infinite/huge limits, whil
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca wrote:
> Marek,
>
> I think we should take one of two approaches here:
> - aim for a short-term workaround, without gallium interface changes:
> - e.g., provide to GLSL compiler infinite/huge limits, while advertising to
> the app the pipe driver one
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface changes:
- e.g., provide to GLSL compiler infinite/huge limits, while advertising to
the app the pipe driver ones
- or detect the wine process and advertise bigger limits in
These are different from hardware limits, because some drivers can correctly
handle higher values than they report in most cases, either due
to driver-specific compiler optimizations, or due to just how the hardware
works internally.
The problem with the linker is that it artifically reduces drive
24 matches
Mail list logo
