Bug 94561 - [llvmpipe] PIPE_CAP_VIDEO_MEMORY reports negative value on 32 bits (with 16GB ram)
Summary: [llvmpipe] PIPE_CAP_VIDEO_MEMORY reports negative value on 32 bits (with 16GB...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-15 22:12 UTC by Axel Davy
Modified: 2016-10-20 14:26 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Axel Davy 2016-03-15 22:12:16 UTC
I was investigating why llvmpipe had issues with my recent pc with gallium nine, and found out that the value returned by PIPE_CAP_VIDEO_MEMORY was -403.

I have 16GB of ram, I guess there is some issue in the llvmpipe ram size detection code, that would cause some overflow.
Comment 1 Axel Davy 2016-03-15 22:17:14 UTC
Actually, my test was 32 bits, and I just checked 64 bits and the issue is not there.

I'm going to adjust the name of the bug to indicate this information.
Comment 2 Roland Scheidegger 2016-03-15 23:13:19 UTC
At a very quick glance I would suspect it's os_get_total_physical_memory() which isn't working. This has phys_pages * page_size which are both just long which would overflow. If you use a int64_t for one of them (or long long) it might work (I think the haiku code in there is broken just the same).
Comment 3 Roland Scheidegger 2016-03-15 23:44:02 UTC
FWIW even if the number reported wouldn't overflow, reporting 16GB on 32bit probably isn't really the right answer. If you'd try to use that much memory, it would not quite succeed - maybe llvmpipe should clamp the amount reported on 32bit (I don't know to what though as it's of course all shared with the address space of the process - maybe 2 GB or so).
Comment 4 Axel Davy 2016-03-16 07:08:57 UTC
Returning 2GB looks like a good idea.
Comment 5 Roland Scheidegger 2016-10-20 14:26:48 UTC
Should be fixed with 814ca96d0d8692c5260f595be53c4b9aed0989fa


bug/show.html.tmpl processed on Jan 16, 2017 at 21:44:06.
(provided by the Example extension).